CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HIn the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: avoid destroy_workqueue(NULL) on vkms init failure Two paths through vmw_vkms_init() can leave vmw->crc_workq NULL while still leaving the rest of the driver in a state that calls vmw_vkms_cleanup() at module unload: 1. vmw_host_get_guestinfo(GUESTINFO_VBLANK, ...) failing or returning an oversized buffer -- the common case on hosts without a VBLANK guestinfo entry -- early-returned before the workqueue allocation. 2. alloc_ordered_workqueue() returning NULL on memory pressure. vmw_vkms_cleanup() then calls destroy_workqueue(NULL), which dereferences wq->name and panics. Fix the first case by removing the early return: vmw->vkms_enabled is already false on the rpci-failure path so no work will ever be queued, and allocating the workqueue unconditionally keeps the control flow simple. Fix the second case by guarding the cleanup with a NULL check, since alloc_ordered_workqueue() can still fail under low memory. A flaw was found in the Linux kernel's `drm/vmwgfx` driver. This vulnerability occurs when the `vmw_vkms_init()` function fails to initialize a workqueue, leaving a pointer as NULL. During module unload, the `vmw_vkms_cleanup()` function attempts to destroy this NULL workqueue, leading to a kernel panic. A local attacker could potentially trigger this condition, resulting in a system crash and a Denial of Service (DoS).
Multiple vulnerabilities have been discovered in the Linux kernel of Debian. These vulnerabilities allow for privilege escalation, data compromise, and denial of service. The affected Debian versions are prior to 6.12.10…