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.
-
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.
-
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.
-
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)
References
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 rootcause is not that the
struct ttm_resource_manager *manpointer itself is NULL,but that
man->bdev(the backing device pointer within the manager) remainsuninitialized (NULL) on APUs—since APUs lack dedicated VRAM and do not fully
set up VRAM manager structures. When
ttm_resource_manager_usage()attempts toacquire
man->bdev->lru_lock, it dereferences the NULLman->bdev, leading toa 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-specificlogic that would trigger the NULL dereference.
amdgpu_kms.c: Update the
AMDGPU_INFO_VRAM_USAGEioctl and memory inforeporting to use a conditional: if the manager is used, return the real VRAM
usage; otherwise, return 0. This avoids accessing
man->bdevwhen it isNULL.
amdgpu_virt.c: Modify the vf2pf (virtual function to physical function)
data write path. Use
ttm_resource_manager_used()to check validity: if themanager is usable, calculate
fb_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:
man->bdevand pass thettm_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)
References