ghsa-5ppv-prh8-hj77
Vulnerability from github
Published
2025-12-07 00:30
Modified
2025-12-07 00:30
Details

In 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.

  1. amdgpu_cs.c: Extend the existing bandwidth control check in amdgpu_cs_get_threshold_for_moves() to include a check for ttm_resource_manager_used(). If the manager is not used (uninitialized bdev), return 0 for migration thresholds immediately—skipping VRAM-specific logic that would trigger the NULL dereference.

  2. amdgpu_kms.c: Update the AMDGPU_INFO_VRAM_USAGE ioctl and memory info reporting to use a conditional: if the manager is used, return the real VRAM usage; otherwise, return 0. This avoids accessing man->bdev when it is NULL.

  3. 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, calculate fb_usage from VRAM usage; otherwise, set fb_usage to 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)

Show details on source website


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


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

Sightings

Author Source Type Date

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
  • Confirmed: The vulnerability is confirmed from an analyst perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
  • Patched: This vulnerability was successfully patched by the user reporting the sighting.
  • Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
  • Not confirmed: The user expresses doubt about the veracity of the vulnerability.
  • Not patched: This vulnerability was not successfully patched by the user reporting the sighting.


Loading…

Loading…