Answer in brief
CVE-2026-46314 records a Medium severity (CVSS 5.5) vulnerability in drm/v3d: Reject empty multisync extension to prevent infinite loop. 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.
CVSS is 5.5. 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 | >=e4165ae8304e5ea822fbe5909dd3be5445c058b7 <309abbddeca0c12714721928a819ef45e5710998 || >=e4165ae8304e5ea822fbe5909dd3be5445c058b7 <4fa42a249e8cd6ed17aea04e5695b6e9001f2433 || >=e4165ae8304e5ea822fbe5909dd3be5445c058b7 <9c5164781cb388d219d8f49fa0f0b04cf86ad544 || >=e4165ae8304e5ea822fbe5909dd3be5445c058b7 <fb44d589bf3148e13452185a6e772a7efbf2d684 | 309abbddeca0c12714721928a819ef45e5710998, 4fa42a249e8cd6ed17aea04e5695b6e9001f2433, 9c5164781cb388d219d8f49fa0f0b04cf86ad544, fb44d589bf3148e13452185a6e772a7efbf2d684 |
| Linux/Linuxgeneric | 5.16 | Not reported |
Published upstream
Jun 8, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Jul 8, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Jun 19, 2026
In the Linux kernel, the following vulnerability has been resolved: drm/v3d: Reject empty multisync extension to prevent infinite loop v3d_get_extensions() walks a userspace-provided singly-linked list of ioctl extensions without any bound on the chain length. A local user can craft a self-referential extension (ext->next == &ext) with zero in_sync_count and out_sync_count, which bypasses the existing duplicate- extension guard: if (se->in_sync_count || se->out_sync_count) return -EINVAL; The guard never fires because v3d_get_multisync_post_deps() returns immediately when count is zero, leaving both fields at zero on every iteration. The result is an infinite loop in kernel context, blocking the calling thread and pegging a CPU core indefinitely. Fix this by rejecting a multisync extension where both in_sync_count and out_sync_count are zero in v3d_get_multisync_submit_deps(). An empty multisync carries no synchronization information and serves no useful purpose, so returning -EINVAL for such an extension is the correct defense against this attack vector.
Quoted source text, attributed separately from HOL analysis.
Answer in brief
CVE-2026-46314 records a Medium severity (CVSS 5.5) vulnerability in drm/v3d: Reject empty multisync extension to prevent infinite loop. 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.
CVSS is 5.5. 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 | >=e4165ae8304e5ea822fbe5909dd3be5445c058b7 <309abbddeca0c12714721928a819ef45e5710998 || >=e4165ae8304e5ea822fbe5909dd3be5445c058b7 <4fa42a249e8cd6ed17aea04e5695b6e9001f2433 || >=e4165ae8304e5ea822fbe5909dd3be5445c058b7 <9c5164781cb388d219d8f49fa0f0b04cf86ad544 || >=e4165ae8304e5ea822fbe5909dd3be5445c058b7 <fb44d589bf3148e13452185a6e772a7efbf2d684 | 309abbddeca0c12714721928a819ef45e5710998, 4fa42a249e8cd6ed17aea04e5695b6e9001f2433, 9c5164781cb388d219d8f49fa0f0b04cf86ad544, fb44d589bf3148e13452185a6e772a7efbf2d684 |
| Linux/Linuxgeneric | 5.16 | Not reported |
Published upstream
Jun 8, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Jul 8, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Jun 19, 2026
In the Linux kernel, the following vulnerability has been resolved: drm/v3d: Reject empty multisync extension to prevent infinite loop v3d_get_extensions() walks a userspace-provided singly-linked list of ioctl extensions without any bound on the chain length. A local user can craft a self-referential extension (ext->next == &ext) with zero in_sync_count and out_sync_count, which bypasses the existing duplicate- extension guard: if (se->in_sync_count || se->out_sync_count) return -EINVAL; The guard never fires because v3d_get_multisync_post_deps() returns immediately when count is zero, leaving both fields at zero on every iteration. The result is an infinite loop in kernel context, blocking the calling thread and pegging a CPU core indefinitely. Fix this by rejecting a multisync extension where both in_sync_count and out_sync_count are zero in v3d_get_multisync_submit_deps(). An empty multisync carries no synchronization information and serves no useful purpose, so returning -EINVAL for such an extension is the correct defense against this attack vector.
Quoted source text, attributed separately from HOL analysis.