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

CVSS Meta Temp Score
CVSS is a standardized scoring system to determine possibilities of attacks. The Temp Score considers temporal factors like disclosure, exploit and countermeasures. The unique Meta Score calculates the average score of different sources to provide a normalized scoring system.
Current Exploit Price (≈)
Our analysts are monitoring exploit markets and are in contact with vulnerability brokers. The range indicates the observed or calculated exploit price to be seen on exploit markets. A good indicator to understand the monetary effort required for and the popularity of an attack.
CTI Interest Score
Our Cyber Threat Intelligence team is monitoring different web sites, mailing lists, exploit markets and social media networks. The CTI Interest Score identifies the interest of attackers and the security community for this specific vulnerability in real-time. A high score indicates an elevated risk to be targeted for this vulnerability.
3.8$0-$5k0.88-

Summaryinfo

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.

Detailsinfo

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.

Productinfo

Type

Vendor

Name

Version

License

Website

CPE 2.3info

CPE 2.2info

CVSSv4info

VulDB Vector: 🔒
VulDB Reliability: 🔍

CVSSv3info

VulDB Meta Base Score: 4.0
VulDB Meta Temp Score: 3.8

VulDB Base Score: 4.0
VulDB Temp Score: 3.8
VulDB Vector: 🔒
VulDB Reliability: 🔍

CVSSv2info

AVACAuCIA
💳💳💳💳💳💳
💳💳💳💳💳💳
💳💳💳💳💳💳
VectorComplexityAuthenticationConfidentialityIntegrityAvailability
UnlockUnlockUnlockUnlockUnlockUnlock
UnlockUnlockUnlockUnlockUnlockUnlock
UnlockUnlockUnlockUnlockUnlockUnlock

VulDB Base Score: 🔒
VulDB Temp Score: 🔒
VulDB Reliability: 🔍

Exploitinginfo

Class: State issue
CWE: CWE-371
CAPEC: 🔒
ATT&CK: 🔒

Physical: Partially
Local: Yes
Remote: Partially

Availability: 🔒
Status: Not defined
Price Prediction: 🔍
Current Price Estimation: 🔒

0-DayUnlockUnlockUnlockUnlock
TodayUnlockUnlockUnlockUnlock

Threat Intelligenceinfo

Interest: 🔍
Active Actors: 🔍
Active APT Groups: 🔍

Countermeasuresinfo

Recommended: Upgrade
Status: 🔍

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

Timelineinfo

07/30/2026 CVE reserved
08/10/2026 +11 days Advisory disclosed
08/10/2026 +0 days VulDB entry created
08/10/2026 +0 days VulDB entry last update

Sourcesinfo

Vendor: kernel.org

Advisory: git.kernel.org
Status: Confirmed

CVE: CVE-2026-68102 (🔒)
GCVE (CVE): GCVE-0-2026-68102
GCVE (VulDB): GCVE-100-387437

Entryinfo

Created: 08/10/2026 14:36
Changes: 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.

Discussion

No comments yet. Languages: en.

Please log in to comment.

Want to stay up to date on a daily basis?

Enable the mail alert feature now!