CVE-2025-39913

tcp_bpf: Call sk_msg_free() when tcp_bpf_send_verdict() fails to allocate psock->cork.

HIGH
7.8
CVSS Score
Published: October 1, 2025 at 07:44 AM UTC
Updated: October 19, 2026 at 09:10 PM UTC
3 products affected across 3 vendorsLinux KernelDebian LinuxRUGGEDCOM RST2428P Firmware

Using Linux by Linux?

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

Real-time alertsTrack your software stackFree plan available
Severity
HIGH7.8
Exploit prediction
EPSS 0.2%
SSVC
No known exploit

Description

In the Linux kernel, the following vulnerability has been resolved: tcp_bpf: Call sk_msg_free() when tcp_bpf_send_verdict() fails to allocate psock->cork. syzbot reported the splat below. [0] The repro does the following: 1. Load a sk_msg prog that calls bpf_msg_cork_bytes(msg, cork_bytes) 2. Attach the prog to a SOCKMAP 3. Add a socket to the SOCKMAP 4. Activate fault injection 5. Send data less than cork_bytes At 5., the data is carried over to the next sendmsg() as it is smaller than the cork_bytes specified by bpf_msg_cork_bytes(). Then, tcp_bpf_send_verdict() tries to allocate psock->cork to hold the data, but this fails silently due to fault injection + __GFP_NOWARN. If the allocation fails, we need to revert the sk->sk_forward_alloc change done by sk_msg_alloc(). Let's call sk_msg_free() when tcp_bpf_send_verdict fails to allocate psock->cork. The "*copied" also needs to be updated such that a proper error can be returned to the caller, sendmsg. It fails to allocate psock->cork. Nothing has been corked so far, so this patch simply sets "*copied" to 0. [0]: WARNING: net/ipv4/af_inet.c:156 at inet_sock_destruct+0x623/0x730 net/ipv4/af_inet.c:156, CPU#1: syz-executor/5983 Modules linked in: CPU: 1 UID: 0 PID: 5983 Comm: syz-executor Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/12/2025 RIP: 0010:inet_sock_destruct+0x623/0x730 net/ipv4/af_inet.c:156 Code: 0f 0b 90 e9 62 fe ff ff e8 7a db b5 f7 90 0f 0b 90 e9 95 fe ff ff e8 6c db b5 f7 90 0f 0b 90 e9 bb fe ff ff e8 5e db b5 f7 90 <0f> 0b 90 e9 e1 fe ff ff 89 f9 80 e1 07 80 c1 03 38 c1 0f 8c 9f fc RSP: 0018:ffffc90000a08b48 EFLAGS: 00010246 RAX: ffffffff8a09d0b2 RBX: dffffc0000000000 RCX: ffff888024a23c80 RDX: 0000000000000100 RSI: 0000000000000fff RDI: 0000000000000000 RBP: 0000000000000fff R08: ffff88807e07c627 R09: 1ffff1100fc0f8c4 R10: dffffc0000000000 R11: ffffed100fc0f8c5 R12: ffff88807e07c380 R13: dffffc0000000000 R14: ffff88807e07c60c R15: 1ffff1100fc0f872 FS: 00005555604c4500(0000) GS:ffff888125af1000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00005555604df5c8 CR3: 0000000032b06000 CR4: 00000000003526f0 Call Trace: <IRQ> __sk_destruct+0x86/0x660 net/core/sock.c:2339 rcu_do_batch kernel/rcu/tree.c:2605 [inline] rcu_core+0xca8/0x1770 kernel/rcu/tree.c:2861 handle_softirqs+0x286/0x870 kernel/softirq.c:579 __do_softirq kernel/softirq.c:613 [inline] invoke_softirq kernel/softirq.c:453 [inline] __irq_exit_rcu+0xca/0x1f0 kernel/softirq.c:680 irq_exit_rcu+0x9/0x30 kernel/softirq.c:696 instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1052 [inline] sysvec_apic_timer_interrupt+0xa6/0xc0 arch/x86/kernel/apic/apic.c:1052 </IRQ>

Affected

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

4.17 ≤ v < 5.4.3005.11 ≤ v < 5.15.1945.16 ≤ v < 6.1.1535.5 ≤ v < 5.10.2456.13 ≤ v < 6.16.86.2 ≤ v < 6.6.1076.7 ≤ v < 6.12.484f738adba30a7cfc006f605707e7aee847ffefa06.176.17 rc16.17 rc26.17 rc36.17 rc46.17 rc5
Vendor states this is fixed in 05366527f44cf4b884f3d9462ae8009be9665856 (fixed)
Vendor states this is fixed in 08f58d10f5abf11d297cc910754922498c921f91 (fixed)
Vendor states this is fixed in 539920180c55f5e13a2488a2339f94e6b8cb69e0 (fixed)
Vendor states this is fixed in 66bcb04a441fbf15d66834b7e3eefb313dd750c8 (fixed)
Vendor states this is fixed in 7429b8b9bfbc276fd304fbaebc405f46b421fedf (fixed)
Vendor states this is fixed in 9c2a6456bdf9794474460d885c359b6c4522d6e3 (fixed)
Vendor states this is fixed in a3967baad4d533dc254c31e0d221e51c8d223d58 (fixed)
Vendor states this is fixed in de89e58368f8f07df005ecc1c86ad94898a999f2 (fixed)
Vendor states this is fixed in 4.17 (unaffected)
Vendor states this is fixed in 5.10.245 (unaffected)
Vendor states this is fixed in 5.15.194 (unaffected)
Vendor states this is fixed in 5.4.300 (unaffected)
Vendor states this is fixed in 6.1.153 (unaffected)
Vendor states this is fixed in 6.12.48 (unaffected)
Vendor states this is fixed in 6.16.8 (unaffected)
Vendor states this is fixed in 6.17 (unaffected)
Vendor states this is fixed in 6.6.107 (unaffected)
v < V4.0
Affected range stops below V4.0, so it looks safe — our inference, not a vendor statement

SSVC — Action Prioritization

SSVCNo known exploitNot automatableTotal impact

SSVC signals action urgency (what to patch first), separate from CVSS which measures severity.

CVSS

Attack Vector
LOCAL
Complexity
LOW
Privileges
LOW
User Interaction
NONE
Scope
UNCHANGED
Confidentiality
HIGH
Integrity
HIGH
Availability
HIGH
Vector?

Quick Info

StatusMODIFIED
CWE
NVD-CWE-noinfo

Get alerted

Stop reading CVE feeds looking for your own stack

Track the products you run and VulnTracker tells you when a new CVE affects them — with what is known about fixing it, and nothing about the rest.

Free plan, no card