{
  "affected": [
    {
      "ecosystem_specific": {
        "aarch64": [
          "bpftool-6.6.0-145.3.17.150.oe2403sp3.aarch64.rpm",
          "bpftool-debuginfo-6.6.0-145.3.17.150.oe2403sp3.aarch64.rpm",
          "kernel-6.6.0-145.3.17.150.oe2403sp3.aarch64.rpm",
          "kernel-debuginfo-6.6.0-145.3.17.150.oe2403sp3.aarch64.rpm",
          "kernel-debugsource-6.6.0-145.3.17.150.oe2403sp3.aarch64.rpm",
          "kernel-devel-6.6.0-145.3.17.150.oe2403sp3.aarch64.rpm",
          "kernel-extra-modules-6.6.0-145.3.17.150.oe2403sp3.aarch64.rpm",
          "kernel-headers-6.6.0-145.3.17.150.oe2403sp3.aarch64.rpm",
          "kernel-source-6.6.0-145.3.17.150.oe2403sp3.aarch64.rpm",
          "kernel-tools-6.6.0-145.3.17.150.oe2403sp3.aarch64.rpm",
          "kernel-tools-debuginfo-6.6.0-145.3.17.150.oe2403sp3.aarch64.rpm",
          "kernel-tools-devel-6.6.0-145.3.17.150.oe2403sp3.aarch64.rpm",
          "perf-6.6.0-145.3.17.150.oe2403sp3.aarch64.rpm",
          "perf-debuginfo-6.6.0-145.3.17.150.oe2403sp3.aarch64.rpm",
          "python3-perf-6.6.0-145.3.17.150.oe2403sp3.aarch64.rpm",
          "python3-perf-debuginfo-6.6.0-145.3.17.150.oe2403sp3.aarch64.rpm"
        ],
        "src": [
          "kernel-6.6.0-145.3.17.150.oe2403sp3.src.rpm"
        ],
        "x86_64": [
          "bpftool-6.6.0-145.3.17.150.oe2403sp3.x86_64.rpm",
          "bpftool-debuginfo-6.6.0-145.3.17.150.oe2403sp3.x86_64.rpm",
          "kernel-6.6.0-145.3.17.150.oe2403sp3.x86_64.rpm",
          "kernel-debuginfo-6.6.0-145.3.17.150.oe2403sp3.x86_64.rpm",
          "kernel-debugsource-6.6.0-145.3.17.150.oe2403sp3.x86_64.rpm",
          "kernel-devel-6.6.0-145.3.17.150.oe2403sp3.x86_64.rpm",
          "kernel-extra-modules-6.6.0-145.3.17.150.oe2403sp3.x86_64.rpm",
          "kernel-headers-6.6.0-145.3.17.150.oe2403sp3.x86_64.rpm",
          "kernel-source-6.6.0-145.3.17.150.oe2403sp3.x86_64.rpm",
          "kernel-tools-6.6.0-145.3.17.150.oe2403sp3.x86_64.rpm",
          "kernel-tools-debuginfo-6.6.0-145.3.17.150.oe2403sp3.x86_64.rpm",
          "kernel-tools-devel-6.6.0-145.3.17.150.oe2403sp3.x86_64.rpm",
          "perf-6.6.0-145.3.17.150.oe2403sp3.x86_64.rpm",
          "perf-debuginfo-6.6.0-145.3.17.150.oe2403sp3.x86_64.rpm",
          "python3-perf-6.6.0-145.3.17.150.oe2403sp3.x86_64.rpm",
          "python3-perf-debuginfo-6.6.0-145.3.17.150.oe2403sp3.x86_64.rpm"
        ]
      },
      "package": {
        "ecosystem": "openEuler:24.03-LTS-SP3",
        "name": "kernel",
        "purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-24.03-LTS-SP3"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "6.6.0-145.3.17.150.oe2403sp3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "database_specific": {
    "severity": "Critical"
  },
  "details": "The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\n\nArm C1-Ultra, C1-Premium, Neoverse V3 \u0026amp; V3AE, Neoverse V2, Neoverse V1, Neoverse-N2, Neoverse-N1, Cortex-X925, Cortex-X4, Cortex-X3, Cortex-X2, Cortex-X1 \u0026amp; X1C, Cortex-A710, Cortex-A78, A78AE \u0026amp; A78C, Cortex-A77, Cortex-A76 \u0026amp; A76A may allow writes to resources owned by a higher exception level.(CVE-2025-10263)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: let smbd_destroy() call disable_work_sync(\u0026amp;info-\u0026gt;post_send_credits_work)\n\nIn smbd_destroy() we may destroy the memory so we better\nwait until post_send_credits_work is no longer pending\nand will never be started again.\n\nI actually just hit the case using rxe:\n\nWARNING: CPU: 0 PID: 138 at drivers/infiniband/sw/rxe/rxe_verbs.c:1032 rxe_post_recv+0x1ee/0x480 [rdma_rxe]\n...\n[ 5305.686979] [    T138]  smbd_post_recv+0x445/0xc10 [cifs]\n[ 5305.687135] [    T138]  ? srso_alias_return_thunk+0x5/0xfbef5\n[ 5305.687149] [    T138]  ? __kasan_check_write+0x14/0x30\n[ 5305.687185] [    T138]  ? __pfx_smbd_post_recv+0x10/0x10 [cifs]\n[ 5305.687329] [    T138]  ? __pfx__raw_spin_lock_irqsave+0x10/0x10\n[ 5305.687356] [    T138]  ? srso_alias_return_thunk+0x5/0xfbef5\n[ 5305.687368] [    T138]  ? srso_alias_return_thunk+0x5/0xfbef5\n[ 5305.687378] [    T138]  ? _raw_spin_unlock_irqrestore+0x11/0x60\n[ 5305.687389] [    T138]  ? srso_alias_return_thunk+0x5/0xfbef5\n[ 5305.687399] [    T138]  ? get_receive_buffer+0x168/0x210 [cifs]\n[ 5305.687555] [    T138]  smbd_post_send_credits+0x382/0x4b0 [cifs]\n[ 5305.687701] [    T138]  ? __pfx_smbd_post_send_credits+0x10/0x10 [cifs]\n[ 5305.687855] [    T138]  ? __pfx___schedule+0x10/0x10\n[ 5305.687865] [    T138]  ? __pfx__raw_spin_lock_irq+0x10/0x10\n[ 5305.687875] [    T138]  ? queue_delayed_work_on+0x8e/0xa0\n[ 5305.687889] [    T138]  process_one_work+0x629/0xf80\n[ 5305.687908] [    T138]  ? srso_alias_return_thunk+0x5/0xfbef5\n[ 5305.687917] [    T138]  ? __kasan_check_write+0x14/0x30\n[ 5305.687933] [    T138]  worker_thread+0x87f/0x1570\n...\n\nIt means rxe_post_recv was called after rdma_destroy_qp().\nThis happened because put_receive_buffer() was triggered\nby ib_drain_qp() and called:\nqueue_work(info-\u0026gt;workqueue, \u0026amp;info-\u0026gt;post_send_credits_work);(CVE-2025-39932)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nriscv: Sanitize syscall table indexing under speculation\n\nThe syscall number is a user-controlled value used to index into the\nsyscall table. Use array_index_nospec() to clamp this value after the\nbounds check to prevent speculative out-of-bounds access and subsequent\ndata leakage via cache side channels.(CVE-2025-71203)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnvme-fc: release admin tagset if init fails\n\nnvme_fabrics creates an NVMe/FC controller in following path:\n\n    nvmf_dev_write()\n      -\u0026gt; nvmf_create_ctrl()\n        -\u0026gt; nvme_fc_create_ctrl()\n          -\u0026gt; nvme_fc_init_ctrl()\n\nnvme_fc_init_ctrl() allocates the admin blk-mq resources right after\nnvme_add_ctrl() succeeds.  If any of the subsequent steps fail (changing\nthe controller state, scheduling connect work, etc.), we jump to the\nfail_ctrl path, which tears down the controller references but never\nfrees the admin queue/tag set.  The leaked blk-mq allocations match the\nkmemleak report seen during blktests nvme/fc.\n\nCheck ctrl-\u0026gt;ctrl.admin_tagset in the fail_ctrl path and call\nnvme_remove_admin_tag_set() when it is set so that all admin queue\nallocations are reclaimed whenever controller setup aborts.(CVE-2026-23261)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\narm64: io: Extract user memory type in ioremap_prot()\n\nThe only caller of ioremap_prot() outside of the generic ioremap()\nimplementation is generic_access_phys(), which passes a \u0026apos;pgprot_t\u0026apos; value\ndetermined from the user mapping of the target \u0026apos;pfn\u0026apos; being accessed by\nthe kernel. On arm64, the \u0026apos;pgprot_t\u0026apos; contains all of the non-address\nbits from the pte, including the permission controls, and so we end up\nreturning a new user mapping from ioremap_prot() which faults when\naccessed from the kernel on systems with PAN:\n\n  | Unable to handle kernel read from unreadable memory at virtual address ffff80008ea89000\n  | ...\n  | Call trace:\n  |   __memcpy_fromio+0x80/0xf8\n  |   generic_access_phys+0x20c/0x2b8\n  |   __access_remote_vm+0x46c/0x5b8\n  |   access_remote_vm+0x18/0x30\n  |   environ_read+0x238/0x3e8\n  |   vfs_read+0xe4/0x2b0\n  |   ksys_read+0xcc/0x178\n  |   __arm64_sys_read+0x4c/0x68\n\nExtract only the memory type from the user \u0026apos;pgprot_t\u0026apos; in ioremap_prot()\nand assert that we\u0026apos;re being passed a user mapping, to protect us against\nany changes in future that may require additional handling. To avoid\nfalsely flagging users of ioremap(), provide our own ioremap() macro\nwhich simply wraps __ioremap_prot().(CVE-2026-23346)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nice: change XDP RxQ frag_size from DMA write length to xdp.frame_sz\n\nThe only user of frag_size field in XDP RxQ info is\nbpf_xdp_frags_increase_tail(). It clearly expects whole buff size instead\nof DMA write size. Different assumptions in ice driver configuration lead\nto negative tailroom.\n\nThis allows to trigger kernel panic, when using\nXDP_ADJUST_TAIL_GROW_MULTI_BUFF xskxceiver test and changing packet size to\n6912 and the requested offset to a huge value, e.g.\nXSK_UMEM__MAX_FRAME_SIZE * 100.\n\nDue to other quirks of the ZC configuration in ice, panic is not observed\nin ZC mode, but tailroom growing still fails when it should not.\n\nUse fill queue buffer truesize instead of DMA write size in XDP RxQ info.\nFix ZC mode too by using the new helper.(CVE-2026-23377)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nf_conntrack_expect: use expect-\u0026gt;helper\n\nUse expect-\u0026gt;helper in ctnetlink and /proc to dump the helper name.\nUsing nfct_help() without holding a reference to the master conntrack\nis unsafe.\n\nUse exp-\u0026gt;master-\u0026gt;helper in ctnetlink path if userspace does not provide\nan explicit helper when creating an expectation to retain the existing\nbehaviour. The ctnetlink expectation path holds the reference on the\nmaster conntrack and nf_conntrack_expect lock and the nfnetlink glue\npath refers to the master ct that is attached to the skb.(CVE-2026-31414)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: fix OOB write in QUERY_INFO for compound requests\n\nWhen a compound request such as READ + QUERY_INFO(Security) is received,\nand the first command (READ) consumes most of the response buffer,\nksmbd could write beyond the allocated buffer while building a security\ndescriptor.\n\nThe root cause was that smb2_get_info_sec() checked buffer space using\nppntsd_size from xattr, while build_sec_desc() often synthesized a\nsignificantly larger descriptor from POSIX ACLs.\n\nThis patch introduces smb_acl_sec_desc_scratch_len() to accurately\ncompute the final descriptor size beforehand, performs proper buffer\nchecking with smb2_calc_max_out_buf_len(), and uses exact-sized\nallocation + iov pinning.(CVE-2026-31432)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndmaengine: idxd: Fix leaking event log memory\n\nDuring the device remove process, the device is reset, causing the\nconfiguration registers to go back to their default state, which is\nzero. As the driver is checking if the event log support was enabled\nbefore deallocating, it will fail if a reset happened before.\n\nDo not check if the support was enabled, the check for \u0026apos;idxd-\u0026gt;evl\u0026apos;\nbeing valid (only allocated if the HW capability is available) is\nenough.(CVE-2026-31440)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndmaengine: idxd: Fix crash when the event log is disabled\n\nIf reporting errors to the event log is not supported by the hardware,\nand an error that causes Function Level Reset (FLR) is received, the\ndriver will try to restore the event log even if it was not allocated.\n\nAlso, only try to free the event log if it was properly allocated.(CVE-2026-31443)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nxfs: avoid dereferencing log items after push callbacks\n\nAfter xfsaild_push_item() calls iop_push(), the log item may have been\nfreed if the AIL lock was dropped during the push. Background inode\nreclaim or the dquot shrinker can free the log item while the AIL lock\nis not held, and the tracepoints in the switch statement dereference\nthe log item after iop_push() returns.\n\nFix this by capturing the log item type, flags, and LSN before calling\nxfsaild_push_item(), and introducing a new xfs_ail_push_class trace\nevent class that takes these pre-captured values and the ailp pointer\ninstead of the log item pointer.(CVE-2026-31453)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm/huge_memory: fix folio isn\u0026apos;t locked in softleaf_to_folio()\n\nOn arm64 server, we found folio that get from migration entry isn\u0026apos;t locked\nin softleaf_to_folio().  This issue triggers when mTHP splitting and\nzap_nonpresent_ptes() races, and the root cause is lack of memory barrier\nin softleaf_to_folio().  The race is as follows:\n\n\tCPU0                                             CPU1\n\ndeferred_split_scan()                              zap_nonpresent_ptes()\n  lock folio\n  split_folio()\n    unmap_folio()\n      change ptes to migration entries\n    __split_folio_to_order()                         softleaf_to_folio()\n      set flags(including PG_locked) for tail pages    folio = pfn_folio(softleaf_to_pfn(entry))\n      smp_wmb()                                        VM_WARN_ON_ONCE(!folio_test_locked(folio))\n      prep_compound_page() for tail pages\n\nIn __split_folio_to_order(), smp_wmb() guarantees page flags of tail pages\nare visible before the tail page becomes non-compound.  smp_wmb() should\nbe paired with smp_rmb() in softleaf_to_folio(), which is missed.  As a\nresult, if zap_nonpresent_ptes() accesses migration entry that stores tail\npfn, softleaf_to_folio() may see the updated compound_head of tail page\nbefore page-\u0026gt;flags.\n\nThis issue will trigger VM_WARN_ON_ONCE() in pfn_swap_entry_folio()\nbecause of the race between folio split and zap_nonpresent_ptes()\nleading to a folio incorrectly undergoing modification without a folio\nlock being held.\n\nThis is a BUG_ON() before commit 93976a20345b (\u0026quot;mm: eliminate further\nswapops predicates\u0026quot;), which in merged in v6.19-rc1.\n\nTo fix it, add missing smp_rmb() if the softleaf entry is migration entry\nin softleaf_to_folio() and softleaf_to_page().\n\n[(CVE-2026-31466)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: openvswitch: Avoid releasing netdev before teardown completes\n\nThe patch cited in the Fixes tag below changed the teardown code for\nOVS ports to no longer unconditionally take the RTNL. After this change,\nthe netdev_destroy() callback can proceed immediately to the call_rcu()\ninvocation if the IFF_OVS_DATAPATH flag is already cleared on the\nnetdev.\n\nThe ovs_netdev_detach_dev() function clears the flag before completing\nthe unregistration, and if it gets preempted after clearing the flag (as\ncan happen on an -rt kernel), netdev_destroy() can complete and the\ndevice can be freed before the unregistration completes. This leads to a\nsplat like:\n\n[  998.393867] Oops: general protection fault, probably for non-canonical address 0xff00000001000239: 0000 [#1] SMP PTI\n[  998.393877] CPU: 42 UID: 0 PID: 55177 Comm: ip Kdump: loaded Not tainted 6.12.0-211.1.1.el10_2.x86_64+rt #1 PREEMPT_RT\n[  998.393886] Hardware name: Dell Inc. PowerEdge R740/0JMK61, BIOS 2.24.0 03/27/2025\n[  998.393889] RIP: 0010:dev_set_promiscuity+0x8d/0xa0\n[  998.393901] Code: 00 00 75 d8 48 8b 53 08 48 83 ba b0 02 00 00 00 75 ca 48 83 c4 08 5b c3 cc cc cc cc 48 83 bf 48 09 00 00 00 75 91 48 8b 47 08 \u0026lt;48\u0026gt; 83 b8 b0 02 00 00 00 74 97 eb 81 0f 1f 80 00 00 00 00 90 90 90\n[  998.393906] RSP: 0018:ffffce5864a5f6a0 EFLAGS: 00010246\n[  998.393912] RAX: ff00000000ffff89 RBX: ffff894d0adf5a05 RCX: 0000000000000000\n[  998.393917] RDX: 0000000000000000 RSI: 00000000ffffffff RDI: ffff894d0adf5a05\n[  998.393921] RBP: ffff894d19252000 R08: ffff894d19252000 R09: 0000000000000000\n[  998.393924] R10: ffff894d19252000 R11: ffff894d192521b8 R12: 0000000000000006\n[  998.393927] R13: ffffce5864a5f738 R14: 00000000ffffffe2 R15: 0000000000000000\n[  998.393931] FS:  00007fad61971800(0000) GS:ffff894cc0140000(0000) knlGS:0000000000000000\n[  998.393936] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[  998.393940] CR2: 000055df0a2a6e40 CR3: 000000011c7fe003 CR4: 00000000007726f0\n[  998.393944] PKRU: 55555554\n[  998.393946] Call Trace:\n[  998.393949]  \u0026lt;TASK\u0026gt;\n[  998.393952]  ? show_trace_log_lvl+0x1b0/0x2f0\n[  998.393961]  ? show_trace_log_lvl+0x1b0/0x2f0\n[  998.393975]  ? dp_device_event+0x41/0x80 [openvswitch]\n[  998.394009]  ? __die_body.cold+0x8/0x12\n[  998.394016]  ? die_addr+0x3c/0x60\n[  998.394027]  ? exc_general_protection+0x16d/0x390\n[  998.394042]  ? asm_exc_general_protection+0x26/0x30\n[  998.394058]  ? dev_set_promiscuity+0x8d/0xa0\n[  998.394066]  ? ovs_netdev_detach_dev+0x3a/0x80 [openvswitch]\n[  998.394092]  dp_device_event+0x41/0x80 [openvswitch]\n[  998.394102]  notifier_call_chain+0x5a/0xd0\n[  998.394106]  unregister_netdevice_many_notify+0x51b/0xa60\n[  998.394110]  rtnl_dellink+0x169/0x3e0\n[  998.394121]  ? rt_mutex_slowlock.constprop.0+0x95/0xd0\n[  998.394125]  rtnetlink_rcv_msg+0x142/0x3f0\n[  998.394128]  ? avc_has_perm_noaudit+0x69/0xf0\n[  998.394130]  ? __pfx_rtnetlink_rcv_msg+0x10/0x10\n[  998.394132]  netlink_rcv_skb+0x50/0x100\n[  998.394138]  netlink_unicast+0x292/0x3f0\n[  998.394141]  netlink_sendmsg+0x21b/0x470\n[  998.394145]  ____sys_sendmsg+0x39d/0x3d0\n[  998.394149]  ___sys_sendmsg+0x9a/0xe0\n[  998.394156]  __sys_sendmsg+0x7a/0xd0\n[  998.394160]  do_syscall_64+0x7f/0x170\n[  998.394162]  entry_SYSCALL_64_after_hwframe+0x76/0x7e\n[  998.394165] RIP: 0033:0x7fad61bf4724\n[  998.394188] Code: 89 02 b8 ff ff ff ff eb bb 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 f3 0f 1e fa 80 3d c5 e9 0c 00 00 74 13 b8 2e 00 00 00 0f 05 \u0026lt;48\u0026gt; 3d 00 f0 ff ff 77 54 c3 0f 1f 00 48 83 ec 28 89 54 24 1c 48 89\n[  998.394189] RSP: 002b:00007ffd7e2f7cb8 EFLAGS: 00000202 ORIG_RAX: 000000000000002e\n[  998.394191] RAX: ffffffffffffffda RBX: 0000000000000001 RCX: 00007fad61bf4724\n[  998.394193] RDX: 0000000000000000 RSI: 00007ffd7e2f7d20 RDI: 0000000000000003\n[  998.394194] RBP: 00007ffd7e2f7d90 R08: 0000000000000010 R09: 000000000000003f\n[  998.394195] R10: 000055df11558010 R11: 0000000000000202 R12: 00007ffd7e2\n---truncated---(CVE-2026-31508)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: mac80211: Fix static_branch_dec() underflow for aql_disable.\n\nsyzbot reported static_branch_dec() underflow in aql_enable_write(). [0]\n\nThe problem is that aql_enable_write() does not serialise concurrent\nwrite()s to the debugfs.\n\naql_enable_write() checks static_key_false(\u0026amp;aql_disable.key) and\nlater calls static_branch_inc() or static_branch_dec(), but the\nstate may change between the two calls.\n\naql_disable does not need to track inc/dec.\n\nLet\u0026apos;s use static_branch_enable() and static_branch_disable().\n\n[0]:\nval == 0\nWARNING: kernel/jump_label.c:311 at __static_key_slow_dec_cpuslocked.part.0+0x107/0x120 kernel/jump_label.c:311, CPU#0: syz.1.3155/20288\nModules linked in:\nCPU: 0 UID: 0 PID: 20288 Comm: syz.1.3155 Tainted: G     U       L      syzkaller #0 PREEMPT(full)\nTainted: [U]=USER, [L]=SOFTLOCKUP\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/24/2026\nRIP: 0010:__static_key_slow_dec_cpuslocked.part.0+0x107/0x120 kernel/jump_label.c:311\nCode: f2 c9 ff 5b 5d c3 cc cc cc cc e8 54 f2 c9 ff 48 89 df e8 ac f9 ff ff eb ad e8 45 f2 c9 ff 90 0f 0b 90 eb a2 e8 3a f2 c9 ff 90 \u0026lt;0f\u0026gt; 0b 90 eb 97 48 89 df e8 5c 4b 33 00 e9 36 ff ff ff 0f 1f 80 00\nRSP: 0018:ffffc9000b9f7c10 EFLAGS: 00010293\nRAX: 0000000000000000 RBX: ffffffff9b3e5d40 RCX: ffffffff823c57b4\nRDX: ffff8880285a0000 RSI: ffffffff823c5846 RDI: ffff8880285a0000\nRBP: 0000000000000000 R08: 0000000000000005 R09: 0000000000000000\nR10: 0000000000000000 R11: 0000000000000000 R12: 000000000000000a\nR13: 1ffff9200173ef88 R14: 0000000000000001 R15: ffffc9000b9f7e98\nFS:  00007f530dd726c0(0000) GS:ffff8881245e3000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000200000001140 CR3: 000000007cc4a000 CR4: 00000000003526f0\nCall Trace:\n \u0026lt;TASK\u0026gt;\n __static_key_slow_dec_cpuslocked kernel/jump_label.c:297 [inline]\n __static_key_slow_dec kernel/jump_label.c:321 [inline]\n static_key_slow_dec+0x7c/0xc0 kernel/jump_label.c:336\n aql_enable_write+0x2b2/0x310 net/mac80211/debugfs.c:343\n short_proxy_write+0x133/0x1a0 fs/debugfs/file.c:383\n vfs_write+0x2aa/0x1070 fs/read_write.c:684\n ksys_pwrite64 fs/read_write.c:793 [inline]\n __do_sys_pwrite64 fs/read_write.c:801 [inline]\n __se_sys_pwrite64 fs/read_write.c:798 [inline]\n __x64_sys_pwrite64+0x1eb/0x250 fs/read_write.c:798\n do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]\n do_syscall_64+0xc9/0xf80 arch/x86/entry/syscall_64.c:94\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\nRIP: 0033:0x7f530cf9aeb9\nCode: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 \u0026lt;48\u0026gt; 3d 01 f0 ff ff 73 01 c3 48 c7 c1 e8 ff ff ff f7 d8 64 89 01 48\nRSP: 002b:00007f530dd72028 EFLAGS: 00000246 ORIG_RAX: 0000000000000012\nRAX: ffffffffffffffda RBX: 00007f530d215fa0 RCX: 00007f530cf9aeb9\nRDX: 0000000000000003 RSI: 0000000000000000 RDI: 0000000000000010\nRBP: 00007f530d008c1f R08: 0000000000000000 R09: 0000000000000000\nR10: 4200000000000005 R11: 0000000000000246 R12: 0000000000000000\nR13: 00007f530d216038 R14: 00007f530d215fa0 R15: 00007ffde89fb978\n \u0026lt;/TASK\u0026gt;(CVE-2026-31551)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnvmet: move async event work off nvmet-wq\n\nFor target nvmet_ctrl_free() flushes ctrl-\u0026gt;async_event_work.\nIf nvmet_ctrl_free() runs on nvmet-wq, the flush re-enters workqueue\ncompletion for the same worker:-\n\nA. Async event work queued on nvmet-wq (prior to disconnect):\n  nvmet_execute_async_event()\n     queue_work(nvmet_wq, \u0026amp;ctrl-\u0026gt;async_event_work)\n\n  nvmet_add_async_event()\n     queue_work(nvmet_wq, \u0026amp;ctrl-\u0026gt;async_event_work)\n\nB. Full pre-work chain (RDMA CM path):\n  nvmet_rdma_cm_handler()\n     nvmet_rdma_queue_disconnect()\n       __nvmet_rdma_queue_disconnect()\n         queue_work(nvmet_wq, \u0026amp;queue-\u0026gt;release_work)\n           process_one_work()\n             lock((wq_completion)nvmet-wq)  \u0026lt;--------- 1st\n             nvmet_rdma_release_queue_work()\n\nC. Recursive path (same worker):\n  nvmet_rdma_release_queue_work()\n     nvmet_rdma_free_queue()\n       nvmet_sq_destroy()\n         nvmet_ctrl_put()\n           nvmet_ctrl_free()\n             flush_work(\u0026amp;ctrl-\u0026gt;async_event_work)\n               __flush_work()\n                 touch_wq_lockdep_map()\n                 lock((wq_completion)nvmet-wq) \u0026lt;--------- 2nd\n\nLockdep splat:\n\n  ============================================\n  WARNING: possible recursive locking detected\n  6.19.0-rc3nvme+ #14 Tainted: G                 N\n  --------------------------------------------\n  kworker/u192:42/44933 is trying to acquire lock:\n  ffff888118a00948 ((wq_completion)nvmet-wq){+.+.}-{0:0}, at: touch_wq_lockdep_map+0x26/0x90\n\n  but task is already holding lock:\n  ffff888118a00948 ((wq_completion)nvmet-wq){+.+.}-{0:0}, at: process_one_work+0x53e/0x660\n\n  3 locks held by kworker/u192:42/44933:\n   #0: ffff888118a00948 ((wq_completion)nvmet-wq){+.+.}-{0:0}, at: process_one_work+0x53e/0x660\n   #1: ffffc9000e6cbe28 ((work_completion)(\u0026amp;queue-\u0026gt;release_work)){+.+.}-{0:0}, at: process_one_work+0x1c5/0x660\n   #2: ffffffff82d4db60 (rcu_read_lock){....}-{1:3}, at: __flush_work+0x62/0x530\n\n  Workqueue: nvmet-wq nvmet_rdma_release_queue_work [nvmet_rdma]\n  Call Trace:\n   __flush_work+0x268/0x530\n   nvmet_ctrl_free+0x140/0x310 [nvmet]\n   nvmet_cq_put+0x74/0x90 [nvmet]\n   nvmet_rdma_free_queue+0x23/0xe0 [nvmet_rdma]\n   nvmet_rdma_release_queue_work+0x19/0x50 [nvmet_rdma]\n   process_one_work+0x206/0x660\n   worker_thread+0x184/0x320\n   kthread+0x10c/0x240\n   ret_from_fork+0x319/0x390\n\nMove async event work to a dedicated nvmet-aen-wq to avoid reentrant\nflush on nvmet-wq.(CVE-2026-31557)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbcache: fix cached_dev.sb_bio use-after-free and crash\n\nIn our production environment, we have received multiple crash reports\nregarding libceph, which have caught our attention:\n\n```\n[6888366.280350] Call Trace:\n[6888366.280452]  blk_update_request+0x14e/0x370\n[6888366.280561]  blk_mq_end_request+0x1a/0x130\n[6888366.280671]  rbd_img_handle_request+0x1a0/0x1b0 [rbd]\n[6888366.280792]  rbd_obj_handle_request+0x32/0x40 [rbd]\n[6888366.280903]  __complete_request+0x22/0x70 [libceph]\n[6888366.281032]  osd_dispatch+0x15e/0xb40 [libceph]\n[6888366.281164]  ? inet_recvmsg+0x5b/0xd0\n[6888366.281272]  ? ceph_tcp_recvmsg+0x6f/0xa0 [libceph]\n[6888366.281405]  ceph_con_process_message+0x79/0x140 [libceph]\n[6888366.281534]  ceph_con_v1_try_read+0x5d7/0xf30 [libceph]\n[6888366.281661]  ceph_con_workfn+0x329/0x680 [libceph]\n```\n\nAfter analyzing the coredump file, we found that the address of\ndc-\u0026gt;sb_bio has been freed. We know that cached_dev is only freed when it\nis stopped.\n\nSince sb_bio is a part of struct cached_dev, rather than an alloc every\ntime.  If the device is stopped while writing to the superblock, the\nreleased address will be accessed at endio.\n\nThis patch hopes to wait for sb_write to complete in cached_dev_free.\n\nIt should be noted that we analyzed the cause of the problem, then tell\nall details to the QWEN and adopted the modifications it made.(CVE-2026-31580)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nxfrm: hold dev ref until after transport_finish NF_HOOK\n\nAfter async crypto completes, xfrm_input_resume() calls dev_put()\nimmediately on re-entry before the skb reaches transport_finish.\nThe skb-\u0026gt;dev pointer is then used inside NF_HOOK and its okfn,\nwhich can race with device teardown.\n\nRemove the dev_put from the async resumption entry and instead\ndrop the reference after the NF_HOOK call in transport_finish,\nusing a saved device pointer since NF_HOOK may consume the skb.\nThis covers NF_DROP, NF_QUEUE and NF_STOLEN paths that skip\nthe okfn.\n\nFor non-transport exits (decaps, gro, drop) and secondary\nasync return points, release the reference inline when\nasync is set.(CVE-2026-31663)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nxfrm: clear trailing padding in build_polexpire()\n\nbuild_expire() clears the trailing padding bytes of struct\nxfrm_user_expire after setting the hard field via memset_after(),\nbut the analogous function build_polexpire() does not do this for\nstruct xfrm_user_polexpire.\n\nThe padding bytes after the __u8 hard field are left\nuninitialized from the heap allocation, and are then sent to\nuserspace via netlink multicast to XFRMNLGRP_EXPIRE listeners,\nleaking kernel heap memory contents.\n\nAdd the missing memset_after() call, matching build_expire().(CVE-2026-31664)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: xt_multiport: validate range encoding in checkentry\n\nports_match_v1() treats any non-zero pflags entry as the start of a\nport range and unconditionally consumes the next ports[] element as\nthe range end.\n\nThe checkentry path currently validates protocol, flags and count, but\nit does not validate the range encoding itself. As a result, malformed\nrules can mark the last slot as a range start or place two range starts\nback to back, leaving ports_match_v1() to step past the last valid\nports[] element while interpreting the rule.\n\nReject malformed multiport v1 rules in checkentry by validating that\neach range start has a following element and that the following element\nis not itself marked as another range start.(CVE-2026-31681)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: validate owner of durable handle on reconnect\n\nCurrently, ksmbd does not verify if the user attempting to reconnect\nto a durable handle is the same user who originally opened the file.\nThis allows any authenticated user to hijack an orphaned durable handle\nby predicting or brute-forcing the persistent ID.\n\nAccording to MS-SMB2, the server MUST verify that the SecurityContext\nof the reconnect request matches the SecurityContext associated with\nthe existing open.\nAdd a durable_owner structure to ksmbd_file to store the original opener\u0026apos;s\nUID, GID, and account name. and catpure the owner information when a file\nhandle becomes orphaned. and implementing ksmbd_vfs_compare_durable_owner()\nto validate the identity of the requester during SMB2_CREATE (DHnC).(CVE-2026-31717)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nusb: gadget: f_ecm: Fix net_device lifecycle with device_move\n\nThe net_device is allocated during function instance creation and\nregistered during the bind phase with the gadget device as its sysfs\nparent. When the function unbinds, the parent device is destroyed, but\nthe net_device survives, resulting in dangling sysfs symlinks:\n\n  console:/ # ls -l /sys/class/net/usb0\n  lrwxrwxrwx ... /sys/class/net/usb0 -\u0026gt;\n  /sys/devices/platform/.../gadget.0/net/usb0\n  console:/ # ls -l /sys/devices/platform/.../gadget.0/net/usb0\n  ls: .../gadget.0/net/usb0: No such file or directory\n\nUse device_move() to reparent the net_device between the gadget device\ntree and /sys/devices/virtual across bind and unbind cycles. During the\nfinal unbind, calling device_move(NULL) moves the net_device to the\nvirtual device tree before the gadget device is destroyed. On rebinding,\ndevice_move() reparents the device back under the new gadget, ensuring\nproper sysfs topology and power management ordering.\n\nTo maintain compatibility with legacy composite drivers (e.g., multi.c),\nthe bound flag is used to indicate whether the network device is shared\nand pre-registered during the legacy driver\u0026apos;s bind phase.(CVE-2026-31725)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: hci_sync: hci_cmd_sync_queue_once() return -EEXIST if exists\n\nhci_cmd_sync_queue_once() needs to indicate whether a queue item was\nadded, so caller can know if callbacks are called, so it can avoid\nleaking resources.\n\nChange the function to return -EEXIST if queue item already exists.\n\nModify all callsites to handle that.(CVE-2026-43022)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: ctnetlink: ignore explicit helper on new expectations\n\nUse the existing master conntrack helper, anything else is not really\nsupported and it just makes validation more complicated, so just ignore\nwhat helper userspace suggests for this expectation.\n\nThis was uncovered when validating CTA_EXPECT_CLASS via different helper\nprovided by userspace than the existing master conntrack helper:\n\n  BUG: KASAN: slab-out-of-bounds in nf_ct_expect_related_report+0x2479/0x27c0\n  Read of size 4 at addr ffff8880043fe408 by task poc/102\n  Call Trace:\n   nf_ct_expect_related_report+0x2479/0x27c0\n   ctnetlink_create_expect+0x22b/0x3b0\n   ctnetlink_new_expect+0x4bd/0x5c0\n   nfnetlink_rcv_msg+0x67a/0x950\n   netlink_rcv_skb+0x120/0x350\n\nAllowing to read kernel memory bytes off the expectation boundary.\n\nCTA_EXPECT_HELP_NAME is still used to offer the helper name to userspace\nvia netlink dump.(CVE-2026-43025)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: ctnetlink: zero expect NAT fields when CTA_EXPECT_NAT absent\n\nctnetlink_alloc_expect() allocates expectations from a non-zeroing\nslab cache via nf_ct_expect_alloc().  When CTA_EXPECT_NAT is not\npresent in the netlink message, saved_addr and saved_proto are\nnever initialized.  Stale data from a previous slab occupant can\nthen be dumped to userspace by ctnetlink_exp_dump_expect(), which\nchecks these fields to decide whether to emit CTA_EXPECT_NAT.\n\nThe safe sibling nf_ct_expect_init(), used by the packet path,\nexplicitly zeroes these fields.\n\nZero saved_addr, saved_proto and dir in the else branch, guarded\nby IS_ENABLED(CONFIG_NF_NAT) since these fields only exist when\nNAT is enabled.\n\nConfirmed by priming the expect slab with NAT-bearing expectations,\nfreeing them, creating a new expectation without CTA_EXPECT_NAT,\nand observing that the ctnetlink dump emits a spurious\nCTA_EXPECT_NAT containing stale data from the prior allocation.(CVE-2026-43026)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nxfrm: Wait for RCU readers during policy netns exit\n\nxfrm_policy_fini() frees the policy_bydst hash tables after flushing the\npolicy work items and deleting all policies, but it does not wait for\nconcurrent RCU readers to leave their read-side critical sections first.\n\nThe policy_bydst tables are published via rcu_assign_pointer() and are\nlooked up through rcu_dereference_check(), so netns teardown must also\nwait for an RCU grace period before freeing the table memory.\n\nFix this by adding synchronize_rcu() before freeing the policy hash tables.(CVE-2026-43091)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: ctnetlink: ensure safe access to master conntrack\n\nHolding reference on the expectation is not sufficient, the master\nconntrack object can just go away, making exp-\u0026gt;master invalid.\n\nTo access exp-\u0026gt;master safely:\n\n- Grab the nf_conntrack_expect_lock, this gets serialized with\n  clean_from_lists() which also holds this lock when the master\n  conntrack goes away.\n\n- Hold reference on master conntrack via nf_conntrack_find_get().\n  Not so easy since the master tuple to look up for the master conntrack\n  is not available in the existing problematic paths.\n\nThis patch goes for extending the nf_conntrack_expect_lock section\nto address this issue for simplicity, in the cases that are described\nbelow this is just slightly extending the lock section.\n\nThe add expectation command already holds a reference to the master\nconntrack from ctnetlink_create_expect().\n\nHowever, the delete expectation command needs to grab the spinlock\nbefore looking up for the expectation. Expand the existing spinlock\nsection to address this to cover the expectation lookup. Note that,\nthe nf_ct_expect_iterate_net() calls already grabs the spinlock while\niterating over the expectation table, which is correct.\n\nThe get expectation command needs to grab the spinlock to ensure master\nconntrack does not go away. This also expands the existing spinlock\nsection to cover the expectation lookup too. I needed to move the\nnetlink skb allocation out of the spinlock to keep it GFP_KERNEL.\n\nFor the expectation events, the IPEXP_DESTROY event is already delivered\nunder the spinlock, just move the delivery of IPEXP_NEW under the\nspinlock too because the master conntrack event cache is reached through\nexp-\u0026gt;master.\n\nWhile at it, add lockdep notations to help identify what codepaths need\nto grab the spinlock.(CVE-2026-43116)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndlm: validate length in dlm_search_rsb_tree\n\nThe len parameter in dlm_dump_rsb_name() is not validated and comes\nfrom network messages. When it exceeds DLM_RESNAME_MAXLEN, it can\ncause out-of-bounds write in dlm_search_rsb_tree().\n\nAdd length validation to prevent potential buffer overflow.(CVE-2026-43125)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nntfs3: fix circular locking dependency in run_unpack_ex\n\nSyzbot reported a circular locking dependency between wnd-\u0026gt;rw_lock\n(sbi-\u0026gt;used.bitmap) and ni-\u0026gt;file.run_lock.\n\nThe deadlock scenario:\n1. ntfs_extend_mft() takes ni-\u0026gt;file.run_lock then wnd-\u0026gt;rw_lock.\n2. run_unpack_ex() takes wnd-\u0026gt;rw_lock then tries to acquire\n   ni-\u0026gt;file.run_lock inside ntfs_refresh_zone().\n\nThis creates an AB-BA deadlock.\n\nFix this by using down_read_trylock() instead of down_read() when\nacquiring run_lock in run_unpack_ex(). If the lock is contended,\nskip ntfs_refresh_zone() - the MFT zone will be refreshed on the\nnext MFT operation. This breaks the circular dependency since we\nnever block waiting for run_lock while holding wnd-\u0026gt;rw_lock.(CVE-2026-43127)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\niommu/amd: serialize sequence allocation under concurrent TLB invalidations\n\nWith concurrent TLB invalidations, completion wait randomly gets timed out\nbecause cmd_sem_val was incremented outside the IOMMU spinlock, allowing\nCMD_COMPL_WAIT commands to be queued out of sequence and breaking the\nordering assumption in wait_on_sem().\nMove the cmd_sem_val increment under iommu-\u0026gt;lock so completion sequence\nallocation is serialized with command queuing.\nAnd remove the unnecessary return.(CVE-2026-43220)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: prevent races in -\u0026gt;query_interfaces()\n\nIt was possible for two query interface works to be concurrently trying\nto update the interfaces.\n\nPrevent this by checking and updating iface_last_update under\niface_lock.(CVE-2026-43239)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmd raid: fix hang when stopping arrays with metadata through dm-raid\n\nWhen using device-mapper\u0026apos;s dm-raid target, stopping a RAID array can cause\nthe system to hang under specific conditions.\n\nThis occurs when:\n\n- A dm-raid managed device tree is suspended from top to bottom\n   (the top-level RAID device is suspended first, followed by its\n    underlying metadata and data devices)\n\n- The top-level RAID device is then removed\n\nRemoving the top-level device triggers a hang in the following sequence:\nthe dm-raid destructor calls md_stop(), which tries to flush the\nwrite-intent bitmap by writing to the metadata sub-devices. However, these\ndevices are already suspended, making them unable to complete the write-intent\noperations and causing an indefinite block.\n\nFix:\n\n- Prevent bitmap flushing when md_stop() is called from dm-raid\ndestructor context\n  and avoid a quiescing/unquescing cycle which could also cause I/O\n\n- Still allow write-intent bitmap flushing when called from dm-raid\nsuspend context\n\nThis ensures that RAID array teardown can complete successfully even when the\nunderlying devices are in a suspended state.\n\nThis second patch uses md_is_rdwr() to distinguish between suspend and\ndestructor paths as elaborated on above.(CVE-2026-43309)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nspi: spidev: fix lock inversion between spi_lock and buf_lock\n\nThe spidev driver previously used two mutexes, spi_lock and buf_lock,\nbut acquired them in different orders depending on the code path:\n\n  write()/read(): buf_lock -\u0026gt; spi_lock\n  ioctl():       spi_lock -\u0026gt; buf_lock\n\nThis AB-BA locking pattern triggers lockdep warnings and can\ncause real deadlocks:\n\n  WARNING: possible circular locking dependency detected\n  spidev_ioctl() -\u0026gt; mutex_lock(\u0026amp;spidev-\u0026gt;buf_lock)\n  spidev_sync_write() -\u0026gt; mutex_lock(\u0026amp;spidev-\u0026gt;spi_lock)\n  *** DEADLOCK ***\n\nThe issue is reproducible with a simple userspace program that\nperforms write() and SPI_IOC_WR_MAX_SPEED_HZ ioctl() calls from\nseparate threads on the same spidev file descriptor.\n\nFix this by simplifying the locking model and removing the lock\ninversion entirely. spidev_sync() no longer performs any locking,\nand all callers serialize access using spi_lock.\n\nbuf_lock is removed since its functionality is fully covered by\nspi_lock, eliminating the possibility of lock ordering issues.\n\nThis removes the lock inversion and prevents deadlocks without\nchanging userspace ABI or behaviour.(CVE-2026-43319)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsched/fair: Fix zero_vruntime tracking fix\n\nJohn reported that stress-ng-yield could make his machine unhappy and\nmanaged to bisect it to commit b3d99f43c72b (\u0026quot;sched/fair: Fix\nzero_vruntime tracking\u0026quot;).\n\nThe combination of yield and that commit was specific enough to\nhypothesize the following scenario:\n\nSuppose we have 2 runnable tasks, both doing yield. Then one will be\neligible and one will not be, because the average position must be in\nbetween these two entities.\n\nTherefore, the runnable task will be eligible, and be promoted a full\nslice (all the tasks do is yield after all). This causes it to jump over\nthe other task and now the other task is eligible and current is no\nlonger. So we schedule.\n\nSince we are runnable, there is no {de,en}queue. All we have is the\n__{en,de}queue_entity() from {put_prev,set_next}_task(). But per the\nfingered commit, those two no longer move zero_vruntime.\n\nAll that moves zero_vruntime are tick and full {de,en}queue.\n\nThis means, that if the two tasks playing leapfrog can reach the\ncritical speed to reach the overflow point inside one tick\u0026apos;s worth of\ntime, we\u0026apos;re up a creek.\n\nAdditionally, when multiple cgroups are involved, there is no guarantee\nthe tick will in fact hit every cgroup in a timely manner. Statistically\nspeaking it will, but that same statistics does not rule out the\npossibility of one cgroup not getting a tick for a significant amount of\ntime -- however unlikely.\n\nTherefore, just like with the yield() case, force an update at the end\nof every slice. This ensures the update is never more than a single\nslice behind and the whole thing is within 2 lag bounds as per the\ncomment on entity_key().(CVE-2026-43323)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: require a full NFS mode SID before reading mode bits\n\nparse_dacl() treats an ACE SID matching sid_unix_NFS_mode as an NFS\nmode SID and reads sid.sub_auth[2] to recover the mode bits.\n\nThat assumes the ACE carries three subauthorities, but compare_sids()\nonly compares min(a, b) subauthorities.  A malicious server can return\nan ACE with num_subauth = 2 and sub_auth[] = {88, 3}, which still\nmatches sid_unix_NFS_mode and then drives the sub_auth[2] read four\nbytes past the end of the ACE.\n\nRequire num_subauth \u0026gt;= 3 before treating the ACE as an NFS mode SID.\nThis keeps the fix local to the special-SID mode path without changing\ncompare_sids() semantics for the rest of cifsacl.(CVE-2026-43350)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ne1000/e1000e: Fix leak in DMA error cleanup\n\nIf an error is encountered while mapping TX buffers, the driver should\nunmap any buffers already mapped for that skb.\n\nBecause count is incremented after a successful mapping, it will always\nmatch the correct number of unmappings needed when dma_error is reached.\nDecrementing count before the while loop in dma_error causes an\noff-by-one error. If any mapping was successful before an unsuccessful\nmapping, exactly one DMA mapping would leak.\n\nIn these commits, a faulty while condition caused an infinite loop in\ndma_error:\nCommit 03b1320dfcee (\u0026quot;e1000e: remove use of skb_dma_map from e1000e\ndriver\u0026quot;)\nCommit 602c0554d7b0 (\u0026quot;e1000: remove use of skb_dma_map from e1000 driver\u0026quot;)\n\nCommit c1fa347f20f1 (\u0026quot;e1000/e1000e/igb/igbvf/ixgb/ixgbe: Fix tests of\nunsigned in *_tx_map()\u0026quot;) fixed the infinite loop, but introduced the\noff-by-one error.\n\nThis issue may still exist in the igbvf driver, but I did not address it\nin this patch.(CVE-2026-43445)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnvme-pci: Fix race bug in nvme_poll_irqdisable()\n\nIn the following scenario, pdev can be disabled between (1) and (3) by\n(2). This sets pdev-\u0026gt;msix_enabled = 0. Then, pci_irq_vector() will\nreturn MSI-X IRQ(\u0026gt;15) for (1) whereas return INTx IRQ(\u0026lt;=15) for (2).\nThis causes IRQ warning because it tries to enable INTx IRQ that has\nnever been disabled before.\n\nTo fix this, save IRQ number into a local variable and ensure\ndisable_irq() and enable_irq() operate on the same IRQ number.  Even if\npci_free_irq_vectors() frees the IRQ concurrently, disable_irq() and\nenable_irq() on a stale IRQ number is still valid and safe, and the\ndepth accounting reamins balanced.\n\ntask 1:\nnvme_poll_irqdisable()\n  disable_irq(pci_irq_vector(pdev, nvmeq-\u0026gt;cq_vector)) ...(1)\n  enable_irq(pci_irq_vector(pdev, nvmeq-\u0026gt;cq_vector))  ...(3)\n\ntask 2:\nnvme_reset_work()\n  nvme_dev_disable()\n    pdev-\u0026gt;msix_enable = 0;  ...(2)\n\ncrash log:\n\n------------[ cut here ]------------\nUnbalanced enable for IRQ 10\nWARNING: kernel/irq/manage.c:753 at __enable_irq+0x102/0x190 kernel/irq/manage.c:753, CPU#1: kworker/1:0H/26\nModules linked in:\nCPU: 1 UID: 0 PID: 26 Comm: kworker/1:0H Not tainted 6.19.0-dirty #9 PREEMPT(voluntary)\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014\nWorkqueue: kblockd blk_mq_timeout_work\nRIP: 0010:__enable_irq+0x107/0x190 kernel/irq/manage.c:753\nCode: ff df 48 89 fa 48 c1 ea 03 0f b6 14 02 48 89 f8 83 e0 07 83 c0 03 38 d0 7c 04 84 d2 75 79 48 8d 3d 2e 7a 3f 05 41 8b 74 24 2c \u0026lt;67\u0026gt; 48 0f b9 3a e8 ef b9 21 00 5b 41 5c 5d e9 46 54 66 03 e8 e1 b9\nRSP: 0018:ffffc900001bf550 EFLAGS: 00010046\nRAX: 0000000000000007 RBX: 0000000000000000 RCX: ffffffffb20c0e90\nRDX: 0000000000000000 RSI: 000000000000000a RDI: ffffffffb74b88f0\nRBP: ffffc900001bf560 R08: ffff88800197cf00 R09: 0000000000000001\nR10: 0000000000000003 R11: 0000000000000003 R12: ffff8880012a6000\nR13: 1ffff92000037eae R14: 000000000000000a R15: 0000000000000293\nFS:  0000000000000000(0000) GS:ffff8880b49f7000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000555da4a25fa8 CR3: 00000000208e8000 CR4: 00000000000006f0\nCall Trace:\n \u0026lt;TASK\u0026gt;\n enable_irq+0x121/0x1e0 kernel/irq/manage.c:797\n nvme_poll_irqdisable+0x162/0x1c0 drivers/nvme/host/pci.c:1494\n nvme_timeout+0x965/0x14b0 drivers/nvme/host/pci.c:1744\n blk_mq_rq_timed_out block/blk-mq.c:1653 [inline]\n blk_mq_handle_expired+0x227/0x2d0 block/blk-mq.c:1721\n bt_iter+0x2fc/0x3a0 block/blk-mq-tag.c:292\n __sbitmap_for_each_set include/linux/sbitmap.h:269 [inline]\n sbitmap_for_each_set include/linux/sbitmap.h:290 [inline]\n bt_for_each block/blk-mq-tag.c:324 [inline]\n blk_mq_queue_tag_busy_iter+0x969/0x1e80 block/blk-mq-tag.c:536\n blk_mq_timeout_work+0x627/0x870 block/blk-mq.c:1763\n process_one_work+0x956/0x1aa0 kernel/workqueue.c:3257\n process_scheduled_works kernel/workqueue.c:3340 [inline]\n worker_thread+0x65c/0xe60 kernel/workqueue.c:3421\n kthread+0x41a/0x930 kernel/kthread.c:463\n ret_from_fork+0x6f8/0x8c0 arch/x86/kernel/process.c:158\n ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:246\n \u0026lt;/TASK\u0026gt;\nirq event stamp: 74478\nhardirqs last  enabled at (74477): [\u0026lt;ffffffffb5720a9c\u0026gt;] __raw_spin_unlock_irq include/linux/spinlock_api_smp.h:159 [inline]\nhardirqs last  enabled at (74477): [\u0026lt;ffffffffb5720a9c\u0026gt;] _raw_spin_unlock_irq+0x2c/0x60 kernel/locking/spinlock.c:202\nhardirqs last disabled at (74478): [\u0026lt;ffffffffb57207b5\u0026gt;] __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:108 [inline]\nhardirqs last disabled at (74478): [\u0026lt;ffffffffb57207b5\u0026gt;] _raw_spin_lock_irqsave+0x85/0xa0 kernel/locking/spinlock.c:162\nsoftirqs last  enabled at (74304): [\u0026lt;ffffffffb1e9466c\u0026gt;] __do_softirq kernel/softirq.c:656 [inline]\nsoftirqs last  enabled at (74304): [\u0026lt;ffffffffb1e9466c\u0026gt;] invoke_softirq kernel/softirq.c:496 [inline]\nsoftirqs last  enabled at (74304): [\u0026lt;ffffffffb1e9466c\u0026gt;] __irq_exit_rcu+0xdc/0x120\n---truncated---(CVE-2026-43448)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nfnetlink_queue: do shared-unconfirmed check before segmentation\n\nUlrich reports a regression with nfqueue:\n\nIf an application did not set the \u0026apos;F_GSO\u0026apos; capability flag and a gso\npacket with an unconfirmed nf_conn entry is received all packets are\nnow dropped instead of queued, because the check happens after\nskb_gso_segment().  In that case, we did have exclusive ownership\nof the skb and its associated conntrack entry.  The elevated use\ncount is due to skb_clone happening via skb_gso_segment().\n\nMove the check so that its peformed vs. the aggregated packet.\n\nThen, annotate the individual segments except the first one so we\ncan do a 2nd check at reinject time.\n\nFor the normal case, where userspace does in-order reinjects, this avoids\npacket drops: first reinjected segment continues traversal and confirms\nentry, remaining segments observe the confirmed entry.\n\nWhile at it, simplify nf_ct_drop_unconfirmed(): We only care about\nunconfirmed entries with a refcnt \u0026gt; 1, there is no need to special-case\ndying entries.\n\nThis only happens with UDP.  With TCP, the only unconfirmed packet will\nbe the TCP SYN, those aren\u0026apos;t aggregated by GRO.\n\nNext patch adds a udpgro test case to cover this scenario.(CVE-2026-45859)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nKVM: SVM: Add missing save/restore handling of LBR MSRs\n\nMSR_IA32_DEBUGCTLMSR and LBR MSRs are currently not enumerated by\nKVM_GET_MSR_INDEX_LIST, and LBR MSRs cannot be set with KVM_SET_MSRS. So\nsave/restore is completely broken.\n\nFix it by adding the MSRs to msrs_to_save_base, and allowing writes to\nLBR MSRs from userspace only (as they are read-only MSRs) if LBR\nvirtualization is enabled.  Additionally, to correctly restore L1\u0026apos;s LBRs\nwhile L2 is running, make sure the LBRs are copied from the captured\nVMCB01 save area in svm_copy_vmrun_state().\n\nNote, for VMX, this also fixes a flaw where MSR_IA32_DEBUGCTLMSR isn\u0026apos;t\nreported as an MSR to save/restore.\n\nNote #2, over-reporting MSR_IA32_LASTxxx on Intel is ok, as KVM already\nhandles unsupported reads and writes thanks to commit b5e2fec0ebc3 (\u0026quot;KVM:\nIgnore DEBUGCTL MSRs with no effect\u0026quot;) (kvm_do_msr_access() will morph the\nunsupported userspace write into a nop).\n\n[sean: guard with lbrv checks, massage changelog](CVE-2026-46014)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nx86/CPU/AMD: Prevent improper isolation of shared resources in Zen2\u0026apos;s op cache\n\nMake sure resources are not improperly shared in the op cache and\ncause instruction corruption this way.(CVE-2026-46174)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nft_inner: Fix IPv6 inner_thoff desync\n\nIn nft_inner_parse_l2l3(), when processing inner IPv6 packets,\nipv6_find_hdr() correctly computes the transport header offset\ntraversing all extension headers, but the result is immediately\noverwritten with nhoff + sizeof(_ip6h) (40 bytes), which only\naccounts for the IPv6 base header. This creates a desync between\ninner_thoff (wrong \u2014 points to extension header start) and l4proto\n(correct \u2014 e.g., IPPROTO_TCP), enabling transport header forgery\nand potential firewall bypass. This issue affects stable versions\nfrom Linux 6.2.\n\nFor comparison, the normal (non-inner) IPv6 path correctly\npreserves ipv6_find_hdr()\u0026apos;s result. Removing the incorrect overwrite\nensures that ipv6_find_hdr()\u0026apos;s calculated transport header offset is\npreserved, thereby fixing the desynchronization.(CVE-2026-46244)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntap: free page on error paths in tap_get_user_xdp()\n\ntap_get_user_xdp() rejects a frame shorter than ETH_HLEN with -EINVAL,\nand returns -ENOMEM when build_skb() fails. Both paths jump to the err\nlabel without freeing the page that vhost_net_build_xdp() allocated for\nthe frame. tap_sendmsg() discards the per-buffer return value and always\nreturns 0, so vhost_tx_batch() takes the success path and never frees\nthe page; each rejected frame in a batch leaks one page-frag chunk.\n\nFree the page on both error paths, before the skb is built. This is the\ntap counterpart of the same leak in tun_xdp_one().(CVE-2026-46320)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntun: free page on short-frame rejection in tun_xdp_one()\n\ntun_xdp_one() returns -EINVAL on a frame shorter than ETH_HLEN without\nfreeing the page that vhost_net_build_xdp() allocated for it.\ntun_sendmsg() discards that -EINVAL and still returns total_len, so\nvhost_tx_batch() takes the success path and never frees the page; each\nshort frame in a batch leaks one page-frag chunk.\n\nA local process that can open /dev/net/tun and /dev/vhost-net can hit\nthis path: it attaches a tun/tap device as the vhost-net backend and\nfeeds TX descriptors whose length minus the virtio-net header is below\nETH_HLEN. Each kick leaks the page-frag chunks for that batch, and a\ntight submission loop exhausts host memory and triggers an OOM panic.\nFree the page before returning -EINVAL, matching the XDP-program error\npath in the same function.(CVE-2026-46321)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntun: free page on build_skb failure in tun_xdp_one()\n\nWhen build_skb() fails in tun_xdp_one(), the function sets ret to\n-ENOMEM and jumps to the out label, which returns without freeing the\npage that vhost_net_build_xdp() allocated for the frame. As with the\nshort-frame rejection path, tun_sendmsg() discards the per-buffer error\nand still returns total_len, so vhost_tx_batch() takes the success path\nand never frees the page. Each build_skb() failure in a batch leaks one\npage-frag chunk.\n\nFree the page before taking the error path, matching the put_page() the\nother error exits of tun_xdp_one() already perform.(CVE-2026-46322)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: gro: don\u0026apos;t merge zcopy skbs\n\nskb_gro_receive() can currently copy frags between the source and GRO\nskb, without checking the zerocopy status, and in particular the\nSKBFL_MANAGED_FRAG_REFS flag.\n\nWhen SKBFL_MANAGED_FRAG_REFS is set, the skb doesn\u0026apos;t hold a reference\non the pages in shinfo-\u0026gt;frags. Appending those frags to another skb\u0026apos;s\nfrags without fixing up the page refcount can lead to UAF.\n\nWhen either the last skb in the GRO chain (the one we would append\nfrags to) or the source skb is zerocopy, don\u0026apos;t merge the skbs.(CVE-2026-46323)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRevert \u0026quot;net/smc: Introduce TCP ULP support\u0026quot;\n\nThis reverts commit d7cd421da9da2cc7b4d25b8537f66db5c8331c40.\n\nAs reported by Al Viro, the TCP ULP support for SMC is fundamentally\nbroken. The implementation attempts to convert an active TCP socket\ninto an SMC socket by modifying the underlying `struct file`, dentry,\nand inode in-place, which violates core VFS invariants that assume\nthese structures are immutable for an open file, creating a risk of\nuse after free errors and general system instability.\n\nGiven the severity of this design flaw and the fact that cleaner\nalternatives (e.g., LD_PRELOAD, BPF) exist for legacy application\ntransparency, the correct course of action is to remove this feature\nentirely.(CVE-2026-46330)",
  "id": "OESA-2026-2869",
  "modified": "2026-08-06T11:11:46Z",
  "published": "2026-07-06T11:11:46Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-2869"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-10263"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39932"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-71203"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23261"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23346"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23377"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31414"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31432"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31440"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31443"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31453"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31466"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31508"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31551"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31557"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31580"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31663"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31664"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31681"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31717"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31725"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43022"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43025"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43026"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43091"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43116"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43125"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43127"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43220"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43239"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43309"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43319"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43323"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43350"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43445"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43448"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45859"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46014"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46174"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46244"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46320"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46321"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46322"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46323"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46330"
    }
  ],
  "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-10263",
    "CVE-2025-39932",
    "CVE-2025-71203",
    "CVE-2026-23261",
    "CVE-2026-23346",
    "CVE-2026-23377",
    "CVE-2026-31414",
    "CVE-2026-31432",
    "CVE-2026-31440",
    "CVE-2026-31443",
    "CVE-2026-31453",
    "CVE-2026-31466",
    "CVE-2026-31508",
    "CVE-2026-31551",
    "CVE-2026-31557",
    "CVE-2026-31580",
    "CVE-2026-31663",
    "CVE-2026-31664",
    "CVE-2026-31681",
    "CVE-2026-31717",
    "CVE-2026-31725",
    "CVE-2026-43022",
    "CVE-2026-43025",
    "CVE-2026-43026",
    "CVE-2026-43091",
    "CVE-2026-43116",
    "CVE-2026-43125",
    "CVE-2026-43127",
    "CVE-2026-43220",
    "CVE-2026-43239",
    "CVE-2026-43309",
    "CVE-2026-43319",
    "CVE-2026-43323",
    "CVE-2026-43350",
    "CVE-2026-43445",
    "CVE-2026-43448",
    "CVE-2026-45859",
    "CVE-2026-46014",
    "CVE-2026-46174",
    "CVE-2026-46244",
    "CVE-2026-46320",
    "CVE-2026-46321",
    "CVE-2026-46322",
    "CVE-2026-46323",
    "CVE-2026-46330"
  ]
}

