Linux Kernel up to 6.6.147/6.12.100/6.18.41/7.1.5 nouveau nouveau_uvmm_vm_bind_ucopy/nouveau_exec_ucopy in_sync/out_sync null pointer dereference

| CVSS Meta Temp Score | Current Exploit Price (≈) | CTI Interest Score |
|---|---|---|
| 5.3 | $0-$5k | 0.00 |
Summary
A vulnerability classified as critical has been found in Linux Kernel up to 6.6.147/6.12.100/6.18.41/7.1.5. This affects the function nouveau_uvmm_vm_bind_ucopy/nouveau_exec_ucopy of the component nouveau. The manipulation of the argument in_sync/out_sync leads to null pointer dereference.
This vulnerability is traded as CVE-2026-68271. An attack has to be approached locally. There is no exploit available.
Details
A vulnerability, which was classified as critical, has been found in Linux Kernel up to 6.6.147/6.12.100/6.18.41/7.1.5. This issue affects the function nouveau_uvmm_vm_bind_ucopy/nouveau_exec_ucopy of the component nouveau. The manipulation of the argument in_sync/out_sync with an unknown input leads to a null pointer dereference vulnerability. Using CWE to declare the problem leads to CWE-476. A NULL pointer dereference occurs when the application dereferences a pointer that it expects to be valid, but is NULL, typically causing a crash or exit. Impacted is availability. The summary by CVE is:
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.
It is possible to read the advisory at git.kernel.org. The identification of this vulnerability is CVE-2026-68271 since 07/30/2026. The exploitation is known to be easy. Attacking locally is a requirement. Technical details of the vulnerability are known, but there is no available exploit.
Upgrading to version 6.6.148, 6.12.101, 6.18.42, 7.1.6 or 7.2-rc1 eliminates this vulnerability. Applying the patch 2473ac314387a5def7244eb6d6a345934ed140bf/e15c25c7972d38a9f6bf8c3f7f29179a67263eba/4e109faa9ea2b6c04cc5a99e76db3126575a59d1/ebbaf64d2635d1e78196c067fa8fa582a7dc17f7/ab99ead646b1b833ecd57fe577a2816f2e848167 is able to eliminate this problem.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Product
Type
Vendor
Name
Version
- 6.0
- 6.1
- 6.2
- 6.3
- 6.4
- 6.5
- 6.6
- 6.6.147
- 6.7
- 6.8
- 6.9
- 6.10
- 6.11
- 6.12.100
- 6.18.0
- 6.18.1
- 6.18.2
- 6.18.3
- 6.18.4
- 6.18.5
- 6.18.6
- 6.18.7
- 6.18.8
- 6.18.9
- 6.18.10
- 6.18.11
- 6.18.12
- 6.18.13
- 6.18.14
- 6.18.15
- 6.18.16
- 6.18.17
- 6.18.18
- 6.18.19
- 6.18.20
- 6.18.21
- 6.18.22
- 6.18.23
- 6.18.24
- 6.18.25
- 6.18.26
- 6.18.27
- 6.18.28
- 6.18.29
- 6.18.30
- 6.18.31
- 6.18.32
- 6.18.33
- 6.18.34
- 6.18.35
- 6.18.36
- 6.18.37
- 6.18.38
- 6.18.39
- 6.18.40
- 6.18.41
- 7.1.0
- 7.1.1
- 7.1.2
- 7.1.3
- 7.1.4
- 7.1.5
License
Website
- Vendor: https://www.kernel.org/
CPE 2.3
CPE 2.2
CVSSv4
VulDB Vector: 🔒VulDB Reliability: 🔍
CVSSv3
VulDB Meta Base Score: 5.5VulDB Meta Temp Score: 5.3
VulDB Base Score: 5.5
VulDB Temp Score: 5.3
VulDB Vector: 🔒
VulDB Reliability: 🔍
CVSSv2
| AV | AC | Au | C | I | A |
|---|---|---|---|---|---|
| 💳 | 💳 | 💳 | 💳 | 💳 | 💳 |
| 💳 | 💳 | 💳 | 💳 | 💳 | 💳 |
| 💳 | 💳 | 💳 | 💳 | 💳 | 💳 |
| Vector | Complexity | Authentication | Confidentiality | Integrity | Availability |
|---|---|---|---|---|---|
| Unlock | Unlock | Unlock | Unlock | Unlock | Unlock |
| Unlock | Unlock | Unlock | Unlock | Unlock | Unlock |
| Unlock | Unlock | Unlock | Unlock | Unlock | Unlock |
VulDB Base Score: 🔒
VulDB Temp Score: 🔒
VulDB Reliability: 🔍
Exploiting
Class: Null pointer dereferenceCWE: CWE-476 / CWE-404
CAPEC: 🔒
ATT&CK: 🔒
Physical: Partially
Local: Yes
Remote: No
Availability: 🔒
Status: Not defined
Price Prediction: 🔍
Current Price Estimation: 🔒
| 0-Day | Unlock | Unlock | Unlock | Unlock |
|---|---|---|---|---|
| Today | Unlock | Unlock | Unlock | Unlock |
Threat Intelligence
Interest: 🔍Active Actors: 🔍
Active APT Groups: 🔍
Countermeasures
Recommended: UpgradeStatus: 🔍
0-Day Time: 🔒
Upgrade: Kernel 6.6.148/6.12.101/6.18.42/7.1.6/7.2-rc1
Patch: 2473ac314387a5def7244eb6d6a345934ed140bf/e15c25c7972d38a9f6bf8c3f7f29179a67263eba/4e109faa9ea2b6c04cc5a99e76db3126575a59d1/ebbaf64d2635d1e78196c067fa8fa582a7dc17f7/ab99ead646b1b833ecd57fe577a2816f2e848167
Timeline
07/30/2026 CVE reserved08/10/2026 Advisory disclosed
08/10/2026 VulDB entry created
08/10/2026 VulDB entry last update
Sources
Vendor: kernel.orgAdvisory: git.kernel.org
Status: Confirmed
CVE: CVE-2026-68271 (🔒)
GCVE (CVE): GCVE-0-2026-68271
GCVE (VulDB): GCVE-100-387659
Entry
Created: 08/10/2026 17:17Changes: 08/10/2026 17:17 (60)
Complete: 🔍
Cache ID: 216::103
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
No comments yet. Languages: en.
Please log in to comment.