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": []
}
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.
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.