HIGH 7.1

CVE-2026-53223: Linux Kernel AF_PACKET Socket Timestamp Heap Memory Disclosure

A flaw in the Linux kernel's network stack allows a local attacker to misuse socket timestamping features to read or leak adjacent kernel heap memory. The vulnerability arises from incorrect classification of packet socket buffers, where the kernel mistakenly treats outgoing AF_PACKET frames as error-queue messages when timestamping is enabled. This confusion causes the kernel to read control buffer state from the wrong location, potentially exposing sensitive data or triggering memory protection mechanisms.

Source data · NVD / CISA · public domain

CVSS
3.1 · 7.1 HIGH · CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H
Weaknesses (CWE)
Affected products
14 configuration(s)
Published / Modified
2026-06-25 / 2026-07-02

NVD description (verbatim)

In the Linux kernel, the following vulnerability has been resolved: net: guard timestamp cmsgs to real error queue skbs skb_is_err_queue() treats PACKET_OUTGOING as the sole marker for an skb from sk_error_queue. That assumption is not true for AF_PACKET sockets: outgoing packet taps are also delivered to packet sockets with skb->pkt_type == PACKET_OUTGOING, but their skb->cb is owned by AF_PACKET instead of struct sock_exterr_skb. If such an skb is received with timestamping enabled, the generic timestamp cmsg path can read AF_PACKET control-buffer state as sock_exterr_skb::opt_stats. With SO_RXQ_OVFL enabled, the packet drop counter overlaps opt_stats. An odd drop count makes the path emit SCM_TIMESTAMPING_OPT_STATS with skb->len and skb->data. For non-linear skbs this copies past the linear head and can trigger hardened usercopy or disclose adjacent heap contents. Keep skb_is_err_queue() local to net/socket.c, but make it verify that the PACKET_OUTGOING marker is paired with the sock_rmem_free destructor installed by sock_queue_err_skb(). AF_PACKET receive skbs use normal receive ownership and no longer pass as error-queue skbs, while legitimate sk_error_queue entries keep the PACKET_OUTGOING marker and sock_rmem_free ownership.

8 reference(s) · View on NVD →

SEC.co analysis · AI-assisted, reviewed against source

Technical summary

The vulnerability exists in the Linux kernel's handling of socket error queues and AF_PACKET sockets. The `skb_is_err_queue()` function incorrectly relies solely on the PACKET_OUTGOING flag to identify error-queue socket buffers. However, AF_PACKET sockets also set this flag on outgoing packet taps, but use different control buffer layout (AF_PACKET's control block rather than struct sock_exterr_skb). When socket timestamping with SO_RXQ_OVFL (receive queue overflow) is enabled, the generic timestamp cmsg handler misinterprets AF_PACKET control-buffer state as sock_exterr_skb::opt_stats, causing the kernel to emit SCM_TIMESTAMPING_OPT_STATS with skb->len and skb->data pointing to non-linear buffer segments. For non-linear skbs, this can read past the linear head into heap memory, bypassing hardened usercopy checks or leaking adjacent heap contents. The fix requires `skb_is_err_queue()` to verify both the PACKET_OUTGOING marker and the presence of the sock_rmem_free destructor—installed only by legitimate error-queue paths—ensuring AF_PACKET receive skbs no longer masquerade as error-queue entries.

Business impact

This vulnerability enables local privilege escalation and information disclosure on systems where untrusted users have network access or can create packet sockets. An attacker can leak kernel heap contents, potentially discovering ASLR bypasses, credential structures, or other sensitive kernel data. On systems with SELinux or AppArmor confinement, the kernel memory disclosure may circumvent security policies. The condition requires local access and socket creation privileges, limiting exposure in fully isolated container or VM environments but posing significant risk on shared multi-user systems or systems running untrusted network-facing daemons.

Affected systems

All Linux kernel versions are potentially affected, as the vulnerability affects core network stack socket handling. The issue resides in generic timestamp cmsg processing and AF_PACKET socket classification, which are present in mainline kernels. Mitigation requires a kernel patch implementing stricter validation of error-queue socket buffers. Systems running older long-term support (LTS) kernels are at risk until patches are backported and deployed.

Exploitability

Exploitation requires local system access and the ability to create AF_PACKET sockets (typically available to any unprivileged user on default configurations). An attacker must enable socket timestamping with SO_RXQ_OVFL and craft specific network conditions to trigger non-linear skb allocation, then read kernel memory via the misclassified timestamp cmsg. No network-based exploitation is possible. The attack does not require kernel source knowledge but does require understanding of socket APIs and packet buffer internals. This is not currently tracked as a known exploited vulnerability (KEV status: not listed).

