CVE-2025-21669

What it actually does

NULL pointer dereference in vsock/virtio when vsk->transport becomes NULL after socket de-assignment or reassignment during interrupted connect operations, causing crash on subsequent packet receipt.

Why it matters to the business

Kernel crashes leading to denial of service on Linux systems relying on virtio vsock for virtual machine networking, with potential disruption to cloud and container workloads.

How an attack unfolds

An attacker performs a connect on a vsock socket that is interrupted by a signal, follows with a second failed connect leaving transport at NULL, then triggers packet handling to dereference the null pointer.

How to fix it

Update the Linux kernel to commit 18a7fc371d1dbf8deff16c2dd9292bcc73f43040 or later versions that include the transport change discard logic.

How to confirm the fix worked

Confirm presence of discard logic for changed transports in vsock/virtio source; reproduce the signal-interrupted connect scenario and verify no NULL dereference occurs.

Typical attack path

1. Create vsock socket
2. Issue connect() interrupted by signal
3. Issue second failed connect()
4. Trigger incoming packet processing to access NULL transport

How to detect it

Review kernel logs and oops reports for NULL pointer dereferences involving vsock or virtio transport access after socket connect failures.

• vsk->transport at NULL
• NULL pointer dereference vsock/virtio
• packet received after transport change

What your security team should do

• Apply the referenced kernel commit or stable update containing the fix
• Monitor kernel logs for vsock-related NULL pointer oops
• Prioritize patching on systems using virtio vsock for inter-VM communication