CVE-2021-4442

What it actually does

The flaw permits TCP_QUEUE_SEQ socket option to alter receive sequence numbers after data has been restored to a non-empty receive queue, bypassing intended sanity checks and causing sequence mismatches that trigger kernel warnings or connection resets.

Why it matters to the business

Local attackers can induce TCP connection failures or kernel warnings on affected systems, resulting in service disruption for network-dependent applications with minimal attacker effort.

How an attack unfolds

An attacker creates a TCP socket, enables repair mode and queue selection via setsockopt, populates the receive queue with data, disables repair mode, then issues TCP_QUEUE_SEQ with an out-of-sync value; subsequent recv operations expose the inconsistency leading to ECONNRESET or warnings.

How to fix it

Apply kernel patches adding empty-queue validation to TCP_QUEUE_SEQ on both rx and tx paths; upgrade to releases containing the fix for the reported TCP sequence handling issue.

How to confirm the fix worked

Confirm presence of sanity checks in tcp_recvmsg_locked and equivalent tx path functions; test that TCP_QUEUE_SEQ calls on non-empty queues are rejected or ignored.

Typical attack path

1. Create AF_INET6 SOCK_STREAM socket
2. Enable TCP_REPAIR via setsockopt
3. Select TCP_REPAIR_QUEUE
4. Send data to populate receive queue
5. Disable TCP_REPAIR
6. Set TCP_QUEUE_SEQ to invalid value
7. Perform recvfrom to trigger mismatch handling

How to detect it

Review system logs for messages containing 'TCP recvmsg seq # bug' or 'WARNING.*tcp_recvmsg_locked'; inspect audit logs for unusual setsockopt calls involving SOL_TCP and TCP_QUEUE_SEQ.

What your security team should do

• Prioritize kernel updates on all Linux hosts handling TCP traffic
• Monitor for TCP sequence warning logs in syslog
• Restrict unprivileged use of TCP_REPAIR socket options where possible