Vulnerability-Lookup

URL	Tags
https://git.kernel.org/stable/c/285d4b953f2ca03c3…
https://git.kernel.org/stable/c/88a38b135d69f5db9…
https://git.kernel.org/stable/c/43005002b60ef3424…
https://git.kernel.org/stable/c/3a10619fdefd3051a…
https://git.kernel.org/stable/c/9a579d6a39513069d…
https://git.kernel.org/stable/c/2ce1de32e05445d77…
https://git.kernel.org/stable/c/5158fb8da162e3982…
https://git.kernel.org/stable/c/420c84c330d1688b8…

Vendor	Product	Version	CPE status
Linux	Linux	Affected: 8b4588b8b00b299be16a35be67b331d8fdba03f3 , < 285d4b953f2ca03c358f986718dd89ee9bde632e (git) Affected: 135199a2edd459d2b123144efcd7f9bcd95128e4 , < 88a38b135d69f5db9024ff6527232f1b51be8915 (git) Affected: 635fd8953e4309b54ca6a81bed1d4a87668694f4 , < 43005002b60ef3424719ecda16d124714b45da3b (git) Affected: a69e617e533edddf3fa3123149900f36e0a6dc74 , < 3a10619fdefd3051aeb14860e4d4335529b4e94d (git) Affected: a69e617e533edddf3fa3123149900f36e0a6dc74 , < 9a579d6a39513069d298eee70770bbac8a148565 (git) Affected: a69e617e533edddf3fa3123149900f36e0a6dc74 , < 2ce1de32e05445d77fc056f6ff8339cfb78a5f84 (git) Affected: a69e617e533edddf3fa3123149900f36e0a6dc74 , < 5158fb8da162e3982940f30cd01ed77bdf42c6fc (git) Affected: a69e617e533edddf3fa3123149900f36e0a6dc74 , < 420c84c330d1688b8c764479e5738bbdbf0a33de (git) Affected: d2d6b530d89b0a912148018027386aa049f0a309 (git) Affected: e2a521a7dcc463c5017b4426ca0804e151faeff7 (git) Affected: 7f77dcbc030c2faa6d8e8a594985eeb34018409e (git) Affected: d49bb8cf9bfaa06aa527eb30f1a52a071da2e32f (git) Affected: db3b738ae5f726204876f4303c49cfdf4311403f (git) Affected: 5.4.211 , < 5.4.302 (semver) Affected: 5.10.137 , < 5.10.247 (semver) Affected: 5.15.61 , < 5.15.197 (semver) Affected: 4.9.326 , < 4.10 (semver) Affected: 4.14.291 , < 4.15 (semver) Affected: 4.19.256 , < 4.20 (semver) Affected: 5.18.18 , < 5.19 (semver) Affected: 5.19.2 , < 5.20 (semver)	guessed
Linux	Linux	Affected: 6.0 Unaffected: 0 , < 6.0 (semver) Unaffected: 5.4.302 , ≤ 5.4.* (semver) Unaffected: 5.10.247 , ≤ 5.10.* (semver) Unaffected: 5.15.197 , ≤ 5.15.* (semver) Unaffected: 6.1.159 , ≤ 6.1.* (semver) Unaffected: 6.6.117 , ≤ 6.6.* (semver) Unaffected: 6.12.58 , ≤ 6.12.* (semver) Unaffected: 6.17.8 , ≤ 6.17.* (semver) Unaffected: 6.18 , ≤ * (original_commit_for_fix)	guessed

OESA-2026-1303 (CVE-2024-57994)

Vulnerability from osv_openeuler – Published: 2026-02-06 11:10 – Updated: 2026-08-06 11:10 – Source website

Summary

kernel security update

Details

The Linux Kernel, the operating system core itself.

Security Fix(es):

In the Linux kernel, the following vulnerability has been resolved:

ptr_ring: do not block hard interrupts in ptr_ring_resize_multiple()

Jakub added a lockdep_assert_no_hardirq() check in __page_pool_put_page() to increase test coverage.

syzbot found a splat caused by hard irq blocking in ptr_ring_resize_multiple() [1]

As current users of ptr_ring_resize_multiple() do not require hard irqs being masked, replace it to only block BH.

Rename helpers to better reflect they are safe against BH only.

ptr_ring_resize_multiple() to ptr_ring_resize_multiple_bh()
skb_array_resize_multiple() to skb_array_resize_multiple_bh()

[1]

WARNING: CPU: 1 PID: 9150 at net/core/page_pool.c:709 __page_pool_put_page net/core/page_pool.c:709 [inline] WARNING: CPU: 1 PID: 9150 at net/core/page_pool.c:709 page_pool_put_unrefed_netmem+0x157/0xa40 net/core/page_pool.c:780 Modules linked in: CPU: 1 UID: 0 PID: 9150 Comm: syz.1.1052 Not tainted 6.11.0-rc3-syzkaller-00202-gf8669d7b5f5d #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 RIP: 0010:__page_pool_put_page net/core/page_pool.c:709 [inline] RIP: 0010:page_pool_put_unrefed_netmem+0x157/0xa40 net/core/page_pool.c:780 Code: 74 0e e8 7c aa fb f7 eb 43 e8 75 aa fb f7 eb 3c 65 8b 1d 38 a8 6a 76 31 ff 89 de e8 a3 ae fb f7 85 db 74 0b e8 5a aa fb f7 90 <0f> 0b 90 eb 1d 65 8b 1d 15 a8 6a 76 31 ff 89 de e8 84 ae fb f7 85 RSP: 0018:ffffc9000bda6b58 EFLAGS: 00010083 RAX: ffffffff8997e523 RBX: 0000000000000000 RCX: 0000000000040000 RDX: ffffc9000fbd0000 RSI: 0000000000001842 RDI: 0000000000001843 RBP: 0000000000000000 R08: ffffffff8997df2c R09: 1ffffd40003a000d R10: dffffc0000000000 R11: fffff940003a000e R12: ffffea0001d00040 R13: ffff88802e8a4000 R14: dffffc0000000000 R15: 00000000ffffffff FS: 00007fb7aaf716c0(0000) GS:ffff8880b9300000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fa15a0d4b72 CR3: 00000000561b0000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> tun_ptr_free drivers/net/tun.c:617 [inline] __ptr_ring_swap_queue include/linux/ptr_ring.h:571 [inline] ptr_ring_resize_multiple_noprof include/linux/ptr_ring.h:643 [inline] tun_queue_resize drivers/net/tun.c:3694 [inline] tun_device_event+0xaaf/0x1080 drivers/net/tun.c:3714 notifier_call_chain+0x19f/0x3e0 kernel/notifier.c:93 call_netdevice_notifiers_extack net/core/dev.c:2032 [inline] call_netdevice_notifiers net/core/dev.c:2046 [inline] dev_change_tx_queue_len+0x158/0x2a0 net/core/dev.c:9024 do_setlink+0xff6/0x41f0 net/core/rtnetlink.c:2923 rtnl_setlink+0x40d/0x5a0 net/core/rtnetlink.c:3201 rtnetlink_rcv_msg+0x73f/0xcf0 net/core/rtnetlink.c:6647 netlink_rcv_skb+0x1e3/0x430 net/netlink/af_netlink.c:2550(CVE-2024-57994)

In the Linux kernel, the following vulnerability has been resolved:

ASoC: SOF: Intel: hda-dai: Ensure DAI widget is valid during params

Each cpu DAI should associate with a widget. However, the topology might not create the right number of DAI widgets for aggregated amps. And it will cause NULL pointer deference. Check that the DAI widget associated with the CPU DAI is valid to prevent NULL pointer deference due to missing DAI widgets in topologies with aggregated amps.(CVE-2024-58012)

In the Linux kernel, the following vulnerability has been resolved:

driver core: fix potential NULL pointer dereference in dev_uevent()

If userspace reads "uevent" device attribute at the same time as another threads unbinds the device from its driver, change to dev->driver from a valid pointer to NULL may result in crash. Fix this by using READ_ONCE() when fetching the pointer, and take bus' drivers klist lock to make sure driver instance will not disappear while we access it.

Use WRITE_ONCE() when setting the driver pointer to ensure there is no tearing.(CVE-2025-37800)

In the Linux kernel, the following vulnerability has been resolved:

net/mdiobus: Fix potential out-of-bounds clause 45 read/write access

When using publicly available tools like 'mdio-tools' to read/write data from/to network interface and its PHY via C45 (clause 45) mdiobus, there is no verification of parameters passed to the ioctl and it accepts any mdio address. Currently there is support for 32 addresses in kernel via PHY_MAX_ADDR define, but it is possible to pass higher value than that via ioctl. While read/write operation should generally fail in this case, mdiobus provides stats array, where wrong address may allow out-of-bounds read/write.

Fix that by adding address verification before C45 read/write operation. While this excludes this access from any statistics, it improves security of read/write operation.(CVE-2025-38110)

In the Linux kernel, the following vulnerability has been resolved:

net/mdiobus: Fix potential out-of-bounds read/write access

When using publicly available tools like 'mdio-tools' to read/write data from/to network interface and its PHY via mdiobus, there is no verification of parameters passed to the ioctl and it accepts any mdio address. Currently there is support for 32 addresses in kernel via PHY_MAX_ADDR define, but it is possible to pass higher value than that via ioctl. While read/write operation should generally fail in this case, mdiobus provides stats array, where wrong address may allow out-of-bounds read/write.

Fix that by adding address verification before read/write operation. While this excludes this access from any statistics, it improves security of read/write operation.(CVE-2025-38111)

In the Linux kernel, the following vulnerability has been resolved:

net: phy: clear phydev->devlink when the link is deleted

There is a potential crash issue when disabling and re-enabling the network port. When disabling the network port, phy_detach() calls device_link_del() to remove the device link, but it does not clear phydev->devlink, so phydev->devlink is not a NULL pointer. Then the network port is re-enabled, but if phy_attach_direct() fails before calling device_link_add(), the code jumps to the "error" label and calls phy_detach(). Since phydev->devlink retains the old value from the previous attach/detach cycle, device_link_del() uses the old value, which accesses a NULL pointer and causes a crash. The simplified crash log is as follows.

[ 24.702421] Call trace: [ 24.704856] device_link_put_kref+0x20/0x120 [ 24.709124] device_link_del+0x30/0x48 [ 24.712864] phy_detach+0x24/0x168 [ 24.716261] phy_attach_direct+0x168/0x3a4 [ 24.720352] phylink_fwnode_phy_connect+0xc8/0x14c [ 24.725140] phylink_of_phy_connect+0x1c/0x34

Therefore, phydev->devlink needs to be cleared when the device link is deleted.(CVE-2025-38149)

In the Linux kernel, the following vulnerability has been resolved:

netfilter: nft_set_pipapo: prevent overflow in lookup table allocation

When calculating the lookup table size, ensure the following multiplication does not overflow:

desc->field_len[] maximum value is U8_MAX multiplied by NFT_PIPAPO_GROUPS_PER_BYTE(f) that can be 2, worst case.
NFT_PIPAPO_BUCKETS(f->bb) is 2^8, worst case.
sizeof(unsigned long), from sizeof(*f->lt), lt in struct nft_pipapo_field.

Then, use check_mul_overflow() to multiply by bucket size and then use check_add_overflow() to the alignment for avx2 (if needed). Finally, add lt_size_check_overflow() helper and use it to consolidate this.

While at it, replace leftover allocation using the GFP_KERNEL to GFP_KERNEL_ACCOUNT for consistency, in pipapo_resize().(CVE-2025-38162)

In the Linux kernel, the following vulnerability has been resolved:

smb: client: add NULL check in automount_fullpath

page is checked for null in __build_path_from_dentry_optional_prefix when tcon->origin_fullpath is not set. However, the check is missing when it is set. Add a check to prevent a potential NULL pointer dereference.(CVE-2025-38208)

In the Linux kernel, the following vulnerability has been resolved:

NFSD: fix race between nfsd registration and exports_proc

As of now nfsd calls create_proc_exports_entry() at start of init_nfsd and cleanup by remove_proc_entry() at last of exit_nfsd.

Which causes kernel OOPs if there is race between below 2 operations: (i) exportfs -r (ii) mount -t nfsd none /proc/fs/nfsd

for 5.4 kernel ARM64:

CPU 1: el1_irq+0xbc/0x180 arch_counter_get_cntvct+0x14/0x18 running_clock+0xc/0x18 preempt_count_add+0x88/0x110 prep_new_page+0xb0/0x220 get_page_from_freelist+0x2d8/0x1778 __alloc_pages_nodemask+0x15c/0xef0 __vmalloc_node_range+0x28c/0x478 __vmalloc_node_flags_caller+0x8c/0xb0 kvmalloc_node+0x88/0xe0 nfsd_init_net+0x6c/0x108 [nfsd] ops_init+0x44/0x170 register_pernet_operations+0x114/0x270 register_pernet_subsys+0x34/0x50 init_nfsd+0xa8/0x718 [nfsd] do_one_initcall+0x54/0x2e0

CPU 2 : Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010

PC is at : exports_net_open+0x50/0x68 [nfsd]

Call trace: exports_net_open+0x50/0x68 [nfsd] exports_proc_open+0x2c/0x38 [nfsd] proc_reg_open+0xb8/0x198 do_dentry_open+0x1c4/0x418 vfs_open+0x38/0x48 path_openat+0x28c/0xf18 do_filp_open+0x70/0xe8 do_sys_open+0x154/0x248

Sometimes it crashes at exports_net_open() and sometimes cache_seq_next_rcu().

and same is happening on latest 6.14 kernel as well:

[ 0.000000] Linux version 6.14.0-rc5-next-20250304-dirty ... [ 285.455918] Unable to handle kernel paging request at virtual address 00001f4800001f48 ... [ 285.464902] pc : cache_seq_next_rcu+0x78/0xa4 ... [ 285.469695] Call trace: [ 285.470083] cache_seq_next_rcu+0x78/0xa4 (P) [ 285.470488] seq_read+0xe0/0x11c [ 285.470675] proc_reg_read+0x9c/0xf0 [ 285.470874] vfs_read+0xc4/0x2fc [ 285.471057] ksys_read+0x6c/0xf4 [ 285.471231] __arm64_sys_read+0x1c/0x28 [ 285.471428] invoke_syscall+0x44/0x100 [ 285.471633] el0_svc_common.constprop.0+0x40/0xe0 [ 285.471870] do_el0_svc_compat+0x1c/0x34 [ 285.472073] el0_svc_compat+0x2c/0x80 [ 285.472265] el0t_32_sync_handler+0x90/0x140 [ 285.472473] el0t_32_sync+0x19c/0x1a0 [ 285.472887] Code: f9400885 93407c23 937d7c27 11000421 (f86378a3) [ 285.473422] ---[ end trace 0000000000000000 ]---

It reproduced simply with below script: while [ 1 ] do /exportfs -r done &

while [ 1 ] do insmod /nfsd.ko mount -t nfsd none /proc/fs/nfsd umount /proc/fs/nfsd rmmod nfsd done &

So exporting interfaces to user space shall be done at last and cleanup at first place.

With change there is no Kernel OOPs.(CVE-2025-38232)

In the Linux kernel, the following vulnerability has been resolved:

smb: client: fix potential deadlock when reconnecting channels

Fix cifs_signal_cifsd_for_reconnect() to take the correct lock order and prevent the following deadlock from happening

====================================================== WARNING: possible circular locking dependency detected 6.16.0-rc3-build2+ #1301 Tainted: G S W

cifsd/6055 is trying to acquire lock: ffff88810ad56038 (&tcp_ses->srv_lock){+.+.}-{3:3}, at: cifs_signal_cifsd_for_reconnect+0x134/0x200

but task is already holding lock: ffff888119c64330 (&ret_buf->chan_lock){+.+.}-{3:3}, at: cifs_signal_cifsd_for_reconnect+0xcf/0x200

which lock already depends on the new lock.

the existing dependency chain (in reverse order) is:

-> #2 (&ret_buf->chan_lock){+.+.}-{3:3}: validate_chain+0x1cf/0x270 __lock_acquire+0x60e/0x780 lock_acquire.part.0+0xb4/0x1f0 _raw_spin_lock+0x2f/0x40 cifs_setup_session+0x81/0x4b0 cifs_get_smb_ses+0x771/0x900 cifs_mount_get_session+0x7e/0x170 cifs_mount+0x92/0x2d0 cifs_smb3_do_mount+0x161/0x460 smb3_get_tree+0x55/0x90 vfs_get_tree+0x46/0x180 do_new_mount+0x1b0/0x2e0 path_mount+0x6ee/0x740 do_mount+0x98/0xe0 __do_sys_mount+0x148/0x180 do_syscall_64+0xa4/0x260 entry_SYSCALL_64_after_hwframe+0x76/0x7e

-> #1 (&ret_buf->ses_lock){+.+.}-{3:3}: validate_chain+0x1cf/0x270 __lock_acquire+0x60e/0x780 lock_acquire.part.0+0xb4/0x1f0 _raw_spin_lock+0x2f/0x40 cifs_match_super+0x101/0x320 sget+0xab/0x270 cifs_smb3_do_mount+0x1e0/0x460 smb3_get_tree+0x55/0x90 vfs_get_tree+0x46/0x180 do_new_mount+0x1b0/0x2e0 path_mount+0x6ee/0x740 do_mount+0x98/0xe0 __do_sys_mount+0x148/0x180 do_syscall_64+0xa4/0x260 entry_SYSCALL_64_after_hwframe+0x76/0x7e

-> #0 (&tcp_ses->srv_lock){+.+.}-{3:3}: check_noncircular+0x95/0xc0 check_prev_add+0x115/0x2f0 validate_chain+0x1cf/0x270 __lock_acquire+0x60e/0x780 lock_acquire.part.0+0xb4/0x1f0 _raw_spin_lock+0x2f/0x40 cifs_signal_cifsd_for_reconnect+0x134/0x200 __cifs_reconnect+0x8f/0x500 cifs_handle_standard+0x112/0x280 cifs_demultiplex_thread+0x64d/0xbc0 kthread+0x2f7/0x310 ret_from_fork+0x2a/0x230 ret_from_fork_asm+0x1a/0x30

other info that might help us debug this:

Chain exists of: &tcp_ses->srv_lock --> &ret_buf->ses_lock --> &ret_buf->chan_lock

Possible unsafe locking scenario:

   CPU0                    CPU1
   ----                    ----

lock(&ret_buf->chan_lock); lock(&ret_buf->ses_lock); lock(&ret_buf->chan_lock); lock(&tcp_ses->srv_lock);

*** DEADLOCK ***

3 locks held by cifsd/6055: #0: ffffffff857de398 (&cifs_tcp_ses_lock){+.+.}-{3:3}, at: cifs_signal_cifsd_for_reconnect+0x7b/0x200 #1: ffff888119c64060 (&ret_buf->ses_lock){+.+.}-{3:3}, at: cifs_signal_cifsd_for_reconnect+0x9c/0x200 #2: ffff888119c64330 (&ret_buf->chan_lock){+.+.}-{3:3}, at: cifs_signal_cifsd_for_reconnect+0xcf/0x200(CVE-2025-38244)

In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: eir: Fix possible crashes on eir_create_adv_data

eir_create_adv_data may attempt to add EIR_FLAGS and EIR_TX_POWER without checking if that would fit.(CVE-2025-38303)

In the Linux kernel, the following vulnerability has been resolved:

software node: Correct a OOB check in software_node_get_reference_args()

software_node_get_reference_args() wants to get @index-th element, so the property value requires at least '(index + 1) * sizeof(*ref)' bytes but that can not be guaranteed by current OOB check, and may cause OOB for malformed property.

Fix by using as OOB check '((index + 1) * sizeof(*ref) > prop->length)'.(CVE-2025-38342)

In the Linux kernel, the following vulnerability has been resolved:

NFSv4/pNFS: Fix a race to wake on NFS_LAYOUT_DRAIN

We found a few different systems hung up in writeback waiting on the same page lock, and one task waiting on the NFS_LAYOUT_DRAIN bit in pnfs_update_layout(), however the pnfs_layout_hdr's plh_outstanding count was zero.

It seems most likely that this is another race between the waiter and waker similar to commit ed0172af5d6f ("SUNRPC: Fix a race to wake a sync task"). Fix it up by applying the advised barrier.(CVE-2025-38393)

In the Linux kernel, the following vulnerability has been resolved:

KVM: SVM: Reject SEV{-ES} intra host migration if vCPU creation is in-flight

Reject migration of SEV{-ES} state if either the source or destination VM is actively creating a vCPU, i.e. if kvm_vm_ioctl_create_vcpu() is in the section between incrementing created_vcpus and online_vcpus. The bulk of vCPU creation runs outside of kvm->lock to allow creating multiple vCPUs in parallel, and so sev_info.es_active can get toggled from false=>true in the destination VM after (or during) svm_vcpu_create(), resulting in an SEV{-ES} VM effectively having a non-SEV{-ES} vCPU.

The issue manifests most visibly as a crash when trying to free a vCPU's NULL VMSA page in an SEV-ES VM, but any number of things can go wrong.

BUG: unable to handle page fault for address: ffffebde00000000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP KASAN NOPTI CPU: 227 UID: 0 PID: 64063 Comm: syz.5.60023 Tainted: G U O 6.15.0-smp-DEV #2 NONE Tainted: [U]=USER, [O]=OOT_MODULE Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 12.52.0-0 10/28/2024 RIP: 0010:constant_test_bit arch/x86/include/asm/bitops.h:206 [inline] RIP: 0010:arch_test_bit arch/x86/include/asm/bitops.h:238 [inline] RIP: 0010:_test_bit include/asm-generic/bitops/instrumented-non-atomic.h:142 [inline] RIP: 0010:PageHead include/linux/page-flags.h:866 [inline] RIP: 0010:freepages+0x3e/0x120 mm/page_alloc.c:5067 Code: <49> f7 06 40 00 00 00 75 05 45 31 ff eb 0c 66 90 4c 89 f0 4c 39 f0 RSP: 0018:ffff8984551978d0 EFLAGS: 00010246 RAX: 0000777f80000001 RBX: 0000000000000000 RCX: ffffffff918aeb98 RDX: 0000000000000000 RSI: 0000000000000008 RDI: ffffebde00000000 RBP: 0000000000000000 R08: ffffebde00000007 R09: 1ffffd7bc0000000 R10: dffffc0000000000 R11: fffff97bc0000001 R12: dffffc0000000000 R13: ffff8983e19751a8 R14: ffffebde00000000 R15: 1ffffd7bc0000000 FS: 0000000000000000(0000) GS:ffff89ee661d3000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffebde00000000 CR3: 000000793ceaa000 CR4: 0000000000350ef0 DR0: 0000000000000000 DR1: 0000000000000b5f DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Call Trace: <TASK> sev_free_vcpu+0x413/0x630 arch/x86/kvm/svm/sev.c:3169 svm_vcpu_free+0x13a/0x2a0 arch/x86/kvm/svm/svm.c:1515 kvm_arch_vcpu_destroy+0x6a/0x1d0 arch/x86/kvm/x86.c:12396 kvm_vcpu_destroy virt/kvm/kvm_main.c:470 [inline] kvm_destroy_vcpus+0xd1/0x300 virt/kvm/kvm_main.c:490 kvm_arch_destroy_vm+0x636/0x820 arch/x86/kvm/x86.c:12895 kvm_put_kvm+0xb8e/0xfb0 virt/kvm/kvm_main.c:1310 kvm_vm_release+0x48/0x60 virt/kvm/kvm_main.c:1369 fput+0x3e4/0x9e0 fs/file_table.c:465 task_work_run+0x1a9/0x220 kernel/task_work.c:227 exit_task_work include/linux/task_work.h:40 [inline] do_exit+0x7f0/0x25b0 kernel/exit.c:953 do_group_exit+0x203/0x2d0 kernel/exit.c:1102 get_signal+0x1357/0x1480 kernel/signal.c:3034 arch_do_signal_or_restart+0x40/0x690 arch/x86/kernel/signal.c:337 exit_to_user_mode_loop kernel/entry/common.c:111 [inline] exit_to_user_mode_prepare include/linux/entry-common.h:329 [inline] __syscall_exit_to_user_mode_work kernel/entry/common.c:207 [inline] syscall_exit_to_user_mode+0x67/0xb0 kernel/entry/common.c:218 do_syscall_64+0x7c/0x150 arch/x86/entry/syscall_64.c:100 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7f87a898e969 </TASK> Modules linked in: gq(O) gsmi: Log Shutdown Reason 0x03 CR2: ffffebde00000000 ---[ end trace 0000000000000000 ]---

Deliberately don't check for a NULL VMSA when freeing the vCPU, as crashing the host is likely desirable due to the VMSA being consumed by hardware. E.g. if KVM manages to allow VMRUN on the vCPU, hardware may read/write a bogus VMSA page. Accessing P ---truncated---(CVE-2025-38455)

In the Linux kernel, the following vulnerability has been resolved:

s390/bpf: Fix bpf_arch_text_poke() with new_addr == NULL again

Commit 7ded842b356d ("s390/bpf: Fix bpf_plt pointer arithmetic") has accidentally removed the critical piece of commit c730fce7c70c ("s390/bpf: Fix bpf_arch_text_poke() with new_addr == NULL"), causing intermittent kernel panics in e.g. perf's on_switch() prog to reappear.

Restore the fix and add a comment.(CVE-2025-38489)

In the Linux kernel, the following vulnerability has been resolved:

iommu/amd: Avoid stack buffer overflow from kernel cmdline

While the kernel command line is considered trusted in most environments, avoid writing 1 byte past the end of "acpiid" if the "str" argument is maximum length.(CVE-2025-38676)

In the Linux kernel, the following vulnerability has been resolved:

iommufd: Prevent ALIGN() overflow

When allocating IOVA the candidate range gets aligned to the target alignment. If the range is close to ULONG_MAX then the ALIGN() can wrap resulting in a corrupted iova.

Open code the ALIGN() using get_add_overflow() to prevent this. This simplifies the checks as we don't need to check for length earlier either.

Consolidate the two copies of this code under a single helper.

This bug would allow userspace to create a mapping that overlaps with some other mapping or a reserved range.(CVE-2025-38688)

In the Linux kernel, the following vulnerability has been resolved:

jfs: upper bound check of tree index in dbAllocAG

When computing the tree index in dbAllocAG, we never check if we are out of bounds realative to the size of the stree. This could happen in a scenario where the filesystem metadata are corrupted.(CVE-2025-38697)

In the Linux kernel, the following vulnerability has been resolved:

hfsplus: don't use BUG_ON() in hfsplus_create_attributes_file()

When the volume header contains erroneous values that do not reflect the actual state of the filesystem, hfsplus_fill_super() assumes that the attributes file is not yet created, which later results in hitting BUG_ON() when hfsplus_create_attributes_file() is called. Replace this BUG_ON() with -EIO error with a message to suggest running fsck tool.(CVE-2025-38712)

In the Linux kernel, the following vulnerability has been resolved:

hfsplus: fix slab-out-of-bounds read in hfsplus_uni2asc()

The hfsplus_readdir() method is capable to crash by calling hfsplus_uni2asc():

[ 667.121659][ T9805] ================================================================== [ 667.122651][ T9805] BUG: KASAN: slab-out-of-bounds in hfsplus_uni2asc+0x902/0xa10 [ 667.123627][ T9805] Read of size 2 at addr ffff88802592f40c by task repro/9805 [ 667.124578][ T9805] [ 667.124876][ T9805] CPU: 3 UID: 0 PID: 9805 Comm: repro Not tainted 6.16.0-rc3 #1 PREEMPT(full) [ 667.124886][ T9805] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 667.124890][ T9805] Call Trace: [ 667.124893][ T9805] <TASK> [ 667.124896][ T9805] dump_stack_lvl+0x10e/0x1f0 [ 667.124911][ T9805] print_report+0xd0/0x660 [ 667.124920][ T9805] ? __virt_addr_valid+0x81/0x610 [ 667.124928][ T9805] ? __phys_addr+0xe8/0x180 [ 667.124934][ T9805] ? hfsplus_uni2asc+0x902/0xa10 [ 667.124942][ T9805] kasan_report+0xc6/0x100 [ 667.124950][ T9805] ? hfsplus_uni2asc+0x902/0xa10 [ 667.124959][ T9805] hfsplus_uni2asc+0x902/0xa10 [ 667.124966][ T9805] ? hfsplus_bnode_read+0x14b/0x360 [ 667.124974][ T9805] hfsplus_readdir+0x845/0xfc0 [ 667.124984][ T9805] ? __pfx_hfsplus_readdir+0x10/0x10 [ 667.124994][ T9805] ? stack_trace_save+0x8e/0xc0 [ 667.125008][ T9805] ? iterate_dir+0x18b/0xb20 [ 667.125015][ T9805] ? trace_lock_acquire+0x85/0xd0 [ 667.125022][ T9805] ? lock_acquire+0x30/0x80 [ 667.125029][ T9805] ? iterate_dir+0x18b/0xb20 [ 667.125037][ T9805] ? down_read_killable+0x1ed/0x4c0 [ 667.125044][ T9805] ? putname+0x154/0x1a0 [ 667.125051][ T9805] ? __pfx_down_read_killable+0x10/0x10 [ 667.125058][ T9805] ? apparmor_file_permission+0x239/0x3e0 [ 667.125069][ T9805] iterate_dir+0x296/0xb20 [ 667.125076][ T9805] __x64_sys_getdents64+0x13c/0x2c0 [ 667.125084][ T9805] ? __pfxx64sys_getdents64+0x10/0x10 [ 667.125091][ T9805] ? x64_sys_openat+0x141/0x200 [ 667.125126][ T9805] ? __pfx_filldir64+0x10/0x10 [ 667.125134][ T9805] ? do_user_addr_fault+0x7fe/0x12f0 [ 667.125143][ T9805] do_syscall_64+0xc9/0x480 [ 667.125151][ T9805] entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 667.125158][ T9805] RIP: 0033:0x7fa8753b2fc9 [ 667.125164][ T9805] Code: 00 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 48 [ 667.125172][ T9805] RSP: 002b:00007ffe96f8e0f8 EFLAGS: 00000217 ORIG_RAX: 00000000000000d9 [ 667.125181][ T9805] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fa8753b2fc9 [ 667.125185][ T9805] RDX: 0000000000000400 RSI: 00002000000063c0 RDI: 0000000000000004 [ 667.125190][ T9805] RBP: 00007ffe96f8e110 R08: 00007ffe96f8e110 R09: 00007ffe96f8e110 [ 667.125195][ T9805] R10: 0000000000000000 R11: 0000000000000217 R12: 0000556b1e3b4260 [ 667.125199][ T9805] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 [ 667.125207][ T9805] </TASK> [ 667.125210][ T9805] [ 667.145632][ T9805] Allocated by task 9805: [ 667.145991][ T9805] kasan_save_stack+0x20/0x40 [ 667.146352][ T9805] kasan_save_track+0x14/0x30 [ 667.146717][ T9805] __kasan_kmalloc+0xaa/0xb0 [ 667.147065][ T9805] __kmalloc_noprof+0x205/0x550 [ 667.147448][ T9805] hfsplus_find_init+0x95/0x1f0 [ 667.147813][ T9805] hfsplus_readdir+0x220/0xfc0 [ 667.148174][ T9805] iterate_dir+0x296/0xb20 [ 667.148549][ T9805] __x64_sys_getdents64+0x13c/0x2c0 [ 667.148937][ T9805] do_syscall_64+0xc9/0x480 [ 667.149291][ T9805] entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 667.149809][ T9805] [ 667.150030][ T9805] The buggy address belongs to the object at ffff88802592f000 [ 667.150030][ T9805] which belongs to the cache kmalloc-2k of size 2048 [ 667.151282][ T9805] The buggy address is located 0 bytes to the right of [ 667.151282][ T9805] allocated 1036-byte region [ffff88802592f000, ffff88802592f40c) [ 667.1 ---truncated---(CVE-2025-38713)

In the Linux kernel, the following vulnerability has been resolved:

hfsplus: fix slab-out-of-bounds in hfsplus_bnode_read()

The hfsplus_bnode_read() method can trigger the issue:

[ 174.852007][ T9784] ================================================================== [ 174.852709][ T9784] BUG: KASAN: slab-out-of-bounds in hfsplus_bnode_read+0x2f4/0x360 [ 174.853412][ T9784] Read of size 8 at addr ffff88810b5fc6c0 by task repro/9784 [ 174.854059][ T9784] [ 174.854272][ T9784] CPU: 1 UID: 0 PID: 9784 Comm: repro Not tainted 6.16.0-rc3 #7 PREEMPT(full) [ 174.854281][ T9784] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 174.854286][ T9784] Call Trace: [ 174.854289][ T9784] <TASK> [ 174.854292][ T9784] dump_stack_lvl+0x10e/0x1f0 [ 174.854305][ T9784] print_report+0xd0/0x660 [ 174.854315][ T9784] ? __virt_addr_valid+0x81/0x610 [ 174.854323][ T9784] ? __phys_addr+0xe8/0x180 [ 174.854330][ T9784] ? hfsplus_bnode_read+0x2f4/0x360 [ 174.854337][ T9784] kasan_report+0xc6/0x100 [ 174.854346][ T9784] ? hfsplus_bnode_read+0x2f4/0x360 [ 174.854354][ T9784] hfsplus_bnode_read+0x2f4/0x360 [ 174.854362][ T9784] hfsplus_bnode_dump+0x2ec/0x380 [ 174.854370][ T9784] ? __pfx_hfsplus_bnode_dump+0x10/0x10 [ 174.854377][ T9784] ? hfsplus_bnode_write_u16+0x83/0xb0 [ 174.854385][ T9784] ? srcu_gp_start+0xd0/0x310 [ 174.854393][ T9784] ? __mark_inode_dirty+0x29e/0xe40 [ 174.854402][ T9784] hfsplus_brec_remove+0x3d2/0x4e0 [ 174.854411][ T9784] __hfsplus_delete_attr+0x290/0x3a0 [ 174.854419][ T9784] ? __pfx_hfs_find_1st_rec_by_cnid+0x10/0x10 [ 174.854427][ T9784] ? __pfxhfsplusdelete_attr+0x10/0x10 [ 174.854436][ T9784] ? asan_memset+0x23/0x50 [ 174.854450][ T9784] hfsplus_delete_all_attrs+0x262/0x320 [ 174.854459][ T9784] ? __pfx_hfsplus_delete_all_attrs+0x10/0x10 [ 174.854469][ T9784] ? rcu_is_watching+0x12/0xc0 [ 174.854476][ T9784] ? __mark_inode_dirty+0x29e/0xe40 [ 174.854483][ T9784] hfsplus_delete_cat+0x845/0xde0 [ 174.854493][ T9784] ? __pfx_hfsplus_delete_cat+0x10/0x10 [ 174.854507][ T9784] hfsplus_unlink+0x1ca/0x7c0 [ 174.854516][ T9784] ? __pfx_hfsplus_unlink+0x10/0x10 [ 174.854525][ T9784] ? down_write+0x148/0x200 [ 174.854532][ T9784] ? __pfx_down_write+0x10/0x10 [ 174.854540][ T9784] vfs_unlink+0x2fe/0x9b0 [ 174.854549][ T9784] do_unlinkat+0x490/0x670 [ 174.854557][ T9784] ? __pfx_do_unlinkat+0x10/0x10 [ 174.854565][ T9784] ? __might_fault+0xbc/0x130 [ 174.854576][ T9784] ? getname_flags.part.0+0x1c5/0x550 [ 174.854584][ T9784] __x64_sys_unlink+0xc5/0x110 [ 174.854592][ T9784] do_syscall_64+0xc9/0x480 [ 174.854600][ T9784] entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 174.854608][ T9784] RIP: 0033:0x7f6fdf4c3167 [ 174.854614][ T9784] Code: f0 ff ff 73 01 c3 48 8b 0d 26 0d 0e 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 08 [ 174.854622][ T9784] RSP: 002b:00007ffcb948bca8 EFLAGS: 00000206 ORIG_RAX: 0000000000000057 [ 174.854630][ T9784] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f6fdf4c3167 [ 174.854636][ T9784] RDX: 00007ffcb948bcc0 RSI: 00007ffcb948bcc0 RDI: 00007ffcb948bd50 [ 174.854641][ T9784] RBP: 00007ffcb948cd90 R08: 0000000000000001 R09: 00007ffcb948bb40 [ 174.854645][ T9784] R10: 00007f6fdf564fc0 R11: 0000000000000206 R12: 0000561e1bc9c2d0 [ 174.854650][ T9784] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 [ 174.854658][ T9784] </TASK> [ 174.854661][ T9784] [ 174.879281][ T9784] Allocated by task 9784: [ 174.879664][ T9784] kasan_save_stack+0x20/0x40 [ 174.880082][ T9784] kasan_save_track+0x14/0x30 [ 174.880500][ T9784] __kasan_kmalloc+0xaa/0xb0 [ 174.880908][ T9784] __kmalloc_noprof+0x205/0x550 [ 174.881337][ T9784] __hfs_bnode_create+0x107/0x890 [ 174.881779][ T9784] hfsplus_bnode_find+0x2d0/0xd10 [ 174.882222][ T9784] hfsplus_brec_find+0x2b0/0x520 [ 174.882659][ T9784] hfsplus_delete_all_attrs+0x23b/0x3 ---truncated---(CVE-2025-38714)

In the Linux kernel, the following vulnerability has been resolved:

smb3: fix for slab out of bounds on mount to ksmbd

With KASAN enabled, it is possible to get a slab out of bounds during mount to ksmbd due to missing check in parse_server_interfaces() (see below):

BUG: KASAN: slab-out-of-bounds in parse_server_interfaces+0x14ee/0x1880 [cifs] Read of size 4 at addr ffff8881433dba98 by task mount/9827

CPU: 5 UID: 0 PID: 9827 Comm: mount Tainted: G OE 6.16.0-rc2-kasan #2 PREEMPT(voluntary) Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE Hardware name: Dell Inc. Precision Tower 3620/0MWYPT, BIOS 2.13.1 06/14/2019 Call Trace: <TASK> dump_stack_lvl+0x9f/0xf0 print_report+0xd1/0x670 __virt_addr_valid+0x22c/0x430 ? parse_server_interfaces+0x14ee/0x1880 [cifs] ? kasan_complete_mode_report_info+0x2a/0x1f0 ? parse_server_interfaces+0x14ee/0x1880 [cifs] kasan_report+0xd6/0x110 parse_server_interfaces+0x14ee/0x1880 [cifs] __asan_report_load_n_noabort+0x13/0x20 parse_server_interfaces+0x14ee/0x1880 [cifs] ? __pfx_parse_server_interfaces+0x10/0x10 [cifs] ? trace_hardirqs_on+0x51/0x60 SMB3_request_interfaces+0x1ad/0x3f0 [cifs] ? __pfx_SMB3_request_interfaces+0x10/0x10 [cifs] ? SMB2_tcon+0x23c/0x15d0 [cifs] smb3_qfs_tcon+0x173/0x2b0 [cifs] ? __pfx_smb3_qfs_tcon+0x10/0x10 [cifs] ? cifs_get_tcon+0x105d/0x2120 [cifs] ? do_raw_spin_unlock+0x5d/0x200 ? cifs_get_tcon+0x105d/0x2120 [cifs] ? __pfx_smb3_qfs_tcon+0x10/0x10 [cifs] cifs_mount_get_tcon+0x369/0xb90 [cifs] ? dfs_cache_find+0xe7/0x150 [cifs] dfs_mount_share+0x985/0x2970 [cifs] ? check_path.constprop.0+0x28/0x50 ? save_trace+0x54/0x370 ? __pfx_dfs_mount_share+0x10/0x10 [cifs] ? __lock_acquire+0xb82/0x2ba0 ? __kasan_check_write+0x18/0x20 cifs_mount+0xbc/0x9e0 [cifs] ? __pfx_cifs_mount+0x10/0x10 [cifs] ? do_raw_spin_unlock+0x5d/0x200 ? cifs_setup_cifs_sb+0x29d/0x810 [cifs] cifs_smb3_do_mount+0x263/0x1990 cifs

