Skip to main content

Linux Kernel CVE-2025-38475

MEDIUM
NULL Pointer Dereference (CWE-476)
2025-07-28 416baaa9-dc9f-4396-8d5f-8c081fb06d67
5.5
CVSS 3.1 · NVD
Share

Severity by source

NVD PRIMARY
5.5 MEDIUM
AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
vuln.today AI
5.5 MEDIUM

Local-only trigger requiring low-privilege socket creation and Smack LSM; pure availability impact via kernel oops, no confidentiality or integrity consequence.

3.1 AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
4.0 AV:L/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
SUSE
7.1 HIGH
AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H
Red Hat
5.5 MEDIUM
qualitative

Primary rating from NVD.

CVSS VectorNVD

Attack Vector
Local
Attack Complexity
Low
Privileges Required
Low
User Interaction
None
Scope
Unchanged
Confidentiality
None
Integrity
None
Availability
High

Lifecycle Timeline

2
Analysis Generated
Jul 30, 2026 - 08:46 vuln.today
CVE Published
Jul 28, 2025 - 12:15 nvd
MEDIUM 5.5

DescriptionNVD

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

smc: Fix various oops due to inet_sock type confusion.

syzbot reported weird splats [0][1] in cipso_v4_sock_setattr() while freeing inet_sk(sk)->inet_opt.

The address was freed multiple times even though it was read-only memory.

cipso_v4_sock_setattr() did nothing wrong, and the root cause was type confusion.

The cited commit made it possible to create smc_sock as an INET socket.

The issue is that struct smc_sock does not have struct inet_sock as the first member but hijacks AF_INET and AF_INET6 sk_family, which confuses various places.

In this case, inet_sock.inet_opt was actually smc_sock.clcsk_data_ready(), which is an address of a function in the text segment.

