{"schema_version":"1.7.2","id":"OESA-2025-2804","modified":"2025-12-12T12:20:10Z","published":"2025-12-12T12:20:10Z","upstream":["CVE-2025-21968","CVE-2025-22025","CVE-2025-22042","CVE-2025-22043","CVE-2025-37973","CVE-2025-38350","CVE-2025-38470","CVE-2025-38527","CVE-2025-38727","CVE-2025-40052","CVE-2025-40061","CVE-2025-40074","CVE-2025-40075","CVE-2025-40104","CVE-2025-40121","CVE-2025-40135","CVE-2025-40139","CVE-2025-40149","CVE-2025-40155","CVE-2025-40158"],"summary":"kernel security update","details":"The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amd/display: Fix slab-use-after-free on hdcp_work\n\n[Why]\nA slab-use-after-free is reported when HDCP is destroyed but the\nproperty_validate_dwork queue is still running.\n\n[How]\nCancel the delayed work when destroying workqueue.\n\n(cherry picked from commit 725a04ba5a95e89c89633d4322430cfbca7ce128)(CVE-2025-21968)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnfsd: put dl_stid if fail to queue dl_recall\n\nBefore calling nfsd4_run_cb to queue dl_recall to the callback_wq, we\nincrement the reference count of dl_stid.\nWe expect that after the corresponding work_struct is processed, the\nreference count of dl_stid will be decremented through the callback\nfunction nfsd4_cb_recall_release.\nHowever, if the call to nfsd4_run_cb fails, the incremented reference\ncount of dl_stid will not be decremented correspondingly, leading to the\nfollowing nfs4_stid leak:\nunreferenced object 0xffff88812067b578 (size 344):\n  comm "nfsd", pid 2761, jiffies 4295044002 (age 5541.241s)\n  hex dump (first 32 bytes):\n    01 00 00 00 6b 6b 6b 6b b8 02 c0 e2 81 88 ff ff  ....kkkk........\n    00 6b 6b 6b 6b 6b 6b 6b 00 00 00 00 ad 4e ad de  .kkkkkkk.....N..\n  backtrace:\n    kmem_cache_alloc+0x4b9/0x700\n    nfsd4_process_open1+0x34/0x300\n    nfsd4_open+0x2d1/0x9d0\n    nfsd4_proc_compound+0x7a2/0xe30\n    nfsd_dispatch+0x241/0x3e0\n    svc_process_common+0x5d3/0xcc0\n    svc_process+0x2a3/0x320\n    nfsd+0x180/0x2e0\n    kthread+0x199/0x1d0\n    ret_from_fork+0x30/0x50\n    ret_from_fork_asm+0x1b/0x30\nunreferenced object 0xffff8881499f4d28 (size 368):\n  comm "nfsd", pid 2761, jiffies 4295044005 (age 5541.239s)\n  hex dump (first 32 bytes):\n    01 00 00 00 00 00 00 00 30 4d 9f 49 81 88 ff ff  ........0M.I....\n    30 4d 9f 49 81 88 ff ff 20 00 00 00 01 00 00 00  0M.I.... .......\n  backtrace:\n    kmem_cache_alloc+0x4b9/0x700\n    nfs4_alloc_stid+0x29/0x210\n    alloc_init_deleg+0x92/0x2e0\n    nfs4_set_delegation+0x284/0xc00\n    nfs4_open_delegation+0x216/0x3f0\n    nfsd4_process_open2+0x2b3/0xee0\n    nfsd4_open+0x770/0x9d0\n    nfsd4_proc_compound+0x7a2/0xe30\n    nfsd_dispatch+0x241/0x3e0\n    svc_process_common+0x5d3/0xcc0\n    svc_process+0x2a3/0x320\n    nfsd+0x180/0x2e0\n    kthread+0x199/0x1d0\n    ret_from_fork+0x30/0x50\n    ret_from_fork_asm+0x1b/0x30\nFix it by checking the result of nfsd4_run_cb and call nfs4_put_stid if\nfail to queue dl_recall.(CVE-2025-22025)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: add bounds check for create lease context\n\nAdd missing bounds check for create lease context.(CVE-2025-22042)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: add bounds check for durable handle context\n\nAdd missing bounds check for durable handle context.(CVE-2025-22043)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwifi: cfg80211: fix out-of-bounds access during multi-link element defragmentation\n\nCurrently during the multi-link element defragmentation process, the\nmulti-link element length added to the total IEs length when calculating\nthe length of remaining IEs after the multi-link element in\ncfg80211_defrag_mle(). This could lead to out-of-bounds access if the\nmulti-link element or its corresponding fragment elements are the last\nelements in the IEs buffer.\n\nTo address this issue, correctly calculate the remaining IEs length by\ndeducting the multi-link element end offset from total IEs end offset.(CVE-2025-37973)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/sched: Always pass notifications when child class becomes empty\n\nCertain classful qdiscs may invoke their classes' dequeue handler on an\nenqueue operation. This may unexpectedly empty the child qdisc and thus\nmake an in-flight class passive via qlen_notify(). Most qdiscs do not\nexpect such behaviour at this point in time and may re-activate the\nclass eventually anyways which will lead to a use-after-free.\n\nThe referenced fix commit attempted to fix this behavior for the HFSC\ncase by moving the backlog accounting around, though this turned out to\nbe incomplete since the parent's parent may run into the issue too.\nThe following reproducer demonstrates this use-after-free:\n\n    tc qdisc add dev lo root handle 1: drr\n    tc filter add dev lo parent 1: basic classid 1:1\n    tc class add dev lo parent 1: classid 1:1 drr\n    tc qdisc add dev lo parent 1:1 handle 2: hfsc def 1\n    tc class add dev lo parent 2: classid 2:1 hfsc rt m1 8 d 1 m2 0\n    tc qdisc add dev lo parent 2:1 handle 3: netem\n    tc qdisc add dev lo parent 3:1 handle 4: blackhole\n\n    echo 1 | socat -u STDIN UDP4-DATAGRAM:127.0.0.1:8888\n    tc class delete dev lo classid 1:1\n    echo 1 | socat -u STDIN UDP4-DATAGRAM:127.0.0.1:8888\n\nSince backlog accounting issues leading to a use-after-frees on stale\nclass pointers is a recurring pattern at this point, this patch takes\na different approach. Instead of trying to fix the accounting, the patch\nensures that qdisc_tree_reduce_backlog always calls qlen_notify when\nthe child qdisc is empty. This solves the problem because deletion of\nqdiscs always involves a call to qdisc_reset() and / or\nqdisc_purge_queue() which ultimately resets its qlen to 0 thus causing\nthe following qdisc_tree_reduce_backlog() to report to the parent. Note\nthat this may call qlen_notify on passive classes multiple times. This\nis not a problem after the recent patch series that made all the\nclassful qdiscs qlen_notify() handlers idempotent.(CVE-2025-38350)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: vlan: fix VLAN 0 refcount imbalance of toggling filtering during runtime\n\nAssuming the "rx-vlan-filter" feature is enabled on a net device, the\n8021q module will automatically add or remove VLAN 0 when the net device\nis put administratively up or down, respectively. There are a couple of\nproblems with the above scheme.\n\nThe first problem is a memory leak that can happen if the "rx-vlan-filter"\nfeature is disabled while the device is running:\n\n # ip link add bond1 up type bond mode 0\n # ethtool -K bond1 rx-vlan-filter off\n # ip link del dev bond1\n\nWhen the device is put administratively down the "rx-vlan-filter"\nfeature is disabled, so the 8021q module will not remove VLAN 0 and the\nmemory will be leaked [1].\n\nAnother problem that can happen is that the kernel can automatically\ndelete VLAN 0 when the device is put administratively down despite not\nadding it when the device was put administratively up since during that\ntime the "rx-vlan-filter" feature was disabled. null-ptr-unref or\nbug_on[2] will be triggered by unregister_vlan_dev() for refcount\nimbalance if toggling filtering during runtime:\n\n$ ip link add bond0 type bond mode 0\n$ ip link add link bond0 name vlan0 type vlan id 0 protocol 802.1q\n$ ethtool -K bond0 rx-vlan-filter off\n$ ifconfig bond0 up\n$ ethtool -K bond0 rx-vlan-filter on\n$ ifconfig bond0 down\n$ ip link del vlan0\n\nRoot cause is as below:\nstep1: add vlan0 for real_dev, such as bond, team.\nregister_vlan_dev\n    vlan_vid_add(real_dev,htons(ETH_P_8021Q),0) //refcnt=1\nstep2: disable vlan filter feature and enable real_dev\nstep3: change filter from 0 to 1\nvlan_device_event\n    vlan_filter_push_vids\n        ndo_vlan_rx_add_vid //No refcnt added to real_dev vlan0\nstep4: real_dev down\nvlan_device_event\n    vlan_vid_del(dev, htons(ETH_P_8021Q), 0); //refcnt=0\n        vlan_info_rcu_free //free vlan0\nstep5: delete vlan0\nunregister_vlan_dev\n    BUG_ON(!vlan_info); //vlan_info is null\n\nFix both problems by noting in the VLAN info whether VLAN 0 was\nautomatically added upon NETDEV_UP and based on that decide whether it\nshould be deleted upon NETDEV_DOWN, regardless of the state of the\n"rx-vlan-filter" feature.\n\n[1]\nunreferenced object 0xffff8880068e3100 (size 256):\n  comm "ip", pid 384, jiffies 4296130254\n  hex dump (first 32 bytes):\n    00 20 30 0d 80 88 ff ff 00 00 00 00 00 00 00 00  . 0.............\n    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................\n  backtrace (crc 81ce31fa):\n    __kmalloc_cache_noprof+0x2b5/0x340\n    vlan_vid_add+0x434/0x940\n    vlan_device_event.cold+0x75/0xa8\n    notifier_call_chain+0xca/0x150\n    __dev_notify_flags+0xe3/0x250\n    rtnl_configure_link+0x193/0x260\n    rtnl_newlink_create+0x383/0x8e0\n    __rtnl_newlink+0x22c/0xa40\n    rtnl_newlink+0x627/0xb00\n    rtnetlink_rcv_msg+0x6fb/0xb70\n    netlink_rcv_skb+0x11f/0x350\n    netlink_unicast+0x426/0x710\n    netlink_sendmsg+0x75a/0xc20\n    __sock_sendmsg+0xc1/0x150\n    ____sys_sendmsg+0x5aa/0x7b0\n    ___sys_sendmsg+0xfc/0x180\n\n[2]\nkernel BUG at net/8021q/vlan.c:99!\nOops: invalid opcode: 0000 [#1] SMP KASAN PTI\nCPU: 0 UID: 0 PID: 382 Comm: ip Not tainted 6.16.0-rc3 #61 PREEMPT(voluntary)\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996),\nBIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014\nRIP: 0010:unregister_vlan_dev (net/8021q/vlan.c:99 (discriminator 1))\nRSP: 0018:ffff88810badf310 EFLAGS: 00010246\nRAX: 0000000000000000 RBX: ffff88810da84000 RCX: ffffffffb47ceb9a\nRDX: dffffc0000000000 RSI: 0000000000000008 RDI: ffff88810e8b43c8\nRBP: 0000000000000000 R08: 0000000000000000 R09: fffffbfff6cefe80\nR10: ffffffffb677f407 R11: ffff88810badf3c0 R12: ffff88810e8b4000\nR13: 0000000000000000 R14: ffff88810642a5c0 R15: 000000000000017e\nFS:  00007f1ff68c20c0(0000) GS:ffff888163a24000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007f1ff5dad240 CR3: 0000000107e56000 CR4: 00000000000006f0\nCall Trace:\n <TASK\n---truncated---(CVE-2025-38470)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: fix use-after-free in cifs_oplock_break\n\nA race condition can occur in cifs_oplock_break() leading to a\nuse-after-free of the cinode structure when unmounting:\n\n  cifs_oplock_break()\n    _cifsFileInfo_put(cfile)\n      cifsFileInfo_put_final()\n        cifs_sb_deactive()\n          [last ref, start releasing sb]\n            kill_sb()\n              kill_anon_super()\n                generic_shutdown_super()\n                  evict_inodes()\n                    dispose_list()\n                      evict()\n                        destroy_inode()\n                          call_rcu(&inode->i_rcu, i_callback)\n    spin_lock(&cinode->open_file_lock)  <- OK\n                            [later] i_callback()\n                              cifs_free_inode()\n                                kmem_cache_free(cinode)\n    spin_unlock(&cinode->open_file_lock)  <- UAF\n    cifs_done_oplock_break(cinode)       <- UAF\n\nThe issue occurs when umount has already released its reference to the\nsuperblock. When _cifsFileInfo_put() calls cifs_sb_deactive(), this\nreleases the last reference, triggering the immediate cleanup of all\ninodes under RCU. However, cifs_oplock_break() continues to access the\ncinode after this point, resulting in use-after-free.\n\nFix this by holding an extra reference to the superblock during the\nentire oplock break operation. This ensures that the superblock and\nits inodes remain valid until the oplock break completes.(CVE-2025-38527)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetlink: avoid infinite retry looping in netlink_unicast()\n\nnetlink_attachskb() checks for the socket's read memory allocation\nconstraints. Firstly, it has:\n\n  rmem < READ_ONCE(sk->sk_rcvbuf)\n\nto check if the just increased rmem value fits into the socket's receive\nbuffer. If not, it proceeds and tries to wait for the memory under:\n\n  rmem + skb->truesize > READ_ONCE(sk->sk_rcvbuf)\n\nThe checks don't cover the case when skb->truesize + sk->sk_rmem_alloc is\nequal to sk->sk_rcvbuf. Thus the function neither successfully accepts\nthese conditions, nor manages to reschedule the task - and is called in\nretry loop for indefinite time which is caught as:\n\n  rcu: INFO: rcu_sched self-detected stall on CPU\n  rcu:     0-....: (25999 ticks this GP) idle=ef2/1/0x4000000000000000 softirq=262269/262269 fqs=6212\n  (t=26000 jiffies g=230833 q=259957)\n  NMI backtrace for cpu 0\n  CPU: 0 PID: 22 Comm: kauditd Not tainted 5.10.240 #68\n  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-4.fc42 04/01/2014\n  Call Trace:\n  <IRQ>\n  dump_stack lib/dump_stack.c:120\n  nmi_cpu_backtrace.cold lib/nmi_backtrace.c:105\n  nmi_trigger_cpumask_backtrace lib/nmi_backtrace.c:62\n  rcu_dump_cpu_stacks kernel/rcu/tree_stall.h:335\n  rcu_sched_clock_irq.cold kernel/rcu/tree.c:2590\n  update_process_times kernel/time/timer.c:1953\n  tick_sched_handle kernel/time/tick-sched.c:227\n  tick_sched_timer kernel/time/tick-sched.c:1399\n  __hrtimer_run_queues kernel/time/hrtimer.c:1652\n  hrtimer_interrupt kernel/time/hrtimer.c:1717\n  __sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1113\n  asm_call_irq_on_stack arch/x86/entry/entry_64.S:808\n  </IRQ>\n\n  netlink_attachskb net/netlink/af_netlink.c:1234\n  netlink_unicast net/netlink/af_netlink.c:1349\n  kauditd_send_queue kernel/audit.c:776\n  kauditd_thread kernel/audit.c:897\n  kthread kernel/kthread.c:328\n  ret_from_fork arch/x86/entry/entry_64.S:304\n\nRestore the original behavior of the check which commit in Fixes\naccidentally missed when restructuring the code.\n\nFound by Linux Verification Center (linuxtesting.org).(CVE-2025-38727)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: fix crypto buffers in non-linear memory\n\nThe crypto API, through the scatterlist API, expects input buffers to be\nin linear memory.  We handle this with the cifs_sg_set_buf() helper\nthat converts vmalloc'd memory to their corresponding pages.\n\nHowever, when we allocate our aead_request buffer (@creq in\nsmb2ops.c::crypt_message()), we do so with kvzalloc(), which possibly\nputs aead_request->__ctx in vmalloc area.\n\nAEAD algorithm then uses ->__ctx for its private/internal data and\noperations, and uses sg_set_buf() for such data on a few places.\n\nThis works fine as long as @creq falls into kmalloc zone (small\nrequests) or vmalloc'd memory is still within linear range.\n\nTasks' stacks are vmalloc'd by default (CONFIG_VMAP_STACK=y), so too\nmany tasks will increment the base stacks' addresses to a point where\nvirt_addr_valid(buf) will fail (BUG() in sg_set_buf()) when that\nhappens.\n\nIn practice: too many parallel reads and writes on an encrypted mount\nwill trigger this bug.\n\nTo fix this, always alloc @creq with kmalloc() instead.\nAlso drop the @sensitive_size variable/arguments since\nkfree_sensitive() doesn't need it.\n\nBacktrace:\n\n[  945.272081] ------------[ cut here ]------------\n[  945.272774] kernel BUG at include/linux/scatterlist.h:209!\n[  945.273520] Oops: invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC NOPTI\n[  945.274412] CPU: 7 UID: 0 PID: 56 Comm: kworker/u33:0 Kdump: loaded Not tainted 6.15.0-lku-11779-g8e9d6efccdd7-dirty #1 PREEMPT(voluntary)\n[  945.275736] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-2-gc13ff2cd-prebuilt.qemu.org 04/01/2014\n[  945.276877] Workqueue: writeback wb_workfn (flush-cifs-2)\n[  945.277457] RIP: 0010:crypto_gcm_init_common+0x1f9/0x220\n[  945.278018] Code: b0 00 00 00 48 83 c4 08 5b 5d 41 5c 41 5d 41 5e 41 5f c3 cc cc cc cc 48 c7 c0 00 00 00 80 48 2b 05 5c 58 e5 00 e9 58 ff ff ff <0f> 0b 0f 0b 0f 0b 0f 0b 0f 0b 0f 0b 48 c7 04 24 01 00 00 00 48 8b\n[  945.279992] RSP: 0018:ffffc90000a27360 EFLAGS: 00010246\n[  945.280578] RAX: 0000000000000000 RBX: ffffc90001d85060 RCX: 0000000000000030\n[  945.281376] RDX: 0000000000080000 RSI: 0000000000000000 RDI: ffffc90081d85070\n[  945.282145] RBP: ffffc90001d85010 R08: ffffc90001d85000 R09: 0000000000000000\n[  945.282898] R10: ffffc90001d85090 R11: 0000000000001000 R12: ffffc90001d85070\n[  945.283656] R13: ffff888113522948 R14: ffffc90001d85060 R15: ffffc90001d85010\n[  945.284407] FS:  0000000000000000(0000) GS:ffff8882e66cf000(0000) knlGS:0000000000000000\n[  945.285262] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[  945.285884] CR2: 00007fa7ffdd31f4 CR3: 000000010540d000 CR4: 0000000000350ef0\n[  945.286683] Call Trace:\n[  945.286952]  <TASK>\n[  945.287184]  ? crypt_message+0x33f/0xad0 [cifs]\n[  945.287719]  crypto_gcm_encrypt+0x36/0xe0\n[  945.288152]  crypt_message+0x54a/0xad0 [cifs]\n[  945.288724]  smb3_init_transform_rq+0x277/0x300 [cifs]\n[  945.289300]  smb_send_rqst+0xa3/0x160 [cifs]\n[  945.289944]  cifs_call_async+0x178/0x340 [cifs]\n[  945.290514]  ? __pfx_smb2_writev_callback+0x10/0x10 [cifs]\n[  945.291177]  smb2_async_writev+0x3e3/0x670 [cifs]\n[  945.291759]  ? find_held_lock+0x32/0x90\n[  945.292212]  ? netfs_advance_write+0xf2/0x310\n[  945.292723]  netfs_advance_write+0xf2/0x310\n[  945.293210]  netfs_write_folio+0x346/0xcc0\n[  945.293689]  ? __pfx__raw_spin_unlock_irq+0x10/0x10\n[  945.294250]  netfs_writepages+0x117/0x460\n[  945.294724]  do_writepages+0xbe/0x170\n[  945.295152]  ? find_held_lock+0x32/0x90\n[  945.295600]  ? kvm_sched_clock_read+0x11/0x20\n[  945.296103]  __writeback_single_inode+0x56/0x4b0\n[  945.296643]  writeback_sb_inodes+0x229/0x550\n[  945.297140]  __writeback_inodes_wb+0x4c/0xe0\n[  945.297642]  wb_writeback+0x2f1/0x3f0\n[  945.298069]  wb_workfn+0x300/0x490\n[  945.298472]  process_one_work+0x1fe/0x590\n[  945.298949]  worker_thread+0x1ce/0x3c0\n[  945.299397]  ? __pfx_worker_thread+0x10/0x10\n[  945.299900]  kthr\n---truncated---(CVE-2025-40052)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/rxe: Fix race in do_task() when draining\n\nWhen do_task() exhausts its iteration budget (!ret), it sets the state\nto TASK_STATE_IDLE to reschedule, without a secondary check on the\ncurrent task->state. This can overwrite the TASK_STATE_DRAINING state\nset by a concurrent call to rxe_cleanup_task() or rxe_disable_task().\n\nWhile state changes are protected by a spinlock, both rxe_cleanup_task()\nand rxe_disable_task() release the lock while waiting for the task to\nfinish draining in the while(!is_done(task)) loop. The race occurs if\ndo_task() hits its iteration limit and acquires the lock in this window.\nThe cleanup logic may then proceed while the task incorrectly\nreschedules itself, leading to a potential use-after-free.\n\nThis bug was introduced during the migration from tasklets to workqueues,\nwhere the special handling for the draining case was lost.\n\nFix this by restoring the original pre-migration behavior. If the state is\nTASK_STATE_DRAINING when iterations are exhausted, set cont to 1 to\nforce a new loop iteration. This allows the task to finish its work, so\nthat a subsequent iteration can reach the switch statement and correctly\ntransition the state to TASK_STATE_DRAINED, stopping the task as intended.(CVE-2025-40061)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipv4: start using dst_dev_rcu()\n\nChange icmpv4_xrlim_allow(), ip_defrag() to prevent possible UAF.\n\nChange ipmr_prepare_xmit(), ipmr_queue_fwd_xmit(), ip_mr_output(),\nipv4_neigh_lookup() to use lockdep enabled dst_dev_rcu().(CVE-2025-40074)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntcp_metrics: use dst_dev_net_rcu()\n\nReplace three dst_dev() with a lockdep enabled helper.(CVE-2025-40075)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nixgbevf: fix mailbox API compatibility by negotiating supported features\n\nThere was backward compatibility in the terms of mailbox API. Various\ndrivers from various OSes supporting 10G adapters from Intel portfolio\ncould easily negotiate mailbox API.\n\nThis convention has been broken since introducing API 1.4.\nCommit 0062e7cc955e ("ixgbevf: add VF IPsec offload code") added support\nfor IPSec which is specific only for the kernel ixgbe driver. None of the\nrest of the Intel 10G PF/VF drivers supports it. And actually lack of\nsupport was not included in the IPSec implementation - there were no such\ncode paths. No possibility to negotiate support for the feature was\nintroduced along with introduction of the feature itself.\n\nCommit 339f28964147 ("ixgbevf: Add support for new mailbox communication\nbetween PF and VF") increasing API version to 1.5 did the same - it\nintroduced code supported specifically by the PF ESX driver. It altered API\nversion for the VF driver in the same time not touching the version\ndefined for the PF ixgbe driver. It led to additional discrepancies,\nas the code provided within API 1.6 cannot be supported for Linux ixgbe\ndriver as it causes crashes.\n\nThe issue was noticed some time ago and mitigated by Jake within the commit\nd0725312adf5 ("ixgbevf: stop attempting IPSEC offload on Mailbox API 1.5").\nAs a result we have regression for IPsec support and after increasing API\nto version 1.6 ixgbevf driver stopped to support ESX MBX.\n\nTo fix this mess add new mailbox op asking PF driver about supported\nfeatures. Basing on a response determine whether to set support for IPSec\nand ESX-specific enhanced mailbox.\n\nNew mailbox op, for compatibility purposes, must be added within new API\nrevision, as API version of OOT PF & VF drivers is already increased to\n1.6 and doesn't incorporate features negotiate op.\n\nFeatures negotiation mechanism gives possibility to be extended with new\nfeatures when needed in the future.(CVE-2025-40104)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nASoC: Intel: bytcr_rt5651: Fix invalid quirk input mapping\n\nWhen an invalid value is passed via quirk option, currently\nbytcr_rt5640 driver just ignores and leaves as is, which may lead to\nunepxected results like OOB access.\n\nThis patch adds the sanity check and corrects the input mapping to the\ncertain default value if an invalid value is passed.(CVE-2025-40121)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipv6: use RCU in ip6_xmit()\n\nUse RCU in ip6_xmit() in order to use dst_dev_rcu() to prevent\npossible UAF.(CVE-2025-40135)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmc: Use __sk_dst_get() and dst_dev_rcu() in in smc_clc_prfx_set().\n\nsmc_clc_prfx_set() is called during connect() and not under RCU\nnor RTNL.\n\nUsing sk_dst_get(sk)->dev could trigger UAF.\n\nLet's use __sk_dst_get() and dev_dst_rcu() under rcu_read_lock()\nafter kernel_getsockname().\n\nNote that the returned value of smc_clc_prfx_set() is not used\nin the caller.\n\nWhile at it, we change the 1st arg of smc_clc_prfx_set[46]_rcu()\nnot to touch dst there.(CVE-2025-40139)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntls: Use __sk_dst_get() and dst_dev_rcu() in get_netdev_for_sock().\n\nget_netdev_for_sock() is called during setsockopt(),\nso not under RCU.\n\nUsing sk_dst_get(sk)->dev could trigger UAF.\n\nLet's use __sk_dst_get() and dst_dev_rcu().\n\nNote that the only ->ndo_sk_get_lower_dev() user is\nbond_sk_get_lower_dev(), which uses RCU.(CVE-2025-40149)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\niommu/vt-d: debugfs: Fix legacy mode page table dump logic\n\nIn legacy mode, SSPTPTR is ignored if TT is not 00b or 01b. SSPTPTR\nmaybe uninitialized or zero in that case and may cause oops like:\n\n Oops: general protection fault, probably for non-canonical address\n       0xf00087d3f000f000: 0000 [#1] SMP NOPTI\n CPU: 2 UID: 0 PID: 786 Comm: cat Not tainted 6.16.0 #191 PREEMPT(voluntary)\n Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.17.0-5.fc42 04/01/2014\n RIP: 0010:pgtable_walk_level+0x98/0x150\n RSP: 0018:ffffc90000f279c0 EFLAGS: 00010206\n RAX: 0000000040000000 RBX: ffffc90000f27ab0 RCX: 000000000000001e\n RDX: 0000000000000003 RSI: f00087d3f000f000 RDI: f00087d3f0010000\n RBP: ffffc90000f27a00 R08: ffffc90000f27a98 R09: 0000000000000002\n R10: 0000000000000000 R11: 0000000000000000 R12: f00087d3f000f000\n R13: 0000000000000000 R14: 0000000040000000 R15: ffffc90000f27a98\n FS:  0000764566dcb740(0000) GS:ffff8881f812c000(0000) knlGS:0000000000000000\n CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 0000764566d44000 CR3: 0000000109d81003 CR4: 0000000000772ef0\n PKRU: 55555554\n Call Trace:\n  <TASK>\n  pgtable_walk_level+0x88/0x150\n  domain_translation_struct_show.isra.0+0x2d9/0x300\n  dev_domain_translation_struct_show+0x20/0x40\n  seq_read_iter+0x12d/0x490\n...\n\nAvoid walking the page table if TT is not 00b or 01b.(CVE-2025-40155)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipv6: use RCU in ip6_output()\n\nUse RCU in ip6_output() in order to use dst_dev_rcu() to prevent\npossible UAF.\n\nWe can remove rcu_read_lock()/rcu_read_unlock() pairs\nfrom ip6_finish_output2().(CVE-2025-40158)","affected":[{"package":{"ecosystem":"openEuler:24.03-LTS-SP2","name":"kernel","purl":"pkg:rpm/openEuler/kernel&distro=openEuler-24.03-LTS-SP2"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"6.6.0-127.0.0.126.oe2403sp2"}]}],"ecosystem_specific":{"aarch64":["bpftool-6.6.0-127.0.0.126.oe2403sp2.aarch64.rpm","bpftool-debuginfo-6.6.0-127.0.0.126.oe2403sp2.aarch64.rpm","kernel-6.6.0-127.0.0.126.oe2403sp2.aarch64.rpm","kernel-debuginfo-6.6.0-127.0.0.126.oe2403sp2.aarch64.rpm","kernel-debugsource-6.6.0-127.0.0.126.oe2403sp2.aarch64.rpm","kernel-devel-6.6.0-127.0.0.126.oe2403sp2.aarch64.rpm","kernel-extra-modules-6.6.0-127.0.0.126.oe2403sp2.aarch64.rpm","kernel-headers-6.6.0-127.0.0.126.oe2403sp2.aarch64.rpm","kernel-source-6.6.0-127.0.0.126.oe2403sp2.aarch64.rpm","kernel-tools-6.6.0-127.0.0.126.oe2403sp2.aarch64.rpm","kernel-tools-debuginfo-6.6.0-127.0.0.126.oe2403sp2.aarch64.rpm","kernel-tools-devel-6.6.0-127.0.0.126.oe2403sp2.aarch64.rpm","perf-6.6.0-127.0.0.126.oe2403sp2.aarch64.rpm","perf-debuginfo-6.6.0-127.0.0.126.oe2403sp2.aarch64.rpm","python3-perf-6.6.0-127.0.0.126.oe2403sp2.aarch64.rpm","python3-perf-debuginfo-6.6.0-127.0.0.126.oe2403sp2.aarch64.rpm"],"src":["kernel-6.6.0-127.0.0.126.oe2403sp2.src.rpm"],"x86_64":["bpftool-6.6.0-127.0.0.126.oe2403sp2.x86_64.rpm","bpftool-debuginfo-6.6.0-127.0.0.126.oe2403sp2.x86_64.rpm","kernel-6.6.0-127.0.0.126.oe2403sp2.x86_64.rpm","kernel-debuginfo-6.6.0-127.0.0.126.oe2403sp2.x86_64.rpm","kernel-debugsource-6.6.0-127.0.0.126.oe2403sp2.x86_64.rpm","kernel-devel-6.6.0-127.0.0.126.oe2403sp2.x86_64.rpm","kernel-extra-modules-6.6.0-127.0.0.126.oe2403sp2.x86_64.rpm","kernel-headers-6.6.0-127.0.0.126.oe2403sp2.x86_64.rpm","kernel-source-6.6.0-127.0.0.126.oe2403sp2.x86_64.rpm","kernel-tools-6.6.0-127.0.0.126.oe2403sp2.x86_64.rpm","kernel-tools-debuginfo-6.6.0-127.0.0.126.oe2403sp2.x86_64.rpm","kernel-tools-devel-6.6.0-127.0.0.126.oe2403sp2.x86_64.rpm","perf-6.6.0-127.0.0.126.oe2403sp2.x86_64.rpm","perf-debuginfo-6.6.0-127.0.0.126.oe2403sp2.x86_64.rpm","python3-perf-6.6.0-127.0.0.126.oe2403sp2.x86_64.rpm","python3-perf-debuginfo-6.6.0-127.0.0.126.oe2403sp2.x86_64.rpm"]}}],"references":[{"type":"ADVISORY","url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2025-2804"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-21968"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-22025"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-22042"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-22043"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-37973"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38350"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38470"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38527"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-38727"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-40052"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-40061"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-40074"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-40075"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-40104"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-40121"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-40135"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-40139"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-40149"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-40155"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2025-40158"}],"database_specific":{"severity":"High"}}