In the Linux kernel, the following vulnerability has been resolved:

ksmbd: fix refcount leak causing resource not released

When ksmbd_conn_releasing(opinfo->conn) returns true,the refcount was not decremented properly, causing a refcount leak that prevents the count from reaching zero and the memory from being released.(CVE-2025-39720)

In the Linux kernel, the following vulnerability has been resolved:

crypto: qat - flush misc workqueue during device shutdown

Repeated loading and unloading of a device specific QAT driver, for example qat_4xxx, in a tight loop can lead to a crash due to a use-after-free scenario. This occurs when a power management (PM) interrupt triggers just before the device-specific driver (e.g., qat_4xxx.ko) is unloaded, while the core driver (intel_qat.ko) remains loaded.

Since the driver uses a shared workqueue (qat_misc_wq) across all devices and owned by intel_qat.ko, a deferred routine from the device-specific driver may still be pending in the queue. If this routine executes after the driver is unloaded, it can dereference freed memory, resulting in a page fault and kernel crash like the following:

BUG: unable to handle page fault for address: ffa000002e50a01c
#PF: supervisor read access in kernel mode
RIP: 0010:pm_bh_handler+0x1d2/0x250 [intel_qat]
Call Trace:
  pm_bh_handler+0x1d2/0x250 [intel_qat]
  process_one_work+0x171/0x340
  worker_thread+0x277/0x3a0
  kthread+0xf0/0x120
  ret_from_fork+0x2d/0x50

To prevent this, flush the misc workqueue during device shutdown to ensure that all pending work items are completed before the driver is unloaded.

Note: This approach may slightly increase shutdown latency if the workqueue contains jobs from other devices, but it ensures correctness and stability.(CVE-2025-39721)

In the Linux kernel, the following vulnerability has been resolved:

NFS: Fix filehandle bounds checking in nfs_fh_to_dentry()

The function needs to check the minimal filehandle length before it can access the embedded filehandle.(CVE-2025-39730)

In the Linux kernel, the following vulnerability has been resolved:

mm/kmemleak: avoid soft lockup in __kmemleak_do_cleanup()

A soft lockup warning was observed on a relative small system x86-64 system with 16 GB of memory when running a debug kernel with kmemleak enabled.

watchdog: BUG: soft lockup - CPU#8 stuck for 33s! [kworker/8:1:134]

The test system was running a workload with hot unplug happening in parallel. Then kemleak decided to disable itself due to its inability to allocate more kmemleak objects. The debug kernel has its CONFIG_DEBUG_KMEMLEAK_MEM_POOL_SIZE set to 40,000.

The soft lockup happened in kmemleak_do_cleanup() when the existing kmemleak objects were being removed and deleted one-by-one in a loop via a workqueue. In this particular case, there are at least 40,000 objects that need to be processed and given the slowness of a debug kernel and the fact that a raw_spinlock has to be acquired and released in __delete_object(), it could take a while to properly handle all these objects.

As kmemleak has been disabled in this case, the object removal and deletion process can be further optimized as locking isn't really needed. However, it is probably not worth the effort to optimize for such an edge case that should rarely happen. So the simple solution is to call cond_resched() at periodic interval in the iteration loop to avoid soft lockup.(CVE-2025-39737)

In the Linux kernel, the following vulnerability has been resolved:

rcu: Protect ->defer_qs_iw_pending from data race

On kernels built with CONFIG_IRQ_WORK=y, when rcu_read_unlock() is invoked within an interrupts-disabled region of code [1], it will invoke rcu_read_unlock_special(), which uses an irq-work handler to force the system to notice when the RCU read-side critical section actually ends. That end won't happen until interrupts are enabled at the soonest.

In some kernels, such as those booted with rcutree.use_softirq=y, the irq-work handler is used unconditionally.

The per-CPU rcu_data structure's ->defer_qs_iw_pending field is updated by the irq-work handler and is both read and updated by rcu_read_unlock_special(). This resulted in the following KCSAN splat:

BUG: KCSAN: data-race in rcu_preempt_deferred_qs_handler / rcu_read_unlock_special

read to 0xffff96b95f42d8d8 of 1 bytes by task 90 on cpu 8: rcu_read_unlock_special+0x175/0x260 __rcu_read_unlock+0x92/0xa0 rt_spin_unlock+0x9b/0xc0 __local_bh_enable+0x10d/0x170 __local_bh_enable_ip+0xfb/0x150 rcu_do_batch+0x595/0xc40 rcu_cpu_kthread+0x4e9/0x830 smpboot_thread_fn+0x24d/0x3b0 kthread+0x3bd/0x410 ret_from_fork+0x35/0x40 ret_from_fork_asm+0x1a/0x30

write to 0xffff96b95f42d8d8 of 1 bytes by task 88 on cpu 8: rcu_preempt_deferred_qs_handler+0x1e/0x30 irq_work_single+0xaf/0x160 run_irq_workd+0x91/0xc0 smpboot_thread_fn+0x24d/0x3b0 kthread+0x3bd/0x410 ret_from_fork+0x35/0x40 ret_from_fork_asm+0x1a/0x30

no locks held by irq_work/8/88. irq event stamp: 200272 hardirqs last enabled at (200272): [<ffffffffb0f56121>] finish_task_switch+0x131/0x320 hardirqs last disabled at (200271): [<ffffffffb25c7859>] __schedule+0x129/0xd70 softirqs last enabled at (0): [<ffffffffb0ee093f>] copy_process+0x4df/0x1cc0 softirqs last disabled at (0): [<0000000000000000>] 0x0

The problem is that irq-work handlers run with interrupts enabled, which means that rcu_preempt_deferred_qs_handler() could be interrupted, and that interrupt handler might contain an RCU read-side critical section, which might invoke rcu_read_unlock_special(). In the strict KCSAN mode of operation used by RCU, this constitutes a data race on the ->defer_qs_iw_pending field.

This commit therefore disables interrupts across the portion of the rcu_preempt_deferred_qs_handler() that updates the ->defer_qs_iw_pending field. This suffices because this handler is not a fast path.(CVE-2025-39749)

In the Linux kernel, the following vulnerability has been resolved:

NFS: Fix the setting of capabilities when automounting a new filesystem

Capabilities cannot be inherited when we cross into a new filesystem. They need to be reset to the minimal defaults, and then probed for again.(CVE-2025-39798)

In the Linux kernel, the following vulnerability has been resolved:

KVM: x86: use array_index_nospec with indices that come from guest

min and dest_id are guest-controlled indices. Using array_index_nospec() after the bounds checks clamps these values to mitigate speculative execution side-channels.(CVE-2025-39823)

In the Linux kernel, the following vulnerability has been resolved:

atm: atmtcp: Prevent arbitrary write in atmtcp_recv_control().

syzbot reported the splat below. [0]

When atmtcp_v_open() or atmtcp_v_close() is called via connect() or close(), atmtcp_send_control() is called to send an in-kernel special message.

The message has ATMTCP_HDR_MAGIC in atmtcp_control.hdr.length. Also, a pointer of struct atm_vcc is set to atmtcp_control.vcc.

The notable thing is struct atmtcp_control is uAPI but has a space for an in-kernel pointer.

struct atmtcp_control { struct atmtcp_hdr hdr; / must be first / ... atm_kptr_t vcc; / both directions / ... } __ATM_API_ALIGN;

typedef struct { unsigned char _[8]; } __ATM_API_ALIGN atm_kptr_t;

The special message is processed in atmtcp_recv_control() called from atmtcp_c_send().

atmtcp_c_send() is vcc->dev->ops->send() and called from 2 paths:

.ndo_start_xmit() (vcc->send() == atm_send_aal0())
vcc_sendmsg()

The problem is sendmsg() does not validate the message length and userspace can abuse atmtcp_recv_control() to overwrite any kptr by atmtcp_control.

Let's add a new ->pre_send() hook to validate messages from sendmsg().

