CVE-2026-68271
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…
Does this matter?
Not yet scored. NVD analysis is pending; check back once CVSS and EPSS values are published.
Description
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.
- CVSS
- Not yet scored
- EPSS
- 0.18% probability · 7th percentile
- CISA KEV
- Not listed
- Source
- 416baaa9-dc9f-4396-8d5f-8c081fb06d67
References
- https://git.kernel.org/stable/c/2473ac314387a5def7244eb6d6a345934ed140bf
- https://git.kernel.org/stable/c/4e109faa9ea2b6c04cc5a99e76db3126575a59d1
- https://git.kernel.org/stable/c/ab99ead646b1b833ecd57fe577a2816f2e848167
- https://git.kernel.org/stable/c/e15c25c7972d38a9f6bf8c3f7f29179a67263eba
- https://git.kernel.org/stable/c/ebbaf64d2635d1e78196c067fa8fa582a7dc17f7
Source: NVD record, EPSS from FIRST.org, KEV from CISA. Refreshed daily.