CVE-2026-53223

What it actually does

This Linux kernel flaw is an information disclosure and potential stability issue in the socket timestamping control-message path. The kernel incorrectly treated certain AF_PACKET outgoing packet tap buffers as if they came from the socket error queue. When timestamping and SO_RXQ_OVFL are enabled, AF_PACKET control-buffer data can be misinterpreted as error-queue metadata. Under specific conditions, including an odd packet-drop counter and a non-linear socket buffer, the kernel may copy data beyond the valid linear packet area, causing hardened usercopy failures or exposing adjacent kernel heap contents to user space.

Why it matters to the business

Successful exploitation could allow a local user or containerized workload with the ability to create AF_PACKET sockets to read unintended kernel memory or trigger kernel safety checks that may affect system stability. While there is no current KEV listing, no known ransomware association, and EPSS is low, Linux kernel exposure is broad and the bug affects a sensitive boundary between user space and kernel memory, so organizations should remediate through normal kernel patch cycles with higher priority on multi-tenant hosts, container platforms, network appliances, and systems granting CAP_NET_RAW.

How an attack unfolds

An attacker first obtains local code execution on a Linux system and the privileges needed to open AF_PACKET sockets, commonly CAP_NET_RAW or equivalent permissions within a user namespace. They create an AF_PACKET socket that receives outgoing packet taps and enable socket timestamping along with SO_RXQ_OVFL so receive-queue overflow accounting is included in ancillary data. The attacker then manipulates packet activity and drop-counter state so that an outgoing AF_PACKET socket buffer is marked PACKET_OUTGOING and the overlapping control-buffer field is interpreted as timestamping option statistics. If the packet buffer is non-linear, the timestamp control-message path can copy beyond the valid linear skb data. Depending on kernel hardening and runtime conditions, this may produce a hardened usercopy fault, kernel warning/oops, or disclose adjacent heap bytes in ancillary data returned to the attacker through recvmsg().

How to fix it

Upgrade to a vendor kernel that includes the upstream fix for the AF_PACKET timestamping/error-queue skb validation issue. Because no exact affected package list or fixed versions were provided, use the fixed kernel versions published by the relevant Linux distribution or appliance vendor and reboot into the updated kernel, or apply an approved live patch if available. As interim mitigation, restrict CAP_NET_RAW, remove unnecessary container capabilities, disable or tightly control unprivileged user namespaces where operationally feasible, apply seccomp/AppArmor/SELinux policies that block or constrain AF_PACKET socket creation, and limit access to packet-capture functionality to trusted administrative workloads.

How to confirm the fix worked

Confirm the running kernel, not only the installed package, is updated to a vendor build containing the fix. Validate with uname -a, package-manager kernel version checks, vendor security advisories, and kernel changelog entries referencing the AF_PACKET timestamping/error-queue skb fix or the change that verifies PACKET_OUTGOING skbs are paired with sock_rmem_free ownership before treating them as error-queue skbs. After reboot or live patching, verify no workloads still run on the vulnerable kernel. Where safe, run a vendor or internal regression test that exercises AF_PACKET sockets with timestamping and SO_RXQ_OVFL and confirm it no longer produces hardened usercopy warnings, kernel oopses, or unexpected SCM_TIMESTAMPING_OPT_STATS data from ordinary AF_PACKET outgoing taps.

Typical attack path

1. Gain local execution on a Linux host or inside a container with permission to create AF_PACKET sockets.
2. Create an AF_PACKET socket and arrange to receive outgoing packet taps.
3. Enable timestamping-related socket options and SO_RXQ_OVFL on the socket.
4. Generate network traffic and queue pressure so the packet drop counter reaches a triggering state.
5. Receive a crafted or naturally occurring non-linear skb through the packet socket.
6. Cause the kernel timestamp control-message path to misclassify the skb as an error-queue skb.
7. Collect leaked ancillary data from recvmsg() or trigger hardened usercopy diagnostics/crash behavior.

How to detect it

Look for evidence in kernel logs, system journals, audit logs, endpoint telemetry, and container runtime audit events. The most useful signs are hardened usercopy failures, kernel oops/panic messages, warnings involving AF_PACKET, skb timestamping, SCM_TIMESTAMPING_OPT_STATS, recvmsg ancillary data, or suspicious processes repeatedly creating AF_PACKET sockets while enabling SO_TIMESTAMPING and SO_RXQ_OVFL. Auditd or eBPF telemetry can identify processes calling socket(AF_PACKET, ...) and setsockopt() for timestamping and overflow counters, especially from unexpected users, containers, build jobs, or application services. For containerized environments, review workloads granted CAP_NET_RAW, hostNetwork, privileged mode, or packet-capture tooling. Memory disclosure may not produce persistent artifacts, so lack of logs does not rule out exploitation; prioritize identifying suspicious capability use and any contemporaneous kernel hardening events.

• hardened usercopy
• usercopy: kernel memory exposure attempt
• usercopy: Kernel memory exposure attempt
• kernel BUG at mm/usercopy.c
• WARNING: CPU:
• Oops:
• general protection fault
• SCM_TIMESTAMPING_OPT_STATS
• SO_RXQ_OVFL
• SO_TIMESTAMPING
• AF_PACKET
• PACKET_OUTGOING
• skb_is_err_queue
• sock_exterr_skb
• sock_rmem_free
• recvmsg
• socket(AF_PACKET
• setsockopt
• CAP_NET_RAW

What your security team should do

• Prioritize patching internet-facing, multi-tenant, container-hosting, CI/CD runner, Kubernetes node, and network-monitoring systems where untrusted code may have CAP_NET_RAW or AF_PACKET access.
• Inventory systems and containers that grant CAP_NET_RAW, host networking, packet capture privileges, or unprivileged user namespaces, and reduce those permissions where possible.
• Deploy the vendor-fixed kernel through standard patch management and ensure systems are rebooted or live-patched successfully.
• Add detection for hardened usercopy, skb, AF_PACKET, and timestamping-related kernel warnings in centralized logging.
• Review container runtime, Kubernetes PodSecurity, seccomp, AppArmor, and SELinux policies to prevent untrusted workloads from creating AF_PACKET sockets.
• Because exploitation may leave little evidence unless it crashes or logs a kernel warning, treat exposure reduction and patch validation as more reliable than retrospective detection.