CVE-2026-68238 in Linux
Summary
by MITRE • 08/10/2026
In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: Release VFCT ACPI table reference
amdgpu_acpi_vfct_bios() fetches the VFCT table with acpi_get_table() but never releases it. acpi_get_table() takes a reference on the table (incrementing its validation_count and mapping it on the 0->1 transition); without a paired acpi_put_table() the mapping is leaked on every call, whether or not a matching VBIOS image is found.
Route all exit paths after the table is acquired through a common acpi_put_table(). The VBIOS image is copied out with kmemdup() before the table is released, so it remains valid for the caller.
(cherry picked from commit ca5988682b4cba4cd125a0fa99b2de1239164ae4)
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 08/10/2026
The vulnerability in question affects the amdgpu driver within the Linux kernel and represents a memory management flaw that leads to resource leakage. This issue specifically occurs in the drm/amdgpu subsystem where the function amdgpu_acpi_vfct_bios() retrieves the VFCT ACPI table using acpi_get_table() but fails to properly release it through a corresponding acpi_put_table() call. The root cause stems from improper reference counting practices within the ACPI table handling mechanism, creating a persistent memory leak that accumulates with each invocation of the affected code path.
The technical flaw manifests as a failure to maintain proper reference counting semantics in the ACPI subsystem. When acpi_get_table() is called, it increments the table's validation_count and maps the table into memory, effectively taking a reference on the resource. However, the absence of a matching acpi_put_table() call means this reference is never released, resulting in the mapping remaining active in memory indefinitely. This creates a memory leak that grows with each execution of the vulnerable code path, regardless of whether a valid VBIOS image is actually found or processed.
From an operational perspective, this vulnerability represents a significant concern for systems running Linux kernels with AMD graphics drivers, particularly those utilizing the amdgpu driver for GPU management. The leaked mappings accumulate over time and can lead to gradual memory consumption that may eventually impact system performance or stability. The vulnerability affects all systems where the amdgpu driver is active and ACPI table processing occurs, making it a widespread concern across various hardware configurations and deployment scenarios.
The mitigation approach involves implementing proper resource cleanup by routing all exit paths through a common acpi_put_table() call after acquiring the VFCT table. This ensures that regardless of which code path is taken during execution, the acquired reference is properly released. The implementation maintains the integrity of the VBIOS image data by copying it out using kmemdup() before releasing the table reference, ensuring that the caller continues to have access to the required data while preventing memory leaks.
This vulnerability aligns with CWE-404, which addresses improper resource management where allocated resources are not properly released, and can be categorized under ATT&CK technique T1490 for resource exhaustion through memory leaks. The flaw demonstrates poor adherence to kernel memory management best practices and represents a classic case of reference counting errors in kernel subsystems. The fix demonstrates proper resource management principles by ensuring all acquisition operations have corresponding release mechanisms, thereby preventing the accumulation of leaked mappings that could eventually lead to system instability or performance degradation.
The patch implementation addresses this issue through careful code restructuring that ensures proper cleanup semantics are maintained throughout all execution paths. By centralizing the table release mechanism and maintaining data integrity through appropriate copying operations, the fix resolves both the immediate memory leak concern and maintains the functional correctness of the VBIOS processing pipeline. This approach aligns with kernel development practices emphasizing robust resource management and prevents the accumulation of leaked mappings that could impact long-running systems or those with frequent GPU access patterns.
The vulnerability represents a subtle but serious flaw in kernel subsystem design where proper reference counting and resource management principles were not followed during implementation. The fix demonstrates the importance of ensuring every acpi_get_table() call has a corresponding acpi_put_table() invocation, particularly in kernel drivers where memory efficiency and resource management are critical for system stability and performance. This type of vulnerability highlights the need for thorough code review processes focusing on reference counting semantics and resource cleanup in kernel subsystems handling ACPI tables or similar system resources.