{
  "affected": [
    {
      "ecosystem_specific": {
        "aarch64": [
          "bpftool-6.6.0-145.1.19.156.oe2403sp1.aarch64.rpm",
          "bpftool-debuginfo-6.6.0-145.1.19.156.oe2403sp1.aarch64.rpm",
          "kernel-6.6.0-145.1.19.156.oe2403sp1.aarch64.rpm",
          "kernel-debuginfo-6.6.0-145.1.19.156.oe2403sp1.aarch64.rpm",
          "kernel-debugsource-6.6.0-145.1.19.156.oe2403sp1.aarch64.rpm",
          "kernel-devel-6.6.0-145.1.19.156.oe2403sp1.aarch64.rpm",
          "kernel-headers-6.6.0-145.1.19.156.oe2403sp1.aarch64.rpm",
          "kernel-source-6.6.0-145.1.19.156.oe2403sp1.aarch64.rpm",
          "kernel-tools-6.6.0-145.1.19.156.oe2403sp1.aarch64.rpm",
          "kernel-tools-debuginfo-6.6.0-145.1.19.156.oe2403sp1.aarch64.rpm",
          "kernel-tools-devel-6.6.0-145.1.19.156.oe2403sp1.aarch64.rpm",
          "perf-6.6.0-145.1.19.156.oe2403sp1.aarch64.rpm",
          "perf-debuginfo-6.6.0-145.1.19.156.oe2403sp1.aarch64.rpm",
          "python3-perf-6.6.0-145.1.19.156.oe2403sp1.aarch64.rpm",
          "python3-perf-debuginfo-6.6.0-145.1.19.156.oe2403sp1.aarch64.rpm"
        ],
        "src": [
          "kernel-6.6.0-145.1.19.156.oe2403sp1.src.rpm"
        ],
        "x86_64": [
          "bpftool-6.6.0-145.1.19.156.oe2403sp1.x86_64.rpm",
          "bpftool-debuginfo-6.6.0-145.1.19.156.oe2403sp1.x86_64.rpm",
          "kernel-6.6.0-145.1.19.156.oe2403sp1.x86_64.rpm",
          "kernel-debuginfo-6.6.0-145.1.19.156.oe2403sp1.x86_64.rpm",
          "kernel-debugsource-6.6.0-145.1.19.156.oe2403sp1.x86_64.rpm",
          "kernel-devel-6.6.0-145.1.19.156.oe2403sp1.x86_64.rpm",
          "kernel-headers-6.6.0-145.1.19.156.oe2403sp1.x86_64.rpm",
          "kernel-source-6.6.0-145.1.19.156.oe2403sp1.x86_64.rpm",
          "kernel-tools-6.6.0-145.1.19.156.oe2403sp1.x86_64.rpm",
          "kernel-tools-debuginfo-6.6.0-145.1.19.156.oe2403sp1.x86_64.rpm",
          "kernel-tools-devel-6.6.0-145.1.19.156.oe2403sp1.x86_64.rpm",
          "perf-6.6.0-145.1.19.156.oe2403sp1.x86_64.rpm",
          "perf-debuginfo-6.6.0-145.1.19.156.oe2403sp1.x86_64.rpm",
          "python3-perf-6.6.0-145.1.19.156.oe2403sp1.x86_64.rpm",
          "python3-perf-debuginfo-6.6.0-145.1.19.156.oe2403sp1.x86_64.rpm"
        ]
      },
      "package": {
        "ecosystem": "openEuler:24.03-LTS-SP1",
        "name": "kernel",
        "purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-24.03-LTS-SP1"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "6.6.0-145.1.19.156.oe2403sp1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "database_specific": {
    "severity": "Critical"
  },
  "details": "The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\n\nArm C1-Ultra, C1-Premium, Neoverse V3 \u0026amp; V3AE, Neoverse V2, Neoverse V1, Neoverse-N2, Neoverse-N1, Cortex-X925, Cortex-X4, Cortex-X3, Cortex-X2, Cortex-X1 \u0026amp; X1C, Cortex-A710, Cortex-A78, A78AE \u0026amp; A78C, Cortex-A77, Cortex-A76 \u0026amp; A76A may allow writes to resources owned by a higher exception level.(CVE-2025-10263)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: let smbd_destroy() call disable_work_sync(\u0026amp;info-\u0026gt;post_send_credits_work)\n\nIn smbd_destroy() we may destroy the memory so we better\nwait until post_send_credits_work is no longer pending\nand will never be started again.\n\nI actually just hit the case using rxe:\n\nWARNING: CPU: 0 PID: 138 at drivers/infiniband/sw/rxe/rxe_verbs.c:1032 rxe_post_recv+0x1ee/0x480 [rdma_rxe]\n...\n[ 5305.686979] [    T138]  smbd_post_recv+0x445/0xc10 [cifs]\n[ 5305.687135] [    T138]  ? srso_alias_return_thunk+0x5/0xfbef5\n[ 5305.687149] [    T138]  ? __kasan_check_write+0x14/0x30\n[ 5305.687185] [    T138]  ? __pfx_smbd_post_recv+0x10/0x10 [cifs]\n[ 5305.687329] [    T138]  ? __pfx__raw_spin_lock_irqsave+0x10/0x10\n[ 5305.687356] [    T138]  ? srso_alias_return_thunk+0x5/0xfbef5\n[ 5305.687368] [    T138]  ? srso_alias_return_thunk+0x5/0xfbef5\n[ 5305.687378] [    T138]  ? _raw_spin_unlock_irqrestore+0x11/0x60\n[ 5305.687389] [    T138]  ? srso_alias_return_thunk+0x5/0xfbef5\n[ 5305.687399] [    T138]  ? get_receive_buffer+0x168/0x210 [cifs]\n[ 5305.687555] [    T138]  smbd_post_send_credits+0x382/0x4b0 [cifs]\n[ 5305.687701] [    T138]  ? __pfx_smbd_post_send_credits+0x10/0x10 [cifs]\n[ 5305.687855] [    T138]  ? __pfx___schedule+0x10/0x10\n[ 5305.687865] [    T138]  ? __pfx__raw_spin_lock_irq+0x10/0x10\n[ 5305.687875] [    T138]  ? queue_delayed_work_on+0x8e/0xa0\n[ 5305.687889] [    T138]  process_one_work+0x629/0xf80\n[ 5305.687908] [    T138]  ? srso_alias_return_thunk+0x5/0xfbef5\n[ 5305.687917] [    T138]  ? __kasan_check_write+0x14/0x30\n[ 5305.687933] [    T138]  worker_thread+0x87f/0x1570\n...\n\nIt means rxe_post_recv was called after rdma_destroy_qp().\nThis happened because put_receive_buffer() was triggered\nby ib_drain_qp() and called:\nqueue_work(info-\u0026gt;workqueue, \u0026amp;info-\u0026gt;post_send_credits_work);(CVE-2025-39932)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nMIPS: ftrace: Fix memory corruption when kernel is located beyond 32 bits\n\nSince commit e424054000878 (\u0026quot;MIPS: Tracing: Reduce the overhead of\ndynamic Function Tracer\u0026quot;), the macro UASM_i_LA_mostly has been used,\nand this macro can generate more than 2 instructions. At the same\ntime, the code in ftrace assumes that no more than 2 instructions can\nbe generated, which is why it stores them in an int[2] array. However,\nas previously noted, the macro UASM_i_LA_mostly (and now UASM_i_LA)\ncauses a buffer overflow when _mcount is beyond 32 bits. This leads to\ncorruption of the variables located in the __read_mostly section.\n\nThis corruption was observed because the variable\n__cpu_primary_thread_mask was corrupted, causing a hang very early\nduring boot.\n\nThis fix prevents the corruption by avoiding the generation of\ninstructions if they could exceed 2 instructions in\nlength. Fortunately, insn_la_mcount is only used if the instrumented\ncode is located outside the kernel code section, so dynamic ftrace can\nstill be used, albeit in a more limited scope. This is still\npreferable to corrupting memory and/or crashing the kernel.(CVE-2025-71109)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nriscv: Sanitize syscall table indexing under speculation\n\nThe syscall number is a user-controlled value used to index into the\nsyscall table. Use array_index_nospec() to clamp this value after the\nbounds check to prevent speculative out-of-bounds access and subsequent\ndata leakage via cache side channels.(CVE-2025-71203)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amd/pm: Disable MMIO access during SMU Mode 1 reset\n\nDuring Mode 1 reset, the ASIC undergoes a reset cycle and becomes\ntemporarily inaccessible via PCIe. Any attempt to access MMIO registers\nduring this window (e.g., from interrupt handlers or other driver threads)\ncan result in uncompleted PCIe transactions, leading to NMI panics or\nsystem hangs.\n\nTo prevent this, set the `no_hw_access` flag to true immediately after\ntriggering the reset. This signals other driver components to skip\nregister accesses while the device is offline.\n\nA memory barrier `smp_mb()` is added to ensure the flag update is\nglobally visible to all cores before the driver enters the sleep/wait\nstate.\n\n(cherry picked from commit 7edb503fe4b6d67f47d8bb0dfafb8e699bb0f8a4)(CVE-2026-23213)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: reject new transactions if the fs is fully read-only\n\n[BUG]\nThere is a bug report where a heavily fuzzed fs is mounted with all\nrescue mount options, which leads to the following warnings during\nunmount:\n\n  BTRFS: Transaction aborted (error -22)\n  Modules linked in:\n  CPU: 0 UID: 0 PID: 9758 Comm: repro.out Not tainted\n  6.19.0-rc5-00002-gb71e635feefc #7 PREEMPT(full)\n  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014\n  RIP: 0010:find_free_extent_update_loop fs/btrfs/extent-tree.c:4208 [inline]\n  RIP: 0010:find_free_extent+0x52f0/0x5d20 fs/btrfs/extent-tree.c:4611\n  Call Trace:\n   \u0026lt;TASK\u0026gt;\n   btrfs_reserve_extent+0x2cd/0x790 fs/btrfs/extent-tree.c:4705\n   btrfs_alloc_tree_block+0x1e1/0x10e0 fs/btrfs/extent-tree.c:5157\n   btrfs_force_cow_block+0x578/0x2410 fs/btrfs/ctree.c:517\n   btrfs_cow_block+0x3c4/0xa80 fs/btrfs/ctree.c:708\n   btrfs_search_slot+0xcad/0x2b50 fs/btrfs/ctree.c:2130\n   btrfs_truncate_inode_items+0x45d/0x2350 fs/btrfs/inode-item.c:499\n   btrfs_evict_inode+0x923/0xe70 fs/btrfs/inode.c:5628\n   evict+0x5f4/0xae0 fs/inode.c:837\n   __dentry_kill+0x209/0x660 fs/dcache.c:670\n   finish_dput+0xc9/0x480 fs/dcache.c:879\n   shrink_dcache_for_umount+0xa0/0x170 fs/dcache.c:1661\n   generic_shutdown_super+0x67/0x2c0 fs/super.c:621\n   kill_anon_super+0x3b/0x70 fs/super.c:1289\n   btrfs_kill_super+0x41/0x50 fs/btrfs/super.c:2127\n   deactivate_locked_super+0xbc/0x130 fs/super.c:474\n   cleanup_mnt+0x425/0x4c0 fs/namespace.c:1318\n   task_work_run+0x1d4/0x260 kernel/task_work.c:233\n   exit_task_work include/linux/task_work.h:40 [inline]\n   do_exit+0x694/0x22f0 kernel/exit.c:971\n   do_group_exit+0x21c/0x2d0 kernel/exit.c:1112\n   __do_sys_exit_group kernel/exit.c:1123 [inline]\n   __se_sys_exit_group kernel/exit.c:1121 [inline]\n   __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1121\n   x64_sys_call+0x2210/0x2210 arch/x86/include/generated/asm/syscalls_64.h:232\n   do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]\n   do_syscall_64+0xe8/0xf80 arch/x86/entry/syscall_64.c:94\n   entry_SYSCALL_64_after_hwframe+0x77/0x7f\n  RIP: 0033:0x44f639\n  Code: Unable to access opcode bytes at 0x44f60f.\n  RSP: 002b:00007ffc15c4e088 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7\n  RAX: ffffffffffffffda RBX: 00000000004c32f0 RCX: 000000000044f639\n  RDX: 000000000000003c RSI: 00000000000000e7 RDI: 0000000000000001\n  RBP: 0000000000000001 R08: ffffffffffffffc0 R09: 0000000000000000\n  R10: 0000000000000000 R11: 0000000000000246 R12: 00000000004c32f0\n  R13: 0000000000000001 R14: 0000000000000000 R15: 0000000000000001\n   \u0026lt;/TASK\u0026gt;\n\nSince rescue mount options will mark the full fs read-only, there should\nbe no new transaction triggered.\n\nBut during unmount we will evict all inodes, which can trigger a new\ntransaction, and triggers warnings on a heavily corrupted fs.\n\n[CAUSE]\nBtrfs allows new transaction even on a read-only fs, this is to allow\nlog replay happen even on read-only mounts, just like what ext4/xfs do.\n\nHowever with rescue mount options, the fs is fully read-only and cannot\nbe remounted read-write, thus in that case we should also reject any new\ntransactions.\n\n[FIX]\nIf we find the fs has rescue mount options, we should treat the fs as\nerror, so that no new transaction can be started.(CVE-2026-23214)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnvme-fc: release admin tagset if init fails\n\nnvme_fabrics creates an NVMe/FC controller in following path:\n\n    nvmf_dev_write()\n      -\u0026gt; nvmf_create_ctrl()\n        -\u0026gt; nvme_fc_create_ctrl()\n          -\u0026gt; nvme_fc_init_ctrl()\n\nnvme_fc_init_ctrl() allocates the admin blk-mq resources right after\nnvme_add_ctrl() succeeds.  If any of the subsequent steps fail (changing\nthe controller state, scheduling connect work, etc.), we jump to the\nfail_ctrl path, which tears down the controller references but never\nfrees the admin queue/tag set.  The leaked blk-mq allocations match the\nkmemleak report seen during blktests nvme/fc.\n\nCheck ctrl-\u0026gt;ctrl.admin_tagset in the fail_ctrl path and call\nnvme_remove_admin_tag_set() when it is set so that all admin queue\nallocations are reclaimed whenever controller setup aborts.(CVE-2026-23261)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nf_conntrack_expect: use expect-\u0026gt;helper\n\nUse expect-\u0026gt;helper in ctnetlink and /proc to dump the helper name.\nUsing nfct_help() without holding a reference to the master conntrack\nis unsafe.\n\nUse exp-\u0026gt;master-\u0026gt;helper in ctnetlink path if userspace does not provide\nan explicit helper when creating an expectation to retain the existing\nbehaviour. The ctnetlink expectation path holds the reference on the\nmaster conntrack and nf_conntrack_expect lock and the nfnetlink glue\npath refers to the master ct that is attached to the skb.(CVE-2026-31414)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: fix OOB write in QUERY_INFO for compound requests\n\nWhen a compound request such as READ + QUERY_INFO(Security) is received,\nand the first command (READ) consumes most of the response buffer,\nksmbd could write beyond the allocated buffer while building a security\ndescriptor.\n\nThe root cause was that smb2_get_info_sec() checked buffer space using\nppntsd_size from xattr, while build_sec_desc() often synthesized a\nsignificantly larger descriptor from POSIX ACLs.\n\nThis patch introduces smb_acl_sec_desc_scratch_len() to accurately\ncompute the final descriptor size beforehand, performs proper buffer\nchecking with smb2_calc_max_out_buf_len(), and uses exact-sized\nallocation + iov pinning.(CVE-2026-31432)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndmaengine: idxd: Fix leaking event log memory\n\nDuring the device remove process, the device is reset, causing the\nconfiguration registers to go back to their default state, which is\nzero. As the driver is checking if the event log support was enabled\nbefore deallocating, it will fail if a reset happened before.\n\nDo not check if the support was enabled, the check for \u0026apos;idxd-\u0026gt;evl\u0026apos;\nbeing valid (only allocated if the HW capability is available) is\nenough.(CVE-2026-31440)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndmaengine: idxd: Fix crash when the event log is disabled\n\nIf reporting errors to the event log is not supported by the hardware,\nand an error that causes Function Level Reset (FLR) is received, the\ndriver will try to restore the event log even if it was not allocated.\n\nAlso, only try to free the event log if it was properly allocated.(CVE-2026-31443)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nxfs: avoid dereferencing log items after push callbacks\n\nAfter xfsaild_push_item() calls iop_push(), the log item may have been\nfreed if the AIL lock was dropped during the push. Background inode\nreclaim or the dquot shrinker can free the log item while the AIL lock\nis not held, and the tracepoints in the switch statement dereference\nthe log item after iop_push() returns.\n\nFix this by capturing the log item type, flags, and LSN before calling\nxfsaild_push_item(), and introducing a new xfs_ail_push_class trace\nevent class that takes these pre-captured values and the ailp pointer\ninstead of the log item pointer.(CVE-2026-31453)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipv4: nexthop: allocate skb dynamically in rtm_get_nexthop()\n\nWhen querying a nexthop object via RTM_GETNEXTHOP, the kernel currently\nallocates a fixed-size skb using NLMSG_GOODSIZE. While sufficient for\nsingle nexthops and small Equal-Cost Multi-Path groups, this fixed\nallocation fails for large nexthop groups like 512 nexthops.\n\nThis results in the following warning splat:\n\n WARNING: net/ipv4/nexthop.c:3395 at rtm_get_nexthop+0x176/0x1c0, CPU#20: rep/4608\n [...]\n RIP: 0010:rtm_get_nexthop (net/ipv4/nexthop.c:3395)\n [...]\n Call Trace:\n  \u0026lt;TASK\u0026gt;\n  rtnetlink_rcv_msg (net/core/rtnetlink.c:6989)\n  netlink_rcv_skb (net/netlink/af_netlink.c:2550)\n  netlink_unicast (net/netlink/af_netlink.c:1319 net/netlink/af_netlink.c:1344)\n  netlink_sendmsg (net/netlink/af_netlink.c:1894)\n  ____sys_sendmsg (net/socket.c:721 net/socket.c:736 net/socket.c:2585)\n  ___sys_sendmsg (net/socket.c:2641)\n  __sys_sendmsg (net/socket.c:2671)\n  do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94)\n  entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)\n  \u0026lt;/TASK\u0026gt;\n\nFix this by allocating the size dynamically using nh_nlmsg_size() and\nusing nlmsg_new(), this is consistent with nexthop_notify() behavior. In\naddition, adjust nh_nlmsg_size_grp() so it calculates the size needed\nbased on flags passed. While at it, also add the size of NHA_FDB for\nnexthop group size calculation as it was missing too.\n\nThis cannot be reproduced via iproute2 as the group size is currently\nlimited and the command fails as follows:\n\naddattr_l ERROR: message exceeded bound of 1048(CVE-2026-31531)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: mac80211: Fix static_branch_dec() underflow for aql_disable.\n\nsyzbot reported static_branch_dec() underflow in aql_enable_write(). [0]\n\nThe problem is that aql_enable_write() does not serialise concurrent\nwrite()s to the debugfs.\n\naql_enable_write() checks static_key_false(\u0026amp;aql_disable.key) and\nlater calls static_branch_inc() or static_branch_dec(), but the\nstate may change between the two calls.\n\naql_disable does not need to track inc/dec.\n\nLet\u0026apos;s use static_branch_enable() and static_branch_disable().\n\n[0]:\nval == 0\nWARNING: kernel/jump_label.c:311 at __static_key_slow_dec_cpuslocked.part.0+0x107/0x120 kernel/jump_label.c:311, CPU#0: syz.1.3155/20288\nModules linked in:\nCPU: 0 UID: 0 PID: 20288 Comm: syz.1.3155 Tainted: G     U       L      syzkaller #0 PREEMPT(full)\nTainted: [U]=USER, [L]=SOFTLOCKUP\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/24/2026\nRIP: 0010:__static_key_slow_dec_cpuslocked.part.0+0x107/0x120 kernel/jump_label.c:311\nCode: f2 c9 ff 5b 5d c3 cc cc cc cc e8 54 f2 c9 ff 48 89 df e8 ac f9 ff ff eb ad e8 45 f2 c9 ff 90 0f 0b 90 eb a2 e8 3a f2 c9 ff 90 \u0026lt;0f\u0026gt; 0b 90 eb 97 48 89 df e8 5c 4b 33 00 e9 36 ff ff ff 0f 1f 80 00\nRSP: 0018:ffffc9000b9f7c10 EFLAGS: 00010293\nRAX: 0000000000000000 RBX: ffffffff9b3e5d40 RCX: ffffffff823c57b4\nRDX: ffff8880285a0000 RSI: ffffffff823c5846 RDI: ffff8880285a0000\nRBP: 0000000000000000 R08: 0000000000000005 R09: 0000000000000000\nR10: 0000000000000000 R11: 0000000000000000 R12: 000000000000000a\nR13: 1ffff9200173ef88 R14: 0000000000000001 R15: ffffc9000b9f7e98\nFS:  00007f530dd726c0(0000) GS:ffff8881245e3000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000200000001140 CR3: 000000007cc4a000 CR4: 00000000003526f0\nCall Trace:\n \u0026lt;TASK\u0026gt;\n __static_key_slow_dec_cpuslocked kernel/jump_label.c:297 [inline]\n __static_key_slow_dec kernel/jump_label.c:321 [inline]\n static_key_slow_dec+0x7c/0xc0 kernel/jump_label.c:336\n aql_enable_write+0x2b2/0x310 net/mac80211/debugfs.c:343\n short_proxy_write+0x133/0x1a0 fs/debugfs/file.c:383\n vfs_write+0x2aa/0x1070 fs/read_write.c:684\n ksys_pwrite64 fs/read_write.c:793 [inline]\n __do_sys_pwrite64 fs/read_write.c:801 [inline]\n __se_sys_pwrite64 fs/read_write.c:798 [inline]\n __x64_sys_pwrite64+0x1eb/0x250 fs/read_write.c:798\n do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]\n do_syscall_64+0xc9/0xf80 arch/x86/entry/syscall_64.c:94\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\nRIP: 0033:0x7f530cf9aeb9\nCode: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 \u0026lt;48\u0026gt; 3d 01 f0 ff ff 73 01 c3 48 c7 c1 e8 ff ff ff f7 d8 64 89 01 48\nRSP: 002b:00007f530dd72028 EFLAGS: 00000246 ORIG_RAX: 0000000000000012\nRAX: ffffffffffffffda RBX: 00007f530d215fa0 RCX: 00007f530cf9aeb9\nRDX: 0000000000000003 RSI: 0000000000000000 RDI: 0000000000000010\nRBP: 00007f530d008c1f R08: 0000000000000000 R09: 0000000000000000\nR10: 4200000000000005 R11: 0000000000000246 R12: 0000000000000000\nR13: 00007f530d216038 R14: 00007f530d215fa0 R15: 00007ffde89fb978\n \u0026lt;/TASK\u0026gt;(CVE-2026-31551)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnvmet: move async event work off nvmet-wq\n\nFor target nvmet_ctrl_free() flushes ctrl-\u0026gt;async_event_work.\nIf nvmet_ctrl_free() runs on nvmet-wq, the flush re-enters workqueue\ncompletion for the same worker:-\n\nA. Async event work queued on nvmet-wq (prior to disconnect):\n  nvmet_execute_async_event()\n     queue_work(nvmet_wq, \u0026amp;ctrl-\u0026gt;async_event_work)\n\n  nvmet_add_async_event()\n     queue_work(nvmet_wq, \u0026amp;ctrl-\u0026gt;async_event_work)\n\nB. Full pre-work chain (RDMA CM path):\n  nvmet_rdma_cm_handler()\n     nvmet_rdma_queue_disconnect()\n       __nvmet_rdma_queue_disconnect()\n         queue_work(nvmet_wq, \u0026amp;queue-\u0026gt;release_work)\n           process_one_work()\n             lock((wq_completion)nvmet-wq)  \u0026lt;--------- 1st\n             nvmet_rdma_release_queue_work()\n\nC. Recursive path (same worker):\n  nvmet_rdma_release_queue_work()\n     nvmet_rdma_free_queue()\n       nvmet_sq_destroy()\n         nvmet_ctrl_put()\n           nvmet_ctrl_free()\n             flush_work(\u0026amp;ctrl-\u0026gt;async_event_work)\n               __flush_work()\n                 touch_wq_lockdep_map()\n                 lock((wq_completion)nvmet-wq) \u0026lt;--------- 2nd\n\nLockdep splat:\n\n  ============================================\n  WARNING: possible recursive locking detected\n  6.19.0-rc3nvme+ #14 Tainted: G                 N\n  --------------------------------------------\n  kworker/u192:42/44933 is trying to acquire lock:\n  ffff888118a00948 ((wq_completion)nvmet-wq){+.+.}-{0:0}, at: touch_wq_lockdep_map+0x26/0x90\n\n  but task is already holding lock:\n  ffff888118a00948 ((wq_completion)nvmet-wq){+.+.}-{0:0}, at: process_one_work+0x53e/0x660\n\n  3 locks held by kworker/u192:42/44933:\n   #0: ffff888118a00948 ((wq_completion)nvmet-wq){+.+.}-{0:0}, at: process_one_work+0x53e/0x660\n   #1: ffffc9000e6cbe28 ((work_completion)(\u0026amp;queue-\u0026gt;release_work)){+.+.}-{0:0}, at: process_one_work+0x1c5/0x660\n   #2: ffffffff82d4db60 (rcu_read_lock){....}-{1:3}, at: __flush_work+0x62/0x530\n\n  Workqueue: nvmet-wq nvmet_rdma_release_queue_work [nvmet_rdma]\n  Call Trace:\n   __flush_work+0x268/0x530\n   nvmet_ctrl_free+0x140/0x310 [nvmet]\n   nvmet_cq_put+0x74/0x90 [nvmet]\n   nvmet_rdma_free_queue+0x23/0xe0 [nvmet_rdma]\n   nvmet_rdma_release_queue_work+0x19/0x50 [nvmet_rdma]\n   process_one_work+0x206/0x660\n   worker_thread+0x184/0x320\n   kthread+0x10c/0x240\n   ret_from_fork+0x319/0x390\n\nMove async event work to a dedicated nvmet-aen-wq to avoid reentrant\nflush on nvmet-wq.(CVE-2026-31557)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbcache: fix cached_dev.sb_bio use-after-free and crash\n\nIn our production environment, we have received multiple crash reports\nregarding libceph, which have caught our attention:\n\n```\n[6888366.280350] Call Trace:\n[6888366.280452]  blk_update_request+0x14e/0x370\n[6888366.280561]  blk_mq_end_request+0x1a/0x130\n[6888366.280671]  rbd_img_handle_request+0x1a0/0x1b0 [rbd]\n[6888366.280792]  rbd_obj_handle_request+0x32/0x40 [rbd]\n[6888366.280903]  __complete_request+0x22/0x70 [libceph]\n[6888366.281032]  osd_dispatch+0x15e/0xb40 [libceph]\n[6888366.281164]  ? inet_recvmsg+0x5b/0xd0\n[6888366.281272]  ? ceph_tcp_recvmsg+0x6f/0xa0 [libceph]\n[6888366.281405]  ceph_con_process_message+0x79/0x140 [libceph]\n[6888366.281534]  ceph_con_v1_try_read+0x5d7/0xf30 [libceph]\n[6888366.281661]  ceph_con_workfn+0x329/0x680 [libceph]\n```\n\nAfter analyzing the coredump file, we found that the address of\ndc-\u0026gt;sb_bio has been freed. We know that cached_dev is only freed when it\nis stopped.\n\nSince sb_bio is a part of struct cached_dev, rather than an alloc every\ntime.  If the device is stopped while writing to the superblock, the\nreleased address will be accessed at endio.\n\nThis patch hopes to wait for sb_write to complete in cached_dev_free.\n\nIt should be noted that we analyzed the cause of the problem, then tell\nall details to the QWEN and adopted the modifications it made.(CVE-2026-31580)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nKVM: x86: Use scratch field in MMIO fragment to hold small write values\n\nWhen exiting to userspace to service an emulated MMIO write, copy the\nto-be-written value to a scratch field in the MMIO fragment if the size\nof the data payload is 8 bytes or less, i.e. can fit in a single chunk,\ninstead of pointing the fragment directly at the source value.\n\nThis fixes a class of use-after-free bugs that occur when the emulator\ninitiates a write using an on-stack, local variable as the source, the\nwrite splits a page boundary, *and* both pages are MMIO pages.  Because\nKVM\u0026apos;s ABI only allows for physically contiguous MMIO requests, accesses\nthat split MMIO pages are separated into two fragments, and are sent to\nuserspace one at a time.  When KVM attempts to complete userspace MMIO in\nresponse to KVM_RUN after the first fragment, KVM will detect the second\nfragment and generate a second userspace exit, and reference the on-stack\nvariable.\n\nThe issue is most visible if the second KVM_RUN is performed by a separate\ntask, in which case the stack of the initiating task can show up as truly\nfreed data.\n\n  ==================================================================\n  BUG: KASAN: use-after-free in complete_emulated_mmio+0x305/0x420\n  Read of size 1 at addr ffff888009c378d1 by task syz-executor417/984\n\n  CPU: 1 PID: 984 Comm: syz-executor417 Not tainted 5.10.0-182.0.0.95.h2627.eulerosv2r13.x86_64 #3\n  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014 Call Trace:\n  dump_stack+0xbe/0xfd\n  print_address_description.constprop.0+0x19/0x170\n  __kasan_report.cold+0x6c/0x84\n  kasan_report+0x3a/0x50\n  check_memory_region+0xfd/0x1f0\n  memcpy+0x20/0x60\n  complete_emulated_mmio+0x305/0x420\n  kvm_arch_vcpu_ioctl_run+0x63f/0x6d0\n  kvm_vcpu_ioctl+0x413/0xb20\n  __se_sys_ioctl+0x111/0x160\n  do_syscall_64+0x30/0x40\n  entry_SYSCALL_64_after_hwframe+0x67/0xd1\n  RIP: 0033:0x42477d\n  Code: \u0026lt;48\u0026gt; 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48\n  RSP: 002b:00007faa8e6890e8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010\n  RAX: ffffffffffffffda RBX: 00000000004d7338 RCX: 000000000042477d\n  RDX: 0000000000000000 RSI: 000000000000ae80 RDI: 0000000000000005\n  RBP: 00000000004d7330 R08: 00007fff28d546df R09: 0000000000000000\n  R10: 0000000000000000 R11: 0000000000000246 R12: 00000000004d733c\n  R13: 0000000000000000 R14: 000000000040a200 R15: 00007fff28d54720\n\n  The buggy address belongs to the page:\n  page:0000000029f6a428 refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x9c37\n  flags: 0xfffffc0000000(node=0|zone=1|lastcpupid=0x1fffff)\n  raw: 000fffffc0000000 0000000000000000 ffffea0000270dc8 0000000000000000\n  raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000 page dumped because: kasan: bad access detected\n\n  Memory state around the buggy address:\n  ffff888009c37780: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff\n  ffff888009c37800: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff\n  \u0026gt;ffff888009c37880: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff\n                                                   ^\n  ffff888009c37900: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff\n  ffff888009c37980: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff\n  ==================================================================\n\nThe bug can also be reproduced with a targeted KVM-Unit-Test by hacking\nKVM to fill a large on-stack variable in complete_emulated_mmio(), i.e. by\noverwrite the data value with garbage.\n\nLimit the use of the scratch fields to 8-byte or smaller accesses, and to\njust writes, as larger accesses and reads are not affected thanks to\nimplementation details in the emulator, but add a sanity check to ensure\nthose details don\u0026apos;t change in the future.  Specifically, KVM never uses\non-stack variables for accesses larger that 8 bytes, e.g. uses an operand\nin the emulator context, and *al\n---truncated---(CVE-2026-31588)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntipc: fix bc_ackers underflow on duplicate GRP_ACK_MSG\n\nThe GRP_ACK_MSG handler in tipc_group_proto_rcv() currently decrements\nbc_ackers on every inbound group ACK, even when the same member has\nalready acknowledged the current broadcast round.\n\nBecause bc_ackers is a u16, a duplicate ACK received after the last\nlegitimate ACK wraps the counter to 65535. Once wrapped,\ntipc_group_bc_cong() keeps reporting congestion and later group\nbroadcasts on the affected socket stay blocked until the group is\nrecreated.\n\nFix this by ignoring duplicate or stale ACKs before touching bc_acked or\nbc_ackers. This makes repeated GRP_ACK_MSG handling idempotent and\nprevents the underflow path.(CVE-2026-31662)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nxfrm: clear trailing padding in build_polexpire()\n\nbuild_expire() clears the trailing padding bytes of struct\nxfrm_user_expire after setting the hard field via memset_after(),\nbut the analogous function build_polexpire() does not do this for\nstruct xfrm_user_polexpire.\n\nThe padding bytes after the __u8 hard field are left\nuninitialized from the heap allocation, and are then sent to\nuserspace via netlink multicast to XFRMNLGRP_EXPIRE listeners,\nleaking kernel heap memory contents.\n\nAdd the missing memset_after() call, matching build_expire().(CVE-2026-31664)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: xt_multiport: validate range encoding in checkentry\n\nports_match_v1() treats any non-zero pflags entry as the start of a\nport range and unconditionally consumes the next ports[] element as\nthe range end.\n\nThe checkentry path currently validates protocol, flags and count, but\nit does not validate the range encoding itself. As a result, malformed\nrules can mark the last slot as a range start or place two range starts\nback to back, leaving ports_match_v1() to step past the last valid\nports[] element while interpreting the rule.\n\nReject malformed multiport v1 rules in checkentry by validating that\neach range start has a following element and that the following element\nis not itself marked as another range start.(CVE-2026-31681)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: validate owner of durable handle on reconnect\n\nCurrently, ksmbd does not verify if the user attempting to reconnect\nto a durable handle is the same user who originally opened the file.\nThis allows any authenticated user to hijack an orphaned durable handle\nby predicting or brute-forcing the persistent ID.\n\nAccording to MS-SMB2, the server MUST verify that the SecurityContext\nof the reconnect request matches the SecurityContext associated with\nthe existing open.\nAdd a durable_owner structure to ksmbd_file to store the original opener\u0026apos;s\nUID, GID, and account name. and catpure the owner information when a file\nhandle becomes orphaned. and implementing ksmbd_vfs_compare_durable_owner()\nto validate the identity of the requester during SMB2_CREATE (DHnC).(CVE-2026-31717)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nusb: gadget: f_ecm: Fix net_device lifecycle with device_move\n\nThe net_device is allocated during function instance creation and\nregistered during the bind phase with the gadget device as its sysfs\nparent. When the function unbinds, the parent device is destroyed, but\nthe net_device survives, resulting in dangling sysfs symlinks:\n\n  console:/ # ls -l /sys/class/net/usb0\n  lrwxrwxrwx ... /sys/class/net/usb0 -\u0026gt;\n  /sys/devices/platform/.../gadget.0/net/usb0\n  console:/ # ls -l /sys/devices/platform/.../gadget.0/net/usb0\n  ls: .../gadget.0/net/usb0: No such file or directory\n\nUse device_move() to reparent the net_device between the gadget device\ntree and /sys/devices/virtual across bind and unbind cycles. During the\nfinal unbind, calling device_move(NULL) moves the net_device to the\nvirtual device tree before the gadget device is destroyed. On rebinding,\ndevice_move() reparents the device back under the new gadget, ensuring\nproper sysfs topology and power management ordering.\n\nTo maintain compatibility with legacy composite drivers (e.g., multi.c),\nthe bound flag is used to indicate whether the network device is shared\nand pre-registered during the legacy driver\u0026apos;s bind phase.(CVE-2026-31725)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nusb: ulpi: fix double free in ulpi_register_interface() error path\n\nWhen device_register() fails, ulpi_register() calls put_device() on\nulpi-\u0026gt;dev.\n\nThe device release callback ulpi_dev_release() drops the OF node\nreference and frees ulpi, but the current error path in\nulpi_register_interface() then calls kfree(ulpi) again, causing a\ndouble free.\n\nLet put_device() handle the cleanup through ulpi_dev_release() and\navoid freeing ulpi again in ulpi_register_interface().(CVE-2026-31759)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: hci_sync: hci_cmd_sync_queue_once() return -EEXIST if exists\n\nhci_cmd_sync_queue_once() needs to indicate whether a queue item was\nadded, so caller can know if callbacks are called, so it can avoid\nleaking resources.\n\nChange the function to return -EEXIST if queue item already exists.\n\nModify all callsites to handle that.(CVE-2026-43022)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: ctnetlink: ignore explicit helper on new expectations\n\nUse the existing master conntrack helper, anything else is not really\nsupported and it just makes validation more complicated, so just ignore\nwhat helper userspace suggests for this expectation.\n\nThis was uncovered when validating CTA_EXPECT_CLASS via different helper\nprovided by userspace than the existing master conntrack helper:\n\n  BUG: KASAN: slab-out-of-bounds in nf_ct_expect_related_report+0x2479/0x27c0\n  Read of size 4 at addr ffff8880043fe408 by task poc/102\n  Call Trace:\n   nf_ct_expect_related_report+0x2479/0x27c0\n   ctnetlink_create_expect+0x22b/0x3b0\n   ctnetlink_new_expect+0x4bd/0x5c0\n   nfnetlink_rcv_msg+0x67a/0x950\n   netlink_rcv_skb+0x120/0x350\n\nAllowing to read kernel memory bytes off the expectation boundary.\n\nCTA_EXPECT_HELP_NAME is still used to offer the helper name to userspace\nvia netlink dump.(CVE-2026-43025)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: ctnetlink: zero expect NAT fields when CTA_EXPECT_NAT absent\n\nctnetlink_alloc_expect() allocates expectations from a non-zeroing\nslab cache via nf_ct_expect_alloc().  When CTA_EXPECT_NAT is not\npresent in the netlink message, saved_addr and saved_proto are\nnever initialized.  Stale data from a previous slab occupant can\nthen be dumped to userspace by ctnetlink_exp_dump_expect(), which\nchecks these fields to decide whether to emit CTA_EXPECT_NAT.\n\nThe safe sibling nf_ct_expect_init(), used by the packet path,\nexplicitly zeroes these fields.\n\nZero saved_addr, saved_proto and dir in the else branch, guarded\nby IS_ENABLED(CONFIG_NF_NAT) since these fields only exist when\nNAT is enabled.\n\nConfirmed by priming the expect slab with NAT-bearing expectations,\nfreeing them, creating a new expectation without CTA_EXPECT_NAT,\nand observing that the ctnetlink dump emits a spurious\nCTA_EXPECT_NAT containing stale data from the prior allocation.(CVE-2026-43026)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: x_tables: ensure names are nul-terminated\n\nReject names that lack a \\0 character before feeding them\nto functions that expect c-strings.\n\nFixes tag is the most recent commit that needs this change.(CVE-2026-43028)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: ioam6: fix OOB and missing lock\n\nWhen trace-\u0026gt;type.bit6 is set:\n\n    if (trace-\u0026gt;type.bit6) {\n        ...\n        queue = skb_get_tx_queue(dev, skb);\n        qdisc = rcu_dereference(queue-\u0026gt;qdisc);\n\nThis code can lead to an out-of-bounds access of the dev-\u0026gt;_tx[] array\nwhen is_input is true. In such a case, the packet is on the RX path and\nskb-\u0026gt;queue_mapping contains the RX queue index of the ingress device. If\nthe ingress device has more RX queues than the egress device (dev) has\nTX queues, skb_get_queue_mapping(skb) will exceed dev-\u0026gt;num_tx_queues.\nAdd a check to avoid this situation since skb_get_tx_queue() does not\nclamp the index. This issue has also revealed that per queue visibility\ncannot be accurate and will be replaced later as a new feature.\n\nWhile at it, add missing lock around qdisc_qstats_qlen_backlog(). The\nfunction __ioam6_fill_trace_data() is called from both softirq and\nprocess contexts, hence the use of spin_lock_bh() here.(CVE-2026-43083)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nxfrm: Wait for RCU readers during policy netns exit\n\nxfrm_policy_fini() frees the policy_bydst hash tables after flushing the\npolicy work items and deleting all policies, but it does not wait for\nconcurrent RCU readers to leave their read-side critical sections first.\n\nThe policy_bydst tables are published via rcu_assign_pointer() and are\nlooked up through rcu_dereference_check(), so netns teardown must also\nwait for an RCU grace period before freeing the table memory.\n\nFix this by adding synchronize_rcu() before freeing the policy hash tables.(CVE-2026-43091)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipv4: icmp: fix null-ptr-deref in icmp_build_probe()\n\nipv6_stub-\u0026gt;ipv6_dev_find() may return ERR_PTR(-EAFNOSUPPORT) when the\nIPv6 stack is not active (CONFIG_IPV6=m and not loaded), and passing\nthis error pointer to dev_hold() will cause a kernel crash with\nnull-ptr-deref.\n\nInstead, silently discard the request. RFC 8335 does not appear to\ndefine a specific response for the case where an IPv6 interface\nidentifier is syntactically valid but the implementation cannot perform\nthe lookup at runtime, and silently dropping the request may safer than\nmisreporting \u0026quot;No Such Interface\u0026quot;.(CVE-2026-43099)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipv6: ioam: fix potential NULL dereferences in __ioam6_fill_trace_data()\n\nWe need to check __in6_dev_get() for possible NULL value, as\nsuggested by Yiming Qian.\n\nAlso add skb_dst_dev_rcu() instead of skb_dst_dev(),\nand two missing READ_ONCE().\n\nNote that @dev can\u0026apos;t be NULL.(CVE-2026-43101)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: ctnetlink: ensure safe access to master conntrack\n\nHolding reference on the expectation is not sufficient, the master\nconntrack object can just go away, making exp-\u0026gt;master invalid.\n\nTo access exp-\u0026gt;master safely:\n\n- Grab the nf_conntrack_expect_lock, this gets serialized with\n  clean_from_lists() which also holds this lock when the master\n  conntrack goes away.\n\n- Hold reference on master conntrack via nf_conntrack_find_get().\n  Not so easy since the master tuple to look up for the master conntrack\n  is not available in the existing problematic paths.\n\nThis patch goes for extending the nf_conntrack_expect_lock section\nto address this issue for simplicity, in the cases that are described\nbelow this is just slightly extending the lock section.\n\nThe add expectation command already holds a reference to the master\nconntrack from ctnetlink_create_expect().\n\nHowever, the delete expectation command needs to grab the spinlock\nbefore looking up for the expectation. Expand the existing spinlock\nsection to address this to cover the expectation lookup. Note that,\nthe nf_ct_expect_iterate_net() calls already grabs the spinlock while\niterating over the expectation table, which is correct.\n\nThe get expectation command needs to grab the spinlock to ensure master\nconntrack does not go away. This also expands the existing spinlock\nsection to cover the expectation lookup too. I needed to move the\nnetlink skb allocation out of the spinlock to keep it GFP_KERNEL.\n\nFor the expectation events, the IPEXP_DESTROY event is already delivered\nunder the spinlock, just move the delivery of IPEXP_NEW under the\nspinlock too because the master conntrack event cache is reached through\nexp-\u0026gt;master.\n\nWhile at it, add lockdep notations to help identify what codepaths need\nto grab the spinlock.(CVE-2026-43116)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndlm: validate length in dlm_search_rsb_tree\n\nThe len parameter in dlm_dump_rsb_name() is not validated and comes\nfrom network messages. When it exceeds DLM_RESNAME_MAXLEN, it can\ncause out-of-bounds write in dlm_search_rsb_tree().\n\nAdd length validation to prevent potential buffer overflow.(CVE-2026-43125)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nntfs3: fix circular locking dependency in run_unpack_ex\n\nSyzbot reported a circular locking dependency between wnd-\u0026gt;rw_lock\n(sbi-\u0026gt;used.bitmap) and ni-\u0026gt;file.run_lock.\n\nThe deadlock scenario:\n1. ntfs_extend_mft() takes ni-\u0026gt;file.run_lock then wnd-\u0026gt;rw_lock.\n2. run_unpack_ex() takes wnd-\u0026gt;rw_lock then tries to acquire\n   ni-\u0026gt;file.run_lock inside ntfs_refresh_zone().\n\nThis creates an AB-BA deadlock.\n\nFix this by using down_read_trylock() instead of down_read() when\nacquiring run_lock in run_unpack_ex(). If the lock is contended,\nskip ntfs_refresh_zone() - the MFT zone will be refreshed on the\nnext MFT operation. This breaks the circular dependency since we\nnever block waiting for run_lock while holding wnd-\u0026gt;rw_lock.(CVE-2026-43127)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: usb: pegasus: enable basic endpoint checking\n\npegasus_probe() fills URBs with hardcoded endpoint pipes without\nverifying the endpoint descriptors:\n\n  - usb_rcvbulkpipe(dev, 1) for RX data\n  - usb_sndbulkpipe(dev, 2) for TX data\n  - usb_rcvintpipe(dev, 3)  for status interrupts\n\nA malformed USB device can present these endpoints with transfer types\nthat differ from what the driver assumes.\n\nAdd a pegasus_usb_ep enum for endpoint numbers, replacing magic\nconstants throughout. Add usb_check_bulk_endpoints() and\nusb_check_int_endpoints() calls before any resource allocation to\nverify endpoint types before use, rejecting devices with mismatched\ndescriptors at probe time, and avoid triggering assertion.\n\nSimilar fix to\n- commit 90b7f2961798 (\u0026quot;net: usb: rtl8150: enable basic endpoint checking\u0026quot;)\n- commit 9e7021d2aeae (\u0026quot;net: usb: catc: enable basic endpoint checking\u0026quot;)(CVE-2026-43156)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmd/bitmap: fix GPF in write_page caused by resize race\n\nA General Protection Fault occurs in write_page() during array resize:\nRIP: 0010:write_page+0x22b/0x3c0 [md_mod]\n\nThis is a use-after-free race between bitmap_daemon_work() and\n__bitmap_resize(). The daemon iterates over `bitmap-\u0026gt;storage.filemap`\nwithout locking, while the resize path frees that storage via\nmd_bitmap_file_unmap(). `quiesce()` does not stop the md thread,\nallowing concurrent access to freed pages.\n\nFix by holding `mddev-\u0026gt;bitmap_info.mutex` during the bitmap update.(CVE-2026-43163)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: usb: kaweth: remove TX queue manipulation in kaweth_set_rx_mode\n\nkaweth_set_rx_mode(), the ndo_set_rx_mode callback, calls\nnetif_stop_queue() and netif_wake_queue(). These are TX queue flow\ncontrol functions unrelated to RX multicast configuration.\n\nThe premature netif_wake_queue() can re-enable TX while tx_urb is still\nin-flight, leading to a double usb_submit_urb() on the same URB:\n\nkaweth_start_xmit() {\n    netif_stop_queue();\n    usb_submit_urb(kaweth-\u0026gt;tx_urb);\n}\n\nkaweth_set_rx_mode() {\n    netif_stop_queue();\n    netif_wake_queue();             // wakes TX queue before URB is done\n}\n\nkaweth_start_xmit() {\n    netif_stop_queue();\n    usb_submit_urb(kaweth-\u0026gt;tx_urb); // URB submitted while active\n}\n\nThis triggers the WARN in usb_submit_urb():\n\n  \u0026quot;URB submitted while active\u0026quot;\n\nThis is a similar class of bug fixed in rtl8150 by\n\n- commit 958baf5eaee3 (\u0026quot;net: usb: Remove disruptive netif_wake_queue in rtl8150_set_multicast\u0026quot;).\n\nAlso kaweth_set_rx_mode() is already functionally broken, the\nreal set_rx_mode action is performed by kaweth_async_set_rx_mode(),\nwhich in turn is not a no-op only at ndo_open() time.(CVE-2026-43180)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipv6: ioam: fix heap buffer overflow in __ioam6_fill_trace_data()\n\nOn the receive path, __ioam6_fill_trace_data() uses trace-\u0026gt;nodelen\nto decide how much data to write for each node. It trusts this field\nas-is from the incoming packet, with no consistency check against\ntrace-\u0026gt;type (the 24-bit field that tells which data items are\npresent). A crafted packet can set nodelen=0 while setting type bits\n0-21, causing the function to write ~100 bytes past the allocated\nregion (into skb_shared_info), which corrupts adjacent heap memory\nand leads to a kernel panic.\n\nAdd a shared helper ioam6_trace_compute_nodelen() in ioam6.c to\nderive the expected nodelen from the type field, and use it:\n\n  - in ioam6_iptunnel.c (send path, existing validation) to replace\n    the open-coded computation;\n  - in exthdrs.c (receive path, ipv6_hop_ioam) to drop packets whose\n    nodelen is inconsistent with the type field, before any data is\n    written.\n\nPer RFC 9197, bits 12-21 are each short (4-octet) fields, so they\nare included in IOAM6_MASK_SHORT_FIELDS (changed from 0xff100000 to\n0xff1ffc00).(CVE-2026-43186)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: consume xmit errors of GSO frames\n\nudpgro_frglist.sh and udpgro_bench.sh are the flakiest tests\ncurrently in NIPA. They fail in the same exact way, TCP GRO\ntest stalls occasionally and the test gets killed after 10min.\n\nThese tests use veth to simulate GRO. They attach a trivial\n(\u0026quot;return XDP_PASS;\u0026quot;) XDP program to the veth to force TSO off\nand NAPI on.\n\nDigging into the failure mode we can see that the connection\nis completely stuck after a burst of drops. The sender\u0026apos;s snd_nxt\nis at sequence number N [1], but the receiver claims to have\nreceived (rcv_nxt) up to N + 3 * MSS [2]. Last piece of the puzzle\nis that senders rtx queue is not empty (let\u0026apos;s say the block in\nthe rtx queue is at sequence number N - 4 * MSS [3]).\n\nIn this state, sender sends a retransmission from the rtx queue\nwith a single segment, and sequence numbers N-4*MSS:N-3*MSS [3].\nReceiver sees it and responds with an ACK all the way up to\nN + 3 * MSS [2]. But sender will reject this ack as TCP_ACK_UNSENT_DATA\nbecause it has no recollection of ever sending data that far out [1].\nAnd we are stuck.\n\nThe root cause is the mess of the xmit return codes. veth returns\nan error when it can\u0026apos;t xmit a frame. We end up with a loss event\nlike this:\n\n  -------------------------------------------------\n  |   GSO super frame 1   |   GSO super frame 2   |\n  |-----------------------------------------------|\n  | seg | seg | seg | seg | seg | seg | seg | seg |\n  |  1  |  2  |  3  |  4  |  5  |  6  |  7  |  8  |\n  -------------------------------------------------\n     x    ok    ok    \u0026lt;ok\u0026gt;|  ok    ok    ok   \u0026lt;x\u0026gt;\n                          \\\\\n\t\t\t   snd_nxt\n\n\u0026quot;x\u0026quot; means packet lost by veth, and \u0026quot;ok\u0026quot; means it went thru.\nSince veth has TSO disabled in this test it sees individual segments.\nSegment 1 is on the retransmit queue and will be resent.\n\nSo why did the sender not advance snd_nxt even tho it clearly did\nsend up to seg 8? tcp_write_xmit() interprets the return code\nfrom the core to mean that data has not been sent at all. Since\nTCP deals with GSO super frames, not individual segment the crux\nof the problem is that loss of a single segment can be interpreted\nas loss of all. TCP only sees the last return code for the last\nsegment of the GSO frame (in \u0026lt;\u0026gt; brackets in the diagram above).\n\nOf course for the problem to occur we need a setup or a device\nwithout a Qdisc. Otherwise Qdisc layer disconnects the protocol\nlayer from the device errors completely.\n\nWe have multiple ways to fix this.\n\n 1) make veth not return an error when it lost a packet.\n    While this is what I think we did in the past, the issue keeps\n    reappearing and it\u0026apos;s annoying to debug. The game of whack\n    a mole is not great.\n\n 2) fix the damn return codes\n    We only talk about NETDEV_TX_OK and NETDEV_TX_BUSY in the\n    documentation, so maybe we should make the return code from\n    ndo_start_xmit() a boolean. I like that the most, but perhaps\n    some ancient, not-really-networking protocol would suffer.\n\n 3) make TCP ignore the errors\n    It is not entirely clear to me what benefit TCP gets from\n    interpreting the result of ip_queue_xmit()? Specifically once\n    the connection is established and we\u0026apos;re pushing data - packet\n    loss is just packet loss?\n\n 4) this fix\n    Ignore the rc in the Qdisc-less+GSO case, since it\u0026apos;s unreliable.\n    We already always return OK in the TCQ_F_CAN_BYPASS case.\n    In the Qdisc-less case let\u0026apos;s be a bit more conservative and only\n    mask the GSO errors. This path is taken by non-IP-\u0026quot;networks\u0026quot;\n    like CAN, MCTP etc, so we could regress some ancient thing.\n    This is the simplest, but also maybe the hackiest fix?\n\nSimilar fix has been proposed by Eric in the past but never committed\nbecause original reporter was working with an OOT driver and wasn\u0026apos;t\nproviding feedback (see Link).(CVE-2026-43194)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetconsole: avoid OOB reads, msg is not nul-terminated\n\nmsg passed to netconsole from the console subsystem is not guaranteed\nto be nul-terminated. Before recent\ncommit 7eab73b18630 (\u0026quot;netconsole: convert to NBCON console infrastructure\u0026quot;)\nthe message would be placed in printk_shared_pbufs, a static global\nbuffer, so KASAN had harder time catching OOB accesses. Now we see:\n\n    printk: console [netcon_ext0] enabled\n    BUG: KASAN: slab-out-of-bounds in string+0x1f7/0x240\n    Read of size 1 at addr ffff88813b6d4c00 by task pr/netcon_ext0/594\n\n    CPU: 65 UID: 0 PID: 594 Comm: pr/netcon_ext0 Not tainted 6.19.0-11754-g4246fd6547c9\n    Call Trace:\n     kasan_report+0xe4/0x120\n     string+0x1f7/0x240\n     vsnprintf+0x655/0xba0\n     scnprintf+0xba/0x120\n     netconsole_write+0x3fe/0xa10\n     nbcon_emit_next_record+0x46e/0x860\n     nbcon_kthread_func+0x623/0x750\n\n    Allocated by task 1:\n     nbcon_alloc+0x1ea/0x450\n     register_console+0x26b/0xe10\n     init_netconsole+0xbb0/0xda0\n\n    The buggy address belongs to the object at ffff88813b6d4000\n                which belongs to the cache kmalloc-4k of size 4096\n    The buggy address is located 0 bytes to the right of\n                allocated 3072-byte region [ffff88813b6d4000, ffff88813b6d4c00)(CVE-2026-43197)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\niommu/amd: serialize sequence allocation under concurrent TLB invalidations\n\nWith concurrent TLB invalidations, completion wait randomly gets timed out\nbecause cmd_sem_val was incremented outside the IOMMU spinlock, allowing\nCMD_COMPL_WAIT commands to be queued out of sequence and breaking the\nordering assumption in wait_on_sem().\nMove the cmd_sem_val increment under iommu-\u0026gt;lock so completion sequence\nallocation is serialized with command queuing.\nAnd remove the unnecessary return.(CVE-2026-43220)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: prevent races in -\u0026gt;query_interfaces()\n\nIt was possible for two query interface works to be concurrently trying\nto update the interfaces.\n\nPrevent this by checking and updating iface_last_update under\niface_lock.(CVE-2026-43239)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nx86/kexec: add a sanity check on previous kernel\u0026apos;s ima kexec buffer\n\nWhen the second-stage kernel is booted via kexec with a limiting command\nline such as \u0026quot;mem=\u0026lt;size\u0026gt;\u0026quot;, the physical range that contains the carried\nover IMA measurement list may fall outside the truncated RAM leading to a\nkernel panic.\n\n    BUG: unable to handle page fault for address: ffff97793ff47000\n    RIP: ima_restore_measurement_list+0xdc/0x45a\n    #PF: error_code(0x0000) \u2013 not-present page\n\nOther architectures already validate the range with page_is_ram(), as done\nin commit cbf9c4b9617b (\u0026quot;of: check previous kernel\u0026apos;s ima-kexec-buffer\nagainst memory bounds\u0026quot;) do a similar check on x86.\n\nWithout carrying the measurement list across kexec, the attestation\nwould fail.(CVE-2026-43240)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\next4: move ext4_percpu_param_init() before ext4_mb_init()\n\nWhen running `kvm-xfstests -c ext4/1k -C 1 generic/383` with the\n`DOUBLE_CHECK` macro defined, the following panic is triggered:\n\n==================================================================\nEXT4-fs error (device vdc): ext4_validate_block_bitmap:423:\n                        comm mount: bg 0: bad block bitmap checksum\nBUG: unable to handle page fault for address: ff110000fa2cc000\nPGD 3e01067 P4D 3e02067 PUD 0\nOops: Oops: 0000 [#1] SMP NOPTI\nCPU: 0 UID: 0 PID: 2386 Comm: mount Tainted: G W\n                        6.18.0-gba65a4e7120a-dirty #1152 PREEMPT(none)\nRIP: 0010:percpu_counter_add_batch+0x13/0xa0\nCall Trace:\n \u0026lt;TASK\u0026gt;\n ext4_mark_group_bitmap_corrupted+0xcb/0xe0\n ext4_validate_block_bitmap+0x2a1/0x2f0\n ext4_read_block_bitmap+0x33/0x50\n mb_group_bb_bitmap_alloc+0x33/0x80\n ext4_mb_add_groupinfo+0x190/0x250\n ext4_mb_init_backend+0x87/0x290\n ext4_mb_init+0x456/0x640\n __ext4_fill_super+0x1072/0x1680\n ext4_fill_super+0xd3/0x280\n get_tree_bdev_flags+0x132/0x1d0\n vfs_get_tree+0x29/0xd0\n vfs_cmd_create+0x59/0xe0\n __do_sys_fsconfig+0x4f6/0x6b0\n do_syscall_64+0x50/0x1f0\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n==================================================================\n\nThis issue can be reproduced using the following commands:\n        mkfs.ext4 -F -q -b 1024 /dev/sda 5G\n        tune2fs -O quota,project /dev/sda\n        mount /dev/sda /tmp/test\n\nWith DOUBLE_CHECK defined, mb_group_bb_bitmap_alloc() reads\nand validates the block bitmap. When the validation fails,\next4_mark_group_bitmap_corrupted() attempts to update\nsbi-\u0026gt;s_freeclusters_counter. However, this percpu_counter has not been\ninitialized yet at this point, which leads to the panic described above.\n\nFix this by moving the execution of ext4_percpu_param_init() to occur\nbefore ext4_mb_init(), ensuring the per-CPU counters are initialized\nbefore they are used.(CVE-2026-43288)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmd raid: fix hang when stopping arrays with metadata through dm-raid\n\nWhen using device-mapper\u0026apos;s dm-raid target, stopping a RAID array can cause\nthe system to hang under specific conditions.\n\nThis occurs when:\n\n- A dm-raid managed device tree is suspended from top to bottom\n   (the top-level RAID device is suspended first, followed by its\n    underlying metadata and data devices)\n\n- The top-level RAID device is then removed\n\nRemoving the top-level device triggers a hang in the following sequence:\nthe dm-raid destructor calls md_stop(), which tries to flush the\nwrite-intent bitmap by writing to the metadata sub-devices. However, these\ndevices are already suspended, making them unable to complete the write-intent\noperations and causing an indefinite block.\n\nFix:\n\n- Prevent bitmap flushing when md_stop() is called from dm-raid\ndestructor context\n  and avoid a quiescing/unquescing cycle which could also cause I/O\n\n- Still allow write-intent bitmap flushing when called from dm-raid\nsuspend context\n\nThis ensures that RAID array teardown can complete successfully even when the\nunderlying devices are in a suspended state.\n\nThis second patch uses md_is_rdwr() to distinguish between suspend and\ndestructor paths as elaborated on above.(CVE-2026-43309)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nspi: spidev: fix lock inversion between spi_lock and buf_lock\n\nThe spidev driver previously used two mutexes, spi_lock and buf_lock,\nbut acquired them in different orders depending on the code path:\n\n  write()/read(): buf_lock -\u0026gt; spi_lock\n  ioctl():       spi_lock -\u0026gt; buf_lock\n\nThis AB-BA locking pattern triggers lockdep warnings and can\ncause real deadlocks:\n\n  WARNING: possible circular locking dependency detected\n  spidev_ioctl() -\u0026gt; mutex_lock(\u0026amp;spidev-\u0026gt;buf_lock)\n  spidev_sync_write() -\u0026gt; mutex_lock(\u0026amp;spidev-\u0026gt;spi_lock)\n  *** DEADLOCK ***\n\nThe issue is reproducible with a simple userspace program that\nperforms write() and SPI_IOC_WR_MAX_SPEED_HZ ioctl() calls from\nseparate threads on the same spidev file descriptor.\n\nFix this by simplifying the locking model and removing the lock\ninversion entirely. spidev_sync() no longer performs any locking,\nand all callers serialize access using spi_lock.\n\nbuf_lock is removed since its functionality is fully covered by\nspi_lock, eliminating the possibility of lock ordering issues.\n\nThis removes the lock inversion and prevents deadlocks without\nchanging userspace ABI or behaviour.(CVE-2026-43319)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: SMP: force responder MITM requirements before building the pairing response\n\nsmp_cmd_pairing_req() currently builds the pairing response from the\ninitiator auth_req before enforcing the local BT_SECURITY_HIGH\nrequirement. If the initiator omits SMP_AUTH_MITM, the response can\nalso omit it even though the local side still requires MITM.\n\ntk_request() then sees an auth value without SMP_AUTH_MITM and may\nselect JUST_CFM, making method selection inconsistent with the pairing\npolicy the responder already enforces.\n\nWhen the local side requires HIGH security, first verify that MITM can\nbe achieved from the IO capabilities and then force SMP_AUTH_MITM in the\nresponse in both rsp.auth_req and auth. This keeps the responder auth bits\nand later method selection aligned.(CVE-2026-43334)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: require a full NFS mode SID before reading mode bits\n\nparse_dacl() treats an ACE SID matching sid_unix_NFS_mode as an NFS\nmode SID and reads sid.sub_auth[2] to recover the mode bits.\n\nThat assumes the ACE carries three subauthorities, but compare_sids()\nonly compares min(a, b) subauthorities.  A malicious server can return\nan ACE with num_subauth = 2 and sub_auth[] = {88, 3}, which still\nmatches sid_unix_NFS_mode and then drives the sub_auth[2] read four\nbytes past the end of the ACE.\n\nRequire num_subauth \u0026gt;= 3 before treating the ACE as an NFS mode SID.\nThis keeps the fix local to the special-SID mode path without changing\ncompare_sids() semantics for the rest of cifsacl.(CVE-2026-43350)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nio_uring/kbuf: check if target buffer list is still legacy on recycle\n\nThere\u0026apos;s a gap between when the buffer was grabbed and when it\npotentially gets recycled, where if the list is empty, someone could\u0026apos;ve\nupgraded it to a ring provided type. This can happen if the request\nis forced via io-wq. The legacy recycling is missing checking if the\nbuffer_list still exists, and if it\u0026apos;s of the correct type. Add those\nchecks.(CVE-2026-43366)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nlibceph: prevent potential out-of-bounds reads in process_message_header()\n\nIf the message frame is (maliciously) corrupted in a way that the\nlength of the control segment ends up being less than the size of the\nmessage header or a different frame is made to look like a message\nframe, out-of-bounds reads may ensue in process_message_header().\n\nPerform an explicit bounds check before decoding the message header.(CVE-2026-43406)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ne1000/e1000e: Fix leak in DMA error cleanup\n\nIf an error is encountered while mapping TX buffers, the driver should\nunmap any buffers already mapped for that skb.\n\nBecause count is incremented after a successful mapping, it will always\nmatch the correct number of unmappings needed when dma_error is reached.\nDecrementing count before the while loop in dma_error causes an\noff-by-one error. If any mapping was successful before an unsuccessful\nmapping, exactly one DMA mapping would leak.\n\nIn these commits, a faulty while condition caused an infinite loop in\ndma_error:\nCommit 03b1320dfcee (\u0026quot;e1000e: remove use of skb_dma_map from e1000e\ndriver\u0026quot;)\nCommit 602c0554d7b0 (\u0026quot;e1000: remove use of skb_dma_map from e1000 driver\u0026quot;)\n\nCommit c1fa347f20f1 (\u0026quot;e1000/e1000e/igb/igbvf/ixgb/ixgbe: Fix tests of\nunsigned in *_tx_map()\u0026quot;) fixed the infinite loop, but introduced the\noff-by-one error.\n\nThis issue may still exist in the igbvf driver, but I did not address it\nin this patch.(CVE-2026-43445)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5e: Fix DMA FIFO desync on error CQE SQ recovery\n\nIn case of a TX error CQE, a recovery flow is triggered,\nmlx5e_reset_txqsq_cc_pc() resets dma_fifo_cc to 0 but not dma_fifo_pc,\ndesyncing the DMA FIFO producer and consumer.\n\nAfter recovery, the producer pushes new DMA entries at the old\ndma_fifo_pc, while the consumer reads from position 0.\nThis causes us to unmap stale DMA addresses from before the recovery.\n\nThe DMA FIFO is a purely software construct with no HW counterpart.\nAt the point of reset, all WQEs have been flushed so dma_fifo_cc is\nalready equal to dma_fifo_pc. There is no need to reset either counter,\nsimilar to how skb_fifo pc/cc are untouched.\n\nRemove the \u0026apos;dma_fifo_cc = 0\u0026apos; reset.\n\nThis fixes the following WARNING:\n    WARNING: CPU: 0 PID: 0 at drivers/iommu/dma-iommu.c:1240 iommu_dma_unmap_page+0x79/0x90\n    Modules linked in: mlx5_vdpa vringh vdpa bonding mlx5_ib mlx5_vfio_pci ipip mlx5_fwctl tunnel4 mlx5_core ib_ipoib geneve ip6_gre ip_gre gre nf_tables ip6_tunnel rdma_ucm ib_uverbs ib_umad vfio_pci vfio_pci_core act_mirred act_skbedit act_vlan vhost_net vhost tap ip6table_mangle ip6table_nat ip6table_filter ip6_tables iptable_mangle cls_matchall nfnetlink_cttimeout act_gact cls_flower sch_ingress vhost_iotlb iptable_raw tunnel6 vfio_iommu_type1 vfio openvswitch nsh rpcsec_gss_krb5 auth_rpcgss oid_registry xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink iptable_nat nf_nat xt_addrtype br_netfilter overlay zram zsmalloc rpcrdma ib_iser libiscsi scsi_transport_iscsi rdma_cm iw_cm ib_cm ib_core fuse [last unloaded: nf_tables]\n    CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.13.0-rc5_for_upstream_min_debug_2024_12_30_21_33 #1\n    Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014\n    RIP: 0010:iommu_dma_unmap_page+0x79/0x90\n    Code: 2b 4d 3b 21 72 26 4d 3b 61 08 73 20 49 89 d8 44 89 f9 5b 4c 89 f2 4c 89 e6 48 89 ef 5d 41 5c 41 5d 41 5e 41 5f e9 c7 ae 9e ff \u0026lt;0f\u0026gt; 0b 5b 5d 41 5c 41 5d 41 5e 41 5f c3 66 2e 0f 1f 84 00 00 00 00\n    Call Trace:\n     \u0026lt;IRQ\u0026gt;\n     ? __warn+0x7d/0x110\n     ? iommu_dma_unmap_page+0x79/0x90\n     ? report_bug+0x16d/0x180\n     ? handle_bug+0x4f/0x90\n     ? exc_invalid_op+0x14/0x70\n     ? asm_exc_invalid_op+0x16/0x20\n     ? iommu_dma_unmap_page+0x79/0x90\n     ? iommu_dma_unmap_page+0x2e/0x90\n     dma_unmap_page_attrs+0x10d/0x1b0\n     mlx5e_tx_wi_dma_unmap+0xbe/0x120 [mlx5_core]\n     mlx5e_poll_tx_cq+0x16d/0x690 [mlx5_core]\n     mlx5e_napi_poll+0x8b/0xac0 [mlx5_core]\n     __napi_poll+0x24/0x190\n     net_rx_action+0x32a/0x3b0\n     ? mlx5_eq_comp_int+0x7e/0x270 [mlx5_core]\n     ? notifier_call_chain+0x35/0xa0\n     handle_softirqs+0xc9/0x270\n     irq_exit_rcu+0x71/0xd0\n     common_interrupt+0x7f/0xa0\n     \u0026lt;/IRQ\u0026gt;\n     \u0026lt;TASK\u0026gt;\n     asm_common_interrupt+0x22/0x40(CVE-2026-43466)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5: Fix deadlock between devlink lock and esw-\u0026gt;wq\n\nesw-\u0026gt;work_queue executes esw_functions_changed_event_handler -\u0026gt;\nesw_vfs_changed_event_handler and acquires the devlink lock.\n\n.eswitch_mode_set (acquires devlink lock in devlink_nl_pre_doit) -\u0026gt;\nmlx5_devlink_eswitch_mode_set -\u0026gt; mlx5_eswitch_disable_locked -\u0026gt;\nmlx5_eswitch_event_handler_unregister -\u0026gt; flush_workqueue deadlocks\nwhen esw_vfs_changed_event_handler executes.\n\nFix that by no longer flushing the work to avoid the deadlock, and using\na generation counter to keep track of work relevance. This avoids an old\nhandler manipulating an esw that has undergone one or more mode changes:\n- the counter is incremented in mlx5_eswitch_event_handler_unregister.\n- the counter is read and passed to the ephemeral mlx5_host_work struct.\n- the work handler takes the devlink lock and bails out if the current\n  generation is different than the one it was scheduled to operate on.\n- mlx5_eswitch_cleanup does the final draining before destroying the wq.\n\nNo longer flushing the workqueue has the side effect of maybe no longer\ncancelling pending vport_change_handler work items, but that\u0026apos;s ok since\nthose are disabled elsewhere:\n- mlx5_eswitch_disable_locked disables the vport eq notifier.\n- mlx5_esw_vport_disable disarms the HW EQ notification and marks\n  vport-\u0026gt;enabled under state_lock to false to prevent pending vport\n  handler from doing anything.\n- mlx5_eswitch_cleanup destroys the workqueue and makes sure all events\n  are disabled/finished.(CVE-2026-43468)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: L2CAP: Fix null-ptr-deref in l2cap_sock_state_change_cb()\n\nAdd the same NULL guard already present in\nl2cap_sock_resume_cb() and l2cap_sock_ready_cb().(CVE-2026-45834)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nfnetlink_queue: do shared-unconfirmed check before segmentation\n\nUlrich reports a regression with nfqueue:\n\nIf an application did not set the \u0026apos;F_GSO\u0026apos; capability flag and a gso\npacket with an unconfirmed nf_conn entry is received all packets are\nnow dropped instead of queued, because the check happens after\nskb_gso_segment().  In that case, we did have exclusive ownership\nof the skb and its associated conntrack entry.  The elevated use\ncount is due to skb_clone happening via skb_gso_segment().\n\nMove the check so that its peformed vs. the aggregated packet.\n\nThen, annotate the individual segments except the first one so we\ncan do a 2nd check at reinject time.\n\nFor the normal case, where userspace does in-order reinjects, this avoids\npacket drops: first reinjected segment continues traversal and confirms\nentry, remaining segments observe the confirmed entry.\n\nWhile at it, simplify nf_ct_drop_unconfirmed(): We only care about\nunconfirmed entries with a refcnt \u0026gt; 1, there is no need to special-case\ndying entries.\n\nThis only happens with UDP.  With TCP, the only unconfirmed packet will\nbe the TCP SYN, those aren\u0026apos;t aggregated by GRO.\n\nNext patch adds a udpgro test case to cover this scenario.(CVE-2026-45859)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ngfs2: Fix slab-use-after-free in qd_put\n\nCommit a475c5dd16e5 (\u0026quot;gfs2: Free quota data objects synchronously\u0026quot;)\nstarted freeing quota data objects during filesystem shutdown instead of\nputting them back onto the LRU list, but it failed to remove these\nobjects from the LRU list, causing LRU list corruption.  This caused\nuse-after-free when the shrinker (gfs2_qd_shrink_scan) tried to access\nalready-freed objects on the LRU list.\n\nFix this by removing qd objects from the LRU list before freeing them in\nqd_put().\n\nInitial fix from Deepanshu Kartikey \u0026lt;(CVE-2026-45861)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Fix bpf_xdp_store_bytes proto for read-only arg\n\nWhile making some maps in Cilium read-only from the BPF side, we noticed\nthat the bpf_xdp_store_bytes proto is incorrect. In particular, the\nverifier was throwing the following error:\n\n  ; ret = ctx_store_bytes(ctx, l3_off + offsetof(struct iphdr, saddr),\n                          \u0026amp;nat-\u0026gt;address, 4, 0);\n  635: (79) r1 = *(u64 *)(r10 -144)     ; R1=ctx() R10=fp0 fp-144=ctx()\n  636: (b4) w2 = 26                     ; R2=26\n  637: (b4) w4 = 4                      ; R4=4\n  638: (b4) w5 = 0                      ; R5=0\n  639: (85) call bpf_xdp_store_bytes#190\n  write into map forbidden, value_size=6 off=0 size=4\n\nnat comes from a BPF_F_RDONLY_PROG map, so R3 is a PTR_TO_MAP_VALUE.\nThe verifier checks the helper\u0026apos;s memory access to R3 in\ncheck_mem_size_reg, as it reaches ARG_CONST_SIZE argument. The third\nargument has expected type ARG_PTR_TO_UNINIT_MEM, which includes the\nMEM_WRITE flag. The verifier thus checks for a BPF_WRITE access on R3.\nGiven R3 points to a read-only map, the check fails.\n\nConversely, ARG_PTR_TO_UNINIT_MEM can also lead to the helper reading\nfrom uninitialized memory.\n\nThis patch simply fixes the expected argument type to match that of\nbpf_skb_store_bytes.(CVE-2026-45886)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nusb: cdns3: fix role switching during resume\n\nIf the role change while we are suspended, the cdns3 driver switches to the\nnew mode during resume. However, switching to host mode in this context\ncauses a NULL pointer dereference.\n\nThe host role\u0026apos;s start() operation registers a xhci-hcd device, but its\nprobe is deferred while we are in the resume path. The host role\u0026apos;s resume()\noperation assumes the xhci-hcd device is already probed, which is not the\ncase, leading to the dereference. Since the start() operation of the new\nrole is already called, the resume operation can be skipped.\n\nSo skip the resume operation for the new role if a role switch occurs\nduring resume. Once the resume sequence is complete, the xhci-hcd device\ncan be probed in case of host mode.\n\nUnable to handle kernel NULL pointer dereference at virtual address 0000000000000208\nMem abort info:\n...\nData abort info:\n...\n[0000000000000208] pgd=0000000000000000, p4d=0000000000000000\nInternal error: Oops: 0000000096000004 [#1]  SMP\nModules linked in:\nCPU: 0 UID: 0 PID: 146 Comm: sh Not tainted\n6.19.0-rc7-00013-g6e64f4aabfae-dirty #135 PREEMPT\nHardware name: Texas Instruments J7200 EVM (DT)\npstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\npc : usb_hcd_is_primary_hcd+0x0/0x1c\nlr : cdns_host_resume+0x24/0x5c\n...\nCall trace:\n usb_hcd_is_primary_hcd+0x0/0x1c (P)\n cdns_resume+0x6c/0xbc\n cdns3_controller_resume.isra.0+0xe8/0x17c\n cdns3_plat_resume+0x18/0x24\n platform_pm_resume+0x2c/0x68\n dpm_run_callback+0x90/0x248\n device_resume+0x100/0x24c\n dpm_resume+0x190/0x2ec\n dpm_resume_end+0x18/0x34\n suspend_devices_and_enter+0x2b0/0xa44\n pm_suspend+0x16c/0x5fc\n state_store+0x80/0xec\n kobj_attr_store+0x18/0x2c\n sysfs_kf_write+0x7c/0x94\n kernfs_fop_write_iter+0x130/0x1dc\n vfs_write+0x240/0x370\n ksys_write+0x70/0x108\n __arm64_sys_write+0x1c/0x28\n invoke_syscall+0x48/0x10c\n el0_svc_common.constprop.0+0x40/0xe0\n do_el0_svc+0x1c/0x28\n el0_svc+0x34/0x108\n el0t_64_sync_handler+0xa0/0xe4\n el0t_64_sync+0x198/0x19c\nCode: 52800003 f9407ca5 d63f00a0 17ffffe4 (f9410401)\n---[ end trace 0000000000000000 ]---(CVE-2026-45911)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ngfs2: fix memory leaks in gfs2_fill_super error path\n\nFix two memory leaks in the gfs2_fill_super() error handling path when\ntransitioning a filesystem to read-write mode fails.\n\nFirst leak: kthread objects (thread_struct, task_struct, etc.)\nWhen gfs2_freeze_lock_shared() fails after init_threads() succeeds, the\ncreated kernel threads (logd and quotad) are never destroyed. This\noccurs because the fail_per_node label doesn\u0026apos;t call\ngfs2_destroy_threads().\n\nSecond leak: quota bitmap buffer (8192 bytes)\nWhen gfs2_make_fs_rw() fails after gfs2_quota_init() succeeds but\nbefore other operations complete, the allocated quota bitmap is never\nfreed.\n\nThe fix moves thread cleanup to the fail_per_node label to handle all\nerror paths uniformly. gfs2_destroy_threads() is safe to call\nunconditionally as it checks for NULL pointers. Quota cleanup is added\nin gfs2_make_fs_rw() to properly handle the withdrawal case where\nquota initialization succeeds but the filesystem is then withdrawn.\n\nThread leak backtrace (gfs2_freeze_lock_shared failure):\n  unreferenced object 0xffff88801d7bca80 (size 4480):\n    copy_process+0x3a1/0x4670 kernel/fork.c:2422\n    kernel_clone+0xf3/0x6e0 kernel/fork.c:2779\n    kthread_create_on_node+0x100/0x150 kernel/kthread.c:478\n    init_threads+0xab/0x350 fs/gfs2/ops_fstype.c:611\n    gfs2_fill_super+0xe5c/0x1240 fs/gfs2/ops_fstype.c:1265\n\nQuota leak backtrace (gfs2_make_fs_rw failure):\n  unreferenced object 0xffff88812de7c000 (size 8192):\n    gfs2_quota_init+0xe5/0x820 fs/gfs2/quota.c:1409\n    gfs2_make_fs_rw+0x7a/0xe0 fs/gfs2/super.c:149\n    gfs2_fill_super+0xfbb/0x1240 fs/gfs2/ops_fstype.c:1275(CVE-2026-45961)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nACPICA: Fix NULL pointer dereference in acpi_ev_address_space_dispatch()\n\nCover a missed execution path with a new check.(CVE-2026-45982)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ngfs2: Fix use-after-free in iomap inline data write path\n\nThe inline data buffer head (dibh) is being released prematurely in\ngfs2_iomap_begin() via release_metapath() while iomap-\u0026gt;inline_data\nstill points to dibh-\u0026gt;b_data. This causes a use-after-free when\niomap_write_end_inline() later attempts to write to the inline data\narea.\n\nThe bug sequence:\n1. gfs2_iomap_begin() calls gfs2_meta_inode_buffer() to read inode\n   metadata into dibh\n2. Sets iomap-\u0026gt;inline_data = dibh-\u0026gt;b_data + sizeof(struct gfs2_dinode)\n3. Calls release_metapath() which calls brelse(dibh), dropping refcount\n   to 0\n4. kswapd reclaims the page (~39ms later in the syzbot report)\n5. iomap_write_end_inline() tries to memcpy() to iomap-\u0026gt;inline_data\n6. KASAN detects use-after-free write to freed memory\n\nFix by storing dibh in iomap-\u0026gt;private and incrementing its refcount\nwith get_bh() in gfs2_iomap_begin(). The buffer is then properly\nreleased in gfs2_iomap_end() after the inline write completes,\nensuring the page stays alive for the entire iomap operation.\n\nNote: A C reproducer is not available for this issue. The fix is based\non analysis of the KASAN report and code review showing the buffer head\nis freed before use.\n\n[agruenba: Take buffer head reference in gfs2_iomap_begin() to avoid\nleaks in gfs2_iomap_get() and gfs2_iomap_alloc().](CVE-2026-45984)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nerofs: fix unsigned underflow in z_erofs_lz4_handle_overlap()\n\nSome crafted images can have illegal (!partial_decoding \u0026amp;\u0026amp;\nm_llen \u0026lt; m_plen) extents, and the LZ4 inplace decompression path\ncan be wrongly hit, but it cannot handle (outpages \u0026lt; inpages)\nproperly: \u0026quot;outpages - inpages\u0026quot; wraps to a large value and\nthe subsequent rq-\u0026gt;out[] access reads past the decompressed_pages\narray.\n\nHowever, such crafted cases can correctly result in a corruption\nreport in the normal LZ4 non-inplace path.\n\nLet\u0026apos;s add an additional check to fix this for backporting.\n\nReproducible image (base64-encoded gzipped blob):\n\nH4sIAJGR12kCA+3SPUoDQRgG4MkmkkZk8QRbRFIIi9hbpEjrHQI5ghfwCN5BLCzTGtLbBI+g\ndilSJo1CnIm7GEXFxhT6PDDwfrs73/ywIQD/1ePD4r7Ou6ETsrq4mu7XcWfj++Pb58nJU/9i\nPNtbjhan04/9GtX4qVYc814WDqt6FaX5s+ZwXXeq52lndT6IuVvlblytLMvh4Gzwaf90nsvz\n2DF/21+20T/ldgp5s1jXRaN4t/8izsy/OUB6e/Qa79r+JwAAAAAAAL52vQVuGQAAAP6+my1w\nywAAAAAAAADwu14ATsEYtgBQAAA=\n\n$ mount -t erofs -o cache_strategy=disabled foo.erofs /mnt\n$ dd if=/mnt/data of=/dev/null bs=4096 count=1(CVE-2026-45999)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/nouveau: fix u32 overflow in pushbuf reloc bounds check\n\nnouveau_gem_pushbuf_reloc_apply() validates each relocation with\n\n    if (r-\u0026gt;reloc_bo_offset + 4 \u0026gt; nvbo-\u0026gt;bo.base.size)\n\nbut reloc_bo_offset is __u32 (uapi/drm/nouveau_drm.h) and the integer\nliteral 4 promotes to unsigned int, so the addition is performed in 32\nbits and wraps before the comparison against the size_t bo size.\n\nCast to u64 so the addition happens in 64-bit arithmetic.\n\n[ Add Fixes: tag. - Danilo ](CVE-2026-46006)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nKVM: SVM: Add missing save/restore handling of LBR MSRs\n\nMSR_IA32_DEBUGCTLMSR and LBR MSRs are currently not enumerated by\nKVM_GET_MSR_INDEX_LIST, and LBR MSRs cannot be set with KVM_SET_MSRS. So\nsave/restore is completely broken.\n\nFix it by adding the MSRs to msrs_to_save_base, and allowing writes to\nLBR MSRs from userspace only (as they are read-only MSRs) if LBR\nvirtualization is enabled.  Additionally, to correctly restore L1\u0026apos;s LBRs\nwhile L2 is running, make sure the LBRs are copied from the captured\nVMCB01 save area in svm_copy_vmrun_state().\n\nNote, for VMX, this also fixes a flaw where MSR_IA32_DEBUGCTLMSR isn\u0026apos;t\nreported as an MSR to save/restore.\n\nNote #2, over-reporting MSR_IA32_LASTxxx on Intel is ok, as KVM already\nhandles unsupported reads and writes thanks to commit b5e2fec0ebc3 (\u0026quot;KVM:\nIgnore DEBUGCTL MSRs with no effect\u0026quot;) (kvm_do_msr_access() will morph the\nunsupported userspace write into a nop).\n\n[sean: guard with lbrv checks, massage changelog](CVE-2026-46014)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipmi:ssif: Clean up kthread on errors\n\nIf an error occurs after the ssif kthread is created, but before the\nmain IPMI code starts the ssif interface, the ssif kthread will not\nbe stopped.\n\nSo make sure the kthread is stopped on an error condition if it is\nrunning.(CVE-2026-46044)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmd/raid5: fix soft lockup in retry_aligned_read()\n\nWhen retry_aligned_read() encounters an overlapped stripe, it releases\nthe stripe via raid5_release_stripe() which puts it on the lockless\nreleased_stripes llist. In the next raid5d loop iteration,\nrelease_stripe_list() drains the stripe onto handle_list (since\nSTRIPE_HANDLE is set by the original IO), but retry_aligned_read()\nruns before handle_active_stripes() and removes the stripe from\nhandle_list via find_get_stripe() -\u0026gt; list_del_init(). This prevents\nhandle_stripe() from ever processing the stripe to resolve the\noverlap, causing an infinite loop and soft lockup.\n\nFix this by using __release_stripe() with temp_inactive_list instead\nof raid5_release_stripe() in the failure path, so the stripe does not\ngo through the released_stripes llist. This allows raid5d to break out\nof its loop, and the overlap will be resolved when the stripe is\neventually processed by handle_stripe().(CVE-2026-46051)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nceph: only d_add() negative dentries when they are unhashed\n\nCeph can call d_add(dentry, NULL) on a negative dentry that is already\npresent in the primary dcache hash.\n\nIn the current VFS that is not safe.  d_add() goes through __d_add()\nto __d_rehash(), which unconditionally reinserts dentry-\u0026gt;d_hash into\nthe hlist_bl bucket.  If the dentry is already hashed, reinserting the\nsame node can corrupt the bucket, including creating a self-loop.\nOnce that happens, __d_lookup() can spin forever in the hlist_bl walk,\ntypically looping only on the d_name.hash mismatch check and\neventually triggering RCU stall reports like this one:\n\n rcu: INFO: rcu_sched self-detected stall on CPU\n rcu:         87-....: (2100 ticks this GP) idle=3a4c/1/0x4000000000000000 softirq=25003319/25003319 fqs=829\n rcu:         (t=2101 jiffies g=79058445 q=698988 ncpus=192)\n CPU: 87 UID: 2952868916 PID: 3933303 Comm: php-cgi8.3 Not tainted 6.18.17-i1-amd #950 NONE\n Hardware name: Dell Inc. PowerEdge R7615/0G9DHV, BIOS 1.6.6 09/22/2023\n RIP: 0010:__d_lookup+0x46/0xb0\n Code: c1 e8 07 48 8d 04 c2 48 8b 00 49 89 fc 49 89 f5 48 89 c3 48 83 e3 fe 48 83 f8 01 77 0f eb 2d 0f 1f 44 00 00 48 8b 1b 48 85 db \u0026lt;74\u0026gt; 20 39 6b 18 75 f3 48 8d 7b 78 e8 ba 85 d0 00 4c 39 63 10 74 1f\n RSP: 0018:ff745a70c8253898 EFLAGS: 00000282\n RAX: ff26e470054cb208 RBX: ff26e470054cb208 RCX: 000000006e958966\n RDX: ff26e48267340000 RSI: ff745a70c82539b0 RDI: ff26e458f74655c0\n RBP: 000000006e958966 R08: 0000000000000180 R09: 9cd08d909b919a89\n R10: ff26e458f74655c0 R11: 0000000000000000 R12: ff26e458f74655c0\n R13: ff745a70c82539b0 R14: d0d0d0d0d0d0d0d0 R15: 2f2f2f2f2f2f2f2f\n FS:  00007f5770896980(0000) GS:ff26e482c5d88000(0000) knlGS:0000000000000000\n CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 00007f5764de50c0 CR3: 000000a72abb5001 CR4: 0000000000771ef0\n PKRU: 55555554\n Call Trace:\n  \u0026lt;TASK\u0026gt;\n  lookup_fast+0x9f/0x100\n  walk_component+0x1f/0x150\n  link_path_walk+0x20e/0x3d0\n  path_lookupat+0x68/0x180\n  filename_lookup+0xdc/0x1e0\n  vfs_statx+0x6c/0x140\n  vfs_fstatat+0x67/0xa0\n  __do_sys_newfstatat+0x24/0x60\n  do_syscall_64+0x6a/0x230\n  entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\nThis is reachable with reused cached negative dentries.  A Ceph lookup\nor atomic_open can be handed a negative dentry that is already hashed,\nand fs/ceph/dir.c then hits one of two paths that incorrectly assume\n\u0026quot;negative\u0026quot; also means \u0026quot;unhashed\u0026quot;:\n\n  - ceph_finish_lookup():\n      MDS reply is -ENOENT with no trace\n      -\u0026gt; d_add(dentry, NULL)\n\n  - ceph_lookup():\n      local ENOENT fast path for a complete directory with shared caps\n      -\u0026gt; d_add(dentry, NULL)\n\nBoth paths can therefore re-add an already-hashed negative dentry.\n\nCeph already uses the correct pattern elsewhere: ceph_fill_trace() only\ncalls d_add(dn, NULL) for a negative null-dentry reply when d_unhashed(dn)\nis true.\n\nFix both fs/ceph/dir.c sites the same way: only call d_add() for a\nnegative dentry when it is actually unhashed.  If the negative dentry\nis already hashed, leave it in place and reuse it as-is.\n\nThis preserves the existing behavior for unhashed dentries while\navoiding d_hash list corruption for reused hashed negatives.(CVE-2026-46052)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nKVM: nSVM: Raise #UD if unhandled VMMCALL isn\u0026apos;t intercepted by L1\n\nExplicitly synthesize a #UD for VMMCALL if L2 is active, L1 does NOT want\nto intercept VMMCALL, nested_svm_l2_tlb_flush_enabled() is true, and the\nhypercall is something other than one of the supported Hyper-V hypercalls.\nWhen all of the above conditions are met, KVM will intercept VMMCALL but\nnever forward it to L1, i.e. will let L2 make hypercalls as if it were L1.\n\nThe TLFS says a whole lot of nothing about this scenario, so go with the\narchitectural behavior, which says that VMMCALL #UDs if it\u0026apos;s not\nintercepted.\n\nOpportunistically do a 2-for-1 stub trade by stub-ifying the new API\ninstead of the helpers it uses.  The last remaining \u0026quot;single\u0026quot; stub will\nsoon be dropped as well.\n\n[sean: rewrite changelog and comment, tag for stable, remove defunct stubs](CVE-2026-46076)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nerofs: fix the out-of-bounds nameoff handling for trailing dirents\n\nCurrently we already have boundary-checks for nameoffs, but the trailing\ndirents are special since the namelens are calculated with strnlen()\nwith unchecked nameoffs.\n\nIf a crafted EROFS has a trailing dirent with nameoff \u0026gt;= maxsize,\nmaxsize - nameoff can underflow, causing strnlen() to read past the\ndirectory block.\n\nnameoff0 should also be verified to be a multiple of\n`sizeof(struct erofs_dirent)` as well [1].\n\n[1] https://sashiko.dev/#/patchset/20260416063511.3173774-1-hsiangkao%40linux.alibaba.com(CVE-2026-46078)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nKVM: SVM: Inject #UD for INVLPGA if EFER.SVME=0\n\nINVLPGA should cause a #UD when EFER.SVME is not set. Add a check to\nproperly inject #UD when EFER.SVME=0.\n\n[sean: tag for stable@](CVE-2026-46082)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm/vmalloc: take vmap_purge_lock in shrinker\n\ndecay_va_pool_node() can be invoked concurrently from two paths:\n__purge_vmap_area_lazy() when pools are being purged, and the shrinker via\nvmap_node_shrink_scan().\n\nHowever, decay_va_pool_node() is not safe to run concurrently, and the\nshrinker path currently lacks serialization, leading to races and possible\nleaks.\n\nProtect decay_va_pool_node() by taking vmap_purge_lock in the shrinker\npath to ensure serialization with purge users.(CVE-2026-46093)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: hci_event: Fix OOB read and infinite loop in hci_le_create_big_complete_evt\n\nhci_le_create_big_complete_evt() iterates over BT_BOUND connections for\na BIG handle using a while loop, accessing ev-\u0026gt;bis_handle[i++] on each\niteration.  However, there is no check that i stays within ev-\u0026gt;num_bis\nbefore the array access.\n\nWhen a controller sends a LE_Create_BIG_Complete event with fewer\nbis_handle entries than there are BT_BOUND connections for that BIG,\nor with num_bis=0, the loop reads beyond the valid bis_handle[] flex\narray into adjacent heap memory.  Since the out-of-bounds values\ntypically exceed HCI_CONN_HANDLE_MAX (0x0EFF), hci_conn_set_handle()\nrejects them and the connection remains in BT_BOUND state.  The same\nconnection is then found again by hci_conn_hash_lookup_big_state(),\ncreating an infinite loop with hci_dev_lock held.\n\nFix this by terminating the BIG if in case not all BIS could be setup\nproperly.(CVE-2026-46138)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nopenvswitch: vport: fix self-deadlock on release of tunnel ports\n\nvports are used concurrently and protected by RCU, so netdev_put()\nmust happen after the RCU grace period.  So, either in an RCU call or\nafter the synchronize_net().  The rtnl_delete_link() must happen under\nRTNL and so can\u0026apos;t be executed in RCU context.  Calling synchronize_net()\nwhile holding RTNL is not a good idea for performance and system\nstability under load in general, so calling netdev_put() in RCU call\nis the right solution here.\n\nHowever,\nwhen the device is deleted, rtnl_unlock() will call netdev_run_todo()\nand block until all the references are gone.  In the current code this\nmeans that we never reach the call_rcu() and the vport is never freed\nand the reference is never released, causing a self-deadlock on device\nremoval.\n\nFix that by moving the rcu_call() before the rtnl_unlock(), so the\nscheduled RCU callback will be executed when synchronize_net() is\ncalled from the rtnl_unlock()-\u0026gt;netdev_run_todo() while the RTNL itself\nis already released.(CVE-2026-46165)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nriscv: kvm: fix vector context allocation leak\n\nWhen the second kzalloc (host_context.vector.datap) fails in\nkvm_riscv_vcpu_alloc_vector_context, the first allocation\n(guest_context.vector.datap) is leaked. Free it before returning.(CVE-2026-46171)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nx86/CPU/AMD: Prevent improper isolation of shared resources in Zen2\u0026apos;s op cache\n\nMake sure resources are not improperly shared in the op cache and\ncause instruction corruption this way.(CVE-2026-46174)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/mlx4: Fix resource leak on error in mlx4_ib_create_srq()\n\nSashiko points out that mlx4_srq_alloc() was not undone during error\nunwind, add the missing call to mlx4_srq_free().(CVE-2026-46178)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmtd: spi-nor: debugfs: fix out-of-bounds read in spi_nor_params_show()\n\nSashiko noticed an out-of-bounds read [1].\n\nIn spi_nor_params_show(), the snor_f_names array is passed to\nspi_nor_print_flags() using sizeof(snor_f_names).\n\nSince snor_f_names is an array of pointers, sizeof() returns the total\nnumber of bytes occupied by the pointers\n\t(element_count * sizeof(void *))\nrather than the element count itself. On 64-bit systems, this makes the\npassed length 8x larger than intended.\n\nInside spi_nor_print_flags(), the \u0026apos;names_len\u0026apos; argument is used to\nbounds-check the \u0026apos;names\u0026apos; array access. An out-of-bounds read occurs\nif a flag bit is set that exceeds the array\u0026apos;s actual element count\nbut is within the inflated byte-size count.\n\nCorrect this by using ARRAY_SIZE() to pass the actual number of\nstring pointers in the array.(CVE-2026-46190)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nft_inner: Fix IPv6 inner_thoff desync\n\nIn nft_inner_parse_l2l3(), when processing inner IPv6 packets,\nipv6_find_hdr() correctly computes the transport header offset\ntraversing all extension headers, but the result is immediately\noverwritten with nhoff + sizeof(_ip6h) (40 bytes), which only\naccounts for the IPv6 base header. This creates a desync between\ninner_thoff (wrong \u2014 points to extension header start) and l4proto\n(correct \u2014 e.g., IPPROTO_TCP), enabling transport header forgery\nand potential firewall bypass. This issue affects stable versions\nfrom Linux 6.2.\n\nFor comparison, the normal (non-inner) IPv6 path correctly\npreserves ipv6_find_hdr()\u0026apos;s result. Removing the incorrect overwrite\nensures that ipv6_find_hdr()\u0026apos;s calculated transport header offset is\npreserved, thereby fixing the desynchronization.(CVE-2026-46244)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntap: free page on error paths in tap_get_user_xdp()\n\ntap_get_user_xdp() rejects a frame shorter than ETH_HLEN with -EINVAL,\nand returns -ENOMEM when build_skb() fails. Both paths jump to the err\nlabel without freeing the page that vhost_net_build_xdp() allocated for\nthe frame. tap_sendmsg() discards the per-buffer return value and always\nreturns 0, so vhost_tx_batch() takes the success path and never frees\nthe page; each rejected frame in a batch leaks one page-frag chunk.\n\nFree the page on both error paths, before the skb is built. This is the\ntap counterpart of the same leak in tun_xdp_one().(CVE-2026-46320)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntun: free page on short-frame rejection in tun_xdp_one()\n\ntun_xdp_one() returns -EINVAL on a frame shorter than ETH_HLEN without\nfreeing the page that vhost_net_build_xdp() allocated for it.\ntun_sendmsg() discards that -EINVAL and still returns total_len, so\nvhost_tx_batch() takes the success path and never frees the page; each\nshort frame in a batch leaks one page-frag chunk.\n\nA local process that can open /dev/net/tun and /dev/vhost-net can hit\nthis path: it attaches a tun/tap device as the vhost-net backend and\nfeeds TX descriptors whose length minus the virtio-net header is below\nETH_HLEN. Each kick leaks the page-frag chunks for that batch, and a\ntight submission loop exhausts host memory and triggers an OOM panic.\nFree the page before returning -EINVAL, matching the XDP-program error\npath in the same function.(CVE-2026-46321)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntun: free page on build_skb failure in tun_xdp_one()\n\nWhen build_skb() fails in tun_xdp_one(), the function sets ret to\n-ENOMEM and jumps to the out label, which returns without freeing the\npage that vhost_net_build_xdp() allocated for the frame. As with the\nshort-frame rejection path, tun_sendmsg() discards the per-buffer error\nand still returns total_len, so vhost_tx_batch() takes the success path\nand never frees the page. Each build_skb() failure in a batch leaks one\npage-frag chunk.\n\nFree the page before taking the error path, matching the put_page() the\nother error exits of tun_xdp_one() already perform.(CVE-2026-46322)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: gro: don\u0026apos;t merge zcopy skbs\n\nskb_gro_receive() can currently copy frags between the source and GRO\nskb, without checking the zerocopy status, and in particular the\nSKBFL_MANAGED_FRAG_REFS flag.\n\nWhen SKBFL_MANAGED_FRAG_REFS is set, the skb doesn\u0026apos;t hold a reference\non the pages in shinfo-\u0026gt;frags. Appending those frags to another skb\u0026apos;s\nfrags without fixing up the page refcount can lead to UAF.\n\nWhen either the last skb in the GRO chain (the one we would append\nfrags to) or the source skb is zerocopy, don\u0026apos;t merge the skbs.(CVE-2026-46323)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRevert \u0026quot;net/smc: Introduce TCP ULP support\u0026quot;\n\nThis reverts commit d7cd421da9da2cc7b4d25b8537f66db5c8331c40.\n\nAs reported by Al Viro, the TCP ULP support for SMC is fundamentally\nbroken. The implementation attempts to convert an active TCP socket\ninto an SMC socket by modifying the underlying `struct file`, dentry,\nand inode in-place, which violates core VFS invariants that assume\nthese structures are immutable for an open file, creating a risk of\nuse after free errors and general system instability.\n\nGiven the severity of this design flaw and the fact that cleaner\nalternatives (e.g., LD_PRELOAD, BPF) exist for legacy application\ntransparency, the correct course of action is to remove this feature\nentirely.(CVE-2026-46330)",
  "id": "OESA-2026-3157",
  "modified": "2026-08-06T11:12:02Z",
  "published": "2026-07-24T11:12:02Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-3157"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-10263"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39932"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-71109"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-71203"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23213"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23214"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23261"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31414"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31432"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31440"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31443"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31453"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31531"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31551"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31557"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31580"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31588"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31662"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31664"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31681"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31717"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31725"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31759"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43022"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43025"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43026"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43028"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43083"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43091"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43099"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43101"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43116"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43125"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43127"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43156"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43163"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43180"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43186"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43194"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43197"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43220"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43239"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43240"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43288"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43309"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43319"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43334"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43350"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43366"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43406"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43445"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43466"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43468"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45834"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45859"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45861"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45886"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45911"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45961"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45982"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45984"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45999"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46006"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46014"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46044"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46051"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46052"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46076"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46078"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46082"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46093"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46138"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46165"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46171"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46174"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46178"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46190"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46244"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46320"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46321"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46322"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46323"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46330"
    }
  ],
  "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-10263",
    "CVE-2025-39932",
    "CVE-2025-71109",
    "CVE-2025-71203",
    "CVE-2026-23213",
    "CVE-2026-23214",
    "CVE-2026-23261",
    "CVE-2026-31414",
    "CVE-2026-31432",
    "CVE-2026-31440",
    "CVE-2026-31443",
    "CVE-2026-31453",
    "CVE-2026-31531",
    "CVE-2026-31551",
    "CVE-2026-31557",
    "CVE-2026-31580",
    "CVE-2026-31588",
    "CVE-2026-31662",
    "CVE-2026-31664",
    "CVE-2026-31681",
    "CVE-2026-31717",
    "CVE-2026-31725",
    "CVE-2026-31759",
    "CVE-2026-43022",
    "CVE-2026-43025",
    "CVE-2026-43026",
    "CVE-2026-43028",
    "CVE-2026-43083",
    "CVE-2026-43091",
    "CVE-2026-43099",
    "CVE-2026-43101",
    "CVE-2026-43116",
    "CVE-2026-43125",
    "CVE-2026-43127",
    "CVE-2026-43156",
    "CVE-2026-43163",
    "CVE-2026-43180",
    "CVE-2026-43186",
    "CVE-2026-43194",
    "CVE-2026-43197",
    "CVE-2026-43220",
    "CVE-2026-43239",
    "CVE-2026-43240",
    "CVE-2026-43288",
    "CVE-2026-43309",
    "CVE-2026-43319",
    "CVE-2026-43334",
    "CVE-2026-43350",
    "CVE-2026-43366",
    "CVE-2026-43406",
    "CVE-2026-43445",
    "CVE-2026-43466",
    "CVE-2026-43468",
    "CVE-2026-45834",
    "CVE-2026-45859",
    "CVE-2026-45861",
    "CVE-2026-45886",
    "CVE-2026-45911",
    "CVE-2026-45961",
    "CVE-2026-45982",
    "CVE-2026-45984",
    "CVE-2026-45999",
    "CVE-2026-46006",
    "CVE-2026-46014",
    "CVE-2026-46044",
    "CVE-2026-46051",
    "CVE-2026-46052",
    "CVE-2026-46076",
    "CVE-2026-46078",
    "CVE-2026-46082",
    "CVE-2026-46093",
    "CVE-2026-46138",
    "CVE-2026-46165",
    "CVE-2026-46171",
    "CVE-2026-46174",
    "CVE-2026-46178",
    "CVE-2026-46190",
    "CVE-2026-46244",
    "CVE-2026-46320",
    "CVE-2026-46321",
    "CVE-2026-46322",
    "CVE-2026-46323",
    "CVE-2026-46330"
  ]
}