CVE-2022-3629

What it actually does

The vulnerability triggers a memory leak in the vsock_connect function of net/vmw_vsock/af_vsock.c by failing to release allocated resources on certain code paths.

Why it matters to the business

Prolonged operation in VSOCK-enabled virtualized environments can gradually exhaust available memory, leading to degraded performance or unplanned restarts on affected Linux systems.

How an attack unfolds

An attacker with local access repeatedly exercises the vsock_connect code path under specific socket conditions that bypass cleanup logic; exploitation is rated high complexity with no public exploits or named threat actor campaigns observed.

How to fix it

Apply the upstream kernel patch or upgrade to a fixed release; the referenced commit 826bfe4bbd7594188e3d74d2539d9707b1c6a14b resolves the leak in the vim/vim GIT tree (note: patch applies to kernel sources).

How to confirm the fix worked

Confirm the vsock_connect function contains the corrected resource-release logic by reviewing the patch diff or running memory-leak detection tools such as kmemleak after exercising VSOCK connections.

Typical attack path

1. Gain local user access on a system running an affected kernel
2. Create and manipulate VSOCK sockets to invoke vsock_connect
3. Trigger error or edge-case paths that allocate without freeing
4. Repeat operations to accumulate leaked memory until resource pressure occurs

How to detect it

Review kernel logs for repeated vsock allocation warnings, monitor /proc/meminfo for unexpected slab growth in vsock-related caches, and inspect process activity that opens VSOCK sockets.

What your security team should do

• Prioritize patching kernel packages on all systems exposing VSOCK interfaces
• Monitor EPSS and KEV status for any future increase in exploit maturity
• Limit VSOCK usage to trusted virtual machine boundaries where possible