Remediation

Deploy a kernel patch that restores strict differentiation between error-queue skbs and AF_PACKET receive skbs by verifying both the PACKET_OUTGOING flag and the sock_rmem_free destructor ownership. The fix moves `skb_is_err_queue()` validation to be more explicit about ownership semantics, ensuring only true error-queue entries pass timestamp cmsg processing. Vendor advisories will specify exact kernel versions receiving fixes; systems should prioritize kernel updates addressing this flaw.

Patch guidance

Consult your Linux distribution's security advisories and kernel release notes for the specific patched kernel version addressing CVE-2026-53223. Patches should be applied as part of routine kernel security updates. Test kernel updates in non-production environments first to ensure compatibility with your workload. Verify patch application by confirming the kernel includes the fix to `skb_is_err_queue()` and socket timestamp cmsg handling. For custom or embedded kernels, apply the upstream fix directly from the Linux kernel repository.

Detection guidance

Monitor system logs for userspace programs attempting to create AF_PACKET sockets with timestamping enabled, particularly in multi-user or container environments. Kernel hardened-usercopy violations or memory protection faults paired with socket operations may indicate exploit attempts. Behavioral detection: watch for processes reading unusually large amounts of network socket data or repeatedly failing socket timestamping calls. Since this is a local vulnerability, monitor sudo/privilege escalation attempts correlating with socket creation. Network monitoring is not effective; focus on system call tracing (seccomp, audit logs) to detect AF_PACKET socket creation and SO_REUSEADDR/SO_RXQ_OVFL socket options being set together.

Why prioritize this

This vulnerability merits HIGH priority due to its CVSS 7.1 score (high severity), local privilege escalation capability, and information disclosure potential. Kernel vulnerabilities affecting core networking paths have wide applicability across Linux deployments. The requirement for local access limits immediate enterprise risk in well-segmented networks, but shared hosting, container orchestration platforms, and development systems face significant exposure. Systems running multi-tenant workloads or allowing untrusted code execution should prioritize patching. The fact that it is not yet in the KEV catalog should not delay remediation—this reflects current exploit prevalence, not risk.

Risk score, explained

CVSS 3.1 score of 7.1 (HIGH) reflects: Attack Vector Local (requires local access, lowering exploitability in pure network scenarios but not in shared systems), Attack Complexity Low (no race conditions or special timing required), Privileges Required Low (any user with socket creation permission), User Interaction None (fully automated attack), Scope Unchanged (impact contained to the affected system), Confidentiality High (kernel heap disclosure), Integrity None (no modification capability), and Availability High (ability to trigger memory protection exceptions or DoS). The combination of memory disclosure and availability impact justifies HIGH severity for environments permitting local attackers.

Frequently asked questions

Can this vulnerability be exploited remotely?

No. This vulnerability requires local system access and the ability to create AF_PACKET sockets. It cannot be triggered via network-facing services or remote connections alone. However, systems running network daemons that process untrusted input or container orchestration platforms where users can create sockets are at risk.

What Linux distributions are affected?

All Linux distributions using unpatched mainline or LTS kernels are affected, as the vulnerability is in core kernel network stack code common to all distributions. Patched versions will vary by distribution; consult your vendor's security advisories for specific kernel versions and update availability.

Can this be mitigated without a kernel patch?

Partial mitigation is possible by restricting socket creation privileges (via seccomp, AppArmor, or SELinux policies) to prevent unprivileged users from creating AF_PACKET sockets, and disabling SO_RXQ_OVFL socket option if not required. However, these are incomplete mitigations; kernel patching is the definitive remediation.

What is the difference between this and other kernel memory disclosure vulnerabilities?

This vulnerability is specific to the intersection of AF_PACKET socket classification and generic timestamp cmsg processing. Unlike many kernel info-leaks that require specific subsystems, this affects any system with timestamping enabled on packet sockets, making it broadly applicable across Linux deployments.

This analysis is provided for informational purposes to support vulnerability management and risk assessment. The information herein is derived from available CVE records and Linux kernel advisory data as of the publication date. Organizations should consult official Linux distribution advisories, kernel release notes, and vendor statements for authoritative patch version numbers, availability dates, and distribution-specific remediation guidance. No exploit code or weaponized proof-of-concept is provided herein. Organizations are responsible for validating patch applicability, conducting testing in non-production environments, and implementing patches according to their own risk tolerance and change management policies. SEC.co makes no warranty regarding the completeness or accuracy of patch deployment details or vendor timelines. Source: NVD (public-domain), retrieved 2026-08-03. Analysis generated by SEC.co (claude-haiku-4-5).