[0]: Oops: general protection fault, probably for non-canonical address 0xdffffc00200000ab: 0000 [#1] SMP KASAN PTI KASAN: probably user-memory-access in range [0x0000000100000558-0x000000010000055f] CPU: 0 UID: 0 PID: 5865 Comm: syz-executor331 Not tainted 6.17.0-rc1-syzkaller-00215-gbab3ce404553 #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/12/2025 RIP: 0010:atmtcp_recv_control drivers/atm/atmtcp.c:93 [inline] RIP: 0010:atmtcp_c_send+0x1da/0x950 drivers/atm/atmtcp.c:297 Code: 4d 8d 75 1a 4c 89 f0 48 c1 e8 03 42 0f b6 04 20 84 c0 0f 85 15 06 00 00 41 0f b7 1e 4d 8d b7 60 05 00 00 4c 89 f0 48 c1 e8 03 <42> 0f b6 04 20 84 c0 0f 85 13 06 00 00 66 41 89 1e 4d 8d 75 1c 4c RSP: 0018:ffffc90003f5f810 EFLAGS: 00010203 RAX: 00000000200000ab RBX: 0000000000000000 RCX: 0000000000000000 RDX: ffff88802a510000 RSI: 00000000ffffffff RDI: ffff888030a6068c RBP: ffff88802699fb40 R08: ffff888030a606eb R09: 1ffff1100614c0dd R10: dffffc0000000000 R11: ffffffff8718fc40 R12: dffffc0000000000 R13: ffff888030a60680 R14: 000000010000055f R15: 00000000ffffffff FS: 00007f8d7e9236c0(0000) GS:ffff888125c1c000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000000045ad50 CR3: 0000000075bde000 CR4: 00000000003526f0 Call Trace: <TASK> vcc_sendmsg+0xa10/0xc60 net/atm/common.c:645 sock_sendmsg_nosec net/socket.c:714 [inline] __sock_sendmsg+0x219/0x270 net/socket.c:729 _syssendmsg+0x505/0x830 net/socket.c:2614 _sys_sendmsg+0x21f/0x2a0 net/socket.c:2668 __sys_sendmsg net/socket.c:2700 [inline] __do_sys_sendmsg net/socket.c:2705 [inline] __se_sys_sendmsg net/socket.c:2703 [inline] __x64_sys_sendmsg+0x19b/0x260 net/socket.c:2703 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f8d7e96a4a9 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 51 18 00 00 90 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 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f8d7e923198 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007f8d7e9f4308 RCX: 00007f8d7e96a4a9 RDX: 0000000000000000 RSI: 0000200000000240 RDI: 0000000000000005 RBP: 00007f8d7e9f4300 R08: 65732f636f72702f R09: 65732f636f72702f R10: 65732f636f72702f R11: 0000000000000246 R12: 00007f8d7e9c10ac R13: 00007f8d7e9231a0 R14: 0000200000000200 R15: 0000200000000250 </TASK> Modules linked in:(CVE-2025-39828)

In the Linux kernel, the following vulnerability has been resolved:

cifs: prevent NULL pointer dereference in UTF16 conversion

There can be a NULL pointer dereference bug here. NULL is passed to __cifs_sfu_make_node without checks, which passes it unchecked to cifs_strndup_to_utf16, which in turn passes it to cifs_local_to_utf16_bytes where '*from' is dereferenced, causing a crash.

This patch adds a check for NULL 'src' in cifs_strndup_to_utf16 and returns NULL early to prevent dereferencing NULL pointer.

Found by Linux Verification Center (linuxtesting.org) with SVACE(CVE-2025-39838)

In the Linux kernel, the following vulnerability has been resolved:

batman-adv: fix OOB read/write in network-coding decode

batadv_nc_skb_decode_packet() trusts coded_len and checks only against skb->len. XOR starts at sizeof(struct batadv_unicast_packet), reducing payload headroom, and the source skb length is not verified, allowing an out-of-bounds read and a small out-of-bounds write.

Validate that coded_len fits within the payload area of both destination and source sk_buffs before XORing.(CVE-2025-39839)

In the Linux kernel, the following vulnerability has been resolved:

ceph: fix race condition validating r_parent before applying state

Add validation to ensure the cached parent directory inode matches the directory info in MDS replies. This prevents client-side race conditions where concurrent operations (e.g. rename) cause r_parent to become stale between request initiation and reply processing, which could lead to applying state changes to incorrect directory inodes.

[ idryomov: folded a kerneldoc fixup and a follow-up fix from Alex to move CEPH_CAP_PIN reference when r_parent is updated:

When the parent directory lock is not held, req->r_parent can become stale and is updated to point to the correct inode. However, the associated CEPH_CAP_PIN reference was not being adjusted. The CEPH_CAP_PIN is a reference on an inode that is tracked for accounting purposes. Moving this pin is important to keep the accounting balanced. When the pin was not moved from the old parent to the new one, it created two problems: The reference on the old, stale parent was never released, causing a reference leak. A reference for the new parent was never acquired, creating the risk of a reference underflow later in ceph_mdsc_release_request(). This patch corrects the logic by releasing the pin from the old parent and acquiring it for the new parent when r_parent is switched. This ensures reference accounting stays balanced. ](CVE-2025-39927)

In the Linux kernel, the following vulnerability has been resolved:

smb: client: fix smbdirect_recv_io leak in smbd_negotiate() error path

During tests of another unrelated patch I was able to trigger this error: Objects remaining on __kmem_cache_shutdown()(CVE-2025-39929)

In the Linux kernel, the following vulnerability has been resolved:

um: virtio_uml: Fix use-after-free after put_device in probe

When register_virtio_device() fails in virtio_uml_probe(), the code sets vu_dev->registered = 1 even though the device was not successfully registered. This can lead to use-after-free or other issues.(CVE-2025-39951)

In the Linux kernel, the following vulnerability has been resolved:

net/sched: sch_qfq: Fix null-deref in agg_dequeue

To prevent a potential crash in agg_dequeue (net/sched/sch_qfq.c) when cl->qdisc->ops->peek(cl->qdisc) returns NULL, we check the return value before using it, similar to the existing approach in sch_hfsc.c.

To avoid code duplication, the following changes are made:

Changed qdisc_warn_nonwc(include/net/pkt_sched.h) into a static inline function.
Moved qdisc_peek_len from net/sched/sch_hfsc.c to include/net/pkt_sched.h so that sch_qfq can reuse it.
Applied qdisc_peek_len in agg_dequeue to avoid crashing.(CVE-2025-40083)

In the Linux kernel, the following vulnerability has been resolved:

NFSD: Define a proc_layoutcommit for the FlexFiles layout type

Avoid a crash if a pNFS client should happen to send a LAYOUTCOMMIT operation on a FlexFiles layout.(CVE-2025-40087)

In the Linux kernel, the following vulnerability has been resolved:

cifs: parse_dfs_referrals: prevent oob on malformed input

Malicious SMB server can send invalid reply to FSCTL_DFS_GET_REFERRALS

reply smaller than sizeof(struct get_dfs_referral_rsp)
reply with number of referrals smaller than NumberOfReferrals in the header

Processing of such replies will cause oob.

Return -EINVAL error on such replies to prevent oob-s.(CVE-2025-40099)

In the Linux kernel, the following vulnerability has been resolved:

smb: client: Fix refcount leak for cifs_sb_tlink

Fix three refcount inconsistency issues related to cifs_sb_tlink.

Comments for cifs_sb_tlink state that cifs_put_tlink() needs to be called after successful calls to cifs_sb_tlink(). Three calls fail to update refcount accordingly, leading to possible resource leaks.(CVE-2025-40103)

In the Linux kernel, the following vulnerability has been resolved:

vfs: Don't leak disconnected dentries on umount

When user calls open_by_handle_at() on some inode that is not cached, we will create disconnected dentry for it. If such dentry is a directory, exportfs_decode_fh_raw() will then try to connect this dentry to the dentry tree through reconnect_path(). It may happen for various reasons (such as corrupted fs or race with rename) that the call to lookup_one_unlocked() in reconnect_one() will fail to find the dentry we are trying to reconnect and instead create a new dentry under the parent. Now this dentry will not be marked as disconnected although the parent still may well be disconnected (at least in case this inconsistency happened because the fs is corrupted and .. doesn't point to the real parent directory). This creates inconsistency in disconnected flags but AFAICS it was mostly harmless. At least until commit f1ee616214cb ("VFS: don't keep disconnected dentries on d_anon") which removed adding of most disconnected dentries to sb->s_anon list. Thus after this commit cleanup of disconnected dentries implicitely relies on the fact that dput() will immediately reclaim such dentries. However when some leaf dentry isn't marked as disconnected, as in the scenario described above, the reclaim doesn't happen and the dentries are "leaked". Memory reclaim can eventually reclaim them but otherwise they stay in memory and if umount comes first, we hit infamous "Busy inodes after unmount" bug. Make sure all dentries created under a disconnected parent are marked as disconnected as well.(CVE-2025-40105)

In the Linux kernel, the following vulnerability has been resolved:

drm/vmwgfx: Fix Use-after-free in validation

Nodes stored in the validation duplicates hashtable come from an arena allocator that is cleared at the end of vmw_execbuf_process. All nodes are expected to be cleared in vmw_validation_drop_ht but this node escaped because its resource was destroyed prematurely.(CVE-2025-40111)

In the Linux kernel, the following vulnerability has been resolved:

net/mlx5: Clean up only new IRQ glue on request_irq() failure

The mlx5_irq_alloc() function can inadvertently free the entire rmap and end up in a crash[1] when the other threads tries to access this, when request_irq() fails due to exhausted IRQ vectors. This commit modifies the cleanup to remove only the specific IRQ mapping that was just added.

This prevents removal of other valid mappings and ensures precise cleanup of the failed IRQ allocation's associated glue object.

Note: This error is observed when both fwctl and rds configs are enabled.

[1] mlx5_core 0000:05:00.0: Successfully registered panic handler for port 1 mlx5_core 0000:05:00.0: mlx5_irq_alloc:293:(pid 66740): Failed to request irq. err = -28 infiniband mlx5_0: mlx5_ib_test_wc:290:(pid 66740): Error -28 while trying to test write-combining support mlx5_core 0000:05:00.0: Successfully unregistered panic handler for port 1 mlx5_core 0000:06:00.0: Successfully registered panic handler for port 1 mlx5_core 0000:06:00.0: mlx5_irq_alloc:293:(pid 66740): Failed to request irq. err = -28 infiniband mlx5_0: mlx5_ib_test_wc:290:(pid 66740): Error -28 while trying to test write-combining support mlx5_core 0000:06:00.0: Successfully unregistered panic handler for port 1 mlx5_core 0000:03:00.0: mlx5_irq_alloc:293:(pid 28895): Failed to request irq. err = -28 mlx5_core 0000:05:00.0: mlx5_irq_alloc:293:(pid 28895): Failed to request irq. err = -28 general protection fault, probably for non-canonical address 0xe277a58fde16f291: 0000 [#1] SMP NOPTI

RIP: 0010:free_irq_cpu_rmap+0x23/0x7d Call Trace: <TASK> ? show_trace_log_lvl+0x1d6/0x2f9 ? show_trace_log_lvl+0x1d6/0x2f9 ? mlx5_irq_alloc.cold+0x5d/0xf3 [mlx5_core] ? __die_body.cold+0x8/0xa ? die_addr+0x39/0x53 ? exc_general_protection+0x1c4/0x3e9 ? dev_vprintk_emit+0x5f/0x90 ? asm_exc_general_protection+0x22/0x27 ? free_irq_cpu_rmap+0x23/0x7d mlx5_irq_alloc.cold+0x5d/0xf3 [mlx5_core] irq_pool_request_vector+0x7d/0x90 [mlx5_core] mlx5_irq_request+0x2e/0xe0 [mlx5_core] mlx5_irq_request_vector+0xad/0xf7 [mlx5_core] comp_irq_request_pci+0x64/0xf0 [mlx5_core] create_comp_eq+0x71/0x385 [mlx5_core] ? mlx5e_open_xdpsq+0x11c/0x230 [mlx5_core] mlx5_comp_eqn_get+0x72/0x90 [mlx5_core] ? xas_load+0x8/0x91 mlx5_comp_irqn_get+0x40/0x90 [mlx5_core] mlx5e_open_channel+0x7d/0x3c7 [mlx5_core] mlx5e_open_channels+0xad/0x250 [mlx5_core] mlx5e_open_locked+0x3e/0x110 [mlx5_core] mlx5e_open+0x23/0x70 [mlx5_core] __dev_open+0xf1/0x1a5 __dev_change_flags+0x1e1/0x249 dev_change_flags+0x21/0x5c do_setlink+0x28b/0xcc4 ? __nla_parse+0x22/0x3d ? inet6_validate_link_af+0x6b/0x108 ? cpumask_next+0x1f/0x35 ? __snmp6_fill_stats64.constprop.0+0x66/0x107 ? __nla_validate_parse+0x48/0x1e6 __rtnl_newlink+0x5ff/0xa57 ? kmem_cache_alloc_trace+0x164/0x2ce rtnl_newlink+0x44/0x6e rtnetlink_rcv_msg+0x2bb/0x362 ? __netlink_sendskb+0x4c/0x6c ? netlink_unicast+0x28f/0x2ce ? rtnl_calcit.isra.0+0x150/0x146 netlink_rcv_skb+0x5f/0x112 netlink_unicast+0x213/0x2ce netlink_sendmsg+0x24f/0x4d9 __sock_sendmsg+0x65/0x6a _syssendmsg+0x28f/0x2c9 ? import_iovec+0x17/0x2b _sys_sendmsg+0x97/0xe0 __sys_sendmsg+0x81/0xd8 do_syscall_64+0x35/0x87 entry_SYSCALL_64_after_hwframe+0x6e/0x0 RIP: 0033:0x7fc328603727 Code: c3 66 90 41 54 41 89 d4 55 48 89 f5 53 89 fb 48 83 ec 10 e8 0b ed ff ff 44 89 e2 48 89 ee 89 df 41 89 c0 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 35 44 89 c7 48 89 44 24 08 e8 44 ed ff ff 48 RSP: 002b:00007ffe8eb3f1a0 EFLAGS: 00000293 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 000000000000000d RCX: 00007fc328603727 RDX: 0000000000000000 RSI: 00007ffe8eb3f1f0 RDI: 000000000000000d RBP: 00007ffe8eb3f1f0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000293 R12: 0000000000000000 R13: 00000000000 ---truncated---(CVE-2025-40250)

In the Linux kernel, the following vulnerability has been resolved:

net: qlogic/qede: fix potential out-of-bounds read in qede_tpa_cont() and qede_tpa_end()

The loops in 'qede_tpa_cont()' and 'qede_tpa_end()', iterate over 'cqe->len_list[]' using only a zero-length terminator as the stopping condition. If the terminator was missing or malformed, the loop could run past the end of the fixed-size array.

Add an explicit bound check using ARRAY_SIZE() in both loops to prevent a potential out-of-bounds access.

Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2025-40252)

In the Linux kernel, the following vulnerability has been resolved:

scsi: sg: Do not sleep in atomic context

sg_finish_rem_req() calls blk_rq_unmap_user(). The latter function may sleep. Hence, call sg_finish_rem_req() with interrupts enabled instead of disabled.(CVE-2025-40259)

In the Linux kernel, the following vulnerability has been resolved:

nvme: nvme-fc: Ensure ->ioerr_work is cancelled in nvme_fc_delete_ctrl()

nvme_fc_delete_assocation() waits for pending I/O to complete before returning, and an error can cause ->ioerr_work to be queued after cancel_work_sync() had been called. Move the call to cancel_work_sync() to be after nvme_fc_delete_association() to ensure ->ioerr_work is not running when the nvme_fc_ctrl object is freed. Otherwise the following can occur:

[ 1135.911754] list_del corruption, ff2d24c8093f31f8->next is NULL [ 1135.917705] ------------[ cut here ]------------ [ 1135.922336] kernel BUG at lib/list_debug.c:52! [ 1135.926784] Oops: invalid opcode: 0000 [#1] SMP NOPTI [ 1135.931851] CPU: 48 UID: 0 PID: 726 Comm: kworker/u449:23 Kdump: loaded Not tainted 6.12.0 #1 PREEMPT(voluntary) [ 1135.943490] Hardware name: Dell Inc. PowerEdge R660/0HGTK9, BIOS 2.5.4 01/16/2025 [ 1135.950969] Workqueue: 0x0 (nvme-wq) [ 1135.954673] RIP: 0010:__list_del_entry_valid_or_report.cold+0xf/0x6f [ 1135.961041] Code: c7 c7 98 68 72 94 e8 26 45 fe ff 0f 0b 48 c7 c7 70 68 72 94 e8 18 45 fe ff 0f 0b 48 89 fe 48 c7 c7 80 69 72 94 e8 07 45 fe ff <0f> 0b 48 89 d1 48 c7 c7 a0 6a 72 94 48 89 c2 e8 f3 44 fe ff 0f 0b [ 1135.979788] RSP: 0018:ff579b19482d3e50 EFLAGS: 00010046 [ 1135.985015] RAX: 0000000000000033 RBX: ff2d24c8093f31f0 RCX: 0000000000000000 [ 1135.992148] RDX: 0000000000000000 RSI: ff2d24d6bfa1d0c0 RDI: ff2d24d6bfa1d0c0 [ 1135.999278] RBP: ff2d24c8093f31f8 R08: 0000000000000000 R09: ffffffff951e2b08 [ 1136.006413] R10: ffffffff95122ac8 R11: 0000000000000003 R12: ff2d24c78697c100 [ 1136.013546] R13: fffffffffffffff8 R14: 0000000000000000 R15: ff2d24c78697c0c0 [ 1136.020677] FS: 0000000000000000(0000) GS:ff2d24d6bfa00000(0000) knlGS:0000000000000000 [ 1136.028765] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1136.034510] CR2: 00007fd207f90b80 CR3: 000000163ea22003 CR4: 0000000000f73ef0 [ 1136.041641] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 1136.048776] DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400 [ 1136.055910] PKRU: 55555554 [ 1136.058623] Call Trace: [ 1136.061074] <TASK> [ 1136.063179] ? show_trace_log_lvl+0x1b0/0x2f0 [ 1136.067540] ? show_trace_log_lvl+0x1b0/0x2f0 [ 1136.071898] ? move_linked_works+0x4a/0xa0 [ 1136.075998] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.081744] ? __die_body.cold+0x8/0x12 [ 1136.085584] ? die+0x2e/0x50 [ 1136.088469] ? do_trap+0xca/0x110 [ 1136.091789] ? do_error_trap+0x65/0x80 [ 1136.095543] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.101289] ? exc_invalid_op+0x50/0x70 [ 1136.105127] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.110874] ? asm_exc_invalid_op+0x1a/0x20 [ 1136.115059] ? __list_del_entry_valid_or_report.cold+0xf/0x6f [ 1136.120806] move_linked_works+0x4a/0xa0 [ 1136.124733] worker_thread+0x216/0x3a0 [ 1136.128485] ? __pfx_worker_thread+0x10/0x10 [ 1136.132758] kthread+0xfa/0x240 [ 1136.135904] ? __pfx_kthread+0x10/0x10 [ 1136.139657] ret_from_fork+0x31/0x50 [ 1136.143236] ? __pfx_kthread+0x10/0x10 [ 1136.146988] ret_from_fork_asm+0x1a/0x30 [ 1136.150915] </TASK>(CVE-2025-40261)

In the Linux kernel, the following vulnerability has been resolved:

be2net: pass wrb_params in case of OS2BMC

be_insert_vlan_in_pkt() is called with the wrb_params argument being NULL at be_send_pkt_to_bmc() call site. This may lead to dereferencing a NULL pointer when processing a workaround for specific packet, as commit bc0c3405abbb ("be2net: fix a Tx stall bug caused by a specific ipv6 packet") states.

The correct way would be to pass the wrb_params from be_xmit().(CVE-2025-40264)

In the Linux kernel, the following vulnerability has been resolved:

cifs: client: fix memory leak in smb3_fs_context_parse_param

The user calls fsconfig twice, but when the program exits, free() only frees ctx->source for the second fsconfig, not the first. Regarding fc->source, there is no code in the fs context related to its memory reclamation.

To fix this memory leak, release the source memory corresponding to ctx or fc before each parsing.

syzbot reported: BUG: memory leak unreferenced object 0xffff888128afa360 (size 96): backtrace (crc 79c9c7ba): kstrdup+0x3c/0x80 mm/util.c:84 smb3_fs_context_parse_param+0x229b/0x36c0 fs/smb/client/fs_context.c:1444

BUG: memory leak unreferenced object 0xffff888112c7d900 (size 96): backtrace (crc 79c9c7ba): smb3_fs_context_fullpath+0x70/0x1b0 fs/smb/client/fs_context.c:629 smb3_fs_context_parse_param+0x2266/0x36c0 fs/smb/client/fs_context.c:1438(CVE-2025-40268)

In the Linux kernel, the following vulnerability has been resolved:

NFSD: free copynotify stateid in nfs4_free_ol_stateid()

Typically copynotify stateid is freed either when parent's stateid is being close/freed or in nfsd4_laundromat if the stateid hasn't been used in a lease period.

However, in case when the server got an OPEN (which created a parent stateid), followed by a COPY_NOTIFY using that stateid, followed by a client reboot. New client instance while doing CREATE_SESSION would force expire previous state of this client. It leads to the open state being freed thru release_openowner-> nfs4_free_ol_stateid() and it finds that it still has copynotify stateid associated with it. We currently print a warning and is triggerred

WARNING: CPU: 1 PID: 8858 at fs/nfsd/nfs4state.c:1550 nfs4_free_ol_stateid+0xb0/0x100 [nfsd]

This patch, instead, frees the associated copynotify stateid here.

If the parent stateid is freed (without freeing the copynotify stateids associated with it), it leads to the list corruption when laundromat ends up freeing the copynotify state later.

[ 1626.839430] Internal error: Oops - BUG: 00000000f2000800 [#1] SMP [ 1626.842828] Modules linked in: nfnetlink_queue nfnetlink_log bluetooth cfg80211 rpcrdma rdma_cm iw_cm ib_cm ib_core nfsd nfs_acl lockd grace nfs_localio ext4 crc16 mbcache jbd2 overlay uinput snd_seq_dummy snd_hrtimer qrtr rfkill vfat fat uvcvideo snd_hda_codec_generic videobuf2_vmalloc videobuf2_memops snd_hda_intel uvc snd_intel_dspcfg videobuf2_v4l2 videobuf2_common snd_hda_codec snd_hda_core videodev snd_hwdep snd_seq mc snd_seq_device snd_pcm snd_timer snd soundcore sg loop auth_rpcgss vsock_loopback vmw_vsock_virtio_transport_common vmw_vsock_vmci_transport vmw_vmci vsock xfs 8021q garp stp llc mrp nvme ghash_ce e1000e nvme_core sr_mod nvme_keyring nvme_auth cdrom vmwgfx drm_ttm_helper ttm sunrpc dm_mirror dm_region_hash dm_log iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi fuse dm_multipath dm_mod nfnetlink [ 1626.855594] CPU: 2 UID: 0 PID: 199 Comm: kworker/u24:33 Kdump: loaded Tainted: G B W 6.17.0-rc7+ #22 PREEMPT(voluntary) [ 1626.857075] Tainted: [B]=BAD_PAGE, [W]=WARN [ 1626.857573] Hardware name: VMware, Inc. VMware20,1/VBSA, BIOS VMW201.00V.24006586.BA64.2406042154 06/04/2024 [ 1626.858724] Workqueue: nfsd4 laundromat_main [nfsd] [ 1626.859304] pstate: 61400005 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) [ 1626.860010] pc : __list_del_entry_valid_or_report+0x148/0x200 [ 1626.860601] lr : __list_del_entry_valid_or_report+0x148/0x200 [ 1626.861182] sp : ffff8000881d7a40 [ 1626.861521] x29: ffff8000881d7a40 x28: 0000000000000018 x27: ffff0000c2a98200 [ 1626.862260] x26: 0000000000000600 x25: 0000000000000000 x24: ffff8000881d7b20 [ 1626.862986] x23: ffff0000c2a981e8 x22: 1fffe00012410e7d x21: ffff0000920873e8 [ 1626.863701] x20: ffff0000920873e8 x19: ffff000086f22998 x18: 0000000000000000 [ 1626.864421] x17: 20747562202c3839 x16: 3932326636383030 x15: 3030666666662065 [ 1626.865092] x14: 6220646c756f6873 x13: 0000000000000001 x12: ffff60004fd9e4a3 [ 1626.865713] x11: 1fffe0004fd9e4a2 x10: ffff60004fd9e4a2 x9 : dfff800000000000 [ 1626.866320] x8 : 00009fffb0261b5e x7 : ffff00027ecf2513 x6 : 0000000000000001 [ 1626.866938] x5 : ffff00027ecf2510 x4 : ffff60004fd9e4a3 x3 : 0000000000000000 [ 1626.867553] x2 : 0000000000000000 x1 : ffff000096069640 x0 : 000000000000006d [ 1626.868167] Call trace: [ 1626.868382] __list_del_entry_valid_or_report+0x148/0x200 (P) [ 1626.868876] _free_cpntf_state_locked+0xd0/0x268 [nfsd] [ 1626.869368] nfs4_laundromat+0x6f8/0x1058 [nfsd] [ 1626.869813] laundromat_main+0x24/0x60 [nfsd] [ 1626.870231] process_one_work+0x584/0x1050 [ 1626.870595] worker_thread+0x4c4/0xc60 [ 1626.870893] kthread+0x2f8/0x398 [ 1626.871146] ret_from_fork+0x10/0x20 [ 1626.871422] Code: aa1303e1 aa1403e3 910e8000 97bc55d7 (d4210000) [ 1626.871892] SMP: stopping secondary CPUs(CVE-2025-40273)

In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: MGMT: cancel mesh send timer when hdev removed

mesh_send_done timer is not canceled when hdev is removed, which causes crash if the timer triggers after hdev is gone.

Cancel the timer when MGMT removes the hdev, like other MGMT timers.

Should fix the BUG: sporadically seen by BlueZ test bot (in "Mesh - Send cancel - 1" test).

Log:

BUG: KASAN: slab-use-after-free in run_timer_softirq+0x76b/0x7d0 ... Freed by task 36: kasan_save_stack+0x24/0x50 kasan_save_track+0x14/0x30 __kasan_save_free_info+0x3a/0x60 __kasan_slab_free+0x43/0x70 kfree+0x103/0x500 device_release+0x9a/0x210 kobject_put+0x100/0x1e0 vhci_release+0x18b/0x240 ------(CVE-2025-40284)

In the Linux kernel, the following vulnerability has been resolved:

fbdev: Add bounds checking in bit_putcs to fix vmalloc-out-of-bounds

Add bounds checking to prevent writes past framebuffer boundaries when rendering text near screen edges. Return early if the Y position is off-screen and clip image height to screen boundary. Break from the rendering loop if the X position is off-screen. When clipping image width to fit the screen, update the character count to match the clipped width to prevent buffer size mismatches.

Without the character count update, bit_putcs_aligned and bit_putcs_unaligned receive mismatched parameters where the buffer is allocated for the clipped width but cnt reflects the original larger count, causing out-of-bounds writes.(CVE-2025-40304)

In the Linux kernel, the following vulnerability has been resolved:

accel/habanalabs: support mapping cb with vmalloc-backed coherent memory

When IOMMU is enabled, dma_alloc_coherent() with GFP_USER may return addresses from the vmalloc range. If such an address is mapped without VM_MIXEDMAP, vm_insert_page() will trigger a BUG_ON due to the VM_PFNMAP restriction.

Fix this by checking for vmalloc addresses and setting VM_MIXEDMAP in the VMA before mapping. This ensures safe mapping and avoids kernel crashes. The memory is still driver-allocated and cannot be accessed directly by userspace.(CVE-2025-40311)

In the Linux kernel, the following vulnerability has been resolved:

usb: cdns3: gadget: Use-after-free during failed initialization and exit of cdnsp gadget

In the __cdnsp_gadget_init() and cdnsp_gadget_exit() functions, the gadget structure (pdev->gadget) was freed before its endpoints. The endpoints are linked via the ep_list in the gadget structure. Freeing the gadget first leaves dangling pointers in the endpoint list. When the endpoints are subsequently freed, this results in a use-after-free.

Fix: By separating the usb_del_gadget_udc() operation into distinct "del" and "put" steps, cdnsp_gadget_free_endpoints() can be executed prior to the final release of the gadget structure with usb_put_gadget().

A patch similar to bb9c74a5bd14("usb: dwc3: gadget: Free gadget structure only after freeing endpoints").(CVE-2025-40314)

In the Linux kernel, the following vulnerability has been resolved:

bpf: Sync pending IRQ work before freeing ring buffer

Fix a race where irq_work can be queued in bpf_ringbuf_commit() but the ring buffer is freed before the work executes. In the syzbot reproducer, a BPF program attached to sched_switch triggers bpf_ringbuf_commit(), queuing an irq_work. If the ring buffer is freed before this work executes, the irq_work thread may accesses freed memory. Calling irq_work_sync(&rb->work) ensures that all pending irq_work complete before freeing the buffer.(CVE-2025-40319)

In the Linux kernel, the following vulnerability has been resolved:

smb: client: fix potential cfid UAF in smb2_query_info_compound

When smb2_query_info_compound() retries, a previously allocated cfid may have been freed in the first attempt. Because cfid wasn't reset on replay, later cleanup could act on a stale pointer, leading to a potential use-after-free.

Reinitialize cfid to NULL under the replay label.

Example trace (trimmed):

refcount_t: underflow; use-after-free. WARNING: CPU: 1 PID: 11224 at ../lib/refcount.c:28 refcount_warn_saturate+0x9c/0x110 [...] RIP: 0010:refcount_warn_saturate+0x9c/0x110 [...] Call Trace: <TASK> smb2_query_info_compound+0x29c/0x5c0 [cifs f90b72658819bd21c94769b6a652029a07a7172f] ? step_into+0x10d/0x690 ? __legitimize_path+0x28/0x60 smb2_queryfs+0x6a/0xf0 [cifs f90b72658819bd21c94769b6a652029a07a7172f] smb311_queryfs+0x12d/0x140 [cifs f90b72658819bd21c94769b6a652029a07a7172f] ? kmem_cache_alloc+0x18a/0x340 ? getname_flags+0x46/0x1e0 cifs_statfs+0x9f/0x2b0 [cifs f90b72658819bd21c94769b6a652029a07a7172f] statfs_by_dentry+0x67/0x90 vfs_statfs+0x16/0xd0 user_statfs+0x54/0xa0 __do_sys_statfs+0x20/0x50 do_syscall_64+0x58/0x80(CVE-2025-40320)

In the Linux kernel, the following vulnerability has been resolved:

fbdev: bitblit: bound-check glyph index in bit_putcs*

bit_putcs_aligned()/unaligned() derived the glyph pointer from the character value masked by 0xff/0x1ff, which may exceed the actual font's glyph count and read past the end of the built-in font array. Clamp the index to the actual glyph count before computing the address.

This fixes a global out-of-bounds read reported by syzbot.(CVE-2025-40322)

In the Linux kernel, the following vulnerability has been resolved:

NFSD: Fix crash in nfsd4_read_release()

When tracing is enabled, the trace_nfsd_read_done trace point crashes during the pynfs read.testNoFh test.(CVE-2025-40324)

In the Linux kernel, the following vulnerability has been resolved:

smb: client: fix potential UAF in smb2_close_cached_fid()

find_or_create_cached_dir() could grab a new reference after kref_put() had seen the refcount drop to zero but before cfid_list_lock is acquired in smb2_close_cached_fid(), leading to use-after-free.

Switch to kref_put_lock() so cfid_release() is called with cfid_list_lock held, closing that gap.(CVE-2025-40328)

In the Linux kernel, the following vulnerability has been resolved:

usb: storage: sddr55: Reject out-of-bound new_pba

Discovered by Atuin - Automated Vulnerability Discovery Engine.

new_pba comes from the status packet returned after each write. A bogus device could report values beyond the block count derived from info->capacity, letting the driver walk off the end of pba_to_lba[] and corrupt heap memory.

Reject PBAs that exceed the computed block count and fail the transfer so we avoid touching out-of-range mapping entries.(CVE-2025-40345)

In the Linux kernel, the following vulnerability has been resolved:

net/mlx5e: RX, Fix generating skb from non-linear xdp_buff for striding RQ

XDP programs can change the layout of an xdp_buff through bpf_xdp_adjust_tail() and bpf_xdp_adjust_head(). Therefore, the driver cannot assume the size of the linear data area nor fragments. Fix the bug in mlx5 by generating skb according to xdp_buff after XDP programs run.

Currently, when handling multi-buf XDP, the mlx5 driver assumes the layout of an xdp_buff to be unchanged. That is, the linear data area continues to be empty and fragments remain the same. This may cause the driver to generate erroneous skb or triggering a kernel warning. When an XDP program added linear data through bpf_xdp_adjust_head(), the linear data will be ignored as mlx5e_build_linear_skb() builds an skb without linear data and then pull data from fragments to fill the linear data area. When an XDP program has shrunk the non-linear data through bpf_xdp_adjust_tail(), the delta passed to __pskb_pull_tail() may exceed the actual nonlinear data size and trigger the BUG_ON in it.

To fix the issue, first record the original number of fragments. If the number of fragments changes after the XDP program runs, rewind the end fragment pointer by the difference and recalculate the truesize. Then, build the skb with the linear data area matching the xdp_buff. Finally, only pull data in if there is non-linear data and fill the linear part up to 256 bytes.(CVE-2025-40350)

In the Linux kernel, the following vulnerability has been resolved:

drm/sysfb: Do not dereference NULL pointer in plane reset

The plane state in __drm_gem_reset_shadow_plane() can be NULL. Do not deref that pointer, but forward NULL to the other plane-reset helpers. Clears plane->state to NULL.

v2: - fix typo in commit description (Javier)(CVE-2025-40360)

In the Linux kernel, the following vulnerability has been resolved:

net: ipv6: fix field-spanning memcpy warning in AH output

Fix field-spanning memcpy warnings in ah6_output() and ah6_output_done() where extension headers are copied to/from IPv6 address fields, triggering fortify-string warnings about writes beyond the 16-byte address fields.

memcpy: detected field-spanning write (size 40) of single field "&top_iph->saddr" at net/ipv6/ah6.c:439 (size 16) WARNING: CPU: 0 PID: 8838 at net/ipv6/ah6.c:439 ah6_output+0xe7e/0x14e0 net/ipv6/ah6.c:439

The warnings are false positives as the extension headers are intentionally placed after the IPv6 header in memory. Fix by properly copying addresses and extension headers separately, and introduce helper functions to avoid code duplication.(CVE-2025-40363)

In the Linux kernel, the following vulnerability has been resolved:

blk-cgroup: fix possible deadlock while configuring policy

Following deadlock can be triggered easily by lockdep:

WARNING: possible circular locking dependency detected 6.17.0-rc3-00124-ga12c2658ced0 #1665 Not tainted

check/1334 is trying to acquire lock: ff1100011d9d0678 (&q->sysfs_lock){+.+.}-{4:4}, at: blk_unregister_queue+0x53/0x180

but task is already holding lock: ff1100011d9d00e0 (&q->q_usage_counter(queue)#3){++++}-{0:0}, at: del_gendisk+0xba/0x110

which lock already depends on the new lock.

the existing dependency chain (in reverse order) is:

-> #2 (&q->q_usage_counter(queue)#3){++++}-{0:0}: blk_queue_enter+0x40b/0x470 blkg_conf_prep+0x7b/0x3c0 tg_set_limit+0x10a/0x3e0 cgroup_file_write+0xc6/0x420 kernfs_fop_write_iter+0x189/0x280 vfs_write+0x256/0x490 ksys_write+0x83/0x190 __x64_sys_write+0x21/0x30 x64_sys_call+0x4608/0x4630 do_syscall_64+0xdb/0x6b0 entry_SYSCALL_64_after_hwframe+0x76/0x7e

-> #1 (&q->rq_qos_mutex){+.+.}-{4:4}: __mutex_lock+0xd8/0xf50 mutex_lock_nested+0x2b/0x40 wbt_init+0x17e/0x280 wbt_enable_default+0xe9/0x140 blk_register_queue+0x1da/0x2e0 __add_disk+0x38c/0x5d0 add_disk_fwnode+0x89/0x250 device_add_disk+0x18/0x30 virtblk_probe+0x13a3/0x1800 virtio_dev_probe+0x389/0x610 really_probe+0x136/0x620 __driver_probe_device+0xb3/0x230 driver_probe_device+0x2f/0xe0 __driver_attach+0x158/0x250 bus_for_each_dev+0xa9/0x130 driver_attach+0x26/0x40 bus_add_driver+0x178/0x3d0 driver_register+0x7d/0x1c0 __register_virtio_driver+0x2c/0x60 virtio_blk_init+0x6f/0xe0 do_one_initcall+0x94/0x540 kernel_init_freeable+0x56a/0x7b0 kernel_init+0x2b/0x270 ret_from_fork+0x268/0x4c0 ret_from_fork_asm+0x1a/0x30

-> #0 (&q->sysfs_lock){+.+.}-{4:4}: __lock_acquire+0x1835/0x2940 lock_acquire+0xf9/0x450 __mutex_lock+0xd8/0xf50 mutex_lock_nested+0x2b/0x40 blk_unregister_queue+0x53/0x180 __del_gendisk+0x226/0x690 del_gendisk+0xba/0x110 sd_remove+0x49/0xb0 [sd_mod] device_remove+0x87/0xb0 device_release_driver_internal+0x11e/0x230 device_release_driver+0x1a/0x30 bus_remove_device+0x14d/0x220 device_del+0x1e1/0x5a0 __scsi_remove_device+0x1ff/0x2f0 scsi_remove_device+0x37/0x60 sdev_store_delete+0x77/0x100 dev_attr_store+0x1f/0x40 sysfs_kf_write+0x65/0x90 kernfs_fop_write_iter+0x189/0x280 vfs_write+0x256/0x490 ksys_write+0x83/0x190 __x64_sys_write+0x21/0x30 x64_sys_call+0x4608/0x4630 do_syscall_64+0xdb/0x6b0 entry_SYSCALL_64_after_hwframe+0x76/0x7e

other info that might help us debug this:

Chain exists of: &q->sysfs_lock --> &q->rq_qos_mutex --> &q->q_usage_counter(queue)#3

Possible unsafe locking scenario:

   CPU0                    CPU1
   ----                    ----

lock(&q->q_usage_counter(queue)#3); lock(&q->rq_qos_mutex); lock(&q->q_usage_counter(queue)#3); lock(&q->sysfs_lock);

Root cause is that queue_usage_counter is grabbed with rq_qos_mutex held in blkg_conf_prep(), while queue should be freezed before rq_qos_mutex from other context.

The blk_queue_enter() from blkg_conf_prep() is used to protect against policy deactivation, which is already protected with blkcg_mutex, hence convert blk_queue_enter() to blkcg_mutex to fix this problem. Meanwhile, consider that blkcg_mutex is held after queue is freezed from policy deactivation, also convert blkg_alloc() to use GFP_NOIO.(CVE-2025-68178)

In the Linux kernel, the following vulnerability has been resolved:

drm/mediatek: Disable AFBC support on Mediatek DRM driver

Commit c410fa9b07c3 ("drm/mediatek: Add AFBC support to Mediatek DRM driver") added AFBC support to Mediatek DRM and enabled the 32x8/split/sparse modifier.

However, this is currently broken on Mediatek MT8188 (Genio 700 EVK platform); tested using upstream Kernel and Mesa (v25.2.1), AFBC is used by default since Mesa v25.0.

Kernel trace reports vblank timeouts constantly, and the render is garbled:

[CRTC:62:crtc-0] vblank wait timed out
WARNING: CPU: 7 PID: 70 at drivers/gpu/drm/drm_atomic_helper.c:1835 drm_atomic_helper_wait_for_vblanks.part.0+0x24c/0x27c
[...]
Hardware name: MediaTek Genio-700 EVK (DT)
Workqueue: events_unbound commit_work
pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : drm_atomic_helper_wait_for_vblanks.part.0+0x24c/0x27c
lr : drm_atomic_helper_wait_for_vblanks.part.0+0x24c/0x27c
sp : ffff80008337bca0
x29: ffff80008337bcd0 x28: 0000000000000061 x27: 0000000000000000
x26: 0000000000000001 x25: 0000000000000000 x24: ffff0000c9dcc000
x23: 0000000000000001 x22: 0000000000000000 x21: ffff0000c66f2f80
x20: ffff0000c0d7d880 x19: 0000000000000000 x18: 000000000000000a
x17: 000000040044ffff x16: 005000f2b5503510 x15: 0000000000000000
x14: 0000000000000000 x13: 74756f2064656d69 x12: 742074696177206b
x11: 0000000000000058 x10: 0000000000000018 x9 : ffff800082396a70
x8 : 0000000000057fa8 x7 : 0000000000000cce x6 : ffff8000823eea70
x5 : ffff0001fef5f408 x4 : ffff80017ccee000 x3 : ffff0000c12cb480
x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0000c12cb480
Call trace:
 drm_atomic_helper_wait_for_vblanks.part.0+0x24c/0x27c (P)
 drm_atomic_helper_commit_tail_rpm+0x64/0x80
 commit_tail+0xa4/0x1a4
 commit_work+0x14/0x20
 process_one_work+0x150/0x290
 worker_thread+0x2d0/0x3ec
 kthread+0x12c/0x210
 ret_from_fork+0x10/0x20
---[ end trace 0000000000000000 ]---

Until this gets fixed upstream, disable AFBC support on this platform, as it's currently broken with upstream Mesa.(CVE-2025-68184)

In the Linux kernel, the following vulnerability has been resolved:

nfs4_setup_readdir(): insufficient locking for ->d_parent->d_inode dereferencing

Theoretically it's an oopsable race, but I don't believe one can manage to hit it on real hardware; might become doable on a KVM, but it still won't be easy to attack.

Anyway, it's easy to deal with - since xdr_encode_hyper() is just a call of put_unaligned_be64(), we can put that under ->d_lock and be done with that.(CVE-2025-68185)

In the Linux kernel, the following vulnerability has been resolved:

udp_tunnel: use netdev_warn() instead of netdev_WARN()

netdev_WARN() uses WARN/WARN_ON to print a backtrace along with file and line information. In this case, udp_tunnel_nic_register() returning an error is just a failed operation, not a kernel bug.

udp_tunnel_nic_register() can fail due to a memory allocation failure (kzalloc() or udp_tunnel_nic_alloc()). This is a normal runtime error and not a kernel bug.

Replace netdev_WARN() with netdev_warn() accordingly.(CVE-2025-68191)

In the Linux kernel, the following vulnerability has been resolved:

nvme-multipath: fix lockdep WARN due to partition scan work

Blktests test cases nvme/014, 057 and 058 fail occasionally due to a lockdep WARN. As reported in the Closes tag URL, the WARN indicates that a deadlock can happen due to the dependency among disk->open_mutex, kblockd workqueue completion and partition_scan_work completion.

To avoid the lockdep WARN and the potential deadlock, cut the dependency by running the partition_scan_work not by kblockd workqueue but by nvme_wq.(CVE-2025-68218)

In the Linux kernel, the following vulnerability has been resolved:

cifs: fix memory leak in smb3_fs_context_parse_param error path

Add proper cleanup of ctx->source and fc->source to the cifs_parse_mount_err error handler. This ensures that memory allocated for the source strings is correctly freed on all error paths, matching the cleanup already performed in the success path by smb3_cleanup_fs_context_contents(). Pointers are also set to NULL after freeing to prevent potential double-free issues.

This change fixes a memory leak originally detected by syzbot. The leak occurred when processing Opt_source mount options if an error happened after ctx->source and fc->source were successfully allocated but before the function completed.

The specific leak sequence was: 1. ctx->source = smb3_fs_context_fullpath(ctx, '/') allocates memory 2. fc->source = kstrdup(ctx->source, GFP_KERNEL) allocates more memory 3. A subsequent error jumps to cifs_parse_mount_err 4. The old error handler freed passwords but not the source strings, causing the memory to leak.

This issue was not addressed by commit e8c73eb7db0a ("cifs: client: fix memory leak in smb3_fs_context_parse_param"), which only fixed leaks from repeated fsconfig() calls but not this error path.

Patch updated with minor change suggested by kernel test robot(CVE-2025-68219)

In the Linux kernel, the following vulnerability has been resolved:

scsi: target: tcm_loop: Fix segfault in tcm_loop_tpg_address_show()

If the allocation of tl_hba->sh fails in tcm_loop_driver_probe() and we attempt to dereference it in tcm_loop_tpg_address_show() we will get a segfault, see below for an example. So, check tl_hba->sh before dereferencing it.

Unable to allocate struct scsi_host BUG: kernel NULL pointer dereference, address: 0000000000000194 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 1 PID: 8356 Comm: tokio-runtime-w Not tainted 6.6.104.2-4.azl3 #1 Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 09/28/2024 RIP: 0010:tcm_loop_tpg_address_show+0x2e/0x50 [tcm_loop] ... Call Trace: <TASK> configfs_read_iter+0x12d/0x1d0 [configfs] vfs_read+0x1b5/0x300 ksys_read+0x6f/0xf0 ...(CVE-2025-68229)

In the Linux kernel, the following vulnerability has been resolved:

binfmt_misc: restore write access before closing files opened by open_exec()

bm_register_write() opens an executable file using open_exec(), which internally calls do_open_execat() and denies write access on the file to avoid modification while it is being executed.

However, when an error occurs, bm_register_write() closes the file using filp_close() directly. This does not restore the write permission, which may cause subsequent write operations on the same file to fail.

Fix this by calling exe_file_allow_write_access() before filp_close() to restore the write permission properly.(CVE-2025-68239)

In the Linux kernel, the following vulnerability has been resolved:

ipv4: route: Prevent rt_bind_exception() from rebinding stale fnhe

The sit driver's packet transmission path calls: sit_tunnel_xmit() -> update_or_create_fnhe(), which lead to fnhe_remove_oldest() being called to delete entries exceeding FNHE_RECLAIM_DEPTH+random.

The race window is between fnhe_remove_oldest() selecting fnheX for deletion and the subsequent kfree_rcu(). During this time, the concurrent path's __mkroute_output() -> find_exception() can fetch the soon-to-be-deleted fnheX, and rt_bind_exception() then binds it with a new dst using a dst_hold(). When the original fnheX is freed via RCU, the dst reference remains permanently leaked.

CPU 0 CPU 1 __mkroute_output() find_exception() [fnheX] update_or_create_fnhe() fnhe_remove_oldest() [fnheX] rt_bind_exception() [bind dst] RCU callback [fnheX freed, dst leak]

This issue manifests as a device reference count leak and a warning in dmesg when unregistering the net device:

unregister_netdevice: waiting for sitX to become free. Usage count = N

Ido Schimmel provided the simple test validation method [1].

The fix clears 'oldest->fnhe_daddr' before calling fnhe_flush_routes(). Since rt_bind_exception() checks this field, setting it to zero prevents the stale fnhe from being reused and bound to a new dst just before it is freed.

[1] ip netns add ns1 ip -n ns1 link set dev lo up ip -n ns1 address add 192.0.2.1/32 dev lo ip -n ns1 link add name dummy1 up type dummy ip -n ns1 route add 192.0.2.2/32 dev dummy1 ip -n ns1 link add name gretap1 up arp off type gretap \ local 192.0.2.1 remote 192.0.2.2 ip -n ns1 route add 198.51.0.0/16 dev gretap1 taskset -c 0 ip netns exec ns1 mausezahn gretap1 \ -A 198.51.100.1 -B 198.51.0.0/16 -t udp -p 1000 -c 0 -q & taskset -c 2 ip netns exec ns1 mausezahn gretap1 \ -A 198.51.100.1 -B 198.51.0.0/16 -t udp -p 1000 -c 0 -q & sleep 10 ip netns pids ns1 | xargs kill ip netns del ns1(CVE-2025-68241)

In the Linux kernel, the following vulnerability has been resolved:

net: netpoll: fix incorrect refcount handling causing incorrect cleanup

commit efa95b01da18 ("netpoll: fix use after free") incorrectly ignored the refcount and prematurely set dev->npinfo to NULL during netpoll cleanup, leading to improper behavior and memory leaks.

Scenario causing lack of proper cleanup:

1) A netpoll is associated with a NIC (e.g., eth0) and netdev->npinfo is allocated, and refcnt = 1 - Keep in mind that npinfo is shared among all netpoll instances. In this case, there is just one.

2) Another netpoll is also associated with the same NIC and npinfo->refcnt += 1. - Now dev->npinfo->refcnt = 2; - There is just one npinfo associated to the netdev.

3) When the first netpolls goes to clean up: - The first cleanup succeeds and clears np->dev->npinfo, ignoring refcnt. - It basically calls RCU_INIT_POINTER(np->dev->npinfo, NULL); - Set dev->npinfo = NULL, without proper cleanup - No ->ndo_netpoll_cleanup() is either called

4) Now the second target tries to clean up - The second cleanup fails because np->dev->npinfo is already NULL. * In this case, ops->ndo_netpoll_cleanup() was never called, and the skb pool is not cleaned as well (for the second netpoll instance) - This leaks npinfo and skbpool skbs, which is clearly reported by kmemleak.

Revert commit efa95b01da18 ("netpoll: fix use after free") and adds clarifying comments emphasizing that npinfo cleanup should only happen once the refcount reaches zero, ensuring stable and correct netpoll behavior.(CVE-2025-68245)

In the Linux kernel, the following vulnerability has been resolved:

erofs: avoid infinite loops due to corrupted subpage compact indexes

Robert reported an infinite loop observed by two crafted images.

The root cause is that clusterofs can be larger than lclustersize for !NONHEAD lclusters in corrupted subpage compact indexes, e.g.:

blocksize = lclustersize = 512 lcn = 6 clusterofs = 515

Move the corresponding check for full compress indexes to z_erofs_load_lcluster_from_disk() to also cover subpage compact compress indexes.

It also fixes the position of m->type >= Z_EROFS_LCLUSTER_TYPE_MAX check, since it should be placed right after z_erofs_load_{compact,full}_lcluster().(CVE-2025-68251)

In the Linux kernel, the following vulnerability has been resolved:

usb: storage: Fix memory leak in USB bulk transport

A kernel memory leak was identified by the 'ioctl_sg01' test from Linux Test Project (LTP). The following bytes were mainly observed: 0x53425355.

When USB storage devices incorrectly skip the data phase with status data, the code extracts/validates the CSW from the sg buffer, but fails to clear it afterwards. This leaves status protocol data in srb's transfer buffer, such as the US_BULK_CS_SIGN 'USBS' signature observed here. Thus, this can lead to USB protocols leaks to user space through SCSI generic (/dev/sg*) interfaces, such as the one seen here when the LTP test requested 512 KiB.

Fix the leak by zeroing the CSW data in srb's transfer buffer immediately after the validation of devices that skip data phase.

Note: Differently from CVE-2018-1000204, which fixed a big leak by zero- ing pages at allocation time, this leak occurs after allocation, when USB protocol data is written to already-allocated sg pages.(CVE-2025-68288)

In the Linux kernel, the following vulnerability has been resolved:

smb: client: fix memory leak in cifs_construct_tcon()

When having a multiuser mount with domain= specified and using cifscreds, cifs_set_cifscreds() will end up setting @ctx->domainname, so it needs to be freed before leaving cifs_construct_tcon().

This fixes the following memory leak reported by kmemleak:

mount.cifs //srv/share /mnt -o domain=ZELDA,multiuser,... su - testuser cifscreds add -d ZELDA -u testuser ... ls /mnt/1 ... umount /mnt echo scan > /sys/kernel/debug/kmemleak cat /sys/kernel/debug/kmemleak unreferenced object 0xffff8881203c3f08 (size 8): comm "ls", pid 5060, jiffies 4307222943 hex dump (first 8 bytes): 5a 45 4c 44 41 00 cc cc ZELDA... backtrace (crc d109a8cf): __kmalloc_node_track_caller_noprof+0x572/0x710 kstrdup+0x3a/0x70 cifs_sb_tlink+0x1209/0x1770 [cifs] cifs_get_fattr+0xe1/0xf50 [cifs] cifs_get_inode_info+0xb5/0x240 [cifs] cifs_revalidate_dentry_attr+0x2d1/0x470 [cifs] cifs_getattr+0x28e/0x450 [cifs] vfs_getattr_nosec+0x126/0x180 vfs_statx+0xf6/0x220 do_statx+0xab/0x110 __x64_sys_statx+0xd5/0x130 do_syscall_64+0xbb/0x380 entry_SYSCALL_64_after_hwframe+0x77/0x7f(CVE-2025-68295)

In the Linux kernel, the following vulnerability has been resolved:

drm, fbcon, vga_switcheroo: Avoid race condition in fbcon setup

Protect vga_switcheroo_client_fb_set() with console lock. Avoids OOB access in fbcon_remap_all(). Without holding the console lock the call races with switching outputs.

VGA switcheroo calls fbcon_remap_all() when switching clients. The fbcon function uses struct fb_info.node, which is set by register_framebuffer(). As the fb-helper code currently sets up VGA switcheroo before registering the framebuffer, the value of node is -1 and therefore not a legal value. For example, fbcon uses the value within set_con2fb_map() [1] as an index into an array.

Moving vga_switcheroo_client_fb_set() after register_framebuffer() can result in VGA switching that does not switch fbcon correctly.

Therefore move vga_switcheroo_client_fb_set() under fbcon_fb_registered(), which already holds the console lock. Fbdev calls fbcon_fb_registered() from within register_framebuffer(). Serializes the helper with VGA switcheroo's call to fbcon_remap_all().

Although vga_switcheroo_client_fb_set() takes an instance of struct fb_info as parameter, it really only needs the contained fbcon state. Moving the call to fbcon initialization is therefore cleaner than before. Only amdgpu, i915, nouveau and radeon support vga_switcheroo. For all other drivers, this change does nothing.(CVE-2025-68296)

In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: hci_sock: Prevent race in socket write iter and sock bind

There is a potential race condition between sock bind and socket write iter. bind may free the same cmd via mgmt_pending before write iter sends the cmd, just as syzbot reported in UAF[1].

Here we use hci_dev_lock to synchronize the two, thereby avoiding the UAF mentioned in [1].

[1] syzbot reported: BUG: KASAN: slab-use-after-free in mgmt_pending_remove+0x3b/0x210 net/bluetooth/mgmt_util.c:316 Read of size 8 at addr ffff888077164818 by task syz.0.17/5989 Call Trace: mgmt_pending_remove+0x3b/0x210 net/bluetooth/mgmt_util.c:316 set_link_security+0x5c2/0x710 net/bluetooth/mgmt.c:1918 hci_mgmt_cmd+0x9c9/0xef0 net/bluetooth/hci_sock.c:1719 hci_sock_sendmsg+0x6ca/0xef0 net/bluetooth/hci_sock.c:1839 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg+0x21c/0x270 net/socket.c:742 sock_write_iter+0x279/0x360 net/socket.c:1195

Allocated by task 5989: mgmt_pending_add+0x35/0x140 net/bluetooth/mgmt_util.c:296 set_link_security+0x557/0x710 net/bluetooth/mgmt.c:1910 hci_mgmt_cmd+0x9c9/0xef0 net/bluetooth/hci_sock.c:1719 hci_sock_sendmsg+0x6ca/0xef0 net/bluetooth/hci_sock.c:1839 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg+0x21c/0x270 net/socket.c:742 sock_write_iter+0x279/0x360 net/socket.c:1195

Freed by task 5991: mgmt_pending_free net/bluetooth/mgmt_util.c:311 [inline] mgmt_pending_foreach+0x30d/0x380 net/bluetooth/mgmt_util.c:257 mgmt_index_removed+0x112/0x2f0 net/bluetooth/mgmt.c:9477 hci_sock_bind+0xbe9/0x1000 net/bluetooth/hci_sock.c:1314(CVE-2025-68305)

In the Linux kernel, the following vulnerability has been resolved:

s390/pci: Avoid deadlock between PCI error recovery and mlx5 crdump

Do not block PCI config accesses through pci_cfg_access_lock() when executing the s390 variant of PCI error recovery: Acquire just device_lock() instead of pci_dev_lock() as powerpc's EEH and generig PCI AER processing do.

During error recovery testing a pair of tasks was reported to be hung:

mlx5_core 0000:00:00.1: mlx5_health_try_recover:338:(pid 5553): health recovery flow aborted, PCI reads still not working INFO: task kmcheck:72 blocked for more than 122 seconds. Not tainted 5.14.0-570.12.1.bringup7.el9.s390x #1 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:kmcheck state:D stack:0 pid:72 tgid:72 ppid:2 flags:0x00000000 Call Trace: [<000000065256f030>] __schedule+0x2a0/0x590 [<000000065256f356>] schedule+0x36/0xe0 [<000000065256f572>] schedule_preempt_disabled+0x22/0x30 [<0000000652570a94>] __mutex_lock.constprop.0+0x484/0x8a8 [<000003ff800673a4>] mlx5_unload_one+0x34/0x58 [mlx5_core] [<000003ff8006745c>] mlx5_pci_err_detected+0x94/0x140 [mlx5_core] [<0000000652556c5a>] zpci_event_attempt_error_recovery+0xf2/0x398 [<0000000651b9184a>] __zpci_event_error+0x23a/0x2c0 INFO: task kworker/u1664:6:1514 blocked for more than 122 seconds. Not tainted 5.14.0-570.12.1.bringup7.el9.s390x #1 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:kworker/u1664:6 state:D stack:0 pid:1514 tgid:1514 ppid:2 flags:0x00000000 Workqueue: mlx5_health0000:00:00.0 mlx5_fw_fatal_reporter_err_work [mlx5_core] Call Trace: [<000000065256f030>] __schedule+0x2a0/0x590 [<000000065256f356>] schedule+0x36/0xe0 [<0000000652172e28>] pci_wait_cfg+0x80/0xe8 [<0000000652172f94>] pci_cfg_access_lock+0x74/0x88 [<000003ff800916b6>] mlx5_vsc_gw_lock+0x36/0x178 [mlx5_core] [<000003ff80098824>] mlx5_crdump_collect+0x34/0x1c8 [mlx5_core] [<000003ff80074b62>] mlx5_fw_fatal_reporter_dump+0x6a/0xe8 [mlx5_core] [<0000000652512242>] devlink_health_do_dump.part.0+0x82/0x168 [<0000000652513212>] devlink_health_report+0x19a/0x230 [<000003ff80075a12>] mlx5_fw_fatal_reporter_err_work+0xba/0x1b0 [mlx5_core]

No kernel log of the exact same error with an upstream kernel is available - but the very same deadlock situation can be constructed there, too:

task: kmcheck mlx5_unload_one() tries to acquire devlink lock while the PCI error recovery code has set pdev->block_cfg_access by way of pci_cfg_access_lock()
task: kworker mlx5_crdump_collect() tries to set block_cfg_access through pci_cfg_access_lock() while devlink_health_report() had acquired the devlink lock.

A similar deadlock situation can be reproduced by requesting a crdump with > devlink health dump show pci/<BDF> reporter fw_fatal

while PCI error recovery is executed on the same <BDF> physical function by mlx5_core's pci_error_handlers. On s390 this can be injected with > zpcictl --reset-fw <BDF>

Tests with this patch failed to reproduce that second deadlock situation, the devlink command is rejected with "kernel answers: Permission denied" - and we get a kernel log message of:

mlx5_core 1ed0:00:00.1: mlx5_crdump_collect:50:(pid 254382): crdump: failed to lock vsc gw err -5

because the config read of VSC_SEMAPHORE is rejected by the underlying hardware.

Two prior attempts to address this issue have been discussed and ultimately rejected [see link], with the primary argument that s390's implementation of PCI error recovery is imposing restrictions that neither powerpc's EEH nor PCI AER handling need. Tests show that PCI error recovery on s390 is running to completion even without blocking access to PCI config space.(CVE-2025-68310)

In the Linux kernel, the following vulnerability has been resolved:

usbnet: Prevents free active kevent

The root cause of this issue are: 1. When probing the usbnet device, executing usbnet_link_change(dev, 0, 0); put the kevent work in global workqueue. However, the kevent has not yet been scheduled when the usbnet device is unregistered. Therefore, executing free_netdev() results in the "free active object (kevent)" error reported here.

Another factor is that when calling usbnet_disconnect()->unregister_netdev(), if the usbnet device is up, ndo_stop() is executed to cancel the kevent. However, because the device is not up, ndo_stop() is not executed.

The solution to this problem is to cancel the kevent before executing free_netdev().(CVE-2025-68312)

In the Linux kernel, the following vulnerability has been resolved:

nbd: defer config unlock in nbd_genl_connect

There is one use-after-free warning when running NBD_CMD_CONNECT and NBD_CLEAR_SOCK:

nbd_genl_connect nbd_alloc_and_init_config // config_refs=1 nbd_start_device // config_refs=2 set NBD_RT_HAS_CONFIG_REF open nbd // config_refs=3 recv_work done // config_refs=2 NBD_CLEAR_SOCK // config_refs=1 close nbd // config_refs=0 refcount_inc -> uaf

------------[ cut here ]------------ refcount_t: addition on 0; use-after-free. WARNING: CPU: 24 PID: 1014 at lib/refcount.c:25 refcount_warn_saturate+0x12e/0x290 nbd_genl_connect+0x16d0/0x1ab0 genl_family_rcv_msg_doit+0x1f3/0x310 genl_rcv_msg+0x44a/0x790

The issue can be easily reproduced by adding a small delay before refcount_inc(&nbd->config_refs) in nbd_genl_connect():

    mutex_unlock(&amp;nbd-&gt;config_lock);
    if (!ret) {
            set_bit(NBD_RT_HAS_CONFIG_REF, &amp;config-&gt;runtime_flags);

printk("before sleep\n");
mdelay(5 * 1000);
printk("after sleep\n"); refcount_inc(&nbd->config_refs); nbd_connect_reply(info, nbd->index); }(CVE-2025-68366)

In the Linux kernel, the following vulnerability has been resolved:

macintosh/mac_hid: fix race condition in mac_hid_toggle_emumouse

The following warning appears when running syzkaller, and this issue also exists in the mainline code.

------------[ cut here ]------------ list_add double add: new=ffffffffa57eee28, prev=ffffffffa57eee28, next=ffffffffa5e63100. WARNING: CPU: 0 PID: 1491 at lib/list_debug.c:35 __list_add_valid_or_report+0xf7/0x130 Modules linked in: CPU: 0 PID: 1491 Comm: syz.1.28 Not tainted 6.6.0+ #3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:__list_add_valid_or_report+0xf7/0x130 RSP: 0018:ff1100010dfb7b78 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffffffffa57eee18 RCX: ffffffff97fc9817 RDX: 0000000000040000 RSI: ffa0000002383000 RDI: 0000000000000001 RBP: ffffffffa57eee28 R08: 0000000000000001 R09: ffe21c0021bf6f2c R10: 0000000000000001 R11: 6464615f7473696c R12: ffffffffa5e63100 R13: ffffffffa57eee28 R14: ffffffffa57eee28 R15: ff1100010dfb7d48 FS: 00007fb14398b640(0000) GS:ff11000119600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 000000010d096005 CR4: 0000000000773ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 80000000 Call Trace: <TASK> input_register_handler+0xb3/0x210 mac_hid_start_emulation+0x1c5/0x290 mac_hid_toggle_emumouse+0x20a/0x240 proc_sys_call_handler+0x4c2/0x6e0 new_sync_write+0x1b1/0x2d0 vfs_write+0x709/0x950 ksys_write+0x12a/0x250 do_syscall_64+0x5a/0x110 entry_SYSCALL_64_after_hwframe+0x78/0xe2

The WARNING occurs when two processes concurrently write to the mac-hid emulation sysctl, causing a race condition in mac_hid_toggle_emumouse(). Both processes read old_val=0, then both try to register the input handler, leading to a double list_add of the same handler.

CPU0 CPU1 ------------------------- ------------------------- vfs_write() //write 1 vfs_write() //write 1 proc_sys_write() proc_sys_write() mac_hid_toggle_emumouse() mac_hid_toggle_emumouse() old_val = valp // old_val=0 old_val = valp // old_val=0 mutex_lock_killable() proc_dointvec() // *valp=1 mac_hid_start_emulation() input_register_handler() mutex_unlock() mutex_lock_killable() proc_dointvec() mac_hid_start_emulation() input_register_handler() //Trigger Warning mutex_unlock()

Fix this by moving the old_val read inside the mutex lock region.(CVE-2025-68367)

In the Linux kernel, the following vulnerability has been resolved:

scsi: smartpqi: Fix device resources accessed after device removal

Correct possible race conditions during device removal.

Previously, a scheduled work item to reset a LUN could still execute after the device was removed, leading to use-after-free and other resource access issues.

This race condition occurs because the abort handler may schedule a LUN reset concurrently with device removal via sdev_destroy(), leading to use-after-free and improper access to freed resources.

Check in the device reset handler if the device is still present in the controller's SCSI device list before running; if not, the reset is skipped.
Cancel any pending TMF work that has not started in sdev_destroy().
Ensure device freeing in sdev_destroy() is done while holding the LUN reset mutex to avoid races with ongoing resets.(CVE-2025-68371)

In the Linux kernel, the following vulnerability has been resolved:

nbd: defer config put in recv_work

There is one uaf issue in recv_work when running NBD_CLEAR_SOCK and NBD_CMD_RECONFIGURE: nbd_genl_connect // conf_ref=2 (connect and recv_work A) nbd_open // conf_ref=3 recv_work A done // conf_ref=2 NBD_CLEAR_SOCK // conf_ref=1 nbd_genl_reconfigure // conf_ref=2 (trigger recv_work B) close nbd // conf_ref=1 recv_work B config_put // conf_ref=0 atomic_dec(&config->recv_threads); -> UAF

Or only running NBD_CLEAR_SOCK: nbd_genl_connect // conf_ref=2 nbd_open // conf_ref=3 NBD_CLEAR_SOCK // conf_ref=2 close nbd nbd_release config_put // conf_ref=1 recv_work config_put // conf_ref=0 atomic_dec(&config->recv_threads); -> UAF

Commit 87aac3a80af5 ("nbd: call nbd_config_put() before notifying the waiter") moved nbd_config_put() to run before waking up the waiter in recv_work, in order to ensure that nbd_start_device_ioctl() would not be woken up while nbd->task_recv was still uncleared.

However, in nbd_start_device_ioctl(), after being woken up it explicitly calls flush_workqueue() to make sure all current works are finished. Therefore, there is no need to move the config put ahead of the wakeup.

Move nbd_config_put() to the end of recv_work, so that the reference is held for the whole lifetime of the worker thread. This makes sure the config cannot be freed while recv_work is still running, even if clear + reconfigure interleave.

In addition, we don't need to worry about recv_work dropping the last nbd_put (which causes deadlock):

path A (netlink with NBD_CFLAG_DESTROY_ON_DISCONNECT): connect // nbd_refs=1 (trigger recv_work) open nbd // nbd_refs=2 NBD_CLEAR_SOCK close nbd nbd_release nbd_disconnect_and_put flush_workqueue // recv_work done nbd_config_put nbd_put // nbd_refs=1 nbd_put // nbd_refs=0 queue_work

path B (netlink without NBD_CFLAG_DESTROY_ON_DISCONNECT): connect // nbd_refs=2 (trigger recv_work) open nbd // nbd_refs=3 NBD_CLEAR_SOCK // conf_refs=2 close nbd nbd_release nbd_config_put // conf_refs=1 nbd_put // nbd_refs=2 recv_work done // conf_refs=0, nbd_refs=1 rmmod // nbd_refs=0

Depends-on: e2daec488c57 ("nbd: Fix hungtask when nbd_config_put")(CVE-2025-68372)

In the Linux kernel, the following vulnerability has been resolved:

md: fix rcu protection in md_wakeup_thread

We attempted to use RCU to protect the pointer 'thread', but directly passed the value when calling md_wakeup_thread(). This means that the RCU pointer has been acquired before rcu_read_lock(), which renders rcu_read_lock() ineffective and could lead to a use-after-free.(CVE-2025-68374)

In the Linux kernel, the following vulnerability has been resolved:

RDMA/rxe: Fix null deref on srq->rq.queue after resize failure

A NULL pointer dereference can occur in rxe_srq_chk_attr() when ibv_modify_srq() is invoked twice in succession under certain error conditions. The first call may fail in rxe_queue_resize(), which leads rxe_srq_from_attr() to set srq->rq.queue = NULL. The second call then triggers a crash (null deref) when accessing srq->rq.queue->buf->index_mask.

Call Trace: <TASK> rxe_modify_srq+0x170/0x480 [rdma_rxe] ? __pfx_rxe_modify_srq+0x10/0x10 [rdma_rxe] ? uverbs_try_lock_object+0x4f/0xa0 [ib_uverbs] ? rdma_lookup_get_uobject+0x1f0/0x380 [ib_uverbs] ib_uverbs_modify_srq+0x204/0x290 [ib_uverbs] ? __pfx_ib_uverbs_modify_srq+0x10/0x10 [ib_uverbs] ? tryinc_node_nr_active+0xe6/0x150 ? uverbs_fill_udata+0xed/0x4f0 [ib_uverbs] ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x2c0/0x470 [ib_uverbs] ? __pfx_ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x10/0x10 [ib_uverbs] ? uverbs_fill_udata+0xed/0x4f0 [ib_uverbs] ib_uverbs_run_method+0x55a/0x6e0 [ib_uverbs] ? __pfx_ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x10/0x10 [ib_uverbs] ib_uverbs_cmd_verbs+0x54d/0x800 [ib_uverbs] ? __pfx_ib_uverbs_cmd_verbs+0x10/0x10 [ib_uverbs] ? __pfxrawspin_lock_irqsave+0x10/0x10 ? pfx_do_vfs_ioctl+0x10/0x10 ? ioctl_has_perm.constprop.0.isra.0+0x2c7/0x4c0 ? __pfx_ioctl_has_perm.constprop.0.isra.0+0x10/0x10 ib_uverbs_ioctl+0x13e/0x220 [ib_uverbs] ? __pfx_ib_uverbs_ioctl+0x10/0x10 [ib_uverbs] __x64_sys_ioctl+0x138/0x1c0 do_syscall_64+0x82/0x250 ? fdget_pos+0x58/0x4c0 ? ksys_write+0xf3/0x1c0 ? __pfx_ksys_write+0x10/0x10 ? do_syscall_64+0xc8/0x250 ? __pfx_vm_mmap_pgoff+0x10/0x10 ? fget+0x173/0x230 ? fput+0x2a/0x80 ? ksys_mmap_pgoff+0x224/0x4c0 ? do_syscall_64+0xc8/0x250 ? do_user_addr_fault+0x37b/0xfe0 ? clear_bhb_loop+0x50/0xa0 ? clear_bhb_loop+0x50/0xa0 ? clear_bhb_loop+0x50/0xa0 entry_SYSCALL_64_after_hwframe+0x76/0x7e(CVE-2025-68379)

In the Linux kernel, the following vulnerability has been resolved:

NFS: Automounted filesystems should inherit ro,noexec,nodev,sync flags

When a filesystem is being automounted, it needs to preserve the user-set superblock mount options, such as the "ro" flag.(CVE-2025-68764)

In the Linux kernel, the following vulnerability has been resolved:

fsnotify: do not generate ACCESS/MODIFY events on child for special files

inotify/fanotify do not allow users with no read access to a file to subscribe to events (e.g. IN_ACCESS/IN_MODIFY), but they do allow the same user to subscribe for watching events on children when the user has access to the parent directory (e.g. /dev).

Users with no read access to a file but with read access to its parent directory can still stat the file and see if it was accessed/modified via atime/mtime change.

The same is not true for special files (e.g. /dev/null). Users will not generally observe atime/mtime changes when other users read/write to special files, only when someone sets atime/mtime via utimensat().

Align fsnotify events with this stat behavior and do not generate ACCESS/MODIFY events to parent watchers on read/write of special files. The events are still generated to parent watchers on utimensat(). This closes some side-channels that could be possibly used for information exfiltration [1].

[1] https://snee.la/pdf/pubs/file-notification-attacks.pdf(CVE-2025-68788)

In the Linux kernel, the following vulnerability has been resolved:

fuse: missing copy_finish in fuse-over-io-uring argument copies

Fix a possible reference count leak of payload pages during fuse argument copies.

Joanne: simplified error cleanup

In the Linux kernel, the following vulnerability has been resolved:

perf/x86/amd: Check event before enable to avoid GPF

On AMD machines cpuc->events[idx] can become NULL in a subtle race condition with NMI->throttle->x86_pmu_stop().

Check event for NULL in amd_pmu_enable_all() before enable to avoid a GPF. This appears to be an AMD only issue.

Syzkaller reported a GPF in amd_pmu_enable_all.

INFO: NMI handler (perf_event_nmi_handler) took too long to run: 13.143 msecs Oops: general protection fault, probably for non-canonical address 0xdffffc0000000034: 0000 PREEMPT SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x00000000000001a0-0x00000000000001a7] CPU: 0 UID: 0 PID: 328415 Comm: repro_36674776 Not tainted 6.12.0-rc1-syzk RIP: 0010:x86_pmu_enable_event (arch/x86/events/perf_event.h:1195 arch/x86/events/core.c:1430) RSP: 0018:ffff888118009d60 EFLAGS: 00010012 RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000000034 RSI: 0000000000000000 RDI: 00000000000001a0 RBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000002 R13: ffff88811802a440 R14: ffff88811802a240 R15: ffff8881132d8601 FS: 00007f097dfaa700(0000) GS:ffff888118000000(0000) GS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000200001c0 CR3: 0000000103d56000 CR4: 00000000000006f0 Call Trace: <IRQ> amd_pmu_enable_all (arch/x86/events/amd/core.c:760 (discriminator 2)) x86_pmu_enable (arch/x86/events/core.c:1360) event_sched_out (kernel/events/core.c:1191 kernel/events/core.c:1186 kernel/events/core.c:2346) __perf_remove_from_context (kernel/events/core.c:2435) event_function (kernel/events/core.c:259) remote_function (kernel/events/core.c:92 (discriminator 1) kernel/events/core.c:72 (discriminator 1)) __flush_smp_call_function_queue (./arch/x86/include/asm/jump_label.h:27 ./include/linux/jump_label.h:207 ./include/trace/events/csd.h:64 kernel/smp.c:135 kernel/smp.c:540) __sysvec_call_function_single (./arch/x86/include/asm/jump_label.h:27 ./include/linux/jump_label.h:207 ./arch/x86/include/asm/trace/irq_vectors.h:99 arch/x86/kernel/smp.c:272) sysvec_call_function_single (arch/x86/kernel/smp.c:266 (discriminator 47) arch/x86/kernel/smp.c:266 (discriminator 47)) </IRQ>(CVE-2025-68798)

In the Linux kernel, the following vulnerability has been resolved:

mlxsw: spectrum_mr: Fix use-after-free when updating multicast route stats

Cited commit added a dedicated mutex (instead of RTNL) to protect the multicast route list, so that it will not change while the driver periodically traverses it in order to update the kernel about multicast route stats that were queried from the device.

One instance of list entry deletion (during route replace) was missed and it can result in a use-after-free [1].

Fix by acquiring the mutex before deleting the entry from the list and releasing it afterwards.

[1] BUG: KASAN: slab-use-after-free in mlxsw_sp_mr_stats_update+0x4a5/0x540 drivers/net/ethernet/mellanox/mlxsw/spectrum_mr.c:1006 [mlxsw_spectrum] Read of size 8 at addr ffff8881523c2fa8 by task kworker/2:5/22043

CPU: 2 UID: 0 PID: 22043 Comm: kworker/2:5 Not tainted 6.18.0-rc1-custom-g1a3d6d7cd014 #1 PREEMPT(full) Hardware name: Mellanox Technologies Ltd. MSN2010/SA002610, BIOS 5.6.5 08/24/2017 Workqueue: mlxsw_core mlxsw_sp_mr_stats_update [mlxsw_spectrum] Call Trace: <TASK> dump_stack_lvl+0xba/0x110 print_report+0x174/0x4f5 kasan_report+0xdf/0x110 mlxsw_sp_mr_stats_update+0x4a5/0x540 drivers/net/ethernet/mellanox/mlxsw/spectrum_mr.c:1006 [mlxsw_spectrum] process_one_work+0x9cc/0x18e0 worker_thread+0x5df/0xe40 kthread+0x3b8/0x730 ret_from_fork+0x3e9/0x560 ret_from_fork_asm+0x1a/0x30 </TASK>

Allocated by task 29933: kasan_save_stack+0x30/0x50 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x8f/0xa0 mlxsw_sp_mr_route_add+0xd8/0x4770 [mlxsw_spectrum] mlxsw_sp_router_fibmr_event_work+0x371/0xad0 drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c:7965 [mlxsw_spectrum] process_one_work+0x9cc/0x18e0 worker_thread+0x5df/0xe40 kthread+0x3b8/0x730 ret_from_fork+0x3e9/0x560 ret_from_fork_asm+0x1a/0x30

Freed by task 29933: kasan_save_stack+0x30/0x50 kasan_save_track+0x14/0x30 __kasan_save_free_info+0x3b/0x70 __kasan_slab_free+0x43/0x70 kfree+0x14e/0x700 mlxsw_sp_mr_route_add+0x2dea/0x4770 drivers/net/ethernet/mellanox/mlxsw/spectrum_mr.c:444 [mlxsw_spectrum] mlxsw_sp_router_fibmr_event_work+0x371/0xad0 drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c:7965 [mlxsw_spectrum] process_one_work+0x9cc/0x18e0 worker_thread+0x5df/0xe40 kthread+0x3b8/0x730 ret_from_fork+0x3e9/0x560 ret_from_fork_asm+0x1a/0x30(CVE-2025-68800)

In the Linux kernel, the following vulnerability has been resolved:

mlxsw: spectrum_router: Fix neighbour use-after-free

We sometimes observe use-after-free when dereferencing a neighbour [1]. The problem seems to be that the driver stores a pointer to the neighbour, but without holding a reference on it. A reference is only taken when the neighbour is used by a nexthop.

Fix by simplifying the reference counting scheme. Always take a reference when storing a neighbour pointer in a neighbour entry. Avoid taking a referencing when the neighbour is used by a nexthop as the neighbour entry associated with the nexthop already holds a reference.

Tested by running the test that uncovered the problem over 300 times. Without this patch the problem was reproduced after a handful of iterations.

[1] BUG: KASAN: slab-use-after-free in mlxsw_sp_neigh_entry_update+0x2d4/0x310 Read of size 8 at addr ffff88817f8e3420 by task ip/3929

CPU: 3 UID: 0 PID: 3929 Comm: ip Not tainted 6.18.0-rc4-virtme-g36b21a067510 #3 PREEMPT(full) Hardware name: Nvidia SN5600/VMOD0013, BIOS 5.13 05/31/2023 Call Trace: <TASK> dump_stack_lvl+0x6f/0xa0 print_address_description.constprop.0+0x6e/0x300 print_report+0xfc/0x1fb kasan_report+0xe4/0x110 mlxsw_sp_neigh_entry_update+0x2d4/0x310 mlxsw_sp_router_rif_gone_sync+0x35f/0x510 mlxsw_sp_rif_destroy+0x1ea/0x730 mlxsw_sp_inetaddr_port_vlan_event+0xa1/0x1b0 __mlxsw_sp_inetaddr_lag_event+0xcc/0x130 __mlxsw_sp_inetaddr_event+0xf5/0x3c0 mlxsw_sp_router_netdevice_event+0x1015/0x1580 notifier_call_chain+0xcc/0x150 call_netdevice_notifiers_info+0x7e/0x100 __netdev_upper_dev_unlink+0x10b/0x210 netdev_upper_dev_unlink+0x79/0xa0 vrf_del_slave+0x18/0x50 do_set_master+0x146/0x7d0 do_setlink.isra.0+0x9a0/0x2880 rtnl_newlink+0x637/0xb20 rtnetlink_rcv_msg+0x6fe/0xb90 netlink_rcv_skb+0x123/0x380 netlink_unicast+0x4a3/0x770 netlink_sendmsg+0x75b/0xc90 __sock_sendmsg+0xbe/0x160 _syssendmsg+0x5b2/0x7d0 _sys_sendmsg+0xfd/0x180 __sys_sendmsg+0x124/0x1c0 do_syscall_64+0xbb/0xfd0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 [...]

Allocated by task 109: kasan_save_stack+0x30/0x50 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x7b/0x90 __kmalloc_noprof+0x2c1/0x790 neigh_alloc+0x6af/0x8f0 ___neigh_create+0x63/0xe90 mlxsw_sp_nexthop_neigh_init+0x430/0x7e0 mlxsw_sp_nexthop_type_init+0x212/0x960 mlxsw_sp_nexthop6_group_info_init.constprop.0+0x81f/0x1280 mlxsw_sp_nexthop6_group_get+0x392/0x6a0 mlxsw_sp_fib6_entry_create+0x46a/0xfd0 mlxsw_sp_router_fib6_replace+0x1ed/0x5f0 mlxsw_sp_router_fib6_event_work+0x10a/0x2a0 process_one_work+0xd57/0x1390 worker_thread+0x4d6/0xd40 kthread+0x355/0x5b0 ret_from_fork+0x1d4/0x270 ret_from_fork_asm+0x11/0x20

Freed by task 154: kasan_save_stack+0x30/0x50 kasan_save_track+0x14/0x30 __kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x43/0x70 kmem_cache_free_bulk.part.0+0x1eb/0x5e0 kvfree_rcu_bulk+0x1f2/0x260 kfree_rcu_work+0x130/0x1b0 process_one_work+0xd57/0x1390 worker_thread+0x4d6/0xd40 kthread+0x355/0x5b0 ret_from_fork+0x1d4/0x270 ret_from_fork_asm+0x11/0x20

Last potentially related work creation: kasan_save_stack+0x30/0x50 kasan_record_aux_stack+0x8c/0xa0 kvfree_call_rcu+0x93/0x5b0 mlxsw_sp_router_neigh_event_work+0x67d/0x860 process_one_work+0xd57/0x1390 worker_thread+0x4d6/0xd40 kthread+0x355/0x5b0 ret_from_fork+0x1d4/0x270 ret_from_fork_asm+0x11/0x20(CVE-2025-68801)

In the Linux kernel, the following vulnerability has been resolved:

fuse: fix io-uring list corruption for terminated non-committed requests

When a request is terminated before it has been committed, the request is not removed from the queue's list. This leaves a dangling list entry that leads to list corruption and use-after-free issues.

Remove the request from the queue's list for terminated non-committed requests.(CVE-2025-68805)

In the Linux kernel, the following vulnerability has been resolved:

fuse: fix readahead reclaim deadlock

Commit e26ee4efbc79 ("fuse: allocate ff->release_args only if release is needed") skips allocating ff->release_args if the server does not implement open. However in doing so, fuse_prepare_release() now skips grabbing the reference on the inode, which makes it possible for an inode to be evicted from the dcache while there are inflight readahead requests. This causes a deadlock if the server triggers reclaim while servicing the readahead request and reclaim attempts to evict the inode of the file being read ahead. Since the folio is locked during readahead, when reclaim evicts the fuse inode and fuse_evict_inode() attempts to remove all folios associated with the inode from the page cache (truncate_inode_pages_range()), reclaim will block forever waiting for the lock since readahead cannot relinquish the lock because it is itself blocked in reclaim:

>>> stack_trace(1504735) folio_wait_bit_common (mm/filemap.c:1308:4) folio_lock (./include/linux/pagemap.h:1052:3) truncate_inode_pages_range (mm/truncate.c:336:10) fuse_evict_inode (fs/fuse/inode.c:161:2) evict (fs/inode.c:704:3) dentry_unlink_inode (fs/dcache.c:412:3) __dentry_kill (fs/dcache.c:615:3) shrink_kill (fs/dcache.c:1060:12) shrink_dentry_list (fs/dcache.c:1087:3) prune_dcache_sb (fs/dcache.c:1168:2) super_cache_scan (fs/super.c:221:10) do_shrink_slab (mm/shrinker.c:435:9) shrink_slab (mm/shrinker.c:626:10) shrink_node (mm/vmscan.c:5951:2) shrink_zones (mm/vmscan.c:6195:3) do_try_to_free_pages (mm/vmscan.c:6257:3) do_swap_page (mm/memory.c:4136:11) handle_pte_fault (mm/memory.c:5562:10) handle_mm_fault (mm/memory.c:5870:9) do_user_addr_fault (arch/x86/mm/fault.c:1338:10) handle_page_fault (arch/x86/mm/fault.c:1481:3) exc_page_fault (arch/x86/mm/fault.c:1539:2) asm_exc_page_fault+0x22/0x27

Fix this deadlock by allocating ff->release_args and grabbing the reference on the inode when preparing the file for release even if the server does not implement open. The inode reference will be dropped when the last reference on the fuse file is dropped (see fuse_file_put() -> fuse_release_end()).(CVE-2025-68821)

In the Linux kernel, the following vulnerability has been resolved:

iavf: fix off-by-one issues in iavf_config_rss_reg()

There are off-by-one bugs when configuring RSS hash key and lookup table, causing out-of-bounds reads to memory [1] and out-of-bounds writes to device registers.

Before commit 43a3d9ba34c9 ("i40evf: Allow PF driver to configure RSS"), the loop upper bounds were: i <= I40E_VFQF_{HKEY,HLUT}_MAX_INDEX which is safe since the value is the last valid index.

That commit changed the bounds to: i <= adapter->rss_{key,lut}_size / 4 where rss_{key,lut}_size / 4 is the number of dwords, so the last valid index is (rss_{key,lut}_size / 4) - 1. Therefore, using <= accesses one element past the end.

Fix the issues by using < instead of <=, ensuring we do not exceed the bounds.

[1] KASAN splat about rss_key_size off-by-one BUG: KASAN: slab-out-of-bounds in iavf_config_rss+0x619/0x800 Read of size 4 at addr ffff888102c50134 by task kworker/u8:6/63

CPU: 0 UID: 0 PID: 63 Comm: kworker/u8:6 Not tainted 6.18.0-rc2-enjuk-tnguy-00378-g3005f5b77652-dirty #156 PREEMPT(voluntary) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Workqueue: iavf iavf_watchdog_task Call Trace: <TASK> dump_stack_lvl+0x6f/0xb0 print_report+0x170/0x4f3 kasan_report+0xe1/0x1a0 iavf_config_rss+0x619/0x800 iavf_watchdog_task+0x2be7/0x3230 process_one_work+0x7fd/0x1420 worker_thread+0x4d1/0xd40 kthread+0x344/0x660 ret_from_fork+0x249/0x320 ret_from_fork_asm+0x1a/0x30 </TASK>

Allocated by task 63: kasan_save_stack+0x30/0x50 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x7f/0x90 __kmalloc_noprof+0x246/0x6f0 iavf_watchdog_task+0x28fc/0x3230 process_one_work+0x7fd/0x1420 worker_thread+0x4d1/0xd40 kthread+0x344/0x660 ret_from_fork+0x249/0x320 ret_from_fork_asm+0x1a/0x30

The buggy address belongs to the object at ffff888102c50100 which belongs to the cache kmalloc-64 of size 64 The buggy address is located 0 bytes to the right of allocated 52-byte region [ffff888102c50100, ffff888102c50134)

The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x102c50 flags: 0x200000000000000(node=0|zone=2) page_type: f5(slab) raw: 0200000000000000 ffff8881000418c0 dead000000000122 0000000000000000 raw: 0000000000000000 0000000080200020 00000000f5000000 0000000000000000 page dumped because: kasan: bad access detected

Memory state around the buggy address: ffff888102c50000: 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc fc ffff888102c50080: 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc fc >ffff888102c50100: 00 00 00 00 00 00 04 fc fc fc fc fc fc fc fc fc ^ ffff888102c50180: 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc ffff888102c50200: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc(CVE-2025-71087)

In the Linux kernel, the following vulnerability has been resolved:

e1000: fix OOB in e1000_tbi_should_accept()

In e1000_tbi_should_accept() we read the last byte of the frame via 'data[length - 1]' to evaluate the TBI workaround. If the descriptor- reported length is zero or larger than the actual RX buffer size, this read goes out of bounds and can hit unrelated slab objects. The issue is observed from the NAPI receive path (e1000_clean_rx_irq):

================================================================== BUG: KASAN: slab-out-of-bounds in e1000_tbi_should_accept+0x610/0x790 Read of size 1 at addr ffff888014114e54 by task sshd/363

CPU: 0 PID: 363 Comm: sshd Not tainted 5.18.0-rc1 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014 Call Trace: <IRQ> dump_stack_lvl+0x5a/0x74 print_address_description+0x7b/0x440 print_report+0x101/0x200 kasan_report+0xc1/0xf0 e1000_tbi_should_accept+0x610/0x790 e1000_clean_rx_irq+0xa8c/0x1110 e1000_clean+0xde2/0x3c10 __napi_poll+0x98/0x380 net_rx_action+0x491/0xa20 __do_softirq+0x2c9/0x61d do_softirq+0xd1/0x120 </IRQ> <TASK> __local_bh_enable_ip+0xfe/0x130 ip_finish_output2+0x7d5/0xb00 __ip_queue_xmit+0xe24/0x1ab0 __tcp_transmit_skb+0x1bcb/0x3340 tcp_write_xmit+0x175d/0x6bd0 __tcp_push_pending_frames+0x7b/0x280 tcp_sendmsg_locked+0x2e4f/0x32d0 tcp_sendmsg+0x24/0x40 sock_write_iter+0x322/0x430 vfs_write+0x56c/0xa60 ksys_write+0xd1/0x190 do_syscall_64+0x43/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7f511b476b10 Code: 73 01 c3 48 8b 0d 88 d3 2b 00 f7 d8 64 89 01 48 83 c8 ff c3 66 0f 1f 44 00 00 83 3d f9 2b 2c 00 00 75 10 b8 01 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 31 c3 48 83 ec 08 e8 8e 9b 01 00 48 89 04 24 RSP: 002b:00007ffc9211d4e8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 0000000000004024 RCX: 00007f511b476b10 RDX: 0000000000004024 RSI: 0000559a9385962c RDI: 0000000000000003 RBP: 0000559a9383a400 R08: fffffffffffffff0 R09: 0000000000004f00 R10: 0000000000000070 R11: 0000000000000246 R12: 0000000000000000 R13: 00007ffc9211d57f R14: 0000559a9347bde7 R15: 0000000000000003 </TASK> Allocated by task 1: __kasan_krealloc+0x131/0x1c0 krealloc+0x90/0xc0 add_sysfs_param+0xcb/0x8a0 kernel_add_sysfs_param+0x81/0xd4 param_sysfs_builtin+0x138/0x1a6 param_sysfs_init+0x57/0x5b do_one_initcall+0x104/0x250 do_initcall_level+0x102/0x132 do_initcalls+0x46/0x74 kernel_init_freeable+0x28f/0x393 kernel_init+0x14/0x1a0 ret_from_fork+0x22/0x30 The buggy address belongs to the object at ffff888014114000 which belongs to the cache kmalloc-2k of size 2048 The buggy address is located 1620 bytes to the right of 2048-byte region [ffff888014114000, ffff888014114800] The buggy address belongs to the physical page: page:ffffea0000504400 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x14110 head:ffffea0000504400 order:3 compound_mapcount:0 compound_pincount:0 flags: 0x100000000010200(slab|head|node=0|zone=1) raw: 0100000000010200 0000000000000000 dead000000000001 ffff888013442000 raw: 0000000000000000 0000000000080008 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected ==================================================================

This happens because the TBI check unconditionally dereferences the last byte without validating the reported length first:

u8 last_byte = *(data + length - 1);

Fix by rejecting the frame early if the length is zero, or if it exceeds adapter->rx_buffer_len. This preserves the TBI workaround semantics for valid frames and prevents touching memory beyond the RX buffer.(CVE-2025-71093)

In the Linux kernel, the following vulnerability has been resolved:

usb: typec: ucsi: Handle incorrect num_connectors capability

The UCSI spec states that the num_connectors field is 7 bits, and the 8th bit is reserved and should be set to zero. Some buggy FW has been known to set this bit, and it can lead to a system not booting. Flag that the FW is not behaving correctly, and auto-fix the value so that the system boots correctly.

Found on Lenovo P1 G8 during Linux enablement program. The FW will be fixed, but seemed worth addressing in case it hit platforms that aren't officially Linux supported.(CVE-2025-71108)

In the Linux kernel, the following vulnerability has been resolved:

crypto: af_alg - zero initialize memory allocated via sock_kmalloc

Several crypto user API contexts and requests allocated with sock_kmalloc() were left uninitialized, relying on callers to set fields explicitly. This resulted in the use of uninitialized data in certain error paths or when new fields are added in the future.

The ACVP patches also contain two user-space interface files: algif_kpp.c and algif_akcipher.c. These too rely on proper initialization of their context structures.

A particular issue has been observed with the newly added 'inflight' variable introduced in af_alg_ctx by commit:

67b164a871af ("crypto: af_alg - Disallow multiple in-flight AIO requests")

Because the context is not memset to zero after allocation, the inflight variable has contained garbage values. As a result, af_alg_alloc_areq() has incorrectly returned -EBUSY randomly when the garbage value was interpreted as true:

https://github.com/gregkh/linux/blame/master/crypto/af_alg.c#L1209

The check directly tests ctx->inflight without explicitly comparing against true/false. Since inflight is only ever set to true or false later, an uninitialized value has triggered -EBUSY failures. Zero-initializing memory allocated with sock_kmalloc() ensures inflight and other fields start in a known state, removing random issues caused by uninitialized data.(CVE-2025-71113)

In the Linux kernel, the following vulnerability has been resolved:

powerpc/kexec: Enable SMT before waking offline CPUs

If SMT is disabled or a partial SMT state is enabled, when a new kernel image is loaded for kexec, on reboot the following warning is observed:

kexec: Waking offline cpu 228. WARNING: CPU: 0 PID: 9062 at arch/powerpc/kexec/core_64.c:223 kexec_prepare_cpus+0x1b0/0x1bc [snip] NIP kexec_prepare_cpus+0x1b0/0x1bc LR kexec_prepare_cpus+0x1a0/0x1bc Call Trace: kexec_prepare_cpus+0x1a0/0x1bc (unreliable) default_machine_kexec+0x160/0x19c machine_kexec+0x80/0x88 kernel_kexec+0xd0/0x118 __do_sys_reboot+0x210/0x2c4 system_call_exception+0x124/0x320 system_call_vectored_common+0x15c/0x2ec

This occurs as add_cpu() fails due to cpu_bootable() returning false for CPUs that fail the cpu_smt_thread_allowed() check or non primary threads if SMT is disabled.

Fix the issue by enabling SMT and resetting the number of SMT threads to the number of threads per core, before attempting to wake up all present CPUs.(CVE-2025-71119)

In the Linux kernel, the following vulnerability has been resolved:

tracing: Do not register unsupported perf events

Synthetic events currently do not have a function to register perf events. This leads to calling the tracepoint register functions with a NULL function pointer which triggers:

------------[ cut here ]------------ WARNING: kernel/tracepoint.c:175 at tracepoint_add_func+0x357/0x370, CPU#2: perf/2272 Modules linked in: kvm_intel kvm irqbypass CPU: 2 UID: 0 PID: 2272 Comm: perf Not tainted 6.18.0-ftest-11964-ge022764176fc-dirty #323 PREEMPTLAZY Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.17.0-debian-1.17.0-1 04/01/2014 RIP: 0010:tracepoint_add_func+0x357/0x370 Code: 28 9c e8 4c 0b f5 ff eb 0f 4c 89 f7 48 c7 c6 80 4d 28 9c e8 ab 89 f4 ff 31 c0 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc cc <0f> 0b 49 c7 c6 ea ff ff ff e9 ee fe ff ff 0f 0b e9 f9 fe ff ff 0f RSP: 0018:ffffabc0c44d3c40 EFLAGS: 00010246 RAX: 0000000000000001 RBX: ffff9380aa9e4060 RCX: 0000000000000000 RDX: 000000000000000a RSI: ffffffff9e1d4a98 RDI: ffff937fcf5fd6c8 RBP: 0000000000000001 R08: 0000000000000007 R09: ffff937fcf5fc780 R10: 0000000000000003 R11: ffffffff9c193910 R12: 000000000000000a R13: ffffffff9e1e5888 R14: 0000000000000000 R15: ffffabc0c44d3c78 FS: 00007f6202f5f340(0000) GS:ffff93819f00f000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000055d3162281a8 CR3: 0000000106a56003 CR4: 0000000000172ef0 Call Trace: <TASK> tracepoint_probe_register+0x5d/0x90 synth_event_reg+0x3c/0x60 perf_trace_event_init+0x204/0x340 perf_trace_init+0x85/0xd0 perf_tp_event_init+0x2e/0x50 perf_try_init_event+0x6f/0x230 ? perf_event_alloc+0x4bb/0xdc0 perf_event_alloc+0x65a/0xdc0 __se_sys_perf_event_open+0x290/0x9f0 do_syscall_64+0x93/0x7b0 ? entry_SYSCALL_64_after_hwframe+0x76/0x7e ? trace_hardirqs_off+0x53/0xc0 entry_SYSCALL_64_after_hwframe+0x76/0x7e

Instead, have the code return -ENODEV, which doesn't warn and has perf error out with:

# perf record -e synthetic:futex_wait Error: The sys_perf_event_open() syscall returned with 19 (No such device) for event (synthetic:futex_wait). "dmesg | grep -i perf" may provide additional information.

Ideally perf should support synthetic events, but for now just fix the warning. The support can come later.(CVE-2025-71125)

In the Linux kernel, the following vulnerability has been resolved:

cifs: Fix memory and information leak in smb3_reconfigure()

In smb3_reconfigure(), if smb3_sync_session_ctx_passwords() fails, the function returns immediately without freeing and erasing the newly allocated new_password and new_password2. This causes both a memory leak and a potential information leak.

Fix this by calling kfree_sensitive() on both password buffers before returning in this error case.(CVE-2025-71151)

Severity

7.8 (High)


                    
                      CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

References

URL

Type

	https://www.openeuler.org/zh/security/security-bu…	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-57994	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-58012	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2025-37800	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2025-38110	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2025-38111	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2025-38149	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2025-38162	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2025-38208	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2025-38232	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2025-38244	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2025-38303	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2025-38342	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2025-38393	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2025-38455	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2025-38489	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2025-38676	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2025-38688	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2025-38697	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2025-38712	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2025-38713	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2025-38714	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2025-38728	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2025-39720	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2025-39721	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2025-39730	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2025-39737	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2025-39749	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2025-39798	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2025-39823	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2025-39828	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2025-39838	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2025-39839	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2025-39927	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2025-39929	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2025-39951	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2025-40083	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2025-40087	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2025-40099	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2025-40103	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2025-40105	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2025-40111	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2025-40250	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2025-40252	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2025-40259	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2025-40261	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2025-40264	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2025-40268	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2025-40273	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2025-40284	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2025-40304	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2025-40311	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2025-40314	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2025-40319	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2025-40320	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2025-40322	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2025-40324	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2025-40328	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2025-40345	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2025-40350	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2025-40360	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2025-40363	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2025-68178	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2025-68184	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2025-68185	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2025-68191	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2025-68218	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2025-68219	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2025-68229	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2025-68239	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2025-68241	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2025-68245	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2025-68251	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2025-68288	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2025-68295	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2025-68296	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2025-68305	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2025-68310	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2025-68312	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2025-68366	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2025-68367	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2025-68371	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2025-68372	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2025-68374	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2025-68379	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2025-68764	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2025-68788	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2025-68791	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2025-68798	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2025-68800	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2025-68801	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2025-68805	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2025-68821	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2025-71087	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2025-71093	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2025-71108	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2025-71113	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2025-71119	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2025-71125	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2025-71151	ADVISORY

JSON

To clipboard

{
  "affected": [
    {
      "ecosystem_specific": {
        "aarch64": [
          "bpftool-6.6.0-138.0.0.119.oe2403.aarch64.rpm",
          "bpftool-debuginfo-6.6.0-138.0.0.119.oe2403.aarch64.rpm",
          "kernel-6.6.0-138.0.0.119.oe2403.aarch64.rpm",
          "kernel-debuginfo-6.6.0-138.0.0.119.oe2403.aarch64.rpm",
          "kernel-debugsource-6.6.0-138.0.0.119.oe2403.aarch64.rpm",
          "kernel-devel-6.6.0-138.0.0.119.oe2403.aarch64.rpm",
          "kernel-headers-6.6.0-138.0.0.119.oe2403.aarch64.rpm",
          "kernel-source-6.6.0-138.0.0.119.oe2403.aarch64.rpm",
          "kernel-tools-6.6.0-138.0.0.119.oe2403.aarch64.rpm",
          "kernel-tools-debuginfo-6.6.0-138.0.0.119.oe2403.aarch64.rpm",
          "kernel-tools-devel-6.6.0-138.0.0.119.oe2403.aarch64.rpm",
          "perf-6.6.0-138.0.0.119.oe2403.aarch64.rpm",
          "perf-debuginfo-6.6.0-138.0.0.119.oe2403.aarch64.rpm",
          "python3-perf-6.6.0-138.0.0.119.oe2403.aarch64.rpm",
          "python3-perf-debuginfo-6.6.0-138.0.0.119.oe2403.aarch64.rpm"
        ],
        "src": [
          "kernel-6.6.0-138.0.0.119.oe2403.src.rpm"
        ],
        "x86_64": [
          "bpftool-6.6.0-138.0.0.119.oe2403.x86_64.rpm",
          "bpftool-debuginfo-6.6.0-138.0.0.119.oe2403.x86_64.rpm",
          "kernel-6.6.0-138.0.0.119.oe2403.x86_64.rpm",
          "kernel-debuginfo-6.6.0-138.0.0.119.oe2403.x86_64.rpm",
          "kernel-debugsource-6.6.0-138.0.0.119.oe2403.x86_64.rpm",
          "kernel-devel-6.6.0-138.0.0.119.oe2403.x86_64.rpm",
          "kernel-headers-6.6.0-138.0.0.119.oe2403.x86_64.rpm",
          "kernel-source-6.6.0-138.0.0.119.oe2403.x86_64.rpm",
          "kernel-tools-6.6.0-138.0.0.119.oe2403.x86_64.rpm",
          "kernel-tools-debuginfo-6.6.0-138.0.0.119.oe2403.x86_64.rpm",
          "kernel-tools-devel-6.6.0-138.0.0.119.oe2403.x86_64.rpm",
          "perf-6.6.0-138.0.0.119.oe2403.x86_64.rpm",
          "perf-debuginfo-6.6.0-138.0.0.119.oe2403.x86_64.rpm",
          "python3-perf-6.6.0-138.0.0.119.oe2403.x86_64.rpm",
          "python3-perf-debuginfo-6.6.0-138.0.0.119.oe2403.x86_64.rpm"
        ]
      },
      "package": {
        "ecosystem": "openEuler:24.03-LTS",
        "name": "kernel",
        "purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-24.03-LTS"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "6.6.0-138.0.0.119.oe2403"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "database_specific": {
    "severity": "High"
  },
  "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\nptr_ring: do not block hard interrupts in ptr_ring_resize_multiple()\n\nJakub added a lockdep_assert_no_hardirq() check in __page_pool_put_page()\nto increase test coverage.\n\nsyzbot found a splat caused by hard irq blocking in\nptr_ring_resize_multiple() [1]\n\nAs current users of ptr_ring_resize_multiple() do not require\nhard irqs being masked, replace it to only block BH.\n\nRename helpers to better reflect they are safe against BH only.\n\n- ptr_ring_resize_multiple() to ptr_ring_resize_multiple_bh()\n- skb_array_resize_multiple() to skb_array_resize_multiple_bh()\n\n[1]\n\nWARNING: CPU: 1 PID: 9150 at net/core/page_pool.c:709 __page_pool_put_page net/core/page_pool.c:709 [inline]\nWARNING: CPU: 1 PID: 9150 at net/core/page_pool.c:709 page_pool_put_unrefed_netmem+0x157/0xa40 net/core/page_pool.c:780\nModules linked in:\nCPU: 1 UID: 0 PID: 9150 Comm: syz.1.1052 Not tainted 6.11.0-rc3-syzkaller-00202-gf8669d7b5f5d #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024\nRIP: 0010:__page_pool_put_page net/core/page_pool.c:709 [inline]\nRIP: 0010:page_pool_put_unrefed_netmem+0x157/0xa40 net/core/page_pool.c:780\nCode: 74 0e e8 7c aa fb f7 eb 43 e8 75 aa fb f7 eb 3c 65 8b 1d 38 a8 6a 76 31 ff 89 de e8 a3 ae fb f7 85 db 74 0b e8 5a aa fb f7 90 \u0026lt;0f\u0026gt; 0b 90 eb 1d 65 8b 1d 15 a8 6a 76 31 ff 89 de e8 84 ae fb f7 85\nRSP: 0018:ffffc9000bda6b58 EFLAGS: 00010083\nRAX: ffffffff8997e523 RBX: 0000000000000000 RCX: 0000000000040000\nRDX: ffffc9000fbd0000 RSI: 0000000000001842 RDI: 0000000000001843\nRBP: 0000000000000000 R08: ffffffff8997df2c R09: 1ffffd40003a000d\nR10: dffffc0000000000 R11: fffff940003a000e R12: ffffea0001d00040\nR13: ffff88802e8a4000 R14: dffffc0000000000 R15: 00000000ffffffff\nFS:  00007fb7aaf716c0(0000) GS:ffff8880b9300000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007fa15a0d4b72 CR3: 00000000561b0000 CR4: 00000000003506f0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n \u0026lt;TASK\u0026gt;\n tun_ptr_free drivers/net/tun.c:617 [inline]\n __ptr_ring_swap_queue include/linux/ptr_ring.h:571 [inline]\n ptr_ring_resize_multiple_noprof include/linux/ptr_ring.h:643 [inline]\n tun_queue_resize drivers/net/tun.c:3694 [inline]\n tun_device_event+0xaaf/0x1080 drivers/net/tun.c:3714\n notifier_call_chain+0x19f/0x3e0 kernel/notifier.c:93\n call_netdevice_notifiers_extack net/core/dev.c:2032 [inline]\n call_netdevice_notifiers net/core/dev.c:2046 [inline]\n dev_change_tx_queue_len+0x158/0x2a0 net/core/dev.c:9024\n do_setlink+0xff6/0x41f0 net/core/rtnetlink.c:2923\n rtnl_setlink+0x40d/0x5a0 net/core/rtnetlink.c:3201\n rtnetlink_rcv_msg+0x73f/0xcf0 net/core/rtnetlink.c:6647\n netlink_rcv_skb+0x1e3/0x430 net/netlink/af_netlink.c:2550(CVE-2024-57994)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nASoC: SOF: Intel: hda-dai: Ensure DAI widget is valid during params\n\nEach cpu DAI should associate with a widget. However, the topology might\nnot create the right number of DAI widgets for aggregated amps. And it\nwill cause NULL pointer deference.\nCheck that the DAI widget associated with the CPU DAI is valid to prevent\nNULL pointer deference due to missing DAI widgets in topologies with\naggregated amps.(CVE-2024-58012)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndriver core: fix potential NULL pointer dereference in dev_uevent()\n\nIf userspace reads \u0026quot;uevent\u0026quot; device attribute at the same time as another\nthreads unbinds the device from its driver, change to dev-\u0026gt;driver from a\nvalid pointer to NULL may result in crash. Fix this by using READ_ONCE()\nwhen fetching the pointer, and take bus\u0026apos; drivers klist lock to make sure\ndriver instance will not disappear while we access it.\n\nUse WRITE_ONCE() when setting the driver pointer to ensure there is no\ntearing.(CVE-2025-37800)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/mdiobus: Fix potential out-of-bounds clause 45 read/write access\n\nWhen using publicly available tools like \u0026apos;mdio-tools\u0026apos; to read/write data\nfrom/to network interface and its PHY via C45 (clause 45) mdiobus,\nthere is no verification of parameters passed to the ioctl and\nit accepts any mdio address.\nCurrently there is support for 32 addresses in kernel via PHY_MAX_ADDR define,\nbut it is possible to pass higher value than that via ioctl.\nWhile read/write operation should generally fail in this case,\nmdiobus provides stats array, where wrong address may allow out-of-bounds\nread/write.\n\nFix that by adding address verification before C45 read/write operation.\nWhile this excludes this access from any statistics, it improves security of\nread/write operation.(CVE-2025-38110)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/mdiobus: Fix potential out-of-bounds read/write access\n\nWhen using publicly available tools like \u0026apos;mdio-tools\u0026apos; to read/write data\nfrom/to network interface and its PHY via mdiobus, there is no verification of\nparameters passed to the ioctl and it accepts any mdio address.\nCurrently there is support for 32 addresses in kernel via PHY_MAX_ADDR define,\nbut it is possible to pass higher value than that via ioctl.\nWhile read/write operation should generally fail in this case,\nmdiobus provides stats array, where wrong address may allow out-of-bounds\nread/write.\n\nFix that by adding address verification before read/write operation.\nWhile this excludes this access from any statistics, it improves security of\nread/write operation.(CVE-2025-38111)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: phy: clear phydev-\u0026gt;devlink when the link is deleted\n\nThere is a potential crash issue when disabling and re-enabling the\nnetwork port. When disabling the network port, phy_detach() calls\ndevice_link_del() to remove the device link, but it does not clear\nphydev-\u0026gt;devlink, so phydev-\u0026gt;devlink is not a NULL pointer. Then the\nnetwork port is re-enabled, but if phy_attach_direct() fails before\ncalling device_link_add(), the code jumps to the \u0026quot;error\u0026quot; label and\ncalls phy_detach(). Since phydev-\u0026gt;devlink retains the old value from\nthe previous attach/detach cycle, device_link_del() uses the old value,\nwhich accesses a NULL pointer and causes a crash. The simplified crash\nlog is as follows.\n\n[   24.702421] Call trace:\n[   24.704856]  device_link_put_kref+0x20/0x120\n[   24.709124]  device_link_del+0x30/0x48\n[   24.712864]  phy_detach+0x24/0x168\n[   24.716261]  phy_attach_direct+0x168/0x3a4\n[   24.720352]  phylink_fwnode_phy_connect+0xc8/0x14c\n[   24.725140]  phylink_of_phy_connect+0x1c/0x34\n\nTherefore, phydev-\u0026gt;devlink needs to be cleared when the device link is\ndeleted.(CVE-2025-38149)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nft_set_pipapo: prevent overflow in lookup table allocation\n\nWhen calculating the lookup table size, ensure the following\nmultiplication does not overflow:\n\n- desc-\u0026gt;field_len[] maximum value is U8_MAX multiplied by\n  NFT_PIPAPO_GROUPS_PER_BYTE(f) that can be 2, worst case.\n- NFT_PIPAPO_BUCKETS(f-\u0026gt;bb) is 2^8, worst case.\n- sizeof(unsigned long), from sizeof(*f-\u0026gt;lt), lt in\n  struct nft_pipapo_field.\n\nThen, use check_mul_overflow() to multiply by bucket size and then use\ncheck_add_overflow() to the alignment for avx2 (if needed). Finally, add\nlt_size_check_overflow() helper and use it to consolidate this.\n\nWhile at it, replace leftover allocation using the GFP_KERNEL to\nGFP_KERNEL_ACCOUNT for consistency, in pipapo_resize().(CVE-2025-38162)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: add NULL check in automount_fullpath\n\npage is checked for null in __build_path_from_dentry_optional_prefix\nwhen tcon-\u0026gt;origin_fullpath is not set. However, the check is missing when\nit is set.\nAdd a check to prevent a potential NULL pointer dereference.(CVE-2025-38208)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nNFSD: fix race between nfsd registration and exports_proc\n\nAs of now nfsd calls create_proc_exports_entry() at start of init_nfsd\nand cleanup by remove_proc_entry() at last of exit_nfsd.\n\nWhich causes kernel OOPs if there is race between below 2 operations:\n(i) exportfs -r\n(ii) mount -t nfsd none /proc/fs/nfsd\n\nfor 5.4 kernel ARM64:\n\nCPU 1:\nel1_irq+0xbc/0x180\narch_counter_get_cntvct+0x14/0x18\nrunning_clock+0xc/0x18\npreempt_count_add+0x88/0x110\nprep_new_page+0xb0/0x220\nget_page_from_freelist+0x2d8/0x1778\n__alloc_pages_nodemask+0x15c/0xef0\n__vmalloc_node_range+0x28c/0x478\n__vmalloc_node_flags_caller+0x8c/0xb0\nkvmalloc_node+0x88/0xe0\nnfsd_init_net+0x6c/0x108 [nfsd]\nops_init+0x44/0x170\nregister_pernet_operations+0x114/0x270\nregister_pernet_subsys+0x34/0x50\ninit_nfsd+0xa8/0x718 [nfsd]\ndo_one_initcall+0x54/0x2e0\n\nCPU 2 :\nUnable to handle kernel NULL pointer dereference at virtual address 0000000000000010\n\nPC is at : exports_net_open+0x50/0x68 [nfsd]\n\nCall trace:\nexports_net_open+0x50/0x68 [nfsd]\nexports_proc_open+0x2c/0x38 [nfsd]\nproc_reg_open+0xb8/0x198\ndo_dentry_open+0x1c4/0x418\nvfs_open+0x38/0x48\npath_openat+0x28c/0xf18\ndo_filp_open+0x70/0xe8\ndo_sys_open+0x154/0x248\n\nSometimes it crashes at exports_net_open() and sometimes cache_seq_next_rcu().\n\nand same is happening on latest 6.14 kernel as well:\n\n[    0.000000] Linux version 6.14.0-rc5-next-20250304-dirty\n...\n[  285.455918] Unable to handle kernel paging request at virtual address 00001f4800001f48\n...\n[  285.464902] pc : cache_seq_next_rcu+0x78/0xa4\n...\n[  285.469695] Call trace:\n[  285.470083]  cache_seq_next_rcu+0x78/0xa4 (P)\n[  285.470488]  seq_read+0xe0/0x11c\n[  285.470675]  proc_reg_read+0x9c/0xf0\n[  285.470874]  vfs_read+0xc4/0x2fc\n[  285.471057]  ksys_read+0x6c/0xf4\n[  285.471231]  __arm64_sys_read+0x1c/0x28\n[  285.471428]  invoke_syscall+0x44/0x100\n[  285.471633]  el0_svc_common.constprop.0+0x40/0xe0\n[  285.471870]  do_el0_svc_compat+0x1c/0x34\n[  285.472073]  el0_svc_compat+0x2c/0x80\n[  285.472265]  el0t_32_sync_handler+0x90/0x140\n[  285.472473]  el0t_32_sync+0x19c/0x1a0\n[  285.472887] Code: f9400885 93407c23 937d7c27 11000421 (f86378a3)\n[  285.473422] ---[ end trace 0000000000000000 ]---\n\nIt reproduced simply with below script:\nwhile [ 1 ]\ndo\n/exportfs -r\ndone \u0026amp;\n\nwhile [ 1 ]\ndo\ninsmod /nfsd.ko\nmount -t nfsd none /proc/fs/nfsd\numount /proc/fs/nfsd\nrmmod nfsd\ndone \u0026amp;\n\nSo exporting interfaces to user space shall be done at last and\ncleanup at first place.\n\nWith change there is no Kernel OOPs.(CVE-2025-38232)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: fix potential deadlock when reconnecting channels\n\nFix cifs_signal_cifsd_for_reconnect() to take the correct lock order\nand prevent the following deadlock from happening\n\n======================================================\nWARNING: possible circular locking dependency detected\n6.16.0-rc3-build2+ #1301 Tainted: G S      W\n------------------------------------------------------\ncifsd/6055 is trying to acquire lock:\nffff88810ad56038 (\u0026amp;tcp_ses-\u0026gt;srv_lock){+.+.}-{3:3}, at: cifs_signal_cifsd_for_reconnect+0x134/0x200\n\nbut task is already holding lock:\nffff888119c64330 (\u0026amp;ret_buf-\u0026gt;chan_lock){+.+.}-{3:3}, at: cifs_signal_cifsd_for_reconnect+0xcf/0x200\n\nwhich lock already depends on the new lock.\n\nthe existing dependency chain (in reverse order) is:\n\n-\u0026gt; #2 (\u0026amp;ret_buf-\u0026gt;chan_lock){+.+.}-{3:3}:\n       validate_chain+0x1cf/0x270\n       __lock_acquire+0x60e/0x780\n       lock_acquire.part.0+0xb4/0x1f0\n       _raw_spin_lock+0x2f/0x40\n       cifs_setup_session+0x81/0x4b0\n       cifs_get_smb_ses+0x771/0x900\n       cifs_mount_get_session+0x7e/0x170\n       cifs_mount+0x92/0x2d0\n       cifs_smb3_do_mount+0x161/0x460\n       smb3_get_tree+0x55/0x90\n       vfs_get_tree+0x46/0x180\n       do_new_mount+0x1b0/0x2e0\n       path_mount+0x6ee/0x740\n       do_mount+0x98/0xe0\n       __do_sys_mount+0x148/0x180\n       do_syscall_64+0xa4/0x260\n       entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\n-\u0026gt; #1 (\u0026amp;ret_buf-\u0026gt;ses_lock){+.+.}-{3:3}:\n       validate_chain+0x1cf/0x270\n       __lock_acquire+0x60e/0x780\n       lock_acquire.part.0+0xb4/0x1f0\n       _raw_spin_lock+0x2f/0x40\n       cifs_match_super+0x101/0x320\n       sget+0xab/0x270\n       cifs_smb3_do_mount+0x1e0/0x460\n       smb3_get_tree+0x55/0x90\n       vfs_get_tree+0x46/0x180\n       do_new_mount+0x1b0/0x2e0\n       path_mount+0x6ee/0x740\n       do_mount+0x98/0xe0\n       __do_sys_mount+0x148/0x180\n       do_syscall_64+0xa4/0x260\n       entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\n-\u0026gt; #0 (\u0026amp;tcp_ses-\u0026gt;srv_lock){+.+.}-{3:3}:\n       check_noncircular+0x95/0xc0\n       check_prev_add+0x115/0x2f0\n       validate_chain+0x1cf/0x270\n       __lock_acquire+0x60e/0x780\n       lock_acquire.part.0+0xb4/0x1f0\n       _raw_spin_lock+0x2f/0x40\n       cifs_signal_cifsd_for_reconnect+0x134/0x200\n       __cifs_reconnect+0x8f/0x500\n       cifs_handle_standard+0x112/0x280\n       cifs_demultiplex_thread+0x64d/0xbc0\n       kthread+0x2f7/0x310\n       ret_from_fork+0x2a/0x230\n       ret_from_fork_asm+0x1a/0x30\n\nother info that might help us debug this:\n\nChain exists of:\n  \u0026amp;tcp_ses-\u0026gt;srv_lock --\u0026gt; \u0026amp;ret_buf-\u0026gt;ses_lock --\u0026gt; \u0026amp;ret_buf-\u0026gt;chan_lock\n\n Possible unsafe locking scenario:\n\n       CPU0                    CPU1\n       ----                    ----\n  lock(\u0026amp;ret_buf-\u0026gt;chan_lock);\n                               lock(\u0026amp;ret_buf-\u0026gt;ses_lock);\n                               lock(\u0026amp;ret_buf-\u0026gt;chan_lock);\n  lock(\u0026amp;tcp_ses-\u0026gt;srv_lock);\n\n *** DEADLOCK ***\n\n3 locks held by cifsd/6055:\n #0: ffffffff857de398 (\u0026amp;cifs_tcp_ses_lock){+.+.}-{3:3}, at: cifs_signal_cifsd_for_reconnect+0x7b/0x200\n #1: ffff888119c64060 (\u0026amp;ret_buf-\u0026gt;ses_lock){+.+.}-{3:3}, at: cifs_signal_cifsd_for_reconnect+0x9c/0x200\n #2: ffff888119c64330 (\u0026amp;ret_buf-\u0026gt;chan_lock){+.+.}-{3:3}, at: cifs_signal_cifsd_for_reconnect+0xcf/0x200(CVE-2025-38244)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: eir: Fix possible crashes on eir_create_adv_data\n\neir_create_adv_data may attempt to add EIR_FLAGS and EIR_TX_POWER\nwithout checking if that would fit.(CVE-2025-38303)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsoftware node: Correct a OOB check in software_node_get_reference_args()\n\nsoftware_node_get_reference_args() wants to get @index-th element, so\nthe property value requires at least \u0026apos;(index + 1) * sizeof(*ref)\u0026apos; bytes\nbut that can not be guaranteed by current OOB check, and may cause OOB\nfor malformed property.\n\nFix by using as OOB check \u0026apos;((index + 1) * sizeof(*ref) \u0026gt; prop-\u0026gt;length)\u0026apos;.(CVE-2025-38342)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nNFSv4/pNFS: Fix a race to wake on NFS_LAYOUT_DRAIN\n\nWe found a few different systems hung up in writeback waiting on the same\npage lock, and one task waiting on the NFS_LAYOUT_DRAIN bit in\npnfs_update_layout(), however the pnfs_layout_hdr\u0026apos;s plh_outstanding count\nwas zero.\n\nIt seems most likely that this is another race between the waiter and waker\nsimilar to commit ed0172af5d6f (\u0026quot;SUNRPC: Fix a race to wake a sync task\u0026quot;).\nFix it up by applying the advised barrier.(CVE-2025-38393)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nKVM: SVM: Reject SEV{-ES} intra host migration if vCPU creation is in-flight\n\nReject migration of SEV{-ES} state if either the source or destination VM\nis actively creating a vCPU, i.e. if kvm_vm_ioctl_create_vcpu() is in the\nsection between incrementing created_vcpus and online_vcpus.  The bulk of\nvCPU creation runs _outside_ of kvm-\u0026gt;lock to allow creating multiple vCPUs\nin parallel, and so sev_info.es_active can get toggled from false=\u0026gt;true in\nthe destination VM after (or during) svm_vcpu_create(), resulting in an\nSEV{-ES} VM effectively having a non-SEV{-ES} vCPU.\n\nThe issue manifests most visibly as a crash when trying to free a vCPU\u0026apos;s\nNULL VMSA page in an SEV-ES VM, but any number of things can go wrong.\n\n  BUG: unable to handle page fault for address: ffffebde00000000\n  #PF: supervisor read access in kernel mode\n  #PF: error_code(0x0000) - not-present page\n  PGD 0 P4D 0\n  Oops: Oops: 0000 [#1] SMP KASAN NOPTI\n  CPU: 227 UID: 0 PID: 64063 Comm: syz.5.60023 Tainted: G     U     O        6.15.0-smp-DEV #2 NONE\n  Tainted: [U]=USER, [O]=OOT_MODULE\n  Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 12.52.0-0 10/28/2024\n  RIP: 0010:constant_test_bit arch/x86/include/asm/bitops.h:206 [inline]\n  RIP: 0010:arch_test_bit arch/x86/include/asm/bitops.h:238 [inline]\n  RIP: 0010:_test_bit include/asm-generic/bitops/instrumented-non-atomic.h:142 [inline]\n  RIP: 0010:PageHead include/linux/page-flags.h:866 [inline]\n  RIP: 0010:___free_pages+0x3e/0x120 mm/page_alloc.c:5067\n  Code: \u0026lt;49\u0026gt; f7 06 40 00 00 00 75 05 45 31 ff eb 0c 66 90 4c 89 f0 4c 39 f0\n  RSP: 0018:ffff8984551978d0 EFLAGS: 00010246\n  RAX: 0000777f80000001 RBX: 0000000000000000 RCX: ffffffff918aeb98\n  RDX: 0000000000000000 RSI: 0000000000000008 RDI: ffffebde00000000\n  RBP: 0000000000000000 R08: ffffebde00000007 R09: 1ffffd7bc0000000\n  R10: dffffc0000000000 R11: fffff97bc0000001 R12: dffffc0000000000\n  R13: ffff8983e19751a8 R14: ffffebde00000000 R15: 1ffffd7bc0000000\n  FS:  0000000000000000(0000) GS:ffff89ee661d3000(0000) knlGS:0000000000000000\n  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n  CR2: ffffebde00000000 CR3: 000000793ceaa000 CR4: 0000000000350ef0\n  DR0: 0000000000000000 DR1: 0000000000000b5f DR2: 0000000000000000\n  DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400\n  Call Trace:\n   \u0026lt;TASK\u0026gt;\n   sev_free_vcpu+0x413/0x630 arch/x86/kvm/svm/sev.c:3169\n   svm_vcpu_free+0x13a/0x2a0 arch/x86/kvm/svm/svm.c:1515\n   kvm_arch_vcpu_destroy+0x6a/0x1d0 arch/x86/kvm/x86.c:12396\n   kvm_vcpu_destroy virt/kvm/kvm_main.c:470 [inline]\n   kvm_destroy_vcpus+0xd1/0x300 virt/kvm/kvm_main.c:490\n   kvm_arch_destroy_vm+0x636/0x820 arch/x86/kvm/x86.c:12895\n   kvm_put_kvm+0xb8e/0xfb0 virt/kvm/kvm_main.c:1310\n   kvm_vm_release+0x48/0x60 virt/kvm/kvm_main.c:1369\n   __fput+0x3e4/0x9e0 fs/file_table.c:465\n   task_work_run+0x1a9/0x220 kernel/task_work.c:227\n   exit_task_work include/linux/task_work.h:40 [inline]\n   do_exit+0x7f0/0x25b0 kernel/exit.c:953\n   do_group_exit+0x203/0x2d0 kernel/exit.c:1102\n   get_signal+0x1357/0x1480 kernel/signal.c:3034\n   arch_do_signal_or_restart+0x40/0x690 arch/x86/kernel/signal.c:337\n   exit_to_user_mode_loop kernel/entry/common.c:111 [inline]\n   exit_to_user_mode_prepare include/linux/entry-common.h:329 [inline]\n   __syscall_exit_to_user_mode_work kernel/entry/common.c:207 [inline]\n   syscall_exit_to_user_mode+0x67/0xb0 kernel/entry/common.c:218\n   do_syscall_64+0x7c/0x150 arch/x86/entry/syscall_64.c:100\n   entry_SYSCALL_64_after_hwframe+0x76/0x7e\n  RIP: 0033:0x7f87a898e969\n   \u0026lt;/TASK\u0026gt;\n  Modules linked in: gq(O)\n  gsmi: Log Shutdown Reason 0x03\n  CR2: ffffebde00000000\n  ---[ end trace 0000000000000000 ]---\n\nDeliberately don\u0026apos;t check for a NULL VMSA when freeing the vCPU, as crashing\nthe host is likely desirable due to the VMSA being consumed by hardware.\nE.g. if KVM manages to allow VMRUN on the vCPU, hardware may read/write a\nbogus VMSA page.  Accessing P\n---truncated---(CVE-2025-38455)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ns390/bpf: Fix bpf_arch_text_poke() with new_addr == NULL again\n\nCommit 7ded842b356d (\u0026quot;s390/bpf: Fix bpf_plt pointer arithmetic\u0026quot;) has\naccidentally removed the critical piece of commit c730fce7c70c\n(\u0026quot;s390/bpf: Fix bpf_arch_text_poke() with new_addr == NULL\u0026quot;), causing\nintermittent kernel panics in e.g. perf\u0026apos;s on_switch() prog to reappear.\n\nRestore the fix and add a comment.(CVE-2025-38489)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\niommu/amd: Avoid stack buffer overflow from kernel cmdline\n\nWhile the kernel command line is considered trusted in most environments,\navoid writing 1 byte past the end of \u0026quot;acpiid\u0026quot; if the \u0026quot;str\u0026quot; argument is\nmaximum length.(CVE-2025-38676)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\niommufd: Prevent ALIGN() overflow\n\nWhen allocating IOVA the candidate range gets aligned to the target\nalignment. If the range is close to ULONG_MAX then the ALIGN() can\nwrap resulting in a corrupted iova.\n\nOpen code the ALIGN() using get_add_overflow() to prevent this.\nThis simplifies the checks as we don\u0026apos;t need to check for length earlier\neither.\n\nConsolidate the two copies of this code under a single helper.\n\nThis bug would allow userspace to create a mapping that overlaps with some\nother mapping or a reserved range.(CVE-2025-38688)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\njfs: upper bound check of tree index in dbAllocAG\n\nWhen computing the tree index in dbAllocAG, we never check if we are\nout of bounds realative to the size of the stree.\nThis could happen in a scenario where the filesystem metadata are\ncorrupted.(CVE-2025-38697)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nhfsplus: don\u0026apos;t use BUG_ON() in hfsplus_create_attributes_file()\n\nWhen the volume header contains erroneous values that do not reflect\nthe actual state of the filesystem, hfsplus_fill_super() assumes that\nthe attributes file is not yet created, which later results in hitting\nBUG_ON() when hfsplus_create_attributes_file() is called. Replace this\nBUG_ON() with -EIO error with a message to suggest running fsck tool.(CVE-2025-38712)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nhfsplus: fix slab-out-of-bounds read in hfsplus_uni2asc()\n\nThe hfsplus_readdir() method is capable to crash by calling\nhfsplus_uni2asc():\n\n[  667.121659][ T9805] ==================================================================\n[  667.122651][ T9805] BUG: KASAN: slab-out-of-bounds in hfsplus_uni2asc+0x902/0xa10\n[  667.123627][ T9805] Read of size 2 at addr ffff88802592f40c by task repro/9805\n[  667.124578][ T9805]\n[  667.124876][ T9805] CPU: 3 UID: 0 PID: 9805 Comm: repro Not tainted 6.16.0-rc3 #1 PREEMPT(full)\n[  667.124886][ T9805] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014\n[  667.124890][ T9805] Call Trace:\n[  667.124893][ T9805]  \u0026lt;TASK\u0026gt;\n[  667.124896][ T9805]  dump_stack_lvl+0x10e/0x1f0\n[  667.124911][ T9805]  print_report+0xd0/0x660\n[  667.124920][ T9805]  ? __virt_addr_valid+0x81/0x610\n[  667.124928][ T9805]  ? __phys_addr+0xe8/0x180\n[  667.124934][ T9805]  ? hfsplus_uni2asc+0x902/0xa10\n[  667.124942][ T9805]  kasan_report+0xc6/0x100\n[  667.124950][ T9805]  ? hfsplus_uni2asc+0x902/0xa10\n[  667.124959][ T9805]  hfsplus_uni2asc+0x902/0xa10\n[  667.124966][ T9805]  ? hfsplus_bnode_read+0x14b/0x360\n[  667.124974][ T9805]  hfsplus_readdir+0x845/0xfc0\n[  667.124984][ T9805]  ? __pfx_hfsplus_readdir+0x10/0x10\n[  667.124994][ T9805]  ? stack_trace_save+0x8e/0xc0\n[  667.125008][ T9805]  ? iterate_dir+0x18b/0xb20\n[  667.125015][ T9805]  ? trace_lock_acquire+0x85/0xd0\n[  667.125022][ T9805]  ? lock_acquire+0x30/0x80\n[  667.125029][ T9805]  ? iterate_dir+0x18b/0xb20\n[  667.125037][ T9805]  ? down_read_killable+0x1ed/0x4c0\n[  667.125044][ T9805]  ? putname+0x154/0x1a0\n[  667.125051][ T9805]  ? __pfx_down_read_killable+0x10/0x10\n[  667.125058][ T9805]  ? apparmor_file_permission+0x239/0x3e0\n[  667.125069][ T9805]  iterate_dir+0x296/0xb20\n[  667.125076][ T9805]  __x64_sys_getdents64+0x13c/0x2c0\n[  667.125084][ T9805]  ? __pfx___x64_sys_getdents64+0x10/0x10\n[  667.125091][ T9805]  ? __x64_sys_openat+0x141/0x200\n[  667.125126][ T9805]  ? __pfx_filldir64+0x10/0x10\n[  667.125134][ T9805]  ? do_user_addr_fault+0x7fe/0x12f0\n[  667.125143][ T9805]  do_syscall_64+0xc9/0x480\n[  667.125151][ T9805]  entry_SYSCALL_64_after_hwframe+0x77/0x7f\n[  667.125158][ T9805] RIP: 0033:0x7fa8753b2fc9\n[  667.125164][ T9805] Code: 00 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 48\n[  667.125172][ T9805] RSP: 002b:00007ffe96f8e0f8 EFLAGS: 00000217 ORIG_RAX: 00000000000000d9\n[  667.125181][ T9805] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fa8753b2fc9\n[  667.125185][ T9805] RDX: 0000000000000400 RSI: 00002000000063c0 RDI: 0000000000000004\n[  667.125190][ T9805] RBP: 00007ffe96f8e110 R08: 00007ffe96f8e110 R09: 00007ffe96f8e110\n[  667.125195][ T9805] R10: 0000000000000000 R11: 0000000000000217 R12: 0000556b1e3b4260\n[  667.125199][ T9805] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000\n[  667.125207][ T9805]  \u0026lt;/TASK\u0026gt;\n[  667.125210][ T9805]\n[  667.145632][ T9805] Allocated by task 9805:\n[  667.145991][ T9805]  kasan_save_stack+0x20/0x40\n[  667.146352][ T9805]  kasan_save_track+0x14/0x30\n[  667.146717][ T9805]  __kasan_kmalloc+0xaa/0xb0\n[  667.147065][ T9805]  __kmalloc_noprof+0x205/0x550\n[  667.147448][ T9805]  hfsplus_find_init+0x95/0x1f0\n[  667.147813][ T9805]  hfsplus_readdir+0x220/0xfc0\n[  667.148174][ T9805]  iterate_dir+0x296/0xb20\n[  667.148549][ T9805]  __x64_sys_getdents64+0x13c/0x2c0\n[  667.148937][ T9805]  do_syscall_64+0xc9/0x480\n[  667.149291][ T9805]  entry_SYSCALL_64_after_hwframe+0x77/0x7f\n[  667.149809][ T9805]\n[  667.150030][ T9805] The buggy address belongs to the object at ffff88802592f000\n[  667.150030][ T9805]  which belongs to the cache kmalloc-2k of size 2048\n[  667.151282][ T9805] The buggy address is located 0 bytes to the right of\n[  667.151282][ T9805]  allocated 1036-byte region [ffff88802592f000, ffff88802592f40c)\n[  667.1\n---truncated---(CVE-2025-38713)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nhfsplus: fix slab-out-of-bounds in hfsplus_bnode_read()\n\nThe hfsplus_bnode_read() method can trigger the issue:\n\n[  174.852007][ T9784] ==================================================================\n[  174.852709][ T9784] BUG: KASAN: slab-out-of-bounds in hfsplus_bnode_read+0x2f4/0x360\n[  174.853412][ T9784] Read of size 8 at addr ffff88810b5fc6c0 by task repro/9784\n[  174.854059][ T9784]\n[  174.854272][ T9784] CPU: 1 UID: 0 PID: 9784 Comm: repro Not tainted 6.16.0-rc3 #7 PREEMPT(full)\n[  174.854281][ T9784] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014\n[  174.854286][ T9784] Call Trace:\n[  174.854289][ T9784]  \u0026lt;TASK\u0026gt;\n[  174.854292][ T9784]  dump_stack_lvl+0x10e/0x1f0\n[  174.854305][ T9784]  print_report+0xd0/0x660\n[  174.854315][ T9784]  ? __virt_addr_valid+0x81/0x610\n[  174.854323][ T9784]  ? __phys_addr+0xe8/0x180\n[  174.854330][ T9784]  ? hfsplus_bnode_read+0x2f4/0x360\n[  174.854337][ T9784]  kasan_report+0xc6/0x100\n[  174.854346][ T9784]  ? hfsplus_bnode_read+0x2f4/0x360\n[  174.854354][ T9784]  hfsplus_bnode_read+0x2f4/0x360\n[  174.854362][ T9784]  hfsplus_bnode_dump+0x2ec/0x380\n[  174.854370][ T9784]  ? __pfx_hfsplus_bnode_dump+0x10/0x10\n[  174.854377][ T9784]  ? hfsplus_bnode_write_u16+0x83/0xb0\n[  174.854385][ T9784]  ? srcu_gp_start+0xd0/0x310\n[  174.854393][ T9784]  ? __mark_inode_dirty+0x29e/0xe40\n[  174.854402][ T9784]  hfsplus_brec_remove+0x3d2/0x4e0\n[  174.854411][ T9784]  __hfsplus_delete_attr+0x290/0x3a0\n[  174.854419][ T9784]  ? __pfx_hfs_find_1st_rec_by_cnid+0x10/0x10\n[  174.854427][ T9784]  ? __pfx___hfsplus_delete_attr+0x10/0x10\n[  174.854436][ T9784]  ? __asan_memset+0x23/0x50\n[  174.854450][ T9784]  hfsplus_delete_all_attrs+0x262/0x320\n[  174.854459][ T9784]  ? __pfx_hfsplus_delete_all_attrs+0x10/0x10\n[  174.854469][ T9784]  ? rcu_is_watching+0x12/0xc0\n[  174.854476][ T9784]  ? __mark_inode_dirty+0x29e/0xe40\n[  174.854483][ T9784]  hfsplus_delete_cat+0x845/0xde0\n[  174.854493][ T9784]  ? __pfx_hfsplus_delete_cat+0x10/0x10\n[  174.854507][ T9784]  hfsplus_unlink+0x1ca/0x7c0\n[  174.854516][ T9784]  ? __pfx_hfsplus_unlink+0x10/0x10\n[  174.854525][ T9784]  ? down_write+0x148/0x200\n[  174.854532][ T9784]  ? __pfx_down_write+0x10/0x10\n[  174.854540][ T9784]  vfs_unlink+0x2fe/0x9b0\n[  174.854549][ T9784]  do_unlinkat+0x490/0x670\n[  174.854557][ T9784]  ? __pfx_do_unlinkat+0x10/0x10\n[  174.854565][ T9784]  ? __might_fault+0xbc/0x130\n[  174.854576][ T9784]  ? getname_flags.part.0+0x1c5/0x550\n[  174.854584][ T9784]  __x64_sys_unlink+0xc5/0x110\n[  174.854592][ T9784]  do_syscall_64+0xc9/0x480\n[  174.854600][ T9784]  entry_SYSCALL_64_after_hwframe+0x77/0x7f\n[  174.854608][ T9784] RIP: 0033:0x7f6fdf4c3167\n[  174.854614][ T9784] Code: f0 ff ff 73 01 c3 48 8b 0d 26 0d 0e 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 08\n[  174.854622][ T9784] RSP: 002b:00007ffcb948bca8 EFLAGS: 00000206 ORIG_RAX: 0000000000000057\n[  174.854630][ T9784] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f6fdf4c3167\n[  174.854636][ T9784] RDX: 00007ffcb948bcc0 RSI: 00007ffcb948bcc0 RDI: 00007ffcb948bd50\n[  174.854641][ T9784] RBP: 00007ffcb948cd90 R08: 0000000000000001 R09: 00007ffcb948bb40\n[  174.854645][ T9784] R10: 00007f6fdf564fc0 R11: 0000000000000206 R12: 0000561e1bc9c2d0\n[  174.854650][ T9784] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000\n[  174.854658][ T9784]  \u0026lt;/TASK\u0026gt;\n[  174.854661][ T9784]\n[  174.879281][ T9784] Allocated by task 9784:\n[  174.879664][ T9784]  kasan_save_stack+0x20/0x40\n[  174.880082][ T9784]  kasan_save_track+0x14/0x30\n[  174.880500][ T9784]  __kasan_kmalloc+0xaa/0xb0\n[  174.880908][ T9784]  __kmalloc_noprof+0x205/0x550\n[  174.881337][ T9784]  __hfs_bnode_create+0x107/0x890\n[  174.881779][ T9784]  hfsplus_bnode_find+0x2d0/0xd10\n[  174.882222][ T9784]  hfsplus_brec_find+0x2b0/0x520\n[  174.882659][ T9784]  hfsplus_delete_all_attrs+0x23b/0x3\n---truncated---(CVE-2025-38714)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmb3: fix for slab out of bounds on mount to ksmbd\n\nWith KASAN enabled, it is possible to get a slab out of bounds\nduring mount to ksmbd due to missing check in parse_server_interfaces()\n(see below):\n\n BUG: KASAN: slab-out-of-bounds in\n parse_server_interfaces+0x14ee/0x1880 [cifs]\n Read of size 4 at addr ffff8881433dba98 by task mount/9827\n\n CPU: 5 UID: 0 PID: 9827 Comm: mount Tainted: G\n OE       6.16.0-rc2-kasan #2 PREEMPT(voluntary)\n Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE\n Hardware name: Dell Inc. Precision Tower 3620/0MWYPT,\n BIOS 2.13.1 06/14/2019\n Call Trace:\n  \u0026lt;TASK\u0026gt;\n dump_stack_lvl+0x9f/0xf0\n print_report+0xd1/0x670\n __virt_addr_valid+0x22c/0x430\n ? parse_server_interfaces+0x14ee/0x1880 [cifs]\n ? kasan_complete_mode_report_info+0x2a/0x1f0\n ? parse_server_interfaces+0x14ee/0x1880 [cifs]\n   kasan_report+0xd6/0x110\n   parse_server_interfaces+0x14ee/0x1880 [cifs]\n   __asan_report_load_n_noabort+0x13/0x20\n   parse_server_interfaces+0x14ee/0x1880 [cifs]\n ? __pfx_parse_server_interfaces+0x10/0x10 [cifs]\n ? trace_hardirqs_on+0x51/0x60\n SMB3_request_interfaces+0x1ad/0x3f0 [cifs]\n ? __pfx_SMB3_request_interfaces+0x10/0x10 [cifs]\n ? SMB2_tcon+0x23c/0x15d0 [cifs]\n smb3_qfs_tcon+0x173/0x2b0 [cifs]\n ? __pfx_smb3_qfs_tcon+0x10/0x10 [cifs]\n ? cifs_get_tcon+0x105d/0x2120 [cifs]\n ? do_raw_spin_unlock+0x5d/0x200\n ? cifs_get_tcon+0x105d/0x2120 [cifs]\n ? __pfx_smb3_qfs_tcon+0x10/0x10 [cifs]\n cifs_mount_get_tcon+0x369/0xb90 [cifs]\n ? dfs_cache_find+0xe7/0x150 [cifs]\n dfs_mount_share+0x985/0x2970 [cifs]\n ? check_path.constprop.0+0x28/0x50\n ? save_trace+0x54/0x370\n ? __pfx_dfs_mount_share+0x10/0x10 [cifs]\n ? __lock_acquire+0xb82/0x2ba0\n ? __kasan_check_write+0x18/0x20\n cifs_mount+0xbc/0x9e0 [cifs]\n ? __pfx_cifs_mount+0x10/0x10 [cifs]\n ? do_raw_spin_unlock+0x5d/0x200\n ? cifs_setup_cifs_sb+0x29d/0x810 [cifs]\n cifs_smb3_do_mount+0x263/0x1990 [cifs](CVE-2025-38728)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: fix refcount leak causing resource not released\n\nWhen ksmbd_conn_releasing(opinfo-\u0026gt;conn) returns true,the refcount was not\ndecremented properly, causing a refcount leak that prevents the count from\nreaching zero and the memory from being released.(CVE-2025-39720)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: qat - flush misc workqueue during device shutdown\n\nRepeated loading and unloading of a device specific QAT driver, for\nexample qat_4xxx, in a tight loop can lead to a crash due to a\nuse-after-free scenario. This occurs when a power management (PM)\ninterrupt triggers just before the device-specific driver (e.g.,\nqat_4xxx.ko) is unloaded, while the core driver (intel_qat.ko) remains\nloaded.\n\nSince the driver uses a shared workqueue (`qat_misc_wq`) across all\ndevices and owned by intel_qat.ko, a deferred routine from the\ndevice-specific driver may still be pending in the queue. If this\nroutine executes after the driver is unloaded, it can dereference freed\nmemory, resulting in a page fault and kernel crash like the following:\n\n    BUG: unable to handle page fault for address: ffa000002e50a01c\n    #PF: supervisor read access in kernel mode\n    RIP: 0010:pm_bh_handler+0x1d2/0x250 [intel_qat]\n    Call Trace:\n      pm_bh_handler+0x1d2/0x250 [intel_qat]\n      process_one_work+0x171/0x340\n      worker_thread+0x277/0x3a0\n      kthread+0xf0/0x120\n      ret_from_fork+0x2d/0x50\n\nTo prevent this, flush the misc workqueue during device shutdown to\nensure that all pending work items are completed before the driver is\nunloaded.\n\nNote: This approach may slightly increase shutdown latency if the\nworkqueue contains jobs from other devices, but it ensures correctness\nand stability.(CVE-2025-39721)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nNFS: Fix filehandle bounds checking in nfs_fh_to_dentry()\n\nThe function needs to check the minimal filehandle length before it can\naccess the embedded filehandle.(CVE-2025-39730)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm/kmemleak: avoid soft lockup in __kmemleak_do_cleanup()\n\nA soft lockup warning was observed on a relative small system x86-64\nsystem with 16 GB of memory when running a debug kernel with kmemleak\nenabled.\n\n  watchdog: BUG: soft lockup - CPU#8 stuck for 33s! [kworker/8:1:134]\n\nThe test system was running a workload with hot unplug happening in\nparallel.  Then kemleak decided to disable itself due to its inability to\nallocate more kmemleak objects.  The debug kernel has its\nCONFIG_DEBUG_KMEMLEAK_MEM_POOL_SIZE set to 40,000.\n\nThe soft lockup happened in kmemleak_do_cleanup() when the existing\nkmemleak objects were being removed and deleted one-by-one in a loop via a\nworkqueue.  In this particular case, there are at least 40,000 objects\nthat need to be processed and given the slowness of a debug kernel and the\nfact that a raw_spinlock has to be acquired and released in\n__delete_object(), it could take a while to properly handle all these\nobjects.\n\nAs kmemleak has been disabled in this case, the object removal and\ndeletion process can be further optimized as locking isn\u0026apos;t really needed. \nHowever, it is probably not worth the effort to optimize for such an edge\ncase that should rarely happen.  So the simple solution is to call\ncond_resched() at periodic interval in the iteration loop to avoid soft\nlockup.(CVE-2025-39737)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nrcu: Protect -\u0026gt;defer_qs_iw_pending from data race\n\nOn kernels built with CONFIG_IRQ_WORK=y, when rcu_read_unlock() is\ninvoked within an interrupts-disabled region of code [1], it will invoke\nrcu_read_unlock_special(), which uses an irq-work handler to force the\nsystem to notice when the RCU read-side critical section actually ends.\nThat end won\u0026apos;t happen until interrupts are enabled at the soonest.\n\nIn some kernels, such as those booted with rcutree.use_softirq=y, the\nirq-work handler is used unconditionally.\n\nThe per-CPU rcu_data structure\u0026apos;s -\u0026gt;defer_qs_iw_pending field is\nupdated by the irq-work handler and is both read and updated by\nrcu_read_unlock_special().  This resulted in the following KCSAN splat:\n\n------------------------------------------------------------------------\n\nBUG: KCSAN: data-race in rcu_preempt_deferred_qs_handler / rcu_read_unlock_special\n\nread to 0xffff96b95f42d8d8 of 1 bytes by task 90 on cpu 8:\n rcu_read_unlock_special+0x175/0x260\n __rcu_read_unlock+0x92/0xa0\n rt_spin_unlock+0x9b/0xc0\n __local_bh_enable+0x10d/0x170\n __local_bh_enable_ip+0xfb/0x150\n rcu_do_batch+0x595/0xc40\n rcu_cpu_kthread+0x4e9/0x830\n smpboot_thread_fn+0x24d/0x3b0\n kthread+0x3bd/0x410\n ret_from_fork+0x35/0x40\n ret_from_fork_asm+0x1a/0x30\n\nwrite to 0xffff96b95f42d8d8 of 1 bytes by task 88 on cpu 8:\n rcu_preempt_deferred_qs_handler+0x1e/0x30\n irq_work_single+0xaf/0x160\n run_irq_workd+0x91/0xc0\n smpboot_thread_fn+0x24d/0x3b0\n kthread+0x3bd/0x410\n ret_from_fork+0x35/0x40\n ret_from_fork_asm+0x1a/0x30\n\nno locks held by irq_work/8/88.\nirq event stamp: 200272\nhardirqs last  enabled at (200272): [\u0026lt;ffffffffb0f56121\u0026gt;] finish_task_switch+0x131/0x320\nhardirqs last disabled at (200271): [\u0026lt;ffffffffb25c7859\u0026gt;] __schedule+0x129/0xd70\nsoftirqs last  enabled at (0): [\u0026lt;ffffffffb0ee093f\u0026gt;] copy_process+0x4df/0x1cc0\nsoftirqs last disabled at (0): [\u0026lt;0000000000000000\u0026gt;] 0x0\n\n------------------------------------------------------------------------\n\nThe problem is that irq-work handlers run with interrupts enabled, which\nmeans that rcu_preempt_deferred_qs_handler() could be interrupted,\nand that interrupt handler might contain an RCU read-side critical\nsection, which might invoke rcu_read_unlock_special().  In the strict\nKCSAN mode of operation used by RCU, this constitutes a data race on\nthe -\u0026gt;defer_qs_iw_pending field.\n\nThis commit therefore disables interrupts across the portion of the\nrcu_preempt_deferred_qs_handler() that updates the -\u0026gt;defer_qs_iw_pending\nfield.  This suffices because this handler is not a fast path.(CVE-2025-39749)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nNFS: Fix the setting of capabilities when automounting a new filesystem\n\nCapabilities cannot be inherited when we cross into a new filesystem.\nThey need to be reset to the minimal defaults, and then probed for\nagain.(CVE-2025-39798)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nKVM: x86: use array_index_nospec with indices that come from guest\n\nmin and dest_id are guest-controlled indices. Using array_index_nospec()\nafter the bounds checks clamps these values to mitigate speculative execution\nside-channels.(CVE-2025-39823)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\natm: atmtcp: Prevent arbitrary write in atmtcp_recv_control().\n\nsyzbot reported the splat below. [0]\n\nWhen atmtcp_v_open() or atmtcp_v_close() is called via connect()\nor close(), atmtcp_send_control() is called to send an in-kernel\nspecial message.\n\nThe message has ATMTCP_HDR_MAGIC in atmtcp_control.hdr.length.\nAlso, a pointer of struct atm_vcc is set to atmtcp_control.vcc.\n\nThe notable thing is struct atmtcp_control is uAPI but has a\nspace for an in-kernel pointer.\n\n  struct atmtcp_control {\n  \tstruct atmtcp_hdr hdr;\t/* must be first */\n  ...\n  \tatm_kptr_t vcc;\t\t/* both directions */\n  ...\n  } __ATM_API_ALIGN;\n\n  typedef struct { unsigned char _[8]; } __ATM_API_ALIGN atm_kptr_t;\n\nThe special message is processed in atmtcp_recv_control() called\nfrom atmtcp_c_send().\n\natmtcp_c_send() is vcc-\u0026gt;dev-\u0026gt;ops-\u0026gt;send() and called from 2 paths:\n\n  1. .ndo_start_xmit() (vcc-\u0026gt;send() == atm_send_aal0())\n  2. vcc_sendmsg()\n\nThe problem is sendmsg() does not validate the message length and\nuserspace can abuse atmtcp_recv_control() to overwrite any kptr\nby atmtcp_control.\n\nLet\u0026apos;s add a new -\u0026gt;pre_send() hook to validate messages from sendmsg().\n\n[0]:\nOops: general protection fault, probably for non-canonical address 0xdffffc00200000ab: 0000 [#1] SMP KASAN PTI\nKASAN: probably user-memory-access in range [0x0000000100000558-0x000000010000055f]\nCPU: 0 UID: 0 PID: 5865 Comm: syz-executor331 Not tainted 6.17.0-rc1-syzkaller-00215-gbab3ce404553 #0 PREEMPT(full)\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/12/2025\nRIP: 0010:atmtcp_recv_control drivers/atm/atmtcp.c:93 [inline]\nRIP: 0010:atmtcp_c_send+0x1da/0x950 drivers/atm/atmtcp.c:297\nCode: 4d 8d 75 1a 4c 89 f0 48 c1 e8 03 42 0f b6 04 20 84 c0 0f 85 15 06 00 00 41 0f b7 1e 4d 8d b7 60 05 00 00 4c 89 f0 48 c1 e8 03 \u0026lt;42\u0026gt; 0f b6 04 20 84 c0 0f 85 13 06 00 00 66 41 89 1e 4d 8d 75 1c 4c\nRSP: 0018:ffffc90003f5f810 EFLAGS: 00010203\nRAX: 00000000200000ab RBX: 0000000000000000 RCX: 0000000000000000\nRDX: ffff88802a510000 RSI: 00000000ffffffff RDI: ffff888030a6068c\nRBP: ffff88802699fb40 R08: ffff888030a606eb R09: 1ffff1100614c0dd\nR10: dffffc0000000000 R11: ffffffff8718fc40 R12: dffffc0000000000\nR13: ffff888030a60680 R14: 000000010000055f R15: 00000000ffffffff\nFS:  00007f8d7e9236c0(0000) GS:ffff888125c1c000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 000000000045ad50 CR3: 0000000075bde000 CR4: 00000000003526f0\nCall Trace:\n \u0026lt;TASK\u0026gt;\n vcc_sendmsg+0xa10/0xc60 net/atm/common.c:645\n sock_sendmsg_nosec net/socket.c:714 [inline]\n __sock_sendmsg+0x219/0x270 net/socket.c:729\n ____sys_sendmsg+0x505/0x830 net/socket.c:2614\n ___sys_sendmsg+0x21f/0x2a0 net/socket.c:2668\n __sys_sendmsg net/socket.c:2700 [inline]\n __do_sys_sendmsg net/socket.c:2705 [inline]\n __se_sys_sendmsg net/socket.c:2703 [inline]\n __x64_sys_sendmsg+0x19b/0x260 net/socket.c:2703\n do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]\n do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\nRIP: 0033:0x7f8d7e96a4a9\nCode: 28 00 00 00 75 05 48 83 c4 28 c3 e8 51 18 00 00 90 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 b0 ff ff ff f7 d8 64 89 01 48\nRSP: 002b:00007f8d7e923198 EFLAGS: 00000246 ORIG_RAX: 000000000000002e\nRAX: ffffffffffffffda RBX: 00007f8d7e9f4308 RCX: 00007f8d7e96a4a9\nRDX: 0000000000000000 RSI: 0000200000000240 RDI: 0000000000000005\nRBP: 00007f8d7e9f4300 R08: 65732f636f72702f R09: 65732f636f72702f\nR10: 65732f636f72702f R11: 0000000000000246 R12: 00007f8d7e9c10ac\nR13: 00007f8d7e9231a0 R14: 0000200000000200 R15: 0000200000000250\n \u0026lt;/TASK\u0026gt;\nModules linked in:(CVE-2025-39828)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncifs: prevent NULL pointer dereference in UTF16 conversion\n\nThere can be a NULL pointer dereference bug here. NULL is passed to\n__cifs_sfu_make_node without checks, which passes it unchecked to\ncifs_strndup_to_utf16, which in turn passes it to\ncifs_local_to_utf16_bytes where \u0026apos;*from\u0026apos; is dereferenced, causing a crash.\n\nThis patch adds a check for NULL \u0026apos;src\u0026apos; in cifs_strndup_to_utf16 and\nreturns NULL early to prevent dereferencing NULL pointer.\n\nFound by Linux Verification Center (linuxtesting.org) with SVACE(CVE-2025-39838)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbatman-adv: fix OOB read/write in network-coding decode\n\nbatadv_nc_skb_decode_packet() trusts coded_len and checks only against\nskb-\u0026gt;len. XOR starts at sizeof(struct batadv_unicast_packet), reducing\npayload headroom, and the source skb length is not verified, allowing an\nout-of-bounds read and a small out-of-bounds write.\n\nValidate that coded_len fits within the payload area of both destination\nand source sk_buffs before XORing.(CVE-2025-39839)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nceph: fix race condition validating r_parent before applying state\n\nAdd validation to ensure the cached parent directory inode matches the\ndirectory info in MDS replies. This prevents client-side race conditions\nwhere concurrent operations (e.g. rename) cause r_parent to become stale\nbetween request initiation and reply processing, which could lead to\napplying state changes to incorrect directory inodes.\n\n[ idryomov: folded a kerneldoc fixup and a follow-up fix from Alex to\n  move CEPH_CAP_PIN reference when r_parent is updated:\n\n  When the parent directory lock is not held, req-\u0026gt;r_parent can become\n  stale and is updated to point to the correct inode.  However, the\n  associated CEPH_CAP_PIN reference was not being adjusted.  The\n  CEPH_CAP_PIN is a reference on an inode that is tracked for\n  accounting purposes.  Moving this pin is important to keep the\n  accounting balanced. When the pin was not moved from the old parent\n  to the new one, it created two problems: The reference on the old,\n  stale parent was never released, causing a reference leak.\n  A reference for the new parent was never acquired, creating the risk\n  of a reference underflow later in ceph_mdsc_release_request().  This\n  patch corrects the logic by releasing the pin from the old parent and\n  acquiring it for the new parent when r_parent is switched.  This\n  ensures reference accounting stays balanced. ](CVE-2025-39927)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: fix smbdirect_recv_io leak in smbd_negotiate() error path\n\nDuring tests of another unrelated patch I was able to trigger this\nerror: Objects remaining on __kmem_cache_shutdown()(CVE-2025-39929)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\num: virtio_uml: Fix use-after-free after put_device in probe\n\nWhen register_virtio_device() fails in virtio_uml_probe(),\nthe code sets vu_dev-\u0026gt;registered = 1 even though\nthe device was not successfully registered.\nThis can lead to use-after-free or other issues.(CVE-2025-39951)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/sched: sch_qfq: Fix null-deref in agg_dequeue\n\nTo prevent a potential crash in agg_dequeue (net/sched/sch_qfq.c)\nwhen cl-\u0026gt;qdisc-\u0026gt;ops-\u0026gt;peek(cl-\u0026gt;qdisc) returns NULL, we check the return\nvalue before using it, similar to the existing approach in sch_hfsc.c.\n\nTo avoid code duplication, the following changes are made:\n\n1. Changed qdisc_warn_nonwc(include/net/pkt_sched.h) into a static\ninline function.\n\n2. Moved qdisc_peek_len from net/sched/sch_hfsc.c to\ninclude/net/pkt_sched.h so that sch_qfq can reuse it.\n\n3. Applied qdisc_peek_len in agg_dequeue to avoid crashing.(CVE-2025-40083)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nNFSD: Define a proc_layoutcommit for the FlexFiles layout type\n\nAvoid a crash if a pNFS client should happen to send a LAYOUTCOMMIT\noperation on a FlexFiles layout.(CVE-2025-40087)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncifs: parse_dfs_referrals: prevent oob on malformed input\n\nMalicious SMB server can send invalid reply to FSCTL_DFS_GET_REFERRALS\n\n- reply smaller than sizeof(struct get_dfs_referral_rsp)\n- reply with number of referrals smaller than NumberOfReferrals in the\nheader\n\nProcessing of such replies will cause oob.\n\nReturn -EINVAL error on such replies to prevent oob-s.(CVE-2025-40099)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: Fix refcount leak for cifs_sb_tlink\n\nFix three refcount inconsistency issues related to `cifs_sb_tlink`.\n\nComments for `cifs_sb_tlink` state that `cifs_put_tlink()` needs to be\ncalled after successful calls to `cifs_sb_tlink()`. Three calls fail to\nupdate refcount accordingly, leading to possible resource leaks.(CVE-2025-40103)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nvfs: Don\u0026apos;t leak disconnected dentries on umount\n\nWhen user calls open_by_handle_at() on some inode that is not cached, we\nwill create disconnected dentry for it. If such dentry is a directory,\nexportfs_decode_fh_raw() will then try to connect this dentry to the\ndentry tree through reconnect_path(). It may happen for various reasons\n(such as corrupted fs or race with rename) that the call to\nlookup_one_unlocked() in reconnect_one() will fail to find the dentry we\nare trying to reconnect and instead create a new dentry under the\nparent. Now this dentry will not be marked as disconnected although the\nparent still may well be disconnected (at least in case this\ninconsistency happened because the fs is corrupted and .. doesn\u0026apos;t point\nto the real parent directory). This creates inconsistency in\ndisconnected flags but AFAICS it was mostly harmless. At least until\ncommit f1ee616214cb (\u0026quot;VFS: don\u0026apos;t keep disconnected dentries on d_anon\u0026quot;)\nwhich removed adding of most disconnected dentries to sb-\u0026gt;s_anon list.\nThus after this commit cleanup of disconnected dentries implicitely\nrelies on the fact that dput() will immediately reclaim such dentries.\nHowever when some leaf dentry isn\u0026apos;t marked as disconnected, as in the\nscenario described above, the reclaim doesn\u0026apos;t happen and the dentries\nare \u0026quot;leaked\u0026quot;. Memory reclaim can eventually reclaim them but otherwise\nthey stay in memory and if umount comes first, we hit infamous \u0026quot;Busy\ninodes after unmount\u0026quot; bug. Make sure all dentries created under a\ndisconnected parent are marked as disconnected as well.(CVE-2025-40105)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/vmwgfx: Fix Use-after-free in validation\n\nNodes stored in the validation duplicates hashtable come from an arena\nallocator that is cleared at the end of vmw_execbuf_process. All nodes\nare expected to be cleared in vmw_validation_drop_ht but this node escaped\nbecause its resource was destroyed prematurely.(CVE-2025-40111)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5: Clean up only new IRQ glue on request_irq() failure\n\nThe mlx5_irq_alloc() function can inadvertently free the entire rmap\nand end up in a crash[1] when the other threads tries to access this,\nwhen request_irq() fails due to exhausted IRQ vectors. This commit\nmodifies the cleanup to remove only the specific IRQ mapping that was\njust added.\n\nThis prevents removal of other valid mappings and ensures precise\ncleanup of the failed IRQ allocation\u0026apos;s associated glue object.\n\nNote: This error is observed when both fwctl and rds configs are enabled.\n\n[1]\nmlx5_core 0000:05:00.0: Successfully registered panic handler for port 1\nmlx5_core 0000:05:00.0: mlx5_irq_alloc:293:(pid 66740): Failed to\nrequest irq. err = -28\ninfiniband mlx5_0: mlx5_ib_test_wc:290:(pid 66740): Error -28 while\ntrying to test write-combining support\nmlx5_core 0000:05:00.0: Successfully unregistered panic handler for port 1\nmlx5_core 0000:06:00.0: Successfully registered panic handler for port 1\nmlx5_core 0000:06:00.0: mlx5_irq_alloc:293:(pid 66740): Failed to\nrequest irq. err = -28\ninfiniband mlx5_0: mlx5_ib_test_wc:290:(pid 66740): Error -28 while\ntrying to test write-combining support\nmlx5_core 0000:06:00.0: Successfully unregistered panic handler for port 1\nmlx5_core 0000:03:00.0: mlx5_irq_alloc:293:(pid 28895): Failed to\nrequest irq. err = -28\nmlx5_core 0000:05:00.0: mlx5_irq_alloc:293:(pid 28895): Failed to\nrequest irq. err = -28\ngeneral protection fault, probably for non-canonical address\n0xe277a58fde16f291: 0000 [#1] SMP NOPTI\n\nRIP: 0010:free_irq_cpu_rmap+0x23/0x7d\nCall Trace:\n   \u0026lt;TASK\u0026gt;\n   ? show_trace_log_lvl+0x1d6/0x2f9\n   ? show_trace_log_lvl+0x1d6/0x2f9\n   ? mlx5_irq_alloc.cold+0x5d/0xf3 [mlx5_core]\n   ? __die_body.cold+0x8/0xa\n   ? die_addr+0x39/0x53\n   ? exc_general_protection+0x1c4/0x3e9\n   ? dev_vprintk_emit+0x5f/0x90\n   ? asm_exc_general_protection+0x22/0x27\n   ? free_irq_cpu_rmap+0x23/0x7d\n   mlx5_irq_alloc.cold+0x5d/0xf3 [mlx5_core]\n   irq_pool_request_vector+0x7d/0x90 [mlx5_core]\n   mlx5_irq_request+0x2e/0xe0 [mlx5_core]\n   mlx5_irq_request_vector+0xad/0xf7 [mlx5_core]\n   comp_irq_request_pci+0x64/0xf0 [mlx5_core]\n   create_comp_eq+0x71/0x385 [mlx5_core]\n   ? mlx5e_open_xdpsq+0x11c/0x230 [mlx5_core]\n   mlx5_comp_eqn_get+0x72/0x90 [mlx5_core]\n   ? xas_load+0x8/0x91\n   mlx5_comp_irqn_get+0x40/0x90 [mlx5_core]\n   mlx5e_open_channel+0x7d/0x3c7 [mlx5_core]\n   mlx5e_open_channels+0xad/0x250 [mlx5_core]\n   mlx5e_open_locked+0x3e/0x110 [mlx5_core]\n   mlx5e_open+0x23/0x70 [mlx5_core]\n   __dev_open+0xf1/0x1a5\n   __dev_change_flags+0x1e1/0x249\n   dev_change_flags+0x21/0x5c\n   do_setlink+0x28b/0xcc4\n   ? __nla_parse+0x22/0x3d\n   ? inet6_validate_link_af+0x6b/0x108\n   ? cpumask_next+0x1f/0x35\n   ? __snmp6_fill_stats64.constprop.0+0x66/0x107\n   ? __nla_validate_parse+0x48/0x1e6\n   __rtnl_newlink+0x5ff/0xa57\n   ? kmem_cache_alloc_trace+0x164/0x2ce\n   rtnl_newlink+0x44/0x6e\n   rtnetlink_rcv_msg+0x2bb/0x362\n   ? __netlink_sendskb+0x4c/0x6c\n   ? netlink_unicast+0x28f/0x2ce\n   ? rtnl_calcit.isra.0+0x150/0x146\n   netlink_rcv_skb+0x5f/0x112\n   netlink_unicast+0x213/0x2ce\n   netlink_sendmsg+0x24f/0x4d9\n   __sock_sendmsg+0x65/0x6a\n   ____sys_sendmsg+0x28f/0x2c9\n   ? import_iovec+0x17/0x2b\n   ___sys_sendmsg+0x97/0xe0\n   __sys_sendmsg+0x81/0xd8\n   do_syscall_64+0x35/0x87\n   entry_SYSCALL_64_after_hwframe+0x6e/0x0\nRIP: 0033:0x7fc328603727\nCode: c3 66 90 41 54 41 89 d4 55 48 89 f5 53 89 fb 48 83 ec 10 e8 0b ed\nff ff 44 89 e2 48 89 ee 89 df 41 89 c0 b8 2e 00 00 00 0f 05 \u0026lt;48\u0026gt; 3d 00\nf0 ff ff 77 35 44 89 c7 48 89 44 24 08 e8 44 ed ff ff 48\nRSP: 002b:00007ffe8eb3f1a0 EFLAGS: 00000293 ORIG_RAX: 000000000000002e\nRAX: ffffffffffffffda RBX: 000000000000000d RCX: 00007fc328603727\nRDX: 0000000000000000 RSI: 00007ffe8eb3f1f0 RDI: 000000000000000d\nRBP: 00007ffe8eb3f1f0 R08: 0000000000000000 R09: 0000000000000000\nR10: 0000000000000000 R11: 0000000000000293 R12: 0000000000000000\nR13: 00000000000\n---truncated---(CVE-2025-40250)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: qlogic/qede: fix potential out-of-bounds read in qede_tpa_cont() and qede_tpa_end()\n\nThe loops in \u0026apos;qede_tpa_cont()\u0026apos; and \u0026apos;qede_tpa_end()\u0026apos;, iterate\nover \u0026apos;cqe-\u0026gt;len_list[]\u0026apos; using only a zero-length terminator as\nthe stopping condition. If the terminator was missing or\nmalformed, the loop could run past the end of the fixed-size array.\n\nAdd an explicit bound check using ARRAY_SIZE() in both loops to prevent\na potential out-of-bounds access.\n\nFound by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2025-40252)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: sg: Do not sleep in atomic context\n\nsg_finish_rem_req() calls blk_rq_unmap_user(). The latter function may\nsleep. Hence, call sg_finish_rem_req() with interrupts enabled instead\nof disabled.(CVE-2025-40259)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnvme: nvme-fc: Ensure -\u0026gt;ioerr_work is cancelled in nvme_fc_delete_ctrl()\n\nnvme_fc_delete_assocation() waits for pending I/O to complete before\nreturning, and an error can cause -\u0026gt;ioerr_work to be queued after\ncancel_work_sync() had been called.  Move the call to cancel_work_sync() to\nbe after nvme_fc_delete_association() to ensure -\u0026gt;ioerr_work is not running\nwhen the nvme_fc_ctrl object is freed.  Otherwise the following can occur:\n\n[ 1135.911754] list_del corruption, ff2d24c8093f31f8-\u0026gt;next is NULL\n[ 1135.917705] ------------[ cut here ]------------\n[ 1135.922336] kernel BUG at lib/list_debug.c:52!\n[ 1135.926784] Oops: invalid opcode: 0000 [#1] SMP NOPTI\n[ 1135.931851] CPU: 48 UID: 0 PID: 726 Comm: kworker/u449:23 Kdump: loaded Not tainted 6.12.0 #1 PREEMPT(voluntary)\n[ 1135.943490] Hardware name: Dell Inc. PowerEdge R660/0HGTK9, BIOS 2.5.4 01/16/2025\n[ 1135.950969] Workqueue:  0x0 (nvme-wq)\n[ 1135.954673] RIP: 0010:__list_del_entry_valid_or_report.cold+0xf/0x6f\n[ 1135.961041] Code: c7 c7 98 68 72 94 e8 26 45 fe ff 0f 0b 48 c7 c7 70 68 72 94 e8 18 45 fe ff 0f 0b 48 89 fe 48 c7 c7 80 69 72 94 e8 07 45 fe ff \u0026lt;0f\u0026gt; 0b 48 89 d1 48 c7 c7 a0 6a 72 94 48 89 c2 e8 f3 44 fe ff 0f 0b\n[ 1135.979788] RSP: 0018:ff579b19482d3e50 EFLAGS: 00010046\n[ 1135.985015] RAX: 0000000000000033 RBX: ff2d24c8093f31f0 RCX: 0000000000000000\n[ 1135.992148] RDX: 0000000000000000 RSI: ff2d24d6bfa1d0c0 RDI: ff2d24d6bfa1d0c0\n[ 1135.999278] RBP: ff2d24c8093f31f8 R08: 0000000000000000 R09: ffffffff951e2b08\n[ 1136.006413] R10: ffffffff95122ac8 R11: 0000000000000003 R12: ff2d24c78697c100\n[ 1136.013546] R13: fffffffffffffff8 R14: 0000000000000000 R15: ff2d24c78697c0c0\n[ 1136.020677] FS:  0000000000000000(0000) GS:ff2d24d6bfa00000(0000) knlGS:0000000000000000\n[ 1136.028765] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ 1136.034510] CR2: 00007fd207f90b80 CR3: 000000163ea22003 CR4: 0000000000f73ef0\n[ 1136.041641] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n[ 1136.048776] DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400\n[ 1136.055910] PKRU: 55555554\n[ 1136.058623] Call Trace:\n[ 1136.061074]  \u0026lt;TASK\u0026gt;\n[ 1136.063179]  ? show_trace_log_lvl+0x1b0/0x2f0\n[ 1136.067540]  ? show_trace_log_lvl+0x1b0/0x2f0\n[ 1136.071898]  ? move_linked_works+0x4a/0xa0\n[ 1136.075998]  ? __list_del_entry_valid_or_report.cold+0xf/0x6f\n[ 1136.081744]  ? __die_body.cold+0x8/0x12\n[ 1136.085584]  ? die+0x2e/0x50\n[ 1136.088469]  ? do_trap+0xca/0x110\n[ 1136.091789]  ? do_error_trap+0x65/0x80\n[ 1136.095543]  ? __list_del_entry_valid_or_report.cold+0xf/0x6f\n[ 1136.101289]  ? exc_invalid_op+0x50/0x70\n[ 1136.105127]  ? __list_del_entry_valid_or_report.cold+0xf/0x6f\n[ 1136.110874]  ? asm_exc_invalid_op+0x1a/0x20\n[ 1136.115059]  ? __list_del_entry_valid_or_report.cold+0xf/0x6f\n[ 1136.120806]  move_linked_works+0x4a/0xa0\n[ 1136.124733]  worker_thread+0x216/0x3a0\n[ 1136.128485]  ? __pfx_worker_thread+0x10/0x10\n[ 1136.132758]  kthread+0xfa/0x240\n[ 1136.135904]  ? __pfx_kthread+0x10/0x10\n[ 1136.139657]  ret_from_fork+0x31/0x50\n[ 1136.143236]  ? __pfx_kthread+0x10/0x10\n[ 1136.146988]  ret_from_fork_asm+0x1a/0x30\n[ 1136.150915]  \u0026lt;/TASK\u0026gt;(CVE-2025-40261)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbe2net: pass wrb_params in case of OS2BMC\n\nbe_insert_vlan_in_pkt() is called with the wrb_params argument being NULL\nat be_send_pkt_to_bmc() call site.\u00a0 This may lead to dereferencing a NULL\npointer when processing a workaround for specific packet, as commit\nbc0c3405abbb (\u0026quot;be2net: fix a Tx stall bug caused by a specific ipv6\npacket\u0026quot;) states.\n\nThe correct way would be to pass the wrb_params from be_xmit().(CVE-2025-40264)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncifs: client: fix memory leak in smb3_fs_context_parse_param\n\nThe user calls fsconfig twice, but when the program exits, free() only\nfrees ctx-\u0026gt;source for the second fsconfig, not the first.\nRegarding fc-\u0026gt;source, there is no code in the fs context related to its\nmemory reclamation.\n\nTo fix this memory leak, release the source memory corresponding to ctx\nor fc before each parsing.\n\nsyzbot reported:\nBUG: memory leak\nunreferenced object 0xffff888128afa360 (size 96):\n  backtrace (crc 79c9c7ba):\n    kstrdup+0x3c/0x80 mm/util.c:84\n    smb3_fs_context_parse_param+0x229b/0x36c0 fs/smb/client/fs_context.c:1444\n\nBUG: memory leak\nunreferenced object 0xffff888112c7d900 (size 96):\n  backtrace (crc 79c9c7ba):\n    smb3_fs_context_fullpath+0x70/0x1b0 fs/smb/client/fs_context.c:629\n    smb3_fs_context_parse_param+0x2266/0x36c0 fs/smb/client/fs_context.c:1438(CVE-2025-40268)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nNFSD: free copynotify stateid in nfs4_free_ol_stateid()\n\nTypically copynotify stateid is freed either when parent\u0026apos;s stateid\nis being close/freed or in nfsd4_laundromat if the stateid hasn\u0026apos;t\nbeen used in a lease period.\n\nHowever, in case when the server got an OPEN (which created\na parent stateid), followed by a COPY_NOTIFY using that stateid,\nfollowed by a client reboot. New client instance while doing\nCREATE_SESSION would force expire previous state of this client.\nIt leads to the open state being freed thru release_openowner-\u0026gt;\nnfs4_free_ol_stateid() and it finds that it still has copynotify\nstateid associated with it. We currently print a warning and is\ntriggerred\n\nWARNING: CPU: 1 PID: 8858 at fs/nfsd/nfs4state.c:1550 nfs4_free_ol_stateid+0xb0/0x100 [nfsd]\n\nThis patch, instead, frees the associated copynotify stateid here.\n\nIf the parent stateid is freed (without freeing the copynotify\nstateids associated with it), it leads to the list corruption\nwhen laundromat ends up freeing the copynotify state later.\n\n[ 1626.839430] Internal error: Oops - BUG: 00000000f2000800 [#1]  SMP\n[ 1626.842828] Modules linked in: nfnetlink_queue nfnetlink_log bluetooth cfg80211 rpcrdma rdma_cm iw_cm ib_cm ib_core nfsd nfs_acl lockd grace nfs_localio ext4 crc16 mbcache jbd2 overlay uinput snd_seq_dummy snd_hrtimer qrtr rfkill vfat fat uvcvideo snd_hda_codec_generic videobuf2_vmalloc videobuf2_memops snd_hda_intel uvc snd_intel_dspcfg videobuf2_v4l2 videobuf2_common snd_hda_codec snd_hda_core videodev snd_hwdep snd_seq mc snd_seq_device snd_pcm snd_timer snd soundcore sg loop auth_rpcgss vsock_loopback vmw_vsock_virtio_transport_common vmw_vsock_vmci_transport vmw_vmci vsock xfs 8021q garp stp llc mrp nvme ghash_ce e1000e nvme_core sr_mod nvme_keyring nvme_auth cdrom vmwgfx drm_ttm_helper ttm sunrpc dm_mirror dm_region_hash dm_log iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi fuse dm_multipath dm_mod nfnetlink\n[ 1626.855594] CPU: 2 UID: 0 PID: 199 Comm: kworker/u24:33 Kdump: loaded Tainted: G    B   W           6.17.0-rc7+ #22 PREEMPT(voluntary)\n[ 1626.857075] Tainted: [B]=BAD_PAGE, [W]=WARN\n[ 1626.857573] Hardware name: VMware, Inc. VMware20,1/VBSA, BIOS VMW201.00V.24006586.BA64.2406042154 06/04/2024\n[ 1626.858724] Workqueue: nfsd4 laundromat_main [nfsd]\n[ 1626.859304] pstate: 61400005 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)\n[ 1626.860010] pc : __list_del_entry_valid_or_report+0x148/0x200\n[ 1626.860601] lr : __list_del_entry_valid_or_report+0x148/0x200\n[ 1626.861182] sp : ffff8000881d7a40\n[ 1626.861521] x29: ffff8000881d7a40 x28: 0000000000000018 x27: ffff0000c2a98200\n[ 1626.862260] x26: 0000000000000600 x25: 0000000000000000 x24: ffff8000881d7b20\n[ 1626.862986] x23: ffff0000c2a981e8 x22: 1fffe00012410e7d x21: ffff0000920873e8\n[ 1626.863701] x20: ffff0000920873e8 x19: ffff000086f22998 x18: 0000000000000000\n[ 1626.864421] x17: 20747562202c3839 x16: 3932326636383030 x15: 3030666666662065\n[ 1626.865092] x14: 6220646c756f6873 x13: 0000000000000001 x12: ffff60004fd9e4a3\n[ 1626.865713] x11: 1fffe0004fd9e4a2 x10: ffff60004fd9e4a2 x9 : dfff800000000000\n[ 1626.866320] x8 : 00009fffb0261b5e x7 : ffff00027ecf2513 x6 : 0000000000000001\n[ 1626.866938] x5 : ffff00027ecf2510 x4 : ffff60004fd9e4a3 x3 : 0000000000000000\n[ 1626.867553] x2 : 0000000000000000 x1 : ffff000096069640 x0 : 000000000000006d\n[ 1626.868167] Call trace:\n[ 1626.868382]  __list_del_entry_valid_or_report+0x148/0x200 (P)\n[ 1626.868876]  _free_cpntf_state_locked+0xd0/0x268 [nfsd]\n[ 1626.869368]  nfs4_laundromat+0x6f8/0x1058 [nfsd]\n[ 1626.869813]  laundromat_main+0x24/0x60 [nfsd]\n[ 1626.870231]  process_one_work+0x584/0x1050\n[ 1626.870595]  worker_thread+0x4c4/0xc60\n[ 1626.870893]  kthread+0x2f8/0x398\n[ 1626.871146]  ret_from_fork+0x10/0x20\n[ 1626.871422] Code: aa1303e1 aa1403e3 910e8000 97bc55d7 (d4210000)\n[ 1626.871892] SMP: stopping secondary CPUs(CVE-2025-40273)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: MGMT: cancel mesh send timer when hdev removed\n\nmesh_send_done timer is not canceled when hdev is removed, which causes\ncrash if the timer triggers after hdev is gone.\n\nCancel the timer when MGMT removes the hdev, like other MGMT timers.\n\nShould fix the BUG: sporadically seen by BlueZ test bot\n(in \u0026quot;Mesh - Send cancel - 1\u0026quot; test).\n\nLog:\n------\nBUG: KASAN: slab-use-after-free in run_timer_softirq+0x76b/0x7d0\n...\nFreed by task 36:\n kasan_save_stack+0x24/0x50\n kasan_save_track+0x14/0x30\n __kasan_save_free_info+0x3a/0x60\n __kasan_slab_free+0x43/0x70\n kfree+0x103/0x500\n device_release+0x9a/0x210\n kobject_put+0x100/0x1e0\n vhci_release+0x18b/0x240\n------(CVE-2025-40284)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfbdev: Add bounds checking in bit_putcs to fix vmalloc-out-of-bounds\n\nAdd bounds checking to prevent writes past framebuffer boundaries when\nrendering text near screen edges. Return early if the Y position is off-screen\nand clip image height to screen boundary. Break from the rendering loop if the\nX position is off-screen. When clipping image width to fit the screen, update\nthe character count to match the clipped width to prevent buffer size\nmismatches.\n\nWithout the character count update, bit_putcs_aligned and bit_putcs_unaligned\nreceive mismatched parameters where the buffer is allocated for the clipped\nwidth but cnt reflects the original larger count, causing out-of-bounds writes.(CVE-2025-40304)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\naccel/habanalabs: support mapping cb with vmalloc-backed coherent memory\n\nWhen IOMMU is enabled, dma_alloc_coherent() with GFP_USER may return\naddresses from the vmalloc range. If such an address is mapped without\nVM_MIXEDMAP, vm_insert_page() will trigger a BUG_ON due to the\nVM_PFNMAP restriction.\n\nFix this by checking for vmalloc addresses and setting VM_MIXEDMAP\nin the VMA before mapping. This ensures safe mapping and avoids kernel\ncrashes. The memory is still driver-allocated and cannot be accessed\ndirectly by userspace.(CVE-2025-40311)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nusb: cdns3: gadget: Use-after-free during failed initialization and exit of cdnsp gadget\n\nIn the __cdnsp_gadget_init() and cdnsp_gadget_exit() functions, the gadget\nstructure (pdev-\u0026gt;gadget) was freed before its endpoints.\nThe endpoints are linked via the ep_list in the gadget structure.\nFreeing the gadget first leaves dangling pointers in the endpoint list.\nWhen the endpoints are subsequently freed, this results in a use-after-free.\n\nFix:\nBy separating the usb_del_gadget_udc() operation into distinct \u0026quot;del\u0026quot; and\n\u0026quot;put\u0026quot; steps, cdnsp_gadget_free_endpoints() can be executed prior to the\nfinal release of the gadget structure with usb_put_gadget().\n\nA patch similar to bb9c74a5bd14(\u0026quot;usb: dwc3: gadget: Free gadget structure\n only after freeing endpoints\u0026quot;).(CVE-2025-40314)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Sync pending IRQ work before freeing ring buffer\n\nFix a race where irq_work can be queued in bpf_ringbuf_commit()\nbut the ring buffer is freed before the work executes.\nIn the syzbot reproducer, a BPF program attached to sched_switch\ntriggers bpf_ringbuf_commit(), queuing an irq_work. If the ring buffer\nis freed before this work executes, the irq_work thread may accesses\nfreed memory.\nCalling `irq_work_sync(\u0026amp;rb-\u0026gt;work)` ensures that all pending irq_work\ncomplete before freeing the buffer.(CVE-2025-40319)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: fix potential cfid UAF in smb2_query_info_compound\n\nWhen smb2_query_info_compound() retries, a previously allocated cfid may\nhave been freed in the first attempt.\nBecause cfid wasn\u0026apos;t reset on replay, later cleanup could act on a stale\npointer, leading to a potential use-after-free.\n\nReinitialize cfid to NULL under the replay label.\n\nExample trace (trimmed):\n\nrefcount_t: underflow; use-after-free.\nWARNING: CPU: 1 PID: 11224 at ../lib/refcount.c:28 refcount_warn_saturate+0x9c/0x110\n[...]\nRIP: 0010:refcount_warn_saturate+0x9c/0x110\n[...]\nCall Trace:\n \u0026lt;TASK\u0026gt;\n smb2_query_info_compound+0x29c/0x5c0 [cifs f90b72658819bd21c94769b6a652029a07a7172f]\n ? step_into+0x10d/0x690\n ? __legitimize_path+0x28/0x60\n smb2_queryfs+0x6a/0xf0 [cifs f90b72658819bd21c94769b6a652029a07a7172f]\n smb311_queryfs+0x12d/0x140 [cifs f90b72658819bd21c94769b6a652029a07a7172f]\n ? kmem_cache_alloc+0x18a/0x340\n ? getname_flags+0x46/0x1e0\n cifs_statfs+0x9f/0x2b0 [cifs f90b72658819bd21c94769b6a652029a07a7172f]\n statfs_by_dentry+0x67/0x90\n vfs_statfs+0x16/0xd0\n user_statfs+0x54/0xa0\n __do_sys_statfs+0x20/0x50\n do_syscall_64+0x58/0x80(CVE-2025-40320)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfbdev: bitblit: bound-check glyph index in bit_putcs*\n\nbit_putcs_aligned()/unaligned() derived the glyph pointer from the\ncharacter value masked by 0xff/0x1ff, which may exceed the actual font\u0026apos;s\nglyph count and read past the end of the built-in font array.\nClamp the index to the actual glyph count before computing the address.\n\nThis fixes a global out-of-bounds read reported by syzbot.(CVE-2025-40322)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nNFSD: Fix crash in nfsd4_read_release()\n\nWhen tracing is enabled, the trace_nfsd_read_done trace point\ncrashes during the pynfs read.testNoFh test.(CVE-2025-40324)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: fix potential UAF in smb2_close_cached_fid()\n\nfind_or_create_cached_dir() could grab a new reference after kref_put()\nhad seen the refcount drop to zero but before cfid_list_lock is acquired\nin smb2_close_cached_fid(), leading to use-after-free.\n\nSwitch to kref_put_lock() so cfid_release() is called with\ncfid_list_lock held, closing that gap.(CVE-2025-40328)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nusb: storage: sddr55: Reject out-of-bound new_pba\n\nDiscovered by Atuin - Automated Vulnerability Discovery Engine.\n\nnew_pba comes from the status packet returned after each write.\nA bogus device could report values beyond the block count derived\nfrom info-\u0026gt;capacity, letting the driver walk off the end of\npba_to_lba[] and corrupt heap memory.\n\nReject PBAs that exceed the computed block count and fail the\ntransfer so we avoid touching out-of-range mapping entries.(CVE-2025-40345)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5e: RX, Fix generating skb from non-linear xdp_buff for striding RQ\n\nXDP programs can change the layout of an xdp_buff through\nbpf_xdp_adjust_tail() and bpf_xdp_adjust_head(). Therefore, the driver\ncannot assume the size of the linear data area nor fragments. Fix the\nbug in mlx5 by generating skb according to xdp_buff after XDP programs\nrun.\n\nCurrently, when handling multi-buf XDP, the mlx5 driver assumes the\nlayout of an xdp_buff to be unchanged. That is, the linear data area\ncontinues to be empty and fragments remain the same. This may cause\nthe driver to generate erroneous skb or triggering a kernel\nwarning. When an XDP program added linear data through\nbpf_xdp_adjust_head(), the linear data will be ignored as\nmlx5e_build_linear_skb() builds an skb without linear data and then\npull data from fragments to fill the linear data area. When an XDP\nprogram has shrunk the non-linear data through bpf_xdp_adjust_tail(),\nthe delta passed to __pskb_pull_tail() may exceed the actual nonlinear\ndata size and trigger the BUG_ON in it.\n\nTo fix the issue, first record the original number of fragments. If the\nnumber of fragments changes after the XDP program runs, rewind the end\nfragment pointer by the difference and recalculate the truesize. Then,\nbuild the skb with the linear data area matching the xdp_buff. Finally,\nonly pull data in if there is non-linear data and fill the linear part\nup to 256 bytes.(CVE-2025-40350)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/sysfb: Do not dereference NULL pointer in plane reset\n\nThe plane state in __drm_gem_reset_shadow_plane() can be NULL. Do not\nderef that pointer, but forward NULL to the other plane-reset helpers.\nClears plane-\u0026gt;state to NULL.\n\nv2:\n- fix typo in commit description (Javier)(CVE-2025-40360)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: ipv6: fix field-spanning memcpy warning in AH output\n\nFix field-spanning memcpy warnings in ah6_output() and\nah6_output_done() where extension headers are copied to/from IPv6\naddress fields, triggering fortify-string warnings about writes beyond\nthe 16-byte address fields.\n\n  memcpy: detected field-spanning write (size 40) of single field \u0026quot;\u0026amp;top_iph-\u0026gt;saddr\u0026quot; at net/ipv6/ah6.c:439 (size 16)\n  WARNING: CPU: 0 PID: 8838 at net/ipv6/ah6.c:439 ah6_output+0xe7e/0x14e0 net/ipv6/ah6.c:439\n\nThe warnings are false positives as the extension headers are\nintentionally placed after the IPv6 header in memory. Fix by properly\ncopying addresses and extension headers separately, and introduce\nhelper functions to avoid code duplication.(CVE-2025-40363)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nblk-cgroup: fix possible deadlock while configuring policy\n\nFollowing deadlock can be triggered easily by lockdep:\n\nWARNING: possible circular locking dependency detected\n6.17.0-rc3-00124-ga12c2658ced0 #1665 Not tainted\n------------------------------------------------------\ncheck/1334 is trying to acquire lock:\nff1100011d9d0678 (\u0026amp;q-\u0026gt;sysfs_lock){+.+.}-{4:4}, at: blk_unregister_queue+0x53/0x180\n\nbut task is already holding lock:\nff1100011d9d00e0 (\u0026amp;q-\u0026gt;q_usage_counter(queue)#3){++++}-{0:0}, at: del_gendisk+0xba/0x110\n\nwhich lock already depends on the new lock.\n\nthe existing dependency chain (in reverse order) is:\n\n-\u0026gt; #2 (\u0026amp;q-\u0026gt;q_usage_counter(queue)#3){++++}-{0:0}:\n       blk_queue_enter+0x40b/0x470\n       blkg_conf_prep+0x7b/0x3c0\n       tg_set_limit+0x10a/0x3e0\n       cgroup_file_write+0xc6/0x420\n       kernfs_fop_write_iter+0x189/0x280\n       vfs_write+0x256/0x490\n       ksys_write+0x83/0x190\n       __x64_sys_write+0x21/0x30\n       x64_sys_call+0x4608/0x4630\n       do_syscall_64+0xdb/0x6b0\n       entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\n-\u0026gt; #1 (\u0026amp;q-\u0026gt;rq_qos_mutex){+.+.}-{4:4}:\n       __mutex_lock+0xd8/0xf50\n       mutex_lock_nested+0x2b/0x40\n       wbt_init+0x17e/0x280\n       wbt_enable_default+0xe9/0x140\n       blk_register_queue+0x1da/0x2e0\n       __add_disk+0x38c/0x5d0\n       add_disk_fwnode+0x89/0x250\n       device_add_disk+0x18/0x30\n       virtblk_probe+0x13a3/0x1800\n       virtio_dev_probe+0x389/0x610\n       really_probe+0x136/0x620\n       __driver_probe_device+0xb3/0x230\n       driver_probe_device+0x2f/0xe0\n       __driver_attach+0x158/0x250\n       bus_for_each_dev+0xa9/0x130\n       driver_attach+0x26/0x40\n       bus_add_driver+0x178/0x3d0\n       driver_register+0x7d/0x1c0\n       __register_virtio_driver+0x2c/0x60\n       virtio_blk_init+0x6f/0xe0\n       do_one_initcall+0x94/0x540\n       kernel_init_freeable+0x56a/0x7b0\n       kernel_init+0x2b/0x270\n       ret_from_fork+0x268/0x4c0\n       ret_from_fork_asm+0x1a/0x30\n\n-\u0026gt; #0 (\u0026amp;q-\u0026gt;sysfs_lock){+.+.}-{4:4}:\n       __lock_acquire+0x1835/0x2940\n       lock_acquire+0xf9/0x450\n       __mutex_lock+0xd8/0xf50\n       mutex_lock_nested+0x2b/0x40\n       blk_unregister_queue+0x53/0x180\n       __del_gendisk+0x226/0x690\n       del_gendisk+0xba/0x110\n       sd_remove+0x49/0xb0 [sd_mod]\n       device_remove+0x87/0xb0\n       device_release_driver_internal+0x11e/0x230\n       device_release_driver+0x1a/0x30\n       bus_remove_device+0x14d/0x220\n       device_del+0x1e1/0x5a0\n       __scsi_remove_device+0x1ff/0x2f0\n       scsi_remove_device+0x37/0x60\n       sdev_store_delete+0x77/0x100\n       dev_attr_store+0x1f/0x40\n       sysfs_kf_write+0x65/0x90\n       kernfs_fop_write_iter+0x189/0x280\n       vfs_write+0x256/0x490\n       ksys_write+0x83/0x190\n       __x64_sys_write+0x21/0x30\n       x64_sys_call+0x4608/0x4630\n       do_syscall_64+0xdb/0x6b0\n       entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\nother info that might help us debug this:\n\nChain exists of:\n  \u0026amp;q-\u0026gt;sysfs_lock --\u0026gt; \u0026amp;q-\u0026gt;rq_qos_mutex --\u0026gt; \u0026amp;q-\u0026gt;q_usage_counter(queue)#3\n\n Possible unsafe locking scenario:\n\n       CPU0                    CPU1\n       ----                    ----\n  lock(\u0026amp;q-\u0026gt;q_usage_counter(queue)#3);\n                               lock(\u0026amp;q-\u0026gt;rq_qos_mutex);\n                               lock(\u0026amp;q-\u0026gt;q_usage_counter(queue)#3);\n  lock(\u0026amp;q-\u0026gt;sysfs_lock);\n\nRoot cause is that queue_usage_counter is grabbed with rq_qos_mutex\nheld in blkg_conf_prep(), while queue should be freezed before\nrq_qos_mutex from other context.\n\nThe blk_queue_enter() from blkg_conf_prep() is used to protect against\npolicy deactivation, which is already protected with blkcg_mutex, hence\nconvert blk_queue_enter() to blkcg_mutex to fix this problem. Meanwhile,\nconsider that blkcg_mutex is held after queue is freezed from policy\ndeactivation, also convert blkg_alloc() to use GFP_NOIO.(CVE-2025-68178)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/mediatek: Disable AFBC support on Mediatek DRM driver\n\nCommit c410fa9b07c3 (\u0026quot;drm/mediatek: Add AFBC support to Mediatek DRM\ndriver\u0026quot;) added AFBC support to Mediatek DRM and enabled the\n32x8/split/sparse modifier.\n\nHowever, this is currently broken on Mediatek MT8188 (Genio 700 EVK\nplatform); tested using upstream Kernel and Mesa (v25.2.1), AFBC is used by\ndefault since Mesa v25.0.\n\nKernel trace reports vblank timeouts constantly, and the render is garbled:\n\n```\n[CRTC:62:crtc-0] vblank wait timed out\nWARNING: CPU: 7 PID: 70 at drivers/gpu/drm/drm_atomic_helper.c:1835 drm_atomic_helper_wait_for_vblanks.part.0+0x24c/0x27c\n[...]\nHardware name: MediaTek Genio-700 EVK (DT)\nWorkqueue: events_unbound commit_work\npstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\npc : drm_atomic_helper_wait_for_vblanks.part.0+0x24c/0x27c\nlr : drm_atomic_helper_wait_for_vblanks.part.0+0x24c/0x27c\nsp : ffff80008337bca0\nx29: ffff80008337bcd0 x28: 0000000000000061 x27: 0000000000000000\nx26: 0000000000000001 x25: 0000000000000000 x24: ffff0000c9dcc000\nx23: 0000000000000001 x22: 0000000000000000 x21: ffff0000c66f2f80\nx20: ffff0000c0d7d880 x19: 0000000000000000 x18: 000000000000000a\nx17: 000000040044ffff x16: 005000f2b5503510 x15: 0000000000000000\nx14: 0000000000000000 x13: 74756f2064656d69 x12: 742074696177206b\nx11: 0000000000000058 x10: 0000000000000018 x9 : ffff800082396a70\nx8 : 0000000000057fa8 x7 : 0000000000000cce x6 : ffff8000823eea70\nx5 : ffff0001fef5f408 x4 : ffff80017ccee000 x3 : ffff0000c12cb480\nx2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0000c12cb480\nCall trace:\n drm_atomic_helper_wait_for_vblanks.part.0+0x24c/0x27c (P)\n drm_atomic_helper_commit_tail_rpm+0x64/0x80\n commit_tail+0xa4/0x1a4\n commit_work+0x14/0x20\n process_one_work+0x150/0x290\n worker_thread+0x2d0/0x3ec\n kthread+0x12c/0x210\n ret_from_fork+0x10/0x20\n---[ end trace 0000000000000000 ]---\n```\n\nUntil this gets fixed upstream, disable AFBC support on this platform, as\nit\u0026apos;s currently broken with upstream Mesa.(CVE-2025-68184)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnfs4_setup_readdir(): insufficient locking for -\u0026gt;d_parent-\u0026gt;d_inode dereferencing\n\nTheoretically it\u0026apos;s an oopsable race, but I don\u0026apos;t believe one can manage\nto hit it on real hardware; might become doable on a KVM, but it still\nwon\u0026apos;t be easy to attack.\n\nAnyway, it\u0026apos;s easy to deal with - since xdr_encode_hyper() is just a call of\nput_unaligned_be64(), we can put that under -\u0026gt;d_lock and be done with that.(CVE-2025-68185)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nudp_tunnel: use netdev_warn() instead of netdev_WARN()\n\nnetdev_WARN() uses WARN/WARN_ON to print a backtrace along with\nfile and line information. In this case, udp_tunnel_nic_register()\nreturning an error is just a failed operation, not a kernel bug.\n\nudp_tunnel_nic_register() can fail due to a memory allocation\nfailure (kzalloc() or udp_tunnel_nic_alloc()).\nThis is a normal runtime error and not a kernel bug.\n\nReplace netdev_WARN() with netdev_warn() accordingly.(CVE-2025-68191)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnvme-multipath: fix lockdep WARN due to partition scan work\n\nBlktests test cases nvme/014, 057 and 058 fail occasionally due to a\nlockdep WARN. As reported in the Closes tag URL, the WARN indicates that\na deadlock can happen due to the dependency among disk-\u0026gt;open_mutex,\nkblockd workqueue completion and partition_scan_work completion.\n\nTo avoid the lockdep WARN and the potential deadlock, cut the dependency\nby running the partition_scan_work not by kblockd workqueue but by\nnvme_wq.(CVE-2025-68218)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncifs: fix memory leak in smb3_fs_context_parse_param error path\n\nAdd proper cleanup of ctx-\u0026gt;source and fc-\u0026gt;source to the\ncifs_parse_mount_err error handler. This ensures that memory allocated\nfor the source strings is correctly freed on all error paths, matching\nthe cleanup already performed in the success path by\nsmb3_cleanup_fs_context_contents().\nPointers are also set to NULL after freeing to prevent potential\ndouble-free issues.\n\nThis change fixes a memory leak originally detected by syzbot. The\nleak occurred when processing Opt_source mount options if an error\nhappened after ctx-\u0026gt;source and fc-\u0026gt;source were successfully\nallocated but before the function completed.\n\nThe specific leak sequence was:\n1. ctx-\u0026gt;source = smb3_fs_context_fullpath(ctx, \u0026apos;/\u0026apos;) allocates memory\n2. fc-\u0026gt;source = kstrdup(ctx-\u0026gt;source, GFP_KERNEL) allocates more memory\n3. A subsequent error jumps to cifs_parse_mount_err\n4. The old error handler freed passwords but not the source strings,\ncausing the memory to leak.\n\nThis issue was not addressed by commit e8c73eb7db0a (\u0026quot;cifs: client:\nfix memory leak in smb3_fs_context_parse_param\u0026quot;), which only fixed\nleaks from repeated fsconfig() calls but not this error path.\n\nPatch updated with minor change suggested by kernel test robot(CVE-2025-68219)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: target: tcm_loop: Fix segfault in tcm_loop_tpg_address_show()\n\nIf the allocation of tl_hba-\u0026gt;sh fails in tcm_loop_driver_probe() and we\nattempt to dereference it in tcm_loop_tpg_address_show() we will get a\nsegfault, see below for an example. So, check tl_hba-\u0026gt;sh before\ndereferencing it.\n\n  Unable to allocate struct scsi_host\n  BUG: kernel NULL pointer dereference, address: 0000000000000194\n  #PF: supervisor read access in kernel mode\n  #PF: error_code(0x0000) - not-present page\n  PGD 0 P4D 0\n  Oops: 0000 [#1] PREEMPT SMP NOPTI\n  CPU: 1 PID: 8356 Comm: tokio-runtime-w Not tainted 6.6.104.2-4.azl3 #1\n  Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 09/28/2024\n  RIP: 0010:tcm_loop_tpg_address_show+0x2e/0x50 [tcm_loop]\n...\n  Call Trace:\n   \u0026lt;TASK\u0026gt;\n   configfs_read_iter+0x12d/0x1d0 [configfs]\n   vfs_read+0x1b5/0x300\n   ksys_read+0x6f/0xf0\n...(CVE-2025-68229)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbinfmt_misc: restore write access before closing files opened by open_exec()\n\nbm_register_write() opens an executable file using open_exec(), which\ninternally calls do_open_execat() and denies write access on the file to\navoid modification while it is being executed.\n\nHowever, when an error occurs, bm_register_write() closes the file using\nfilp_close() directly. This does not restore the write permission, which\nmay cause subsequent write operations on the same file to fail.\n\nFix this by calling exe_file_allow_write_access() before filp_close() to\nrestore the write permission properly.(CVE-2025-68239)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipv4: route: Prevent rt_bind_exception() from rebinding stale fnhe\n\nThe sit driver\u0026apos;s packet transmission path calls: sit_tunnel_xmit() -\u0026gt;\nupdate_or_create_fnhe(), which lead to fnhe_remove_oldest() being called\nto delete entries exceeding FNHE_RECLAIM_DEPTH+random.\n\nThe race window is between fnhe_remove_oldest() selecting fnheX for\ndeletion and the subsequent kfree_rcu(). During this time, the\nconcurrent path\u0026apos;s __mkroute_output() -\u0026gt; find_exception() can fetch the\nsoon-to-be-deleted fnheX, and rt_bind_exception() then binds it with a\nnew dst using a dst_hold(). When the original fnheX is freed via RCU,\nthe dst reference remains permanently leaked.\n\nCPU 0                             CPU 1\n__mkroute_output()\n  find_exception() [fnheX]\n                                  update_or_create_fnhe()\n                                    fnhe_remove_oldest() [fnheX]\n  rt_bind_exception() [bind dst]\n                                  RCU callback [fnheX freed, dst leak]\n\nThis issue manifests as a device reference count leak and a warning in\ndmesg when unregistering the net device:\n\n  unregister_netdevice: waiting for sitX to become free. Usage count = N\n\nIdo Schimmel provided the simple test validation method [1].\n\nThe fix clears \u0026apos;oldest-\u0026gt;fnhe_daddr\u0026apos; before calling fnhe_flush_routes().\nSince rt_bind_exception() checks this field, setting it to zero prevents\nthe stale fnhe from being reused and bound to a new dst just before it\nis freed.\n\n[1]\nip netns add ns1\nip -n ns1 link set dev lo up\nip -n ns1 address add 192.0.2.1/32 dev lo\nip -n ns1 link add name dummy1 up type dummy\nip -n ns1 route add 192.0.2.2/32 dev dummy1\nip -n ns1 link add name gretap1 up arp off type gretap \\\n    local 192.0.2.1 remote 192.0.2.2\nip -n ns1 route add 198.51.0.0/16 dev gretap1\ntaskset -c 0 ip netns exec ns1 mausezahn gretap1 \\\n    -A 198.51.100.1 -B 198.51.0.0/16 -t udp -p 1000 -c 0 -q \u0026amp;\ntaskset -c 2 ip netns exec ns1 mausezahn gretap1 \\\n    -A 198.51.100.1 -B 198.51.0.0/16 -t udp -p 1000 -c 0 -q \u0026amp;\nsleep 10\nip netns pids ns1 | xargs kill\nip netns del ns1(CVE-2025-68241)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: netpoll: fix incorrect refcount handling causing incorrect cleanup\n\ncommit efa95b01da18 (\u0026quot;netpoll: fix use after free\u0026quot;) incorrectly\nignored the refcount and prematurely set dev-\u0026gt;npinfo to NULL during\nnetpoll cleanup, leading to improper behavior and memory leaks.\n\nScenario causing lack of proper cleanup:\n\n1) A netpoll is associated with a NIC (e.g., eth0) and netdev-\u0026gt;npinfo is\n   allocated, and refcnt = 1\n   - Keep in mind that npinfo is shared among all netpoll instances. In\n     this case, there is just one.\n\n2) Another netpoll is also associated with the same NIC and\n   npinfo-\u0026gt;refcnt += 1.\n   - Now dev-\u0026gt;npinfo-\u0026gt;refcnt = 2;\n   - There is just one npinfo associated to the netdev.\n\n3) When the first netpolls goes to clean up:\n   - The first cleanup succeeds and clears np-\u0026gt;dev-\u0026gt;npinfo, ignoring\n     refcnt.\n     - It basically calls `RCU_INIT_POINTER(np-\u0026gt;dev-\u0026gt;npinfo, NULL);`\n   - Set dev-\u0026gt;npinfo = NULL, without proper cleanup\n   - No -\u0026gt;ndo_netpoll_cleanup() is either called\n\n4) Now the second target tries to clean up\n   - The second cleanup fails because np-\u0026gt;dev-\u0026gt;npinfo is already NULL.\n     * In this case, ops-\u0026gt;ndo_netpoll_cleanup() was never called, and\n       the skb pool is not cleaned as well (for the second netpoll\n       instance)\n  - This leaks npinfo and skbpool skbs, which is clearly reported by\n    kmemleak.\n\nRevert commit efa95b01da18 (\u0026quot;netpoll: fix use after free\u0026quot;) and adds\nclarifying comments emphasizing that npinfo cleanup should only happen\nonce the refcount reaches zero, ensuring stable and correct netpoll\nbehavior.(CVE-2025-68245)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nerofs: avoid infinite loops due to corrupted subpage compact indexes\n\nRobert reported an infinite loop observed by two crafted images.\n\nThe root cause is that `clusterofs` can be larger than `lclustersize`\nfor !NONHEAD `lclusters` in corrupted subpage compact indexes, e.g.:\n\n  blocksize = lclustersize = 512   lcn = 6   clusterofs = 515\n\nMove the corresponding check for full compress indexes to\n`z_erofs_load_lcluster_from_disk()` to also cover subpage compact\ncompress indexes.\n\nIt also fixes the position of `m-\u0026gt;type \u0026gt;= Z_EROFS_LCLUSTER_TYPE_MAX`\ncheck, since it should be placed right after\n`z_erofs_load_{compact,full}_lcluster()`.(CVE-2025-68251)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nusb: storage: Fix memory leak in USB bulk transport\n\nA kernel memory leak was identified by the \u0026apos;ioctl_sg01\u0026apos; test from Linux\nTest Project (LTP). The following bytes were mainly observed: 0x53425355.\n\nWhen USB storage devices incorrectly skip the data phase with status data,\nthe code extracts/validates the CSW from the sg buffer, but fails to clear\nit afterwards. This leaves status protocol data in srb\u0026apos;s transfer buffer,\nsuch as the US_BULK_CS_SIGN \u0026apos;USBS\u0026apos; signature observed here. Thus, this can\nlead to USB protocols leaks to user space through SCSI generic (/dev/sg*)\ninterfaces, such as the one seen here when the LTP test requested 512 KiB.\n\nFix the leak by zeroing the CSW data in srb\u0026apos;s transfer buffer immediately\nafter the validation of devices that skip data phase.\n\nNote: Differently from CVE-2018-1000204, which fixed a big leak by zero-\ning pages at allocation time, this leak occurs after allocation, when USB\nprotocol data is written to already-allocated sg pages.(CVE-2025-68288)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: fix memory leak in cifs_construct_tcon()\n\nWhen having a multiuser mount with domain= specified and using\ncifscreds, cifs_set_cifscreds() will end up setting @ctx-\u0026gt;domainname,\nso it needs to be freed before leaving cifs_construct_tcon().\n\nThis fixes the following memory leak reported by kmemleak:\n\n  mount.cifs //srv/share /mnt -o domain=ZELDA,multiuser,...\n  su - testuser\n  cifscreds add -d ZELDA -u testuser\n  ...\n  ls /mnt/1\n  ...\n  umount /mnt\n  echo scan \u0026gt; /sys/kernel/debug/kmemleak\n  cat /sys/kernel/debug/kmemleak\n  unreferenced object 0xffff8881203c3f08 (size 8):\n    comm \u0026quot;ls\u0026quot;, pid 5060, jiffies 4307222943\n    hex dump (first 8 bytes):\n      5a 45 4c 44 41 00 cc cc                          ZELDA...\n    backtrace (crc d109a8cf):\n      __kmalloc_node_track_caller_noprof+0x572/0x710\n      kstrdup+0x3a/0x70\n      cifs_sb_tlink+0x1209/0x1770 [cifs]\n      cifs_get_fattr+0xe1/0xf50 [cifs]\n      cifs_get_inode_info+0xb5/0x240 [cifs]\n      cifs_revalidate_dentry_attr+0x2d1/0x470 [cifs]\n      cifs_getattr+0x28e/0x450 [cifs]\n      vfs_getattr_nosec+0x126/0x180\n      vfs_statx+0xf6/0x220\n      do_statx+0xab/0x110\n      __x64_sys_statx+0xd5/0x130\n      do_syscall_64+0xbb/0x380\n      entry_SYSCALL_64_after_hwframe+0x77/0x7f(CVE-2025-68295)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm, fbcon, vga_switcheroo: Avoid race condition in fbcon setup\n\nProtect vga_switcheroo_client_fb_set() with console lock. Avoids OOB\naccess in fbcon_remap_all(). Without holding the console lock the call\nraces with switching outputs.\n\nVGA switcheroo calls fbcon_remap_all() when switching clients. The fbcon\nfunction uses struct fb_info.node, which is set by register_framebuffer().\nAs the fb-helper code currently sets up VGA switcheroo before registering\nthe framebuffer, the value of node is -1 and therefore not a legal value.\nFor example, fbcon uses the value within set_con2fb_map() [1] as an index\ninto an array.\n\nMoving vga_switcheroo_client_fb_set() after register_framebuffer() can\nresult in VGA switching that does not switch fbcon correctly.\n\nTherefore move vga_switcheroo_client_fb_set() under fbcon_fb_registered(),\nwhich already holds the console lock. Fbdev calls fbcon_fb_registered()\nfrom within register_framebuffer(). Serializes the helper with VGA\nswitcheroo\u0026apos;s call to fbcon_remap_all().\n\nAlthough vga_switcheroo_client_fb_set() takes an instance of struct fb_info\nas parameter, it really only needs the contained fbcon state. Moving the\ncall to fbcon initialization is therefore cleaner than before. Only amdgpu,\ni915, nouveau and radeon support vga_switcheroo. For all other drivers,\nthis change does nothing.(CVE-2025-68296)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: hci_sock: Prevent race in socket write iter and sock bind\n\nThere is a potential race condition between sock bind and socket write\niter. bind may free the same cmd via mgmt_pending before write iter sends\nthe cmd, just as syzbot reported in UAF[1].\n\nHere we use hci_dev_lock to synchronize the two, thereby avoiding the\nUAF mentioned in [1].\n\n[1]\nsyzbot reported:\nBUG: KASAN: slab-use-after-free in mgmt_pending_remove+0x3b/0x210 net/bluetooth/mgmt_util.c:316\nRead of size 8 at addr ffff888077164818 by task syz.0.17/5989\nCall Trace:\n mgmt_pending_remove+0x3b/0x210 net/bluetooth/mgmt_util.c:316\n set_link_security+0x5c2/0x710 net/bluetooth/mgmt.c:1918\n hci_mgmt_cmd+0x9c9/0xef0 net/bluetooth/hci_sock.c:1719\n hci_sock_sendmsg+0x6ca/0xef0 net/bluetooth/hci_sock.c:1839\n sock_sendmsg_nosec net/socket.c:727 [inline]\n __sock_sendmsg+0x21c/0x270 net/socket.c:742\n sock_write_iter+0x279/0x360 net/socket.c:1195\n\nAllocated by task 5989:\n mgmt_pending_add+0x35/0x140 net/bluetooth/mgmt_util.c:296\n set_link_security+0x557/0x710 net/bluetooth/mgmt.c:1910\n hci_mgmt_cmd+0x9c9/0xef0 net/bluetooth/hci_sock.c:1719\n hci_sock_sendmsg+0x6ca/0xef0 net/bluetooth/hci_sock.c:1839\n sock_sendmsg_nosec net/socket.c:727 [inline]\n __sock_sendmsg+0x21c/0x270 net/socket.c:742\n sock_write_iter+0x279/0x360 net/socket.c:1195\n\nFreed by task 5991:\n mgmt_pending_free net/bluetooth/mgmt_util.c:311 [inline]\n mgmt_pending_foreach+0x30d/0x380 net/bluetooth/mgmt_util.c:257\n mgmt_index_removed+0x112/0x2f0 net/bluetooth/mgmt.c:9477\n hci_sock_bind+0xbe9/0x1000 net/bluetooth/hci_sock.c:1314(CVE-2025-68305)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ns390/pci: Avoid deadlock between PCI error recovery and mlx5 crdump\n\nDo not block PCI config accesses through pci_cfg_access_lock() when\nexecuting the s390 variant of PCI error recovery: Acquire just\ndevice_lock() instead of pci_dev_lock() as powerpc\u0026apos;s EEH and\ngenerig PCI AER processing do.\n\nDuring error recovery testing a pair of tasks was reported to be hung:\n\nmlx5_core 0000:00:00.1: mlx5_health_try_recover:338:(pid 5553): health recovery flow aborted, PCI reads still not working\nINFO: task kmcheck:72 blocked for more than 122 seconds.\n      Not tainted 5.14.0-570.12.1.bringup7.el9.s390x #1\n\u0026quot;echo 0 \u0026gt; /proc/sys/kernel/hung_task_timeout_secs\u0026quot; disables this message.\ntask:kmcheck         state:D stack:0     pid:72    tgid:72    ppid:2      flags:0x00000000\nCall Trace:\n [\u0026lt;000000065256f030\u0026gt;] __schedule+0x2a0/0x590\n [\u0026lt;000000065256f356\u0026gt;] schedule+0x36/0xe0\n [\u0026lt;000000065256f572\u0026gt;] schedule_preempt_disabled+0x22/0x30\n [\u0026lt;0000000652570a94\u0026gt;] __mutex_lock.constprop.0+0x484/0x8a8\n [\u0026lt;000003ff800673a4\u0026gt;] mlx5_unload_one+0x34/0x58 [mlx5_core]\n [\u0026lt;000003ff8006745c\u0026gt;] mlx5_pci_err_detected+0x94/0x140 [mlx5_core]\n [\u0026lt;0000000652556c5a\u0026gt;] zpci_event_attempt_error_recovery+0xf2/0x398\n [\u0026lt;0000000651b9184a\u0026gt;] __zpci_event_error+0x23a/0x2c0\nINFO: task kworker/u1664:6:1514 blocked for more than 122 seconds.\n      Not tainted 5.14.0-570.12.1.bringup7.el9.s390x #1\n\u0026quot;echo 0 \u0026gt; /proc/sys/kernel/hung_task_timeout_secs\u0026quot; disables this message.\ntask:kworker/u1664:6 state:D stack:0     pid:1514  tgid:1514  ppid:2      flags:0x00000000\nWorkqueue: mlx5_health0000:00:00.0 mlx5_fw_fatal_reporter_err_work [mlx5_core]\nCall Trace:\n [\u0026lt;000000065256f030\u0026gt;] __schedule+0x2a0/0x590\n [\u0026lt;000000065256f356\u0026gt;] schedule+0x36/0xe0\n [\u0026lt;0000000652172e28\u0026gt;] pci_wait_cfg+0x80/0xe8\n [\u0026lt;0000000652172f94\u0026gt;] pci_cfg_access_lock+0x74/0x88\n [\u0026lt;000003ff800916b6\u0026gt;] mlx5_vsc_gw_lock+0x36/0x178 [mlx5_core]\n [\u0026lt;000003ff80098824\u0026gt;] mlx5_crdump_collect+0x34/0x1c8 [mlx5_core]\n [\u0026lt;000003ff80074b62\u0026gt;] mlx5_fw_fatal_reporter_dump+0x6a/0xe8 [mlx5_core]\n [\u0026lt;0000000652512242\u0026gt;] devlink_health_do_dump.part.0+0x82/0x168\n [\u0026lt;0000000652513212\u0026gt;] devlink_health_report+0x19a/0x230\n [\u0026lt;000003ff80075a12\u0026gt;] mlx5_fw_fatal_reporter_err_work+0xba/0x1b0 [mlx5_core]\n\nNo kernel log of the exact same error with an upstream kernel is\navailable - but the very same deadlock situation can be constructed there,\ntoo:\n\n- task: kmcheck\n  mlx5_unload_one() tries to acquire devlink lock while the PCI error\n  recovery code has set pdev-\u0026gt;block_cfg_access by way of\n  pci_cfg_access_lock()\n- task: kworker\n  mlx5_crdump_collect() tries to set block_cfg_access through\n  pci_cfg_access_lock() while devlink_health_report() had acquired\n  the devlink lock.\n\nA similar deadlock situation can be reproduced by requesting a\ncrdump with\n  \u0026gt; devlink health dump show pci/\u0026lt;BDF\u0026gt; reporter fw_fatal\n\nwhile PCI error recovery is executed on the same \u0026lt;BDF\u0026gt; physical function\nby mlx5_core\u0026apos;s pci_error_handlers. On s390 this can be injected with\n  \u0026gt; zpcictl --reset-fw \u0026lt;BDF\u0026gt;\n\nTests with this patch failed to reproduce that second deadlock situation,\nthe devlink command is rejected with \u0026quot;kernel answers: Permission denied\u0026quot; -\nand we get a kernel log message of:\n\nmlx5_core 1ed0:00:00.1: mlx5_crdump_collect:50:(pid 254382): crdump: failed to lock vsc gw err -5\n\nbecause the config read of VSC_SEMAPHORE is rejected by the underlying\nhardware.\n\nTwo prior attempts to address this issue have been discussed and\nultimately rejected [see link], with the primary argument that s390\u0026apos;s\nimplementation of PCI error recovery is imposing restrictions that\nneither powerpc\u0026apos;s EEH nor PCI AER handling need. Tests show that PCI\nerror recovery on s390 is running to completion even without blocking\naccess to PCI config space.(CVE-2025-68310)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nusbnet: Prevents free active kevent\n\nThe root cause of this issue are:\n1. When probing the usbnet device, executing usbnet_link_change(dev, 0, 0);\nput the kevent work in global workqueue. However, the kevent has not yet\nbeen scheduled when the usbnet device is unregistered. Therefore, executing\nfree_netdev() results in the \u0026quot;free active object (kevent)\u0026quot; error reported\nhere.\n\n2. Another factor is that when calling usbnet_disconnect()-\u0026gt;unregister_netdev(),\nif the usbnet device is up, ndo_stop() is executed to cancel the kevent.\nHowever, because the device is not up, ndo_stop() is not executed.\n\nThe solution to this problem is to cancel the kevent before executing\nfree_netdev().(CVE-2025-68312)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnbd: defer config unlock in nbd_genl_connect\n\nThere is one use-after-free warning when running NBD_CMD_CONNECT and\nNBD_CLEAR_SOCK:\n\nnbd_genl_connect\n  nbd_alloc_and_init_config // config_refs=1\n  nbd_start_device // config_refs=2\n  set NBD_RT_HAS_CONFIG_REF\t\t\topen nbd // config_refs=3\n  recv_work done // config_refs=2\n\t\t\t\t\t\tNBD_CLEAR_SOCK // config_refs=1\n\t\t\t\t\t\tclose nbd // config_refs=0\n  refcount_inc -\u0026gt; uaf\n\n------------[ cut here ]------------\nrefcount_t: addition on 0; use-after-free.\nWARNING: CPU: 24 PID: 1014 at lib/refcount.c:25 refcount_warn_saturate+0x12e/0x290\n nbd_genl_connect+0x16d0/0x1ab0\n genl_family_rcv_msg_doit+0x1f3/0x310\n genl_rcv_msg+0x44a/0x790\n\nThe issue can be easily reproduced by adding a small delay before\nrefcount_inc(\u0026amp;nbd-\u0026gt;config_refs) in nbd_genl_connect():\n\n        mutex_unlock(\u0026amp;nbd-\u0026gt;config_lock);\n        if (!ret) {\n                set_bit(NBD_RT_HAS_CONFIG_REF, \u0026amp;config-\u0026gt;runtime_flags);\n+               printk(\u0026quot;before sleep\\n\u0026quot;);\n+               mdelay(5 * 1000);\n+               printk(\u0026quot;after sleep\\n\u0026quot;);\n                refcount_inc(\u0026amp;nbd-\u0026gt;config_refs);\n                nbd_connect_reply(info, nbd-\u0026gt;index);\n        }(CVE-2025-68366)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmacintosh/mac_hid: fix race condition in mac_hid_toggle_emumouse\n\nThe following warning appears when running syzkaller, and this issue also\nexists in the mainline code.\n\n ------------[ cut here ]------------\n list_add double add: new=ffffffffa57eee28, prev=ffffffffa57eee28, next=ffffffffa5e63100.\n WARNING: CPU: 0 PID: 1491 at lib/list_debug.c:35 __list_add_valid_or_report+0xf7/0x130\n Modules linked in:\n CPU: 0 PID: 1491 Comm: syz.1.28 Not tainted 6.6.0+ #3\n Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014\n RIP: 0010:__list_add_valid_or_report+0xf7/0x130\n RSP: 0018:ff1100010dfb7b78 EFLAGS: 00010282\n RAX: 0000000000000000 RBX: ffffffffa57eee18 RCX: ffffffff97fc9817\n RDX: 0000000000040000 RSI: ffa0000002383000 RDI: 0000000000000001\n RBP: ffffffffa57eee28 R08: 0000000000000001 R09: ffe21c0021bf6f2c\n R10: 0000000000000001 R11: 6464615f7473696c R12: ffffffffa5e63100\n R13: ffffffffa57eee28 R14: ffffffffa57eee28 R15: ff1100010dfb7d48\n FS:  00007fb14398b640(0000) GS:ff11000119600000(0000) knlGS:0000000000000000\n CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 0000000000000000 CR3: 000000010d096005 CR4: 0000000000773ef0\n DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n PKRU: 80000000\n Call Trace:\n  \u0026lt;TASK\u0026gt;\n  input_register_handler+0xb3/0x210\n  mac_hid_start_emulation+0x1c5/0x290\n  mac_hid_toggle_emumouse+0x20a/0x240\n  proc_sys_call_handler+0x4c2/0x6e0\n  new_sync_write+0x1b1/0x2d0\n  vfs_write+0x709/0x950\n  ksys_write+0x12a/0x250\n  do_syscall_64+0x5a/0x110\n  entry_SYSCALL_64_after_hwframe+0x78/0xe2\n\nThe WARNING occurs when two processes concurrently write to the mac-hid\nemulation sysctl, causing a race condition in mac_hid_toggle_emumouse().\nBoth processes read old_val=0, then both try to register the input handler,\nleading to a double list_add of the same handler.\n\n  CPU0                             CPU1\n  -------------------------        -------------------------\n  vfs_write() //write 1            vfs_write()  //write 1\n    proc_sys_write()                 proc_sys_write()\n      mac_hid_toggle_emumouse()          mac_hid_toggle_emumouse()\n        old_val = *valp // old_val=0\n                                           old_val = *valp // old_val=0\n                                           mutex_lock_killable()\n                                           proc_dointvec() // *valp=1\n                                           mac_hid_start_emulation()\n                                             input_register_handler()\n                                           mutex_unlock()\n        mutex_lock_killable()\n        proc_dointvec()\n        mac_hid_start_emulation()\n          input_register_handler() //Trigger Warning\n        mutex_unlock()\n\nFix this by moving the old_val read inside the mutex lock region.(CVE-2025-68367)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: smartpqi: Fix device resources accessed after device removal\n\nCorrect possible race conditions during device removal.\n\nPreviously, a scheduled work item to reset a LUN could still execute\nafter the device was removed, leading to use-after-free and other\nresource access issues.\n\nThis race condition occurs because the abort handler may schedule a LUN\nreset concurrently with device removal via sdev_destroy(), leading to\nuse-after-free and improper access to freed resources.\n\n  - Check in the device reset handler if the device is still present in\n    the controller\u0026apos;s SCSI device list before running; if not, the reset\n    is skipped.\n\n  - Cancel any pending TMF work that has not started in sdev_destroy().\n\n  - Ensure device freeing in sdev_destroy() is done while holding the\n    LUN reset mutex to avoid races with ongoing resets.(CVE-2025-68371)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnbd: defer config put in recv_work\n\nThere is one uaf issue in recv_work when running NBD_CLEAR_SOCK and\nNBD_CMD_RECONFIGURE:\n  nbd_genl_connect     // conf_ref=2 (connect and recv_work A)\n  nbd_open\t       // conf_ref=3\n  recv_work A done     // conf_ref=2\n  NBD_CLEAR_SOCK       // conf_ref=1\n  nbd_genl_reconfigure // conf_ref=2 (trigger recv_work B)\n  close nbd\t       // conf_ref=1\n  recv_work B\n    config_put         // conf_ref=0\n    atomic_dec(\u0026amp;config-\u0026gt;recv_threads); -\u0026gt; UAF\n\nOr only running NBD_CLEAR_SOCK:\n  nbd_genl_connect   // conf_ref=2\n  nbd_open \t     // conf_ref=3\n  NBD_CLEAR_SOCK     // conf_ref=2\n  close nbd\n    nbd_release\n      config_put     // conf_ref=1\n  recv_work\n    config_put \t     // conf_ref=0\n    atomic_dec(\u0026amp;config-\u0026gt;recv_threads); -\u0026gt; UAF\n\nCommit 87aac3a80af5 (\u0026quot;nbd: call nbd_config_put() before notifying the\nwaiter\u0026quot;) moved nbd_config_put() to run before waking up the waiter in\nrecv_work, in order to ensure that nbd_start_device_ioctl() would not\nbe woken up while nbd-\u0026gt;task_recv was still uncleared.\n\nHowever, in nbd_start_device_ioctl(), after being woken up it explicitly\ncalls flush_workqueue() to make sure all current works are finished.\nTherefore, there is no need to move the config put ahead of the wakeup.\n\nMove nbd_config_put() to the end of recv_work, so that the reference is\nheld for the whole lifetime of the worker thread. This makes sure the\nconfig cannot be freed while recv_work is still running, even if clear\n+ reconfigure interleave.\n\nIn addition, we don\u0026apos;t need to worry about recv_work dropping the last\nnbd_put (which causes deadlock):\n\npath A (netlink with NBD_CFLAG_DESTROY_ON_DISCONNECT):\n  connect  // nbd_refs=1 (trigger recv_work)\n  open nbd // nbd_refs=2\n  NBD_CLEAR_SOCK\n  close nbd\n    nbd_release\n      nbd_disconnect_and_put\n        flush_workqueue // recv_work done\n      nbd_config_put\n        nbd_put // nbd_refs=1\n      nbd_put // nbd_refs=0\n        queue_work\n\npath B (netlink without NBD_CFLAG_DESTROY_ON_DISCONNECT):\n  connect  // nbd_refs=2 (trigger recv_work)\n  open nbd // nbd_refs=3\n  NBD_CLEAR_SOCK // conf_refs=2\n  close nbd\n    nbd_release\n      nbd_config_put // conf_refs=1\n      nbd_put // nbd_refs=2\n  recv_work done // conf_refs=0, nbd_refs=1\n  rmmod // nbd_refs=0\n\nDepends-on: e2daec488c57 (\u0026quot;nbd: Fix hungtask when nbd_config_put\u0026quot;)(CVE-2025-68372)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmd: fix rcu protection in md_wakeup_thread\n\nWe attempted to use RCU to protect the pointer \u0026apos;thread\u0026apos;, but directly\npassed the value when calling md_wakeup_thread(). This means that the\nRCU pointer has been acquired before rcu_read_lock(), which renders\nrcu_read_lock() ineffective and could lead to a use-after-free.(CVE-2025-68374)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/rxe: Fix null deref on srq-\u0026gt;rq.queue after resize failure\n\nA NULL pointer dereference can occur in rxe_srq_chk_attr() when\nibv_modify_srq() is invoked twice in succession under certain error\nconditions. The first call may fail in rxe_queue_resize(), which leads\nrxe_srq_from_attr() to set srq-\u0026gt;rq.queue = NULL. The second call then\ntriggers a crash (null deref) when accessing\nsrq-\u0026gt;rq.queue-\u0026gt;buf-\u0026gt;index_mask.\n\nCall Trace:\n\u0026lt;TASK\u0026gt;\nrxe_modify_srq+0x170/0x480 [rdma_rxe]\n? __pfx_rxe_modify_srq+0x10/0x10 [rdma_rxe]\n? uverbs_try_lock_object+0x4f/0xa0 [ib_uverbs]\n? rdma_lookup_get_uobject+0x1f0/0x380 [ib_uverbs]\nib_uverbs_modify_srq+0x204/0x290 [ib_uverbs]\n? __pfx_ib_uverbs_modify_srq+0x10/0x10 [ib_uverbs]\n? tryinc_node_nr_active+0xe6/0x150\n? uverbs_fill_udata+0xed/0x4f0 [ib_uverbs]\nib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x2c0/0x470 [ib_uverbs]\n? __pfx_ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x10/0x10 [ib_uverbs]\n? uverbs_fill_udata+0xed/0x4f0 [ib_uverbs]\nib_uverbs_run_method+0x55a/0x6e0 [ib_uverbs]\n? __pfx_ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x10/0x10 [ib_uverbs]\nib_uverbs_cmd_verbs+0x54d/0x800 [ib_uverbs]\n? __pfx_ib_uverbs_cmd_verbs+0x10/0x10 [ib_uverbs]\n? __pfx___raw_spin_lock_irqsave+0x10/0x10\n? __pfx_do_vfs_ioctl+0x10/0x10\n? ioctl_has_perm.constprop.0.isra.0+0x2c7/0x4c0\n? __pfx_ioctl_has_perm.constprop.0.isra.0+0x10/0x10\nib_uverbs_ioctl+0x13e/0x220 [ib_uverbs]\n? __pfx_ib_uverbs_ioctl+0x10/0x10 [ib_uverbs]\n__x64_sys_ioctl+0x138/0x1c0\ndo_syscall_64+0x82/0x250\n? fdget_pos+0x58/0x4c0\n? ksys_write+0xf3/0x1c0\n? __pfx_ksys_write+0x10/0x10\n? do_syscall_64+0xc8/0x250\n? __pfx_vm_mmap_pgoff+0x10/0x10\n? fget+0x173/0x230\n? fput+0x2a/0x80\n? ksys_mmap_pgoff+0x224/0x4c0\n? do_syscall_64+0xc8/0x250\n? do_user_addr_fault+0x37b/0xfe0\n? clear_bhb_loop+0x50/0xa0\n? clear_bhb_loop+0x50/0xa0\n? clear_bhb_loop+0x50/0xa0\nentry_SYSCALL_64_after_hwframe+0x76/0x7e(CVE-2025-68379)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nNFS: Automounted filesystems should inherit ro,noexec,nodev,sync flags\n\nWhen a filesystem is being automounted, it needs to preserve the\nuser-set superblock mount options, such as the \u0026quot;ro\u0026quot; flag.(CVE-2025-68764)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfsnotify: do not generate ACCESS/MODIFY events on child for special files\n\ninotify/fanotify do not allow users with no read access to a file to\nsubscribe to events (e.g. IN_ACCESS/IN_MODIFY), but they do allow the\nsame user to subscribe for watching events on children when the user\nhas access to the parent directory (e.g. /dev).\n\nUsers with no read access to a file but with read access to its parent\ndirectory can still stat the file and see if it was accessed/modified\nvia atime/mtime change.\n\nThe same is not true for special files (e.g. /dev/null). Users will not\ngenerally observe atime/mtime changes when other users read/write to\nspecial files, only when someone sets atime/mtime via utimensat().\n\nAlign fsnotify events with this stat behavior and do not generate\nACCESS/MODIFY events to parent watchers on read/write of special files.\nThe events are still generated to parent watchers on utimensat(). This\ncloses some side-channels that could be possibly used for information\nexfiltration [1].\n\n[1] https://snee.la/pdf/pubs/file-notification-attacks.pdf(CVE-2025-68788)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfuse: missing copy_finish in fuse-over-io-uring argument copies\n\nFix a possible reference count leak of payload pages during\nfuse argument copies.\n\n[Joanne: simplified error cleanup](CVE-2025-68791)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nperf/x86/amd: Check event before enable to avoid GPF\n\nOn AMD machines cpuc-\u0026gt;events[idx] can become NULL in a subtle race\ncondition with NMI-\u0026gt;throttle-\u0026gt;x86_pmu_stop().\n\nCheck event for NULL in amd_pmu_enable_all() before enable to avoid a GPF.\nThis appears to be an AMD only issue.\n\nSyzkaller reported a GPF in amd_pmu_enable_all.\n\nINFO: NMI handler (perf_event_nmi_handler) took too long to run: 13.143\n    msecs\nOops: general protection fault, probably for non-canonical address\n    0xdffffc0000000034: 0000  PREEMPT SMP KASAN NOPTI\nKASAN: null-ptr-deref in range [0x00000000000001a0-0x00000000000001a7]\nCPU: 0 UID: 0 PID: 328415 Comm: repro_36674776 Not tainted 6.12.0-rc1-syzk\nRIP: 0010:x86_pmu_enable_event (arch/x86/events/perf_event.h:1195\n    arch/x86/events/core.c:1430)\nRSP: 0018:ffff888118009d60 EFLAGS: 00010012\nRAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000000\nRDX: 0000000000000034 RSI: 0000000000000000 RDI: 00000000000001a0\nRBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000000\nR10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000002\nR13: ffff88811802a440 R14: ffff88811802a240 R15: ffff8881132d8601\nFS:  00007f097dfaa700(0000) GS:ffff888118000000(0000) GS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00000000200001c0 CR3: 0000000103d56000 CR4: 00000000000006f0\nCall Trace:\n \u0026lt;IRQ\u0026gt;\namd_pmu_enable_all (arch/x86/events/amd/core.c:760 (discriminator 2))\nx86_pmu_enable (arch/x86/events/core.c:1360)\nevent_sched_out (kernel/events/core.c:1191 kernel/events/core.c:1186\n    kernel/events/core.c:2346)\n__perf_remove_from_context (kernel/events/core.c:2435)\nevent_function (kernel/events/core.c:259)\nremote_function (kernel/events/core.c:92 (discriminator 1)\n    kernel/events/core.c:72 (discriminator 1))\n__flush_smp_call_function_queue (./arch/x86/include/asm/jump_label.h:27\n    ./include/linux/jump_label.h:207 ./include/trace/events/csd.h:64\n    kernel/smp.c:135 kernel/smp.c:540)\n__sysvec_call_function_single (./arch/x86/include/asm/jump_label.h:27\n    ./include/linux/jump_label.h:207\n    ./arch/x86/include/asm/trace/irq_vectors.h:99 arch/x86/kernel/smp.c:272)\nsysvec_call_function_single (arch/x86/kernel/smp.c:266 (discriminator 47)\n    arch/x86/kernel/smp.c:266 (discriminator 47))\n \u0026lt;/IRQ\u0026gt;(CVE-2025-68798)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmlxsw: spectrum_mr: Fix use-after-free when updating multicast route stats\n\nCited commit added a dedicated mutex (instead of RTNL) to protect the\nmulticast route list, so that it will not change while the driver\nperiodically traverses it in order to update the kernel about multicast\nroute stats that were queried from the device.\n\nOne instance of list entry deletion (during route replace) was missed\nand it can result in a use-after-free [1].\n\nFix by acquiring the mutex before deleting the entry from the list and\nreleasing it afterwards.\n\n[1]\nBUG: KASAN: slab-use-after-free in mlxsw_sp_mr_stats_update+0x4a5/0x540 drivers/net/ethernet/mellanox/mlxsw/spectrum_mr.c:1006 [mlxsw_spectrum]\nRead of size 8 at addr ffff8881523c2fa8 by task kworker/2:5/22043\n\nCPU: 2 UID: 0 PID: 22043 Comm: kworker/2:5 Not tainted 6.18.0-rc1-custom-g1a3d6d7cd014 #1 PREEMPT(full)\nHardware name: Mellanox Technologies Ltd. MSN2010/SA002610, BIOS 5.6.5 08/24/2017\nWorkqueue: mlxsw_core mlxsw_sp_mr_stats_update [mlxsw_spectrum]\nCall Trace:\n \u0026lt;TASK\u0026gt;\n dump_stack_lvl+0xba/0x110\n print_report+0x174/0x4f5\n kasan_report+0xdf/0x110\n mlxsw_sp_mr_stats_update+0x4a5/0x540 drivers/net/ethernet/mellanox/mlxsw/spectrum_mr.c:1006 [mlxsw_spectrum]\n process_one_work+0x9cc/0x18e0\n worker_thread+0x5df/0xe40\n kthread+0x3b8/0x730\n ret_from_fork+0x3e9/0x560\n ret_from_fork_asm+0x1a/0x30\n \u0026lt;/TASK\u0026gt;\n\nAllocated by task 29933:\n kasan_save_stack+0x30/0x50\n kasan_save_track+0x14/0x30\n __kasan_kmalloc+0x8f/0xa0\n mlxsw_sp_mr_route_add+0xd8/0x4770 [mlxsw_spectrum]\n mlxsw_sp_router_fibmr_event_work+0x371/0xad0 drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c:7965 [mlxsw_spectrum]\n process_one_work+0x9cc/0x18e0\n worker_thread+0x5df/0xe40\n kthread+0x3b8/0x730\n ret_from_fork+0x3e9/0x560\n ret_from_fork_asm+0x1a/0x30\n\nFreed by task 29933:\n kasan_save_stack+0x30/0x50\n kasan_save_track+0x14/0x30\n __kasan_save_free_info+0x3b/0x70\n __kasan_slab_free+0x43/0x70\n kfree+0x14e/0x700\n mlxsw_sp_mr_route_add+0x2dea/0x4770 drivers/net/ethernet/mellanox/mlxsw/spectrum_mr.c:444 [mlxsw_spectrum]\n mlxsw_sp_router_fibmr_event_work+0x371/0xad0 drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c:7965 [mlxsw_spectrum]\n process_one_work+0x9cc/0x18e0\n worker_thread+0x5df/0xe40\n kthread+0x3b8/0x730\n ret_from_fork+0x3e9/0x560\n ret_from_fork_asm+0x1a/0x30(CVE-2025-68800)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmlxsw: spectrum_router: Fix neighbour use-after-free\n\nWe sometimes observe use-after-free when dereferencing a neighbour [1].\nThe problem seems to be that the driver stores a pointer to the\nneighbour, but without holding a reference on it. A reference is only\ntaken when the neighbour is used by a nexthop.\n\nFix by simplifying the reference counting scheme. Always take a\nreference when storing a neighbour pointer in a neighbour entry. Avoid\ntaking a referencing when the neighbour is used by a nexthop as the\nneighbour entry associated with the nexthop already holds a reference.\n\nTested by running the test that uncovered the problem over 300 times.\nWithout this patch the problem was reproduced after a handful of\niterations.\n\n[1]\nBUG: KASAN: slab-use-after-free in mlxsw_sp_neigh_entry_update+0x2d4/0x310\nRead of size 8 at addr ffff88817f8e3420 by task ip/3929\n\nCPU: 3 UID: 0 PID: 3929 Comm: ip Not tainted 6.18.0-rc4-virtme-g36b21a067510 #3 PREEMPT(full)\nHardware name: Nvidia SN5600/VMOD0013, BIOS 5.13 05/31/2023\nCall Trace:\n \u0026lt;TASK\u0026gt;\n dump_stack_lvl+0x6f/0xa0\n print_address_description.constprop.0+0x6e/0x300\n print_report+0xfc/0x1fb\n kasan_report+0xe4/0x110\n mlxsw_sp_neigh_entry_update+0x2d4/0x310\n mlxsw_sp_router_rif_gone_sync+0x35f/0x510\n mlxsw_sp_rif_destroy+0x1ea/0x730\n mlxsw_sp_inetaddr_port_vlan_event+0xa1/0x1b0\n __mlxsw_sp_inetaddr_lag_event+0xcc/0x130\n __mlxsw_sp_inetaddr_event+0xf5/0x3c0\n mlxsw_sp_router_netdevice_event+0x1015/0x1580\n notifier_call_chain+0xcc/0x150\n call_netdevice_notifiers_info+0x7e/0x100\n __netdev_upper_dev_unlink+0x10b/0x210\n netdev_upper_dev_unlink+0x79/0xa0\n vrf_del_slave+0x18/0x50\n do_set_master+0x146/0x7d0\n do_setlink.isra.0+0x9a0/0x2880\n rtnl_newlink+0x637/0xb20\n rtnetlink_rcv_msg+0x6fe/0xb90\n netlink_rcv_skb+0x123/0x380\n netlink_unicast+0x4a3/0x770\n netlink_sendmsg+0x75b/0xc90\n __sock_sendmsg+0xbe/0x160\n ____sys_sendmsg+0x5b2/0x7d0\n ___sys_sendmsg+0xfd/0x180\n __sys_sendmsg+0x124/0x1c0\n do_syscall_64+0xbb/0xfd0\n entry_SYSCALL_64_after_hwframe+0x4b/0x53\n[...]\n\nAllocated by task 109:\n kasan_save_stack+0x30/0x50\n kasan_save_track+0x14/0x30\n __kasan_kmalloc+0x7b/0x90\n __kmalloc_noprof+0x2c1/0x790\n neigh_alloc+0x6af/0x8f0\n ___neigh_create+0x63/0xe90\n mlxsw_sp_nexthop_neigh_init+0x430/0x7e0\n mlxsw_sp_nexthop_type_init+0x212/0x960\n mlxsw_sp_nexthop6_group_info_init.constprop.0+0x81f/0x1280\n mlxsw_sp_nexthop6_group_get+0x392/0x6a0\n mlxsw_sp_fib6_entry_create+0x46a/0xfd0\n mlxsw_sp_router_fib6_replace+0x1ed/0x5f0\n mlxsw_sp_router_fib6_event_work+0x10a/0x2a0\n process_one_work+0xd57/0x1390\n worker_thread+0x4d6/0xd40\n kthread+0x355/0x5b0\n ret_from_fork+0x1d4/0x270\n ret_from_fork_asm+0x11/0x20\n\nFreed by task 154:\n kasan_save_stack+0x30/0x50\n kasan_save_track+0x14/0x30\n __kasan_save_free_info+0x3b/0x60\n __kasan_slab_free+0x43/0x70\n kmem_cache_free_bulk.part.0+0x1eb/0x5e0\n kvfree_rcu_bulk+0x1f2/0x260\n kfree_rcu_work+0x130/0x1b0\n process_one_work+0xd57/0x1390\n worker_thread+0x4d6/0xd40\n kthread+0x355/0x5b0\n ret_from_fork+0x1d4/0x270\n ret_from_fork_asm+0x11/0x20\n\nLast potentially related work creation:\n kasan_save_stack+0x30/0x50\n kasan_record_aux_stack+0x8c/0xa0\n kvfree_call_rcu+0x93/0x5b0\n mlxsw_sp_router_neigh_event_work+0x67d/0x860\n process_one_work+0xd57/0x1390\n worker_thread+0x4d6/0xd40\n kthread+0x355/0x5b0\n ret_from_fork+0x1d4/0x270\n ret_from_fork_asm+0x11/0x20(CVE-2025-68801)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfuse: fix io-uring list corruption for terminated non-committed requests\n\nWhen a request is terminated before it has been committed, the request\nis not removed from the queue\u0026apos;s list. This leaves a dangling list entry\nthat leads to list corruption and use-after-free issues.\n\nRemove the request from the queue\u0026apos;s list for terminated non-committed\nrequests.(CVE-2025-68805)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfuse: fix readahead reclaim deadlock\n\nCommit e26ee4efbc79 (\u0026quot;fuse: allocate ff-\u0026gt;release_args only if release is\nneeded\u0026quot;) skips allocating ff-\u0026gt;release_args if the server does not\nimplement open. However in doing so, fuse_prepare_release() now skips\ngrabbing the reference on the inode, which makes it possible for an\ninode to be evicted from the dcache while there are inflight readahead\nrequests. This causes a deadlock if the server triggers reclaim while\nservicing the readahead request and reclaim attempts to evict the inode\nof the file being read ahead. Since the folio is locked during\nreadahead, when reclaim evicts the fuse inode and fuse_evict_inode()\nattempts to remove all folios associated with the inode from the page\ncache (truncate_inode_pages_range()), reclaim will block forever waiting\nfor the lock since readahead cannot relinquish the lock because it is\nitself blocked in reclaim:\n\n\u0026gt;\u0026gt;\u0026gt; stack_trace(1504735)\n folio_wait_bit_common (mm/filemap.c:1308:4)\n folio_lock (./include/linux/pagemap.h:1052:3)\n truncate_inode_pages_range (mm/truncate.c:336:10)\n fuse_evict_inode (fs/fuse/inode.c:161:2)\n evict (fs/inode.c:704:3)\n dentry_unlink_inode (fs/dcache.c:412:3)\n __dentry_kill (fs/dcache.c:615:3)\n shrink_kill (fs/dcache.c:1060:12)\n shrink_dentry_list (fs/dcache.c:1087:3)\n prune_dcache_sb (fs/dcache.c:1168:2)\n super_cache_scan (fs/super.c:221:10)\n do_shrink_slab (mm/shrinker.c:435:9)\n shrink_slab (mm/shrinker.c:626:10)\n shrink_node (mm/vmscan.c:5951:2)\n shrink_zones (mm/vmscan.c:6195:3)\n do_try_to_free_pages (mm/vmscan.c:6257:3)\n do_swap_page (mm/memory.c:4136:11)\n handle_pte_fault (mm/memory.c:5562:10)\n handle_mm_fault (mm/memory.c:5870:9)\n do_user_addr_fault (arch/x86/mm/fault.c:1338:10)\n handle_page_fault (arch/x86/mm/fault.c:1481:3)\n exc_page_fault (arch/x86/mm/fault.c:1539:2)\n asm_exc_page_fault+0x22/0x27\n\nFix this deadlock by allocating ff-\u0026gt;release_args and grabbing the\nreference on the inode when preparing the file for release even if the\nserver does not implement open. The inode reference will be dropped when\nthe last reference on the fuse file is dropped (see fuse_file_put() -\u0026gt;\nfuse_release_end()).(CVE-2025-68821)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\niavf: fix off-by-one issues in iavf_config_rss_reg()\n\nThere are off-by-one bugs when configuring RSS hash key and lookup\ntable, causing out-of-bounds reads to memory [1] and out-of-bounds\nwrites to device registers.\n\nBefore commit 43a3d9ba34c9 (\u0026quot;i40evf: Allow PF driver to configure RSS\u0026quot;),\nthe loop upper bounds were:\n    i \u0026lt;= I40E_VFQF_{HKEY,HLUT}_MAX_INDEX\nwhich is safe since the value is the last valid index.\n\nThat commit changed the bounds to:\n    i \u0026lt;= adapter-\u0026gt;rss_{key,lut}_size / 4\nwhere `rss_{key,lut}_size / 4` is the number of dwords, so the last\nvalid index is `(rss_{key,lut}_size / 4) - 1`. Therefore, using `\u0026lt;=`\naccesses one element past the end.\n\nFix the issues by using `\u0026lt;` instead of `\u0026lt;=`, ensuring we do not exceed\nthe bounds.\n\n[1] KASAN splat about rss_key_size off-by-one\n  BUG: KASAN: slab-out-of-bounds in iavf_config_rss+0x619/0x800\n  Read of size 4 at addr ffff888102c50134 by task kworker/u8:6/63\n\n  CPU: 0 UID: 0 PID: 63 Comm: kworker/u8:6 Not tainted 6.18.0-rc2-enjuk-tnguy-00378-g3005f5b77652-dirty #156 PREEMPT(voluntary)\n  Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014\n  Workqueue: iavf iavf_watchdog_task\n  Call Trace:\n   \u0026lt;TASK\u0026gt;\n   dump_stack_lvl+0x6f/0xb0\n   print_report+0x170/0x4f3\n   kasan_report+0xe1/0x1a0\n   iavf_config_rss+0x619/0x800\n   iavf_watchdog_task+0x2be7/0x3230\n   process_one_work+0x7fd/0x1420\n   worker_thread+0x4d1/0xd40\n   kthread+0x344/0x660\n   ret_from_fork+0x249/0x320\n   ret_from_fork_asm+0x1a/0x30\n   \u0026lt;/TASK\u0026gt;\n\n  Allocated by task 63:\n   kasan_save_stack+0x30/0x50\n   kasan_save_track+0x14/0x30\n   __kasan_kmalloc+0x7f/0x90\n   __kmalloc_noprof+0x246/0x6f0\n   iavf_watchdog_task+0x28fc/0x3230\n   process_one_work+0x7fd/0x1420\n   worker_thread+0x4d1/0xd40\n   kthread+0x344/0x660\n   ret_from_fork+0x249/0x320\n   ret_from_fork_asm+0x1a/0x30\n\n  The buggy address belongs to the object at ffff888102c50100\n   which belongs to the cache kmalloc-64 of size 64\n  The buggy address is located 0 bytes to the right of\n   allocated 52-byte region [ffff888102c50100, ffff888102c50134)\n\n  The buggy address belongs to the physical page:\n  page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x102c50\n  flags: 0x200000000000000(node=0|zone=2)\n  page_type: f5(slab)\n  raw: 0200000000000000 ffff8881000418c0 dead000000000122 0000000000000000\n  raw: 0000000000000000 0000000080200020 00000000f5000000 0000000000000000\n  page dumped because: kasan: bad access detected\n\n  Memory state around the buggy address:\n   ffff888102c50000: 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc fc\n   ffff888102c50080: 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc fc\n  \u0026gt;ffff888102c50100: 00 00 00 00 00 00 04 fc fc fc fc fc fc fc fc fc\n                                       ^\n   ffff888102c50180: 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc\n   ffff888102c50200: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc(CVE-2025-71087)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ne1000: fix OOB in e1000_tbi_should_accept()\n\nIn e1000_tbi_should_accept() we read the last byte of the frame via\n\u0026apos;data[length - 1]\u0026apos; to evaluate the TBI workaround. If the descriptor-\nreported length is zero or larger than the actual RX buffer size, this\nread goes out of bounds and can hit unrelated slab objects. The issue\nis observed from the NAPI receive path (e1000_clean_rx_irq):\n\n==================================================================\nBUG: KASAN: slab-out-of-bounds in e1000_tbi_should_accept+0x610/0x790\nRead of size 1 at addr ffff888014114e54 by task sshd/363\n\nCPU: 0 PID: 363 Comm: sshd Not tainted 5.18.0-rc1 #1\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014\nCall Trace:\n \u0026lt;IRQ\u0026gt;\n dump_stack_lvl+0x5a/0x74\n print_address_description+0x7b/0x440\n print_report+0x101/0x200\n kasan_report+0xc1/0xf0\n e1000_tbi_should_accept+0x610/0x790\n e1000_clean_rx_irq+0xa8c/0x1110\n e1000_clean+0xde2/0x3c10\n __napi_poll+0x98/0x380\n net_rx_action+0x491/0xa20\n __do_softirq+0x2c9/0x61d\n do_softirq+0xd1/0x120\n \u0026lt;/IRQ\u0026gt;\n \u0026lt;TASK\u0026gt;\n __local_bh_enable_ip+0xfe/0x130\n ip_finish_output2+0x7d5/0xb00\n __ip_queue_xmit+0xe24/0x1ab0\n __tcp_transmit_skb+0x1bcb/0x3340\n tcp_write_xmit+0x175d/0x6bd0\n __tcp_push_pending_frames+0x7b/0x280\n tcp_sendmsg_locked+0x2e4f/0x32d0\n tcp_sendmsg+0x24/0x40\n sock_write_iter+0x322/0x430\n vfs_write+0x56c/0xa60\n ksys_write+0xd1/0x190\n do_syscall_64+0x43/0x90\n entry_SYSCALL_64_after_hwframe+0x44/0xae\nRIP: 0033:0x7f511b476b10\nCode: 73 01 c3 48 8b 0d 88 d3 2b 00 f7 d8 64 89 01 48 83 c8 ff c3 66 0f 1f 44 00 00 83 3d f9 2b 2c 00 00 75 10 b8 01 00 00 00 0f 05 \u0026lt;48\u0026gt; 3d 01 f0 ff ff 73 31 c3 48 83 ec 08 e8 8e 9b 01 00 48 89 04 24\nRSP: 002b:00007ffc9211d4e8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001\nRAX: ffffffffffffffda RBX: 0000000000004024 RCX: 00007f511b476b10\nRDX: 0000000000004024 RSI: 0000559a9385962c RDI: 0000000000000003\nRBP: 0000559a9383a400 R08: fffffffffffffff0 R09: 0000000000004f00\nR10: 0000000000000070 R11: 0000000000000246 R12: 0000000000000000\nR13: 00007ffc9211d57f R14: 0000559a9347bde7 R15: 0000000000000003\n \u0026lt;/TASK\u0026gt;\nAllocated by task 1:\n __kasan_krealloc+0x131/0x1c0\n krealloc+0x90/0xc0\n add_sysfs_param+0xcb/0x8a0\n kernel_add_sysfs_param+0x81/0xd4\n param_sysfs_builtin+0x138/0x1a6\n param_sysfs_init+0x57/0x5b\n do_one_initcall+0x104/0x250\n do_initcall_level+0x102/0x132\n do_initcalls+0x46/0x74\n kernel_init_freeable+0x28f/0x393\n kernel_init+0x14/0x1a0\n ret_from_fork+0x22/0x30\nThe buggy address belongs to the object at ffff888014114000\n which belongs to the cache kmalloc-2k of size 2048\nThe buggy address is located 1620 bytes to the right of\n 2048-byte region [ffff888014114000, ffff888014114800]\nThe buggy address belongs to the physical page:\npage:ffffea0000504400 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x14110\nhead:ffffea0000504400 order:3 compound_mapcount:0 compound_pincount:0\nflags: 0x100000000010200(slab|head|node=0|zone=1)\nraw: 0100000000010200 0000000000000000 dead000000000001 ffff888013442000\nraw: 0000000000000000 0000000000080008 00000001ffffffff 0000000000000000\npage dumped because: kasan: bad access detected\n==================================================================\n\nThis happens because the TBI check unconditionally dereferences the last\nbyte without validating the reported length first:\n\n\tu8 last_byte = *(data + length - 1);\n\nFix by rejecting the frame early if the length is zero, or if it exceeds\nadapter-\u0026gt;rx_buffer_len. This preserves the TBI workaround semantics for\nvalid frames and prevents touching memory beyond the RX buffer.(CVE-2025-71093)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nusb: typec: ucsi: Handle incorrect num_connectors capability\n\nThe UCSI spec states that the num_connectors field is 7 bits, and the\n8th bit is reserved and should be set to zero.\nSome buggy FW has been known to set this bit, and it can lead to a\nsystem not booting.\nFlag that the FW is not behaving correctly, and auto-fix the value\nso that the system boots correctly.\n\nFound on Lenovo P1 G8 during Linux enablement program. The FW will\nbe fixed, but seemed worth addressing in case it hit platforms that\naren\u0026apos;t officially Linux supported.(CVE-2025-71108)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: af_alg - zero initialize memory allocated via sock_kmalloc\n\nSeveral crypto user API contexts and requests allocated with\nsock_kmalloc() were left uninitialized, relying on callers to\nset fields explicitly. This resulted in the use of uninitialized\ndata in certain error paths or when new fields are added in the\nfuture.\n\nThe ACVP patches also contain two user-space interface files:\nalgif_kpp.c and algif_akcipher.c. These too rely on proper\ninitialization of their context structures.\n\nA particular issue has been observed with the newly added\n\u0026apos;inflight\u0026apos; variable introduced in af_alg_ctx by commit:\n\n  67b164a871af (\u0026quot;crypto: af_alg - Disallow multiple in-flight AIO requests\u0026quot;)\n\nBecause the context is not memset to zero after allocation,\nthe inflight variable has contained garbage values. As a result,\naf_alg_alloc_areq() has incorrectly returned -EBUSY randomly when\nthe garbage value was interpreted as true:\n\n  https://github.com/gregkh/linux/blame/master/crypto/af_alg.c#L1209\n\nThe check directly tests ctx-\u0026gt;inflight without explicitly\ncomparing against true/false. Since inflight is only ever set to\ntrue or false later, an uninitialized value has triggered\n-EBUSY failures. Zero-initializing memory allocated with\nsock_kmalloc() ensures inflight and other fields start in a known\nstate, removing random issues caused by uninitialized data.(CVE-2025-71113)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\npowerpc/kexec: Enable SMT before waking offline CPUs\n\nIf SMT is disabled or a partial SMT state is enabled, when a new kernel\nimage is loaded for kexec, on reboot the following warning is observed:\n\nkexec: Waking offline cpu 228.\nWARNING: CPU: 0 PID: 9062 at arch/powerpc/kexec/core_64.c:223 kexec_prepare_cpus+0x1b0/0x1bc\n[snip]\n NIP kexec_prepare_cpus+0x1b0/0x1bc\n LR  kexec_prepare_cpus+0x1a0/0x1bc\n Call Trace:\n  kexec_prepare_cpus+0x1a0/0x1bc (unreliable)\n  default_machine_kexec+0x160/0x19c\n  machine_kexec+0x80/0x88\n  kernel_kexec+0xd0/0x118\n  __do_sys_reboot+0x210/0x2c4\n  system_call_exception+0x124/0x320\n  system_call_vectored_common+0x15c/0x2ec\n\nThis occurs as add_cpu() fails due to cpu_bootable() returning false for\nCPUs that fail the cpu_smt_thread_allowed() check or non primary\nthreads if SMT is disabled.\n\nFix the issue by enabling SMT and resetting the number of SMT threads to\nthe number of threads per core, before attempting to wake up all present\nCPUs.(CVE-2025-71119)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntracing: Do not register unsupported perf events\n\nSynthetic events currently do not have a function to register perf events.\nThis leads to calling the tracepoint register functions with a NULL\nfunction pointer which triggers:\n\n ------------[ cut here ]------------\n WARNING: kernel/tracepoint.c:175 at tracepoint_add_func+0x357/0x370, CPU#2: perf/2272\n Modules linked in: kvm_intel kvm irqbypass\n CPU: 2 UID: 0 PID: 2272 Comm: perf Not tainted 6.18.0-ftest-11964-ge022764176fc-dirty #323 PREEMPTLAZY\n Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.17.0-debian-1.17.0-1 04/01/2014\n RIP: 0010:tracepoint_add_func+0x357/0x370\n Code: 28 9c e8 4c 0b f5 ff eb 0f 4c 89 f7 48 c7 c6 80 4d 28 9c e8 ab 89 f4 ff 31 c0 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc cc \u0026lt;0f\u0026gt; 0b 49 c7 c6 ea ff ff ff e9 ee fe ff ff 0f 0b e9 f9 fe ff ff 0f\n RSP: 0018:ffffabc0c44d3c40 EFLAGS: 00010246\n RAX: 0000000000000001 RBX: ffff9380aa9e4060 RCX: 0000000000000000\n RDX: 000000000000000a RSI: ffffffff9e1d4a98 RDI: ffff937fcf5fd6c8\n RBP: 0000000000000001 R08: 0000000000000007 R09: ffff937fcf5fc780\n R10: 0000000000000003 R11: ffffffff9c193910 R12: 000000000000000a\n R13: ffffffff9e1e5888 R14: 0000000000000000 R15: ffffabc0c44d3c78\n FS:  00007f6202f5f340(0000) GS:ffff93819f00f000(0000) knlGS:0000000000000000\n CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 000055d3162281a8 CR3: 0000000106a56003 CR4: 0000000000172ef0\n Call Trace:\n  \u0026lt;TASK\u0026gt;\n  tracepoint_probe_register+0x5d/0x90\n  synth_event_reg+0x3c/0x60\n  perf_trace_event_init+0x204/0x340\n  perf_trace_init+0x85/0xd0\n  perf_tp_event_init+0x2e/0x50\n  perf_try_init_event+0x6f/0x230\n  ? perf_event_alloc+0x4bb/0xdc0\n  perf_event_alloc+0x65a/0xdc0\n  __se_sys_perf_event_open+0x290/0x9f0\n  do_syscall_64+0x93/0x7b0\n  ? entry_SYSCALL_64_after_hwframe+0x76/0x7e\n  ? trace_hardirqs_off+0x53/0xc0\n  entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\nInstead, have the code return -ENODEV, which doesn\u0026apos;t warn and has perf\nerror out with:\n\n # perf record -e synthetic:futex_wait\nError:\nThe sys_perf_event_open() syscall returned with 19 (No such device) for event (synthetic:futex_wait).\n\u0026quot;dmesg | grep -i perf\u0026quot; may provide additional information.\n\nIdeally perf should support synthetic events, but for now just fix the\nwarning. The support can come later.(CVE-2025-71125)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncifs: Fix memory and information leak in smb3_reconfigure()\n\nIn smb3_reconfigure(), if smb3_sync_session_ctx_passwords() fails, the\nfunction returns immediately without freeing and erasing the newly\nallocated new_password and new_password2. This causes both a memory leak\nand a potential information leak.\n\nFix this by calling kfree_sensitive() on both password buffers before\nreturning in this error case.(CVE-2025-71151)",
  "id": "OESA-2026-1303",
  "modified": "2026-08-06T11:10:20Z",
  "published": "2026-02-06T11:10:20Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-1303"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-57994"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-58012"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-37800"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38110"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38111"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38149"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38162"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38208"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38232"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38244"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38303"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38342"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38393"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38455"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38489"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38676"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38688"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38697"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38712"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38713"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38714"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38728"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39720"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39721"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39730"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39737"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39749"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39798"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39823"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39828"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39838"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39839"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39927"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39929"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39951"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40083"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40087"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40099"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40103"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40105"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40111"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40250"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40252"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40259"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40261"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40264"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40268"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40273"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40284"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40304"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40311"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40314"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40319"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40320"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40322"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40324"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40328"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40345"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40350"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40360"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40363"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68178"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68184"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68185"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68191"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68218"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68219"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68229"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68239"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68241"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68245"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68251"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68288"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68295"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68296"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68305"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68310"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68312"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68366"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68367"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68371"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68372"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68374"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68379"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68764"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68788"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68791"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68798"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68800"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68801"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68805"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68821"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-71087"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-71093"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-71108"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-71113"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-71119"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-71125"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-71151"
    }
  ],
  "schema_version": "1.7.2",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "kernel security update",
  "upstream": [
    "CVE-2024-57994",
    "CVE-2024-58012",
    "CVE-2025-37800",
    "CVE-2025-38110",
    "CVE-2025-38111",
    "CVE-2025-38149",
    "CVE-2025-38162",
    "CVE-2025-38208",
    "CVE-2025-38232",
    "CVE-2025-38244",
    "CVE-2025-38303",
    "CVE-2025-38342",
    "CVE-2025-38393",
    "CVE-2025-38455",
    "CVE-2025-38489",
    "CVE-2025-38676",
    "CVE-2025-38688",
    "CVE-2025-38697",
    "CVE-2025-38712",
    "CVE-2025-38713",
    "CVE-2025-38714",
    "CVE-2025-38728",
    "CVE-2025-39720",
    "CVE-2025-39721",
    "CVE-2025-39730",
    "CVE-2025-39737",
    "CVE-2025-39749",
    "CVE-2025-39798",
    "CVE-2025-39823",
    "CVE-2025-39828",
    "CVE-2025-39838",
    "CVE-2025-39839",
    "CVE-2025-39927",
    "CVE-2025-39929",
    "CVE-2025-39951",
    "CVE-2025-40083",
    "CVE-2025-40087",
    "CVE-2025-40099",
    "CVE-2025-40103",
    "CVE-2025-40105",
    "CVE-2025-40111",
    "CVE-2025-40250",
    "CVE-2025-40252",
    "CVE-2025-40259",
    "CVE-2025-40261",
    "CVE-2025-40264",
    "CVE-2025-40268",
    "CVE-2025-40273",
    "CVE-2025-40284",
    "CVE-2025-40304",
    "CVE-2025-40311",
    "CVE-2025-40314",
    "CVE-2025-40319",
    "CVE-2025-40320",
    "CVE-2025-40322",
    "CVE-2025-40324",
    "CVE-2025-40328",
    "CVE-2025-40345",
    "CVE-2025-40350",
    "CVE-2025-40360",
    "CVE-2025-40363",
    "CVE-2025-68178",
    "CVE-2025-68184",
    "CVE-2025-68185",
    "CVE-2025-68191",
    "CVE-2025-68218",
    "CVE-2025-68219",
    "CVE-2025-68229",
    "CVE-2025-68239",
    "CVE-2025-68241",
    "CVE-2025-68245",
    "CVE-2025-68251",
    "CVE-2025-68288",
    "CVE-2025-68295",
    "CVE-2025-68296",
    "CVE-2025-68305",
    "CVE-2025-68310",
    "CVE-2025-68312",
    "CVE-2025-68366",
    "CVE-2025-68367",
    "CVE-2025-68371",
    "CVE-2025-68372",
    "CVE-2025-68374",
    "CVE-2025-68379",
    "CVE-2025-68764",
    "CVE-2025-68788",
    "CVE-2025-68791",
    "CVE-2025-68798",
    "CVE-2025-68800",
    "CVE-2025-68801",
    "CVE-2025-68805",
    "CVE-2025-68821",
    "CVE-2025-71087",
    "CVE-2025-71093",
    "CVE-2025-71108",
    "CVE-2025-71113",
    "CVE-2025-71119",
    "CVE-2025-71125",
    "CVE-2025-71151"
  ]
}

OESA-2026-1304 (CVE-2024-57994)

Vulnerability from osv_openeuler – Published: 2026-02-06 11:10 – Updated: 2026-08-06 11:10 – Source website

Summary

kernel security update

Details

The Linux Kernel, the operating system core itself.

Security Fix(es):

In the Linux kernel, the following vulnerability has been resolved:

ptr_ring: do not block hard interrupts in ptr_ring_resize_multiple()

Jakub added a lockdep_assert_no_hardirq() check in __page_pool_put_page() to increase test coverage.

syzbot found a splat caused by hard irq blocking in ptr_ring_resize_multiple() [1]

As current users of ptr_ring_resize_multiple() do not require hard irqs being masked, replace it to only block BH.

Rename helpers to better reflect they are safe against BH only.

ptr_ring_resize_multiple() to ptr_ring_resize_multiple_bh()
skb_array_resize_multiple() to skb_array_resize_multiple_bh()