CVE-2025-37750

smb: client: fix UAF in decryption with multichannel

HIGH

7.8

CVSS Score

Published: May 1, 2025 at 12:55 PM UTC

Updated: October 30, 2026 at 01:17 PM UTC

1 product affected across 1 vendorLinux Kernel

Using Linux by Linux?

Get instant alerts when new vulnerabilities affect Linux - before attackers find them.

Real-time alertsTrack your software stackFree plan available

Start Free Sign In

Severity

HIGH7.8

Exploit prediction

EPSS 0.5%

Description

In the Linux kernel, the following vulnerability has been resolved: smb: client: fix UAF in decryption with multichannel After commit f7025d861694 ("smb: client: allocate crypto only for primary server") and commit b0abcd65ec54 ("smb: client: fix UAF in async decryption"), the channels started reusing AEAD TFM from primary channel to perform synchronous decryption, but that can't done as there could be multiple cifsd threads (one per channel) simultaneously accessing it to perform decryption. This fixes the following KASAN splat when running fstest generic/249 with 'vers=3.1.1,multichannel,max_channels=4,seal' against Windows Server 2022: BUG: KASAN: slab-use-after-free in gf128mul_4k_lle+0xba/0x110 Read of size 8 at addr ffff8881046c18a0 by task cifsd/986 CPU: 3 UID: 0 PID: 986 Comm: cifsd Not tainted 6.15.0-rc1 #1 PREEMPT(voluntary) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-3.fc41 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x5d/0x80 print_report+0x156/0x528 ? gf128mul_4k_lle+0xba/0x110 ? __virt_addr_valid+0x145/0x300 ? __phys_addr+0x46/0x90 ? gf128mul_4k_lle+0xba/0x110 kasan_report+0xdf/0x1a0 ? gf128mul_4k_lle+0xba/0x110 gf128mul_4k_lle+0xba/0x110 ghash_update+0x189/0x210 shash_ahash_update+0x295/0x370 ? __pfx_shash_ahash_update+0x10/0x10 ? __pfx_shash_ahash_update+0x10/0x10 ? __pfx_extract_iter_to_sg+0x10/0x10 ? ___kmalloc_large_node+0x10e/0x180 ? __asan_memset+0x23/0x50 crypto_ahash_update+0x3c/0xc0 gcm_hash_assoc_remain_continue+0x93/0xc0 crypt_message+0xe09/0xec0 [cifs] ? __pfx_crypt_message+0x10/0x10 [cifs] ? _raw_spin_unlock+0x23/0x40 ? __pfx_cifs_readv_from_socket+0x10/0x10 [cifs] decrypt_raw_data+0x229/0x380 [cifs] ? __pfx_decrypt_raw_data+0x10/0x10 [cifs] ? __pfx_cifs_read_iter_from_socket+0x10/0x10 [cifs] smb3_receive_transform+0x837/0xc80 [cifs] ? __pfx_smb3_receive_transform+0x10/0x10 [cifs] ? __pfx___might_resched+0x10/0x10 ? __pfx_smb3_is_transform_hdr+0x10/0x10 [cifs] cifs_demultiplex_thread+0x692/0x1570 [cifs] ? __pfx_cifs_demultiplex_thread+0x10/0x10 [cifs] ? rcu_is_watching+0x20/0x50 ? rcu_lockdep_current_cpu_online+0x62/0xb0 ? find_held_lock+0x32/0x90 ? kvm_sched_clock_read+0x11/0x20 ? local_clock_noinstr+0xd/0xd0 ? trace_irq_enable.constprop.0+0xa8/0xe0 ? __pfx_cifs_demultiplex_thread+0x10/0x10 [cifs] kthread+0x1fe/0x380 ? kthread+0x10f/0x380 ? __pfx_kthread+0x10/0x10 ? local_clock_noinstr+0xd/0xd0 ? ret_from_fork+0x1b/0x60 ? local_clock+0x15/0x30 ? lock_release+0x29b/0x390 ? rcu_is_watching+0x20/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x31/0x60 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 </TASK>

Affected

Our own answer: ranges merged, affected separated from platform-only, with confidence and review flags.

Linux Kernel · Linux

95%

5.10.237 ≤ v < 5.115.15.181 ≤ v < 5.166.1.128 ≤ v < 6.26.11.4 ≤ v < 6.12.246.13 ≤ v < 6.13.126.14 ≤ v < 6.14.36.6.57 ≤ v < 6.75.10.237 5.15.181538c26d9bf70c90edc460d18c81008a4e555925a6.1.128 6.11.4 6.15 6.15 rc1 6.6.57809fb86ad13b29e1d6d491364fc7ea4fb5459958f14a476abba13144df5434871a7225fd29af633b0abcd65ec545701b8793e12bc27dc98042b151abce966530fd5542bbb422cb45ecb775f7a1a6bc3ef51c0d544b1518b35364480317ab6d3468f205d

Vendor states this is fixed in 9502dd5c7029902f4a425bf959917a5a9e7c0e50 (fixed)

Vendor states this is fixed in 950557922c1298464749c216d8763e97faf5d0a6 (fixed)

Vendor states this is fixed in aa5a1e4b882964eb79d5b5d1d1e8a1a5efbb1d15 (fixed)

Vendor states this is fixed in e859b216d94668bc66330e61be201234f4413d1a (fixed)

Affected range stops below 5.11, so it looks safe — our inference, not a vendor statement

Affected range stops below 5.16, so it looks safe — our inference, not a vendor statement

Vendor states this is fixed in 6.12 (unaffected)

Vendor states this is fixed in 6.12.24 (unaffected)

Vendor states this is fixed in 6.13.12 (unaffected)

Vendor states this is fixed in 6.14.3 (unaffected)

Vendor states this is fixed in 6.15 (unaffected)

Affected range stops below 6.2, so it looks safe — our inference, not a vendor statement