CVE-2023-52843 in Linux
Summary
by MITRE • 05/21/2024
In the Linux kernel, the following vulnerability has been resolved:
llc: verify mac len before reading mac header
LLC reads the mac header with eth_hdr without verifying that the skb has an Ethernet header.
Syzbot was able to enter llc_rcv on a tun device. Tun can insert packets without mac len and with user configurable skb->protocol (passing a tun_pi header when not configuring IFF_NO_PI).
BUG: KMSAN: uninit-value in llc_station_ac_send_test_r net/llc/llc_station.c:81 [inline]
BUG: KMSAN: uninit-value in llc_station_rcv+0x6fb/0x1290 net/llc/llc_station.c:111 llc_station_ac_send_test_r net/llc/llc_station.c:81 [inline]
llc_station_rcv+0x6fb/0x1290 net/llc/llc_station.c:111 llc_rcv+0xc5d/0x14a0 net/llc/llc_input.c:218 __netif_receive_skb_one_core net/core/dev.c:5523 [inline]
__netif_receive_skb+0x1a6/0x5a0 net/core/dev.c:5637 netif_receive_skb_internal net/core/dev.c:5723 [inline]
netif_receive_skb+0x58/0x660 net/core/dev.c:5782 tun_rx_batched+0x3ee/0x980 drivers/net/tun.c:1555 tun_get_user+0x54c5/0x69c0 drivers/net/tun.c:2002
Add a mac_len test before all three eth_hdr(skb) calls under net/llc.
There are further uses in include/net/llc_pdu.h. All these are protected by a test skb->protocol == ETH_P_802_2. Which does not protect against this tun scenario.
But the mac_len test added in this patch in llc_fixup_skb will indirectly protect those too. That is called from llc_rcv before any other LLC code.
It is tempting to just add a blanket mac_len check in llc_rcv, but not sure whether that could break valid LLC paths that do not assume an Ethernet header. 802.2 LLC may be used on top of non-802.3 protocols in principle. The below referenced commit shows that used to, on top of Token Ring.
At least one of the three eth_hdr uses goes back to before the start of git history. But the one that syzbot exercises is introduced in this commit. That commit is old enough (2008), that effectively all stable kernels should receive this.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 09/24/2025
The vulnerability identified as CVE-2023-52843 resides within the Linux kernel's Logical Link Control (LLC) subsystem, specifically in how it processes incoming network packets through the llc_rcv function. This flaw represents a classic case of uninitialized memory access that can lead to system instability and potential security implications. The issue manifests when LLC attempts to read Ethernet headers without first validating whether the incoming packet actually contains valid MAC layer information, particularly in scenarios involving TUN (virtual network device) interfaces where packets may be constructed without proper MAC length fields or with user-configurable protocol identifiers.
The technical root cause stems from insufficient input validation within the LLC packet processing pipeline. When syzbot, an automated fuzzer, triggered the vulnerability through a TUN device, it demonstrated that LLC could be invoked with packets that lack proper Ethernet header structure. The kernel's llc_rcv function directly calls eth_hdr(skb) without verifying that the skb (socket buffer) contains sufficient data to support such an operation. This leads to KMSAN (Kernel Memory Sanitizer) reporting uninitialized value errors in critical LLC station functions, specifically in llc_station_rcv and llc_station_ac_send_test_r, where the code attempts to access memory locations that have not been properly initialized due to the absence of valid MAC header information.
The operational impact of this vulnerability extends beyond simple kernel crashes, potentially enabling attackers to exploit the uninitialized memory access for privilege escalation or denial of service conditions. The vulnerability is particularly concerning because it can be triggered through TUN device interfaces, which are commonly used in virtualization environments, container technologies, and network tunneling applications. The stack trace reveals that packets flow through tun_rx_batched and tun_get_user functions before reaching the vulnerable LLC code path, indicating that this issue affects not just direct network interfaces but also virtualized network configurations. The vulnerability affects kernel versions that have not yet received the specific patch addressing the mac_len verification issue.
The patch implementation addresses this by introducing a mac_len test before all three eth_hdr(skb) calls within the LLC subsystem, specifically in the llc_fixup_skb function which is invoked prior to any other LLC processing. This approach follows the principle of defensive programming and aligns with CWE-457: Use of Uninitialized Variable, which is a fundamental security principle in kernel development. The solution also acknowledges the complexity of maintaining backward compatibility with non-Ethernet LLC implementations, as referenced in the commit history showing that LLC was historically used over Token Ring and other non-802.3 protocols. However, the patch ensures that even though the code maintains flexibility for different network protocols, it still performs proper validation before accessing memory that might not be properly initialized, thus protecting against the specific exploitation scenario while preserving the protocol's broader functionality. This vulnerability demonstrates the critical importance of input validation in kernel space code and represents a typical example of how seemingly minor oversight in memory access patterns can create significant security risks.