CVE-2022-50842

What it actually does

NULL pointer dereference in the virtio DRM driver when userspace submits a 2D buffer object that is not shmem-backed, instead of enforcing the required shmem BO type during transfer operations.

Why it matters to the business

Potential kernel crashes or instability in virtualized Linux environments using virtio graphics, leading to VM downtime or denial of service without widespread active exploitation.

How an attack unfolds

A local userspace process interacting with the virtio GPU device allocates or references a VRAM-backed BO and triggers a 2D transfer operation; the missing type check allows the driver to dereference a NULL pointer.

How to fix it

Upgrade affected packages to the listed fixed versions: libvncserver 0.9.11+dfsg-1.2 on Debian 11-14 or the Linux kernel commit f134f261d76ae3d5ecf68db642eaa746ceb84cfb; apply vendor updates promptly.

How to confirm the fix worked

Confirm package versions match or exceed the fixed releases; verify the presence of the type check in drm/virtio code paths handling 2D BO transfers.

Typical attack path

1. Locate virtio GPU device node
2. Prepare and submit a non-shmem 2D BO via ioctl
3. Invoke transfer operation that assumes shmem backing
4. Trigger NULL dereference in kernel context

How to detect it

Review kernel logs for virtio or drm NULL dereference oops messages around graphics transfer operations; no public exploitation artifacts are known.

What your security team should do

• Apply the specified kernel and libvncserver updates across all affected systems
• Monitor for any future EPSS increases or KEV inclusion
• Restrict untrusted userspace access to virtio GPU devices where feasible