CVE-2026-53223: net: guard timestamp cmsgs to real error queue skbs
In the Linux kernel, the following vulnerability has been resolved:
net: guard timestamp cmsgs to real error queue skbs
skbiserrqueue() treats PACKETOUTGOING as the sole marker for an skb from skerrorqueue. That assumption is not true for AFPACKET sockets: outgoing packet taps are also delivered to packet sockets with skb->pkttype == PACKETOUTGOING, but their skb->cb is owned by AFPACKET instead of struct sockexterrskb.
If such an skb is received with timestamping enabled, the generic timestamp cmsg path can read AFPACKET control-buffer state as sockexterrskb::optstats. With SORXQOVFL enabled, the packet drop counter overlaps optstats. An odd drop count makes the path emit SCMTIMESTAMPINGOPTSTATS 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 skbiserrqueue() local to net/socket.c, but make it verify that the PACKETOUTGOING marker is paired with the sockrmemfree destructor installed by sockqueueerrskb(). AFPACKET receive skbs use normal receive ownership and no longer pass as error-queue skbs, while legitimate skerrorqueue entries keep the PACKETOUTGOING marker and sockrmemfree ownership.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Fixed in 6.6.143.1-1
Event History
Frequently Asked Questions
Which systems are realistically exposed?
Systems using AF_PACKET sockets that receive outgoing packet taps are exposed when timestamping is enabled. The issue is locally exploitable, so an attacker needs local access with the privileges required to use the affected socket configuration.
What conditions are needed to trigger the problematic timestamp handling?
An AF_PACKET receive skb marked PACKET_OUTGOING must be processed through the generic timestamp control-message path. With SO_RXQ_OVFL enabled, an odd packet-drop count can be interpreted as timestamp statistics and cause SCM_TIMESTAMPING_OPT_STATS to include skb length and data; non-linear skbs can then copy beyond the linear head.
What can be done before an update is available?
Disable timestamping on affected AF_PACKET sockets to prevent the generic timestamp cmsg path from handling these packet-tap skbs. Where feasible, also avoid enabling SO_RXQ_OVFL on those sockets, since its drop counter is the value that can overlap the misread timestamp statistics.