CVE-2025-38618

What it actually does

The flaw permits vsock sockets to autobind to VMADDR_PORT_ANY, resulting in a use-after-free when an incoming connection triggers accept() on a socket absent from the unbound list, causing an erroneous refcount decrement on subsequent bind operations.

Why it matters to the business

Linux kernel systems relying on vsock (common in virtualized and containerized environments) face elevated risk of crashes or memory corruption that could enable local privilege escalation; low EPSS and no KEV listing reduce immediate external threat but affected Chainguard packages and upstream kernels still require prompt attention given 431 days since publication.

How an attack unfolds

An attacker creates a vsock socket that autobinds to VMADDR_PORT_ANY, establishes a connection to trigger accept(), then issues a bind on the resulting socket; this path mirrors the earlier fcdd2242c023 fix and can be reached via local or containerized access, with listed threat actors in Linux kernel privilege escalation campaigns providing contextual exploitation patterns.

How to fix it

Update affected packages to the listed fixed versions: openjdk-11-openj9 family packages to 0.53.0-r0 on Chainguard and the Linux kernel to commit c04a2c1ca25b9b23104124d3b2d349d934e302de; rebuild and reboot systems using vsock.

How to confirm the fix worked

Verify package versions match the fixed releases, confirm the kernel commit is present via git log or uname, and test that binding attempts to VMADDR_PORT_ANY are rejected in __vsock_bind_connectible().

Typical attack path

1. Create vsock socket and trigger autobind to VMADDR_PORT_ANY
2. Initiate connection to the bound socket
3. Call accept() on the listening socket to obtain a new socket with VMADDR_PORT_ANY
4. Perform bind on the accepted socket to induce extra refcount decrement and use-after-free

How to detect it

Review kernel logs for vsock-related oops or refcount warnings, audit process creation around vsock bind/accept calls, and correlate with container runtime activity; threat-actor context from Linux kernel privilege-escalation campaigns can guide targeted log searches.

What your security team should do

• Apply kernel and package updates immediately on all Linux hosts using vsock
• Audit container and VM images for older Chainguard openjdk-11-openj9 variants
• Monitor for local privilege-escalation attempts in environments with vsock sockets
• Reassess EPSS trend monthly and review any new threat-actor reporting