Linux Kernel up to 7.2-rc1 amdgpu amdgpu_ttm.c amdgpu_ttm_fini state issue

| CVSS Meta Temp Score | Current Exploit Price (≈) | CTI Interest Score |
|---|---|---|
| 3.8 | $0-$5k | 0.88- |
Summary
A vulnerability, which was classified as problematic, has been found in Linux Kernel up to 6.6.147/6.12.100/6.18.41/7.1.5/7.2-rc1. The affected element is the function amdgpu_ttm_fini of the file amdgpu_ttm.c of the component amdgpu. The manipulation leads to state issue.
This vulnerability is uniquely identified as CVE-2026-68102. Local access is required to approach this attack. No exploit exists.
Details
A vulnerability was found in Linux Kernel up to 6.6.147/6.12.100/6.18.41/7.1.5/7.2-rc1 and classified as problematic. This issue affects the function amdgpu_ttm_fini of the file amdgpu_ttm.c of the component amdgpu. The manipulation with an unknown input leads to a state issue vulnerability. Using CWE to declare the problem leads to CWE-371. Impacted is confidentiality, integrity, and availability. The summary by CVE is:
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: fix aperture mapping leak amdgpu_pci_remove() calls drm_dev_unplug() before invoking the driver fini routines. This causes drm_dev_enter() in amdgpu_ttm_fini() to always return false, so iounmap(aper_base_kaddr) never runs on normal driver unload, leaving an orphaned entry in the x86 PAT interval tree. On connected_to_cpu hardware, the aperture is mapped write-back (WB) via ioremap_cache(). On reload, IP discovery calls memremap(..., MEMREMAP_WC) over the same range. The WC vs WB conflict causes: ioremap error for 0x..., requested 0x1, got 0x0 amdgpu: discovery failed: -2 Fix by switching to devres-managed mappings so cleanup is guaranteed regardless of drm_dev_enter() state: - connected_to_cpu path: devm_memremap(MEMREMAP_WB). For IORESOURCE_SYSTEM_RAM ranges this takes the try_ram_remap() shortcut, returning __va(offset) from the existing kernel direct map. No new ioremap VA or PAT entry is created, so there is nothing to orphan. - dGPU path: devm_ioremap_wc() registers iounmap() as a devres action, guaranteeing cleanup at device_del() time. Also remove iounmap(aper_base_kaddr) from amdgpu_device_unmap_mmio() since the mapping is now devres-owned. v2: Remove redundant x86_64 guard (Lijo) (cherry picked from commit d871e99879cb5fd1fa798b006b4888887e63a17a)
The advisory is shared at git.kernel.org. The identification of this vulnerability is CVE-2026-68102 since 07/30/2026. The exploitation is known to be easy. An attack has to be approached locally. Additional levels of successful authentication are required for exploitation. It demands that the victim is doing some kind of user interaction. Technical details are known, but no exploit is available.
Upgrading to version 6.6.148, 6.12.101, 6.18.42, 7.1.6 or 7.2-rc2 eliminates this vulnerability. Applying the patch 67bc3647e418e23dc0d17604bdba634a73de809f/a343d028ad6c174da8dc6af560c51e6d140a6727/6405c4e75b3bcf0e72bd7a0ff5f1ed0c475e23aa/f5988b5c300a32ff751724ffd33d5a8d5873e4a7/ea772a440d56b285f4d491affac50ecd41f6b402 is able to eliminate this problem.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
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
- 7.2-rc1
License
Website
- Vendor: https://www.kernel.org/
CPE 2.3
CPE 2.2
CVSSv4
VulDB Vector: 🔒VulDB Reliability: 🔍
CVSSv3
VulDB Meta Base Score: 4.0VulDB Meta Temp Score: 3.8
VulDB Base Score: 4.0
VulDB Temp Score: 3.8
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: State issueCWE: CWE-371
CAPEC: 🔒
ATT&CK: 🔒
Physical: Partially
Local: Yes
Remote: Partially
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-rc2
Patch: 67bc3647e418e23dc0d17604bdba634a73de809f/a343d028ad6c174da8dc6af560c51e6d140a6727/6405c4e75b3bcf0e72bd7a0ff5f1ed0c475e23aa/f5988b5c300a32ff751724ffd33d5a8d5873e4a7/ea772a440d56b285f4d491affac50ecd41f6b402
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-68102 (🔒)
GCVE (CVE): GCVE-0-2026-68102
GCVE (VulDB): GCVE-100-387437
Entry
Created: 08/10/2026 14:36Changes: 08/10/2026 14:36 (60)
Complete: 🔍
Cache ID: 216::103
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
No comments yet. Languages: en.
Please log in to comment.