Answer in brief
CVE-2026-74442 records a Unknown severity vulnerability in drm/vmwgfx: avoid destroy_workqueue(NULL) on vkms init failure. The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
A CVSS score is not reported in the current record. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | >=7b0062036c3b71b4a69e244ecf0502c06c4cf5f0 <7c701778c6a369769992614dac8dc00c8ac72afc || >=7b0062036c3b71b4a69e244ecf0502c06c4cf5f0 <96efee36453b697ccbaf75091b7a1807c11809dd || >=7b0062036c3b71b4a69e244ecf0502c06c4cf5f0 <0ee0532f1d405d37f38c44cbba87342e63d3bbd4 || >=7b0062036c3b71b4a69e244ecf0502c06c4cf5f0 <05eaa887e7b4f40fba425f8a1d7a5a8a043092a6 | 7c701778c6a369769992614dac8dc00c8ac72afc, 96efee36453b697ccbaf75091b7a1807c11809dd, 0ee0532f1d405d37f38c44cbba87342e63d3bbd4, 05eaa887e7b4f40fba425f8a1d7a5a8a043092a6 |
| Linux/Linuxgeneric | 6.10 | Not reported |
Published upstream
Aug 15, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Aug 15, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Aug 15, 2026
In 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.
Quoted source text, attributed separately from HOL analysis.
Answer in brief
CVE-2026-74442 records a Unknown severity vulnerability in drm/vmwgfx: avoid destroy_workqueue(NULL) on vkms init failure. The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
A CVSS score is not reported in the current record. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | >=7b0062036c3b71b4a69e244ecf0502c06c4cf5f0 <7c701778c6a369769992614dac8dc00c8ac72afc || >=7b0062036c3b71b4a69e244ecf0502c06c4cf5f0 <96efee36453b697ccbaf75091b7a1807c11809dd || >=7b0062036c3b71b4a69e244ecf0502c06c4cf5f0 <0ee0532f1d405d37f38c44cbba87342e63d3bbd4 || >=7b0062036c3b71b4a69e244ecf0502c06c4cf5f0 <05eaa887e7b4f40fba425f8a1d7a5a8a043092a6 | 7c701778c6a369769992614dac8dc00c8ac72afc, 96efee36453b697ccbaf75091b7a1807c11809dd, 0ee0532f1d405d37f38c44cbba87342e63d3bbd4, 05eaa887e7b4f40fba425f8a1d7a5a8a043092a6 |
| Linux/Linuxgeneric | 6.10 | Not reported |
Published upstream
Aug 15, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Aug 15, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Aug 15, 2026
In 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.
Quoted source text, attributed separately from HOL analysis.