CVE-2025-38462

What it actually does

A TOCTOU race in vsock_find_cid() and vsock_dev_do_ioctl() allows transport_{g2h,h2g} pointers to become NULL after the initial check when a module unloads, resulting in null-pointer dereference.

Why it matters to the business

Kernel crashes or denial-of-service on systems using the vsock subsystem, with elevated urgency due to listed threat actor interest in related Linux kernel flaws and 459 days of public exposure.

How an attack unfolds

An attacker concurrently invokes vsock bind or ioctl operations while a vsock transport module is unloading; the pointers pass the NULL check but are dereferenced after becoming NULL, triggering KASAN null-ptr-deref as shown in the call traces for __vsock_bind and vsock_dev_do_ioctl. Named actors have shown interest in similar Linux kernel privilege-escalation and spyware campaigns.

How to fix it

Apply the upstream fix that introduces vsock_transport_local_cid() to protect the pointers; update affected kernels to versions containing the resolution referenced for the vsock transport handling.

How to confirm the fix worked

Confirm the vsock_transport_local_cid() helper is present and that KASAN no longer reports null-ptr-deref at vsock_find_cid+0x47 or vsock_dev_do_ioctl+0x58; re-run bind/ioctl stress tests under module unload.

Typical attack path

1. Load or ensure vsock module usage on target
2. Trigger concurrent module unload with bind or ioctl syscalls
3. Force dereference of now-NULL transport pointer
4. Cause kernel panic via null-ptr-deref

How to detect it

Search kernel logs and KASAN reports for the strings vsock_find_cid, vsock_dev_do_ioctl, and null-ptr-deref in the ranges shown in the call traces; correlate with module unload events and bind/ioctl syscalls.

• vsock_find_cid+0x47/0x90
• vsock_dev_do_ioctl.isra.0+0x58/0xf0
• KASAN: null-ptr-deref in range [0x0000000000000118-0x000000000000011f]
• __vsock_bind+0x4b2/0x720
• vsock_bind+0x90/0xe0

What your security team should do

• Prioritize kernel updates on all systems exposing vsock
• Monitor kernel logs for vsock-related KASAN null-ptr-deref entries
• Restrict unprivileged access to vsock bind and ioctl surfaces where possible
• Track EPSS trend and related threat-actor activity for escalation