CVE-2022-36280

What it actually does

Out-of-bounds memory access in the vmwgfx driver (drivers/gpu/vmxgfx/vmxgfx_kms.c) triggered via the /dev/dri/renderD* device file, resulting in local denial of service.

Why it matters to the business

Local users on affected Linux systems can crash the GPU subsystem or host, disrupting workloads and availability; the flaw remains relevant in long-lived distributions and container hosts despite low exploitation probability.

How an attack unfolds

An attacker with a local account opens the GPU render device file and issues crafted ioctls that cause the vmwgfx driver to read or write beyond allocated memory bounds, leading to a kernel crash.

How to fix it

Upgrade the Linux kernel to a version containing the fix for the vmwgfx out-of-bounds access in vmwgfx_kms.c; apply vendor backports for Debian and other distributions still shipping vulnerable kernels.

How to confirm the fix worked

Confirm the running kernel version is newer than the vulnerable release, review the vmwgfx_kms.c source for the bounds check, and test that unprivileged access to the render device no longer triggers a crash under load.

Typical attack path

1. Obtain a local shell on a Linux system exposing the vmwgfx driver
2. Open /dev/dri/renderD* with standard user permissions
3. Issue malicious GPU-related ioctls to trigger out-of-bounds access
4. Cause kernel panic resulting in denial of service

How to detect it

Review kernel logs (dmesg, /var/log/kern.log) for vmwgfx driver faults or oops messages around the time of crashes; correlate with process accounting showing access to GPU device nodes by non-privileged users.

• /dev/dri/renderD128
• vmwgfx oops
• vmwgfx_kms.c

What your security team should do

• Patch all systems to a fixed kernel as soon as distribution updates are available
• Restrict access to /dev/dri/renderD* devices via udev rules or group membership where GPU access is not required
• Monitor kernel logs for vmwgfx-related oops or panic entries