CVE-2026-74666: packet: synchronize pressure clearing with ring reconfiguration
In the Linux kernel, the following vulnerability has been resolved:
packet: synchronize pressure clearing with ring reconfiguration
packetsetring() updates the RX ring state under skreceivequeue.lock, but used to publish the tpacket receive mode through po->prothook.func after releasing that lock. packetpoll() and packetrecvmsg() can then run the pressure clearing path after the ring has been cleared while still seeing tpacketrcv, causing packetrcvhasroom() to dereference stale or NULL ring storage.
Move the existing receive hook assignment into the same skreceivequeue.lock section as the ring state update. Keep the assignment otherwise unchanged, including on TX ring reconfiguration, to avoid adding behavior changes that are not required for the fix.
Serialize packetrecvmsg() pressure clearing with the same queue lock only after PACKETSOCKPRESSURE has been observed. If the flag is clear and the socket has moved away from tpacketrcv, packetsetring() has already detached the socket and waited for synchronizenet(), so no new packet input can set the flag again.
packetpoll() already holds skreceivequeue.lock, so it uses the new unlocked helper directly.
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.152.1-1
Event History
Frequently Asked Questions
Which systems are exposed to this issue?
Systems using Linux packet sockets with a configured packet RX ring are exposed when ring reconfiguration can occur concurrently with packet polling or receive processing. The affected paths involve tpacket receive mode and PACKET_SOCK_PRESSURE handling.
What conditions are required to trigger the vulnerability?
The issue requires a race between packet_set_ring() clearing or reconfiguring the RX ring and packet_poll() or packet_recvmsg() executing pressure clearing while still observing the tpacket_rcv receive hook. That race can cause __packet_rcv_has_room() to access stale or NULL ring storage.
How can I tell whether a running system contains the fix?
Check whether the kernel includes one of the referenced stable commits: cf8189b82bb93f219ab740e0346c919ad65ada62, ad740b4990347521f0db260d381f9f74e7b340ba, or 2c7b5eb87b2b288cdbde825f21d2b83b2f5da747. The fix moves receive-hook assignment under sk_receive_queue.lock and serializes the relevant packet_recvmsg() pressure-clearing path.