$ pahole -C inet_sock vmlinux struct inet_sock { ... struct ip_options_rcu * inet_opt; /* 784 8 */

$ pahole -C smc_sock vmlinux struct smc_sock { ... void (*clcsk_data_ready)(struct sock *); /* 784 8 */

The same issue for another field was reported before. [2][3]

At that time, an ugly hack was suggested [4], but it makes both INET and SMC code error-prone and hard to change.

Also, yet another variant was fixed by a hacky commit 98d4435efcbf3 ("net/smc: prevent NULL pointer dereference in txopt_get").

Instead of papering over the root cause by such hacks, we should not allow non-INET socket to reuse the INET infra.

Let's add inet_sock as the first member of smc_sock.

[0]: kvfree_call_rcu(): Double-freed call. rcu_head 000000006921da73 WARNING: CPU: 0 PID: 6718 at mm/slab_common.c:1956 kvfree_call_rcu+0x94/0x3f0 mm/slab_common.c:1955 Modules linked in: CPU: 0 UID: 0 PID: 6718 Comm: syz.0.17 Tainted: G W 6.16.0-rc4-syzkaller-g7482bb149b9f #0 PREEMPT Tainted: [W]=WARN Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025 pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : kvfree_call_rcu+0x94/0x3f0 mm/slab_common.c:1955 lr : kvfree_call_rcu+0x94/0x3f0 mm/slab_common.c:1955 sp : ffff8000a03a7730 x29: ffff8000a03a7730 x28: 00000000fffffff5 x27: 1fffe000184823d3 x26: dfff800000000000 x25: ffff0000c2411e9e x24: ffff0000dd88da00 x23: ffff8000891ac9a0 x22: 00000000ffffffea x21: ffff8000891ac9a0 x20: ffff8000891ac9a0 x19: ffff80008afc2480 x18: 00000000ffffffff x17: 0000000000000000 x16: ffff80008ae642c8 x15: ffff700011ede14c x14: 1ffff00011ede14c x13: 0000000000000004 x12: ffffffffffffffff x11: ffff700011ede14c x10: 0000000000ff0100 x9 : 5fa3c1ffaf0ff000 x8 : 5fa3c1ffaf0ff000 x7 : 0000000000000001 x6 : 0000000000000001 x5 : ffff8000a03a7078 x4 : ffff80008f766c20 x3 : ffff80008054d360 x2 : 0000000000000000 x1 : 0000000000000201 x0 : 0000000000000000 Call trace: kvfree_call_rcu+0x94/0x3f0 mm/slab_common.c:1955 (P) cipso_v4_sock_setattr+0x2f0/0x3f4 net/ipv4/cipso_ipv4.c:1914 netlbl_sock_setattr+0x240/0x334 net/netlabel/netlabel_kapi.c:1000 smack_netlbl_add+0xa8/0x158 security/smack/smack_lsm.c:2581 smack_inode_setsecurity+0x378/0x430 security/smack/smack_lsm.c:2912 security_inode_setsecurity+0x118/0x3c0 security/security.c:2706 __vfs_setxattr_noperm+0x174/0x5c4 fs/xattr.c:251 __vfs_setxattr_locked+0x1ec/0x218 fs/xattr.c:295 vfs_setxattr+0x158/0x2ac fs/xattr.c:321 do_setxattr fs/xattr.c:636 [inline] file_setxattr+0x1b8/0x294 fs/xattr.c:646 path_setxattrat+0x2ac/0x320 fs/xattr.c:711 __do_sys_fsetxattr fs/xattr.c:761 [inline] __se_sys_fsetxattr fs/xattr.c:758 [inline] __arm64_sys_fsetxattr+0xc0/0xdc fs/xattr.c:758 __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline] invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49 el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:132 do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151 el0_svc+0x58/0x180 arch/arm64/kernel/entry-common.c:879 el0t_64_sync_handler+0x84/0x12c arch/arm64/kernel/entry-common.c:898 el0t_64_sync+0x198/0x19c arch/arm64/kernel/entry.S:600

[ ---truncated---

AnalysisAI

Kernel oops and double-free in Linux SMC networking code causes local denial of service through a struct type confusion between smc_sock and inet_sock. The smc_sock structure hijacks AF_INET/AF_INET6 sk_family without placing inet_sock as its first member, causing downstream INET infrastructure - specifically cipso_v4_sock_setattr() - to misinterpret the smc_sock.clcsk_data_ready function pointer (at offset 784) as an inet_sock.inet_opt IP options pointer and attempt to free read-only text-segment memory. No public exploit exists and EPSS is at the 3rd percentile, but syzbot confirmed reliable reproduction through Smack LSM + CIPSO interactions on affected kernels.

Technical ContextAI

The vulnerability is rooted in CWE-476-adjacent type confusion: the SMC (Shared Memory Communication over RDMA) socket subsystem allows creation of smc_sock instances tagged with AF_INET or AF_INET6 sk_family values, causing generic INET-layer code to cast these sockets as struct inet_sock. Because struct smc_sock does not place struct inet_sock as its first member, field offsets collide. Specifically, at byte offset 784, inet_sock carries inet_opt (a struct ip_options_rcu pointer freed via kvfree_call_rcu), while smc_sock carries clcsk_data_ready (a function pointer into kernel text). When the Smack LSM invokes smack_inode_setsecurity → smack_netlbl_add → netlbl_sock_setattr → cipso_v4_sock_setattr on an SMC socket, it reads the function pointer as inet_opt and calls kvfree_call_rcu on a text-segment address, triggering a double-free WARNING and kernel oops. The fix restructures smc_sock to embed inet_sock as its first member, eliminating the layout collision. Affected CPE: cpe:2.3:o:linux:linux_kernel across multiple version ranges including 6.16-rc1 through 6.16-rc6.

RemediationAI

Apply the upstream kernel patches available at the three kernel.org stable commits referenced in this CVE: https://git.kernel.org/stable/c/5b02e397929e5b13b969ef1f8e43c7951e2864f5, https://git.kernel.org/stable/c/60ada4fe644edaa6c2da97364184b0425e8aeaf5, and https://git.kernel.org/stable/c/67a167a6b8b45607bc34aa541d1c75097d18d460. A specific patched release version is not independently confirmed from the available data - check your distribution's security tracker for backported fixes. As a compensating control, disabling Smack LSM (if it is not a security requirement) will prevent the CIPSO labeling code path that triggers the oops. Alternatively, if SMC socket support is not required, removing or blacklisting the SMC kernel module (CONFIG_SMC disabled) eliminates the type-confused socket creation path entirely. Both workarounds carry operational trade-offs: disabling Smack reduces MAC enforcement, while disabling SMC removes high-speed RDMA-based communication for workloads that rely on it.

Vendor StatusVendor

SUSE

Severity: Important
Product Status
Image SLES-Azure-3P Image SLES-Azure-Basic Image SLES-Azure-Standard Image SLES-BYOS-Azure Image SLES-BYOS-EC2 Image SLES-BYOS-GCE Image SLES-CHOST-BYOS-Aliyun Image SLES-CHOST-BYOS-Azure Image SLES-CHOST-BYOS-EC2 Image SLES-CHOST-BYOS-GCE Image SLES-CHOST-BYOS-GDC Image SLES-CHOST-BYOS-SAP-CCloud Image SLES-EC2 Image SLES-EC2-ECS Image SLES-GCE Image SLES-GCE-3P Image SLES-Hardened-BYOS-Azure Image SLES-Hardened-BYOS-EC2 Image SLES-Hardened-BYOS-GCE Image SLES-SAPCAL-Azure Image SLES-SAPCAL-EC2 Image SLES-SAPCAL-GCE Affected
Image SLES-SAP-Azure Image SLES-SAP-Azure-3P Image SLES-SAP-BYOS-Azure Image SLES-SAP-BYOS-EC2 Image SLES-SAP-BYOS-GCE Image SLES-SAP-EC2 Image SLES-SAP-GCE Image SLES-SAP-GCE-3P Affected
Image SLES15-SP7-Azure-3P Image SLES15-SP7-Azure-Basic Image SLES15-SP7-Azure-Standard Image SLES15-SP7-HPC-Azure Affected
Image SLES15-SP7-BYOS-Azure Image SLES15-SP7-BYOS-EC2 Image SLES15-SP7-BYOS-GCE Image SLES15-SP7-CHOST-BYOS-Aliyun Image SLES15-SP7-CHOST-BYOS-Azure Image SLES15-SP7-CHOST-BYOS-EC2 Image SLES15-SP7-CHOST-BYOS-GCE Image SLES15-SP7-CHOST-BYOS-GDC Image SLES15-SP7-CHOST-BYOS-SAP-CCloud Image SLES15-SP7-EC2 Image SLES15-SP7-EC2-ECS-HVM Image SLES15-SP7-GCE Image SLES15-SP7-GCE-3P Image SLES15-SP7-HPC-BYOS-Azure Image SLES15-SP7-HPC-BYOS-EC2 Image SLES15-SP7-HPC-BYOS-GCE Image SLES15-SP7-Hardened-BYOS-Azure Image SLES15-SP7-Hardened-BYOS-EC2 Image SLES15-SP7-Hardened-BYOS-GCE Image SLES15-SP7-SAPCAL-Azure Image SLES15-SP7-SAPCAL-EC2 Image SLES15-SP7-SAPCAL-GCE Affected
Image SLES15-SP7-SAP-Azure Image SLES15-SP7-SAP-Azure-3P Image SLES15-SP7-SAP-Azure-LI-BYOS-Production Image SLES15-SP7-SAP-Azure-VLI-BYOS-Production Image SLES15-SP7-SAP-BYOS-Azure Image SLES15-SP7-SAP-BYOS-EC2 Image SLES15-SP7-SAP-BYOS-GCE Image SLES15-SP7-SAP-EC2 Image SLES15-SP7-SAP-GCE Image SLES15-SP7-SAP-GCE-3P Image SLES15-SP7-SAP-Hardened-Azure Image SLES15-SP7-SAP-Hardened-BYOS-Azure Image SLES15-SP7-SAP-Hardened-BYOS-EC2 Image SLES15-SP7-SAP-Hardened-BYOS-GCE Image SLES15-SP7-SAP-Hardened-GCE Affected

Share

CVE-2025-38475 vulnerability details – vuln.today

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy