Look up another CVE · open CVE-2026-43016 in the interactive tracker

CVE-2026-43016

bpf: sockmap: Fix use-after-free of sk->sk_socket in sk_psock_verdict_data_ready().

7.8 EPSS 0.2% AV:L

Published 2026-05-01 (6 months ago) by the Linux kernel CNA. Subsystem net/core. Debian urgency: not yet assigned.

What to do, per Debian release

Debian's own status for CVE-2026-43016 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source

Release	Status	Version	What this means
Debian 12bookworm	vulnerable	6.1.190-1	No fix published anywhere yet, neither in Debian nor upstream for the series bookworm tracks. Watch the Debian tracker page for this CVE. Advisories for bookworm have historically landed a median of 23 days after publication.
Debian 13trixie	fixed	6.12.85-1	Update the kernel and reboot. Fixed in 6.12.85-1. A running kernel keeps the old code until the machine restarts.
Debian 14forky	fixed	6.19.12-1	Update the kernel and reboot. Fixed in 6.19.12-1. A running kernel keeps the old code until the machine restarts.
Debian unstablesid	fixed	6.19.12-1	Update the kernel and reboot. Fixed in 6.19.12-1. A running kernel keeps the old code until the machine restarts.

The vulnerability

What the bug is

syzbot reported use-after-free of AF_UNIX socket's sk->sk_socket in sk_psock_verdict_data_ready(). [0] In unix_stream_sendmsg(), the peer socket's ->sk_data_ready() is called after dropping its unix_state_lock(). Although the sender socket holds the peer's refcount, it does not prevent the peer's sock_orphan(), and the peer's sk_socket might be freed after one RCU grace period. Let's fetch the peer's sk->sk_socket and sk->sk_socket->ops under RCU in sk_psock_verdict_data_ready(). [0]: BUG: KASAN: slab-use-after-free in sk_psock_verdict_data_ready+0xec/0x590 net/core/skmsg.c:1278 Read of size 8 at addr ffff8880594da860 by task syz.4.1842/11013 CPU: 1 UID: 0 PID: 11013 Comm: syz.4.1842 Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2026 Call Trace: <TASK> dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xba/0x230 mm/kasan/report.c:482 kasan_report+0x117/0x150 mm/kasan/report.c:595 sk_psock_verdict_data_ready+0xec/0x590 net/core/skmsg.c:1278 unix_stream_sendmsg+0x8a3/0xe80 net/unix/af_unix.c:2482 sock_sendmsg_nosec net/socket.c:721 [inline] __sock_sendmsg net/socket.c:736 [inline] ____sys_sendmsg+0x972/0x9f0 net/socket.c:2585 ___sys_sendmsg+0x2a5/0x360 net/socket.c:2639 __sys_sendmsg net/socket.c:2671 [inline] __do_sys_sendmsg net/socket.c:2676 [inline] __se_sys_sendmsg net/socket.c:2674 [inline] __x64_sys_sendmsg+0x1bd/0x2a0 net/socket.c:2674 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x14d/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7facf899c819 Code: ff 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 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 e8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007facf9827028 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007facf8c15fa0 RCX: 00007facf899c819 RDX: 0000000000000000 RSI: 0000200000000500 RDI: 0000000000000004 RBP: 00007facf8a32c91 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007facf8c16038 R14: 00007facf8c15fa0 R15: 00007ffd41b01c78 </TASK> Allocated by task 11013: kasan_save_stack mm/kasan/common.c:57 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:78 unpoison_slab_object mm/kasan/common.c:340 [inline] __kasan_slab_alloc+0x6c/0x80 mm/kasan/common.c:366 kasan_slab_alloc include/linux/kasan.h:253 [inline] slab_post_alloc_hook mm/slub.c:4538 [inline] slab_alloc_node mm/slub.c:4866 [inline] kmem_cache_alloc_lru_noprof+0x2b8/0x640 mm/slub.c:4885 sock_alloc_inode+0x28/0xc0 net/socket.c:316 alloc_inode+0x6a/0x1b0 fs/inode.c:347 new_inode_pseudo include/linux/fs.h:3003 [inline] sock_alloc net/socket.c:631 [inline] __sock_create+0x12d/0x9d0 net/socket.c:1562 sock_create net/socket.c:1656 [inline] __sys_socketpair+0x1c4/0x560 net/socket.c:1803 __do_sys_socketpair net/socket.c:1856 [inline] __se_sys_socketpair net/socket.c:1853 [inline] __x64_sys_socketpair+0x9b/0xb0 net/socket.c:1853 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x14d/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f Freed by task 15: kasan_save_stack mm/kasan/common.c:57 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:78 kasan_save_free_info+0x46/0x50 mm/kasan/generic.c:584 poison_slab_object mm/kasan/common.c:253 [inline] __kasan_slab_free+0x5c/0x80 mm/kasan/common.c:285 kasan_slab_free include/linux/kasan.h:235 [inline] slab_free_hook mm/slub.c:2685 [inline] slab_free mm/slub.c:6165 [inline] kmem_cache_free+0x187/0x630 mm/slub.c:6295 rcu_do_batch kernel/rcu/tree.c: ---truncated---

Where it lives

The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.

net/core/skmsg.c

What this is: BPF [L7 FRAMEWORK] (sockmap)MAINTAINERS section matched on net/core/skmsg.c · netdev@vger.kernel.org · Maintained

Check it on the machine

grep -w CONFIG_NET_SOCK_MSG /boot/config-$(uname -r)

Reads the booted kernel's own configuration, on the machine and nowhere else. =y is built in, =m is a module, and an is not set line means the code is not there.

Show whether Debian builds this, per release

Debian builds this code. Every release below compiles the affected file into the kernels it ships.

bookworm, trixie, forky, sidy

y: built into the kernel image on every flavour - only a patch removes it

Build switch: CONFIG_NET_SOCK_MSG

From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS kbuild Makefiles Debian linux-config packages

Debian tracker CVE record NVD kernel CNA record

Signals

Published: 2026-05-01 (6 months ago)source
CVSS: 7.8 high
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:Hsource recompute it
Attack vector: local (AV:L)source
EPSS: 0.17%, higher than 6.0% of all CVEssource
CISA KEV: not listedthe KEV catalogue
Debian urgency: not yet assignedsource
Subsystem: net/core

Upstream fixes

The versions the CNA records as introducing and fixing this, and the commit for each. source

Introduced	Fixed in	Commit
5.15	6.6.134	8d597e3e7402
5.15	6.12.81	68187f18a89b
5.15	6.18.22	18861f87a043
5.15	6.19.12	af95bc39a83d
5.15	7.0	ad8391d37f33

Why the CNA scored it this way

Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source

AV:LAttack vector, local: The vulnerable callback is reached through local BPF sockmap setup and local AF_UNIX send/close activity, not by unauthenticated network packets alone.
AC:LAttack complexity, low: The attacker can create the socketpair, install the sockmap verdict path, and race sendmsg against close/orphaning of the peer socket; both sides of the race are attacker-controlled.
PR:LPrivileges required, low: Creating and attaching the required sockmap/SK_SKB or SK_MSG BPF objects requires BPF/CAP_NET_ADMIN-style privileges, but these can be available to a low-privileged local user in delegated or user-namespace BPF deployments; choosing the higher severity option gives PR:L.
UI:NUser interaction, none: No victim action is needed after the attacker has local execution and the required BPF access; triggering is done with attacker-controlled syscalls.
S:UScope, unchanged: The impact is within the kernel security authority and represents ordinary kernel memory corruption or privilege escalation, not a cross-scope boundary such as guest-to-host escape.
C:HConfidentiality impact, high: This is a use-after-free of the socket object used to fetch proto_ops, and kernel UAFs can be shaped into information disclosure primitives.
I:HIntegrity impact, high: The stale socket pointer can lead to use of attacker-influenced freed memory and function-pointer-oriented control flow, making arbitrary modification or code execution defensible.
A:HAvailability impact, high: The reported KASAN splat demonstrates a kernel use-after-free reachable from sendmsg, and repeated triggering can crash or destabilize the kernel.