GHSA-5PPV-PRH8-HJ77
Vulnerability from github – Published: 2025-12-07 00:30 – Updated: 2025-12-07 00:30In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: Fix NULL pointer dereference in VRAM logic for APU devices
Previously, APU platforms (and other scenarios with uninitialized VRAM managers)
triggered a NULL pointer dereference in ttm_resource_manager_usage(). The root
cause is not that the struct ttm_resource_manager *man pointer itself is NULL,
but that man->bdev (the backing device pointer within the manager) remains
uninitialized (NULL) on APUs—since APUs lack dedicated VRAM and do not fully
set up VRAM manager structures. When ttm_resource_manager_usage() attempts to
acquire man->bdev->lru_lock, it dereferences the NULL man->bdev, leading to
a kernel OOPS.
-
amdgpu_cs.c: Extend the existing bandwidth control check in
amdgpu_cs_get_threshold_for_moves()to include a check forttm_resource_manager_used(). If the manager is not used (uninitializedbdev), return 0 for migration thresholds immediately—skipping VRAM-specific logic that would trigger the NULL dereference. -
amdgpu_kms.c: Update the
AMDGPU_INFO_VRAM_USAGEioctl and memory info reporting to use a conditional: if the manager is used, return the real VRAM usage; otherwise, return 0. This avoids accessingman->bdevwhen it is NULL. -
amdgpu_virt.c: Modify the vf2pf (virtual function to physical function) data write path. Use
ttm_resource_manager_used()to check validity: if the manager is usable, calculatefb_usagefrom VRAM usage; otherwise, setfb_usageto 0 (APUs have no discrete framebuffer to report).
This approach is more robust than APU-specific checks because it:
- Works for all scenarios where the VRAM manager is uninitialized (not just APUs),
- Aligns with TTM's design by using its native helper function,
- Preserves correct behavior for discrete GPUs (which have fully initialized
man->bdev and pass the ttm_resource_manager_used() check).
v4: use ttm_resource_manager_used(&adev->mman.vram_mgr.manager) instead of checking the adev->gmc.is_app_apu flag (Christian)
{
"affected": [],
"aliases": [
"CVE-2025-40288"
],
"database_specific": {
"cwe_ids": [],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-12-06T22:15:57Z",
"severity": null
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amdgpu: Fix NULL pointer dereference in VRAM logic for APU devices\n\nPreviously, APU platforms (and other scenarios with uninitialized VRAM managers)\ntriggered a NULL pointer dereference in `ttm_resource_manager_usage()`. The root\ncause is not that the `struct ttm_resource_manager *man` pointer itself is NULL,\nbut that `man-\u003ebdev` (the backing device pointer within the manager) remains\nuninitialized (NULL) on APUs\u2014since APUs lack dedicated VRAM and do not fully\nset up VRAM manager structures. When `ttm_resource_manager_usage()` attempts to\nacquire `man-\u003ebdev-\u003elru_lock`, it dereferences the NULL `man-\u003ebdev`, leading to\na kernel OOPS.\n\n1. **amdgpu_cs.c**: Extend the existing bandwidth control check in\n `amdgpu_cs_get_threshold_for_moves()` to include a check for\n `ttm_resource_manager_used()`. If the manager is not used (uninitialized\n `bdev`), return 0 for migration thresholds immediately\u2014skipping VRAM-specific\n logic that would trigger the NULL dereference.\n\n2. **amdgpu_kms.c**: Update the `AMDGPU_INFO_VRAM_USAGE` ioctl and memory info\n reporting to use a conditional: if the manager is used, return the real VRAM\n usage; otherwise, return 0. This avoids accessing `man-\u003ebdev` when it is\n NULL.\n\n3. **amdgpu_virt.c**: Modify the vf2pf (virtual function to physical function)\n data write path. Use `ttm_resource_manager_used()` to check validity: if the\n manager is usable, calculate `fb_usage` from VRAM usage; otherwise, set\n `fb_usage` to 0 (APUs have no discrete framebuffer to report).\n\nThis approach is more robust than APU-specific checks because it:\n- Works for all scenarios where the VRAM manager is uninitialized (not just APUs),\n- Aligns with TTM\u0027s design by using its native helper function,\n- Preserves correct behavior for discrete GPUs (which have fully initialized\n `man-\u003ebdev` and pass the `ttm_resource_manager_used()` check).\n\nv4: use ttm_resource_manager_used(\u0026adev-\u003emman.vram_mgr.manager) instead of checking the adev-\u003egmc.is_app_apu flag (Christian)",
"id": "GHSA-5ppv-prh8-hj77",
"modified": "2025-12-07T00:30:56Z",
"published": "2025-12-07T00:30:56Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40288"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/070bdce18fb12a49eb9c421e57df17d2ad29bf5f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1243e396148a65bb6c42a2b70fe43e50c16c494f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/43aa61c18a3a45042b098b7a1186ffb29364002c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/883f309add55060233bf11c1ea6947140372920f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e70113b741ba253886cd71dbadfe3ea444bb2f5c"
}
],
"schema_version": "1.4.0",
"severity": []
}
Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Vulnerability timeline
Sightings and recorded dates, grouped by day · UTC
How durations are calculated
Following the VTEM framework (Black Hat USA 2015), time to patch starts when the vendor or a coordinator was informed, total time to patch at discovery, and disclosure to patch at public disclosure; vendor response time runs from the report to its acknowledgement. Time to exploit and time unpatched start at the earliest discovery or report, falling back to public disclosure. Unpatched time ends at the first recorded patch, or the calculation time when no patch is recorded. Exploitation to patch shows the interval between those two events; a published proof of concept is a public exploit, not exploitation.
Each result shows its source dates. A negative interval means the end event came first; when date-only inputs leave the order open, the result says so. Date-only inputs are approximate. The earliest evidence wins: KEV report dates and sightings are labelled as such. Records describing another vulnerability are listed but never calculated from, and a PoC alone does not establish exploitation. Missing patch evidence does not prove that no patch exists. Filters below change the event list only.
Loading timeline…
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.