CVE-2026-52942

What it actually does

This is a Linux kernel out-of-bounds read in the netfilter logging path. When netfilter logs a packet on the netdev path, dump_mac_header() can attempt to read a MAC header even when the socket buffer's MAC header was never initialized. In that state, the kernel treats an unset header offset as valid and reads roughly 64 KiB beyond the expected packet buffer area, copying adjacent kernel memory bytes into kernel logs. The primary impact is local information disclosure from kernel memory via logs; the bug is not described as allowing code execution or privilege escalation by itself, but leaked kernel data can potentially assist later exploitation of other kernel bugs.

Why it matters to the business

Systems running affected Linux kernels may unintentionally write fragments of kernel memory into system logs when a local attacker can trigger the vulnerable packet logging path. This can expose sensitive runtime data, weaken kernel address-randomization defenses, and create compliance or incident-response concerns if logs are centralized or retained. Current public exploitation maturity is listed as none, EPSS is low, and it is not in CISA KEV, but kernel vulnerabilities still warrant timely patching because exploitation conditions can vary by distribution, container policy, packet socket restrictions, and netfilter configuration.

How an attack unfolds

An attacker needs local ability to send crafted traffic through AF_PACKET and reach a netfilter netdev logging rule that invokes the vulnerable logging routine. The attacker sends packets using the packet socket path with queueing bypass behavior so the socket buffer reaches the egress hook without a valid MAC header. Netfilter logging then attempts to dump the MAC header for an unknown or logged packet. Because the vulnerable kernel checks only whether the MAC and network header offsets differ, rather than confirming the MAC header was actually set, it reads bytes outside the packet buffer and emits them into kernel logging output. If the attacker can read local kernel logs, syslog, journald, dmesg, or centralized log output, they may recover leaked kernel memory contents.

How to fix it

Upgrade to a vendor-supported Linux kernel that includes the upstream fix for netfilter nf_log MAC header validation. The corrected code checks skb_mac_header_was_set() before dumping the MAC header and uses skb_mac_header_len() for length validation. Because no fixed package versions were provided in the input, track the relevant distribution kernel advisory for the exact patched kernel release. Until patching is complete, reduce exposure by disabling or narrowing nftables/netfilter netdev logging rules that invoke packet logging on egress paths, restricting local access to AF_PACKET/CAP_NET_RAW where operationally possible, disabling unprivileged user namespaces if they grant practical access to packet-socket capabilities in the environment, and restricting kernel log access using controls such as kernel.dmesg_restrict=1 and appropriate permissions on system logs. Treat logs generated before remediation as potentially containing sensitive kernel memory fragments.

How to confirm the fix worked

Confirm the running kernel has been updated to a vendor release containing the nf_log dump_mac_header fix, not merely that packages are installed. Validate with the active kernel version after reboot and compare it to the distribution advisory. For source-based or custom kernels, confirm net/netfilter/nf_log_syslog.c checks whether the skb MAC header was set before reading it and uses the kernel helper for MAC header length validation. Review nftables rules with netdev hooks and log actions to understand whether the vulnerable path was reachable before patching. Check that kernel log access is restricted, for example by verifying kernel.dmesg_restrict is enabled where appropriate. After remediation, monitor kernel logs for absence of KASAN, slab-out-of-bounds, dump_mac_header, or nf_log_netdev_packet warnings during normal packet logging activity.

Typical attack path

1. Obtain local code execution or a foothold on a Linux system where packet sockets are available.
2. Identify or rely on an nftables/netfilter netdev logging configuration that logs egress packets or unknown packets.
3. Create/send AF_PACKET traffic that reaches the direct egress hook with the MAC header unset, such as via a queueing-bypass packet transmission path.
4. Trigger netfilter logging so the kernel attempts to dump the missing MAC header.
5. Read kernel, syslog, journald, or centralized logs to collect out-of-bounds kernel memory bytes emitted by the logging function.
6. Use the disclosed data directly or as support for later attacks, such as bypassing kernel memory layout protections.

How to detect it

Look for evidence in kernel ring buffer logs, journald, syslog, audit logs, endpoint telemetry, and centralized log platforms. Strong indicators include KASAN or kernel BUG reports referencing slab-out-of-bounds reads in dump_mac_header, stack traces containing nf_log_netdev_packet, nft_log_eval, nf_hook_direct_egress, packet_xmit, packet_sendmsg, or references to net/netfilter/nf_log_syslog.c around the MAC header dump logic. Also review nftables rulesets for netdev hook log actions that could have made the path reachable. In audit or EDR telemetry, look for unusual local processes creating AF_PACKET sockets, using CAP_NET_RAW, or generating high volumes of packet sends near kernel log anomalies. Because the leaked data is written to normal logs, investigate who or what accessed dmesg, journalctl, /var/log/kern.log, /var/log/messages, or centralized kernel-log indexes after suspicious entries were created.

• BUG: KASAN: slab-out-of-bounds in dump_mac_header
• slab-out-of-bounds in dump_mac_header
• dump_mac_header (net/netfilter/nf_log_syslog.c:831)
• nf_log_netdev_packet
• nf_log_unknown_packet
• nft_log_eval
• nf_hook_direct_egress
• packet_xmit
• packet_sendmsg
• PACKET_QDISC_BYPASS
• net/netfilter/nf_log_syslog.c:831
• Read of size 1 at addr
• skb_mac_header
• mac_header is 0xffff

What your security team should do

• Prioritize patching Linux kernels on systems that allow local users, containers, or workloads to create packet sockets or hold CAP_NET_RAW.
• Inventory nftables/netfilter configurations for netdev hook logging rules and temporarily disable unnecessary packet logging until patched.
• Restrict access to kernel logs, syslog, journald, and centralized log streams that may contain leaked memory bytes.
• Harden local privilege boundaries by limiting CAP_NET_RAW, reviewing container capabilities, and disabling unprivileged user namespaces where feasible and supported.
• Search historical kernel and system logs for indicators of this bug being triggered, especially KASAN reports or stack traces involving dump_mac_header and nf_log_netdev_packet.
• If indicators are found, preserve relevant logs for incident response, assess who could read those logs, and rotate any secrets that may plausibly have been resident in kernel memory or captured in logs.
• Track distribution advisories for exact fixed kernel builds and ensure systems are rebooted into the patched kernel.