Answer in brief
CVE-2026-68271 records a Unknown severity vulnerability in drm/nouveau: fix reversed error cleanup order in ucopy functions. 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 | >=b88baab828713ce0b49b185444b2ee83bed373a8 <2473ac314387a5def7244eb6d6a345934ed140bf || >=b88baab828713ce0b49b185444b2ee83bed373a8 <e15c25c7972d38a9f6bf8c3f7f29179a67263eba || >=b88baab828713ce0b49b185444b2ee83bed373a8 <4e109faa9ea2b6c04cc5a99e76db3126575a59d1 || >=b88baab828713ce0b49b185444b2ee83bed373a8 <ebbaf64d2635d1e78196c067fa8fa582a7dc17f7 || >=b88baab828713ce0b49b185444b2ee83bed373a8 <ab99ead646b1b833ecd57fe577a2816f2e848167 | 2473ac314387a5def7244eb6d6a345934ed140bf, e15c25c7972d38a9f6bf8c3f7f29179a67263eba, 4e109faa9ea2b6c04cc5a99e76db3126575a59d1, ebbaf64d2635d1e78196c067fa8fa582a7dc17f7, ab99ead646b1b833ecd57fe577a2816f2e848167 |
| Linux/Linuxgeneric | 6.6 | Not reported |
Published upstream
Aug 10, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Aug 17, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Aug 10, 2026
In the Linux kernel, the following vulnerability has been resolved: drm/nouveau: fix reversed error cleanup order in ucopy functions nouveau_uvmm_vm_bind_ucopy() and nouveau_exec_ucopy() place their error cleanup labels in allocation order rather than reverse allocation order. On a u_memcpya() failure for in_sync.s, the goto to err_free_ops (or err_free_pushs) frees the first allocation and then falls through to err_free_ins, which calls u_free() on args->in_sync.s. Since args->in_sync.s still holds the ERR_PTR returned by the failed u_memcpya(), and ERR_PTR values are not caught by ZERO_OR_NULL_PTR(), kvfree() proceeds to dereference it, which can result in a kernel oops. A failure for out_sync.s instead jumps to err_free_ins and skips freeing the first allocation, leading to a memory leak. Fix by swapping the cleanup label order so resources are freed in the correct reverse allocation sequence.
Quoted source text, attributed separately from HOL analysis.