CVE-2024-50169

What it actually does

Failing to call virtio_transport_dec_rx_pkt after dequeuing a packet via read_skb leaves rx_bytes non-zero while the rx_queue is empty, violating the balance with virtio_transport_inc_rx_pkt and triggering warnings plus incorrect peer credit updates in vsock SOCK_STREAM paths.

Why it matters to the business

Disrupts stable operation of virtual socket communications in virtualized Linux environments, potentially causing application errors or requiring restarts; urgency remains low given absence from KEV and flat EPSS.

How an attack unfolds

An attacker with access to a vsock endpoint sends traffic that triggers packet dequeue without rx_bytes update; this produces the empty-queue warning and may allow credit miscalculation, with similar Linux kernel issues previously leveraged by espionage and financially motivated actors in 2024 campaigns.

How to fix it

Upgrade the Linux kernel to a version containing the fix that ensures virtio_transport_inc_rx_pkt and dec_rx_pkt calls remain balanced after read_skb and sends updated credit to the peer.

How to confirm the fix worked

Confirm the kernel version includes the vsock rx_bytes update commit; exercise vsock recv paths under load and verify absence of the rx_queue empty warning in dmesg.

Typical attack path

1. Gain local or guest access to a system using virtio-vsock
2. Establish a SOCK_STREAM vsock connection
3. Induce repeated read_skb operations that dequeue packets
4. Observe or trigger the rx_bytes mismatch warning and resulting socket state errors

How to detect it

Search kernel logs for the exact warning string about rx_queue empty but rx_bytes non-zero; correlate with vsock socket activity in affected virtualized workloads.

What your security team should do

• Prioritize kernel updates on all systems exposing vsock interfaces
• Monitor for the rx_queue warning in system logs as a sign of exposure
• Review vsock usage in container or VM workloads for unnecessary exposure