CVE-2023-53836 in Linux
Summary
by MITRE • 12/09/2025
In the Linux kernel, the following vulnerability has been resolved:
bpf, sockmap: Fix skb refcnt race after locking changes
There is a race where skb's from the sk_psock_backlog can be referenced after userspace side has already skb_consumed() the sk_buff and its refcnt dropped to zer0 causing use after free.
The flow is the following:
while ((skb = skb_peek(&psock->ingress_skb)) sk_psock_handle_Skb(psock, skb, ..., ingress) if (!ingress) ... sk_psock_skb_ingress sk_psock_skb_ingress_enqueue(skb) msg->skb = skb sk_psock_queue_msg(psock, msg) skb_dequeue(&psock->ingress_skb)
The sk_psock_queue_msg() puts the msg on the ingress_msg queue. This is what the application reads when recvmsg() is called. An application can read this anytime after the msg is placed on the queue. The recvmsg hook will also read msg->skb and then after user space reads the msg will call consume_skb(skb) on it effectively free'ing it.
But, the race is in above where backlog queue still has a reference to the skb and calls skb_dequeue(). If the skb_dequeue happens after the user reads and free's the skb we have a use after free.
The !ingress case does not suffer from this problem because it uses sendmsg_*(sk, msg) which does not pass the sk_buff further down the stack.
The following splat was observed with 'test_progs -t sockmap_listen':
[ 1022.710250][ T2556] general protection fault, ...
[...]
[ 1022.712830][ T2556] Workqueue: events sk_psock_backlog
[ 1022.713262][ T2556] RIP: 0010:skb_dequeue+0x4c/0x80
[ 1022.713653][ T2556] Code: ...
[...]
[ 1022.720699][ T2556] Call Trace:
[ 1022.720984][ T2556] <TASK>
[ 1022.721254][ T2556] ? die_addr+0x32/0x80^M
[ 1022.721589][ T2556] ? exc_general_protection+0x25a/0x4b0
[ 1022.722026][ T2556] ? asm_exc_general_protection+0x22/0x30
[ 1022.722489][ T2556] ? skb_dequeue+0x4c/0x80
[ 1022.722854][ T2556] sk_psock_backlog+0x27a/0x300
[ 1022.723243][ T2556] process_one_work+0x2a7/0x5b0
[ 1022.723633][ T2556] worker_thread+0x4f/0x3a0
[ 1022.723998][ T2556] ? __pfx_worker_thread+0x10/0x10
[ 1022.724386][ T2556] kthread+0xfd/0x130
[ 1022.724709][ T2556] ? __pfx_kthread+0x10/0x10
[ 1022.725066][ T2556] ret_from_fork+0x2d/0x50
[ 1022.725409][ T2556] ? __pfx_kthread+0x10/0x10
[ 1022.725799][ T2556] ret_from_fork_asm+0x1b/0x30
[ 1022.726201][ T2556] </TASK>
To fix we add an skb_get() before passing the skb to be enqueued in the engress queue. This bumps the skb->users refcnt so that consume_skb() and kfree_skb will not immediately free the sk_buff. With this we can be sure the skb is still around when we do the dequeue. Then we just need to decrement the refcnt or free the skb in the backlog case which we do by calling kfree_skb() on the ingress case as well as the sendmsg case.
Before locking change from fixes tag we had the sock locked so we couldn't race with user and there was no issue here.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 03/30/2026
The vulnerability described in CVE-2023-53836 resides within the Linux kernel's BPF (Berkeley Packet Filter) subsystem, specifically within the sockmap implementation that handles socket packet processing. This issue represents a classic use-after-free condition that occurs during the handling of socket buffer (skb) references in the socket processing backlog. The flaw manifests when the kernel attempts to process incoming packets through the sk_psock_backlog mechanism, creating a race condition between kernel-level packet processing and user-space consumption of the same packet data structures.
The technical root cause involves a race condition in the packet processing flow where the socket's ingress_skb backlog queue maintains references to sk_buff structures even after user-space has already processed and freed them. The vulnerability occurs during the sk_psock_handle_Skb function execution, where packets are enqueued onto the ingress_msg queue for user-space consumption. When recvmsg() is called, the user-space code processes the message and calls consume_skb() which decrements the reference count to zero, effectively freeing the memory. However, the kernel's backlog processing continues to reference this freed memory through the skb_dequeue operation, leading to memory corruption and potential system instability.
This vulnerability specifically affects the sockmap functionality within BPF programs that handle socket operations, particularly those involving ingress packet processing. The race condition occurs because the kernel maintains a reference to the skb in the backlog queue while user-space simultaneously consumes and frees the same skb structure. The problem is exacerbated by the fact that the !ingress case does not suffer from this issue because it uses sendmsg_* functions that do not pass sk_buff structures further down the processing stack. The vulnerability was triggered by specific test cases involving sockmap_listen functionality, as evidenced by the kernel log output showing general protection faults during skb_dequeue operations.
The fix implemented addresses this race condition by adding an skb_get() call before enqueuing the skb in the ingress queue, which increments the reference count to prevent premature freeing. This ensures that even when user-space consumes and frees the skb, the kernel's backlog processing still maintains a valid reference to the packet data. The solution also includes proper cleanup by calling kfree_skb() in both the backlog case and sendmsg case to maintain consistent reference counting behavior. This fix aligns with established security practices for preventing use-after-free vulnerabilities and follows the principles outlined in CWE-416 (Use After Free) and ATT&CK technique T1059.008 (Command and Scripting Interpreter: PowerShell) for memory safety. The vulnerability demonstrates the complexity of concurrent access control in kernel space where multiple execution contexts must properly coordinate packet buffer references to prevent memory corruption. The issue was particularly significant in environments using BPF sockmap programs for network packet processing, where the race condition could lead to system crashes or potential privilege escalation if exploited by malicious actors. The fix maintains backward compatibility while ensuring thread safety in the packet processing pipeline and represents a defensive programming approach that prevents memory safety violations in kernel-level networking code.