Описание
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 forttm_resource_manager_used(). If the manager is not used (uninitializedbdev), return 0 for migration thresholds immediately—skipping VRAM-...
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 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->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)
Ссылки
- https://nvd.nist.gov/vuln/detail/CVE-2025-40288
- https://git.kernel.org/stable/c/070bdce18fb12a49eb9c421e57df17d2ad29bf5f
- https://git.kernel.org/stable/c/1243e396148a65bb6c42a2b70fe43e50c16c494f
- https://git.kernel.org/stable/c/43aa61c18a3a45042b098b7a1186ffb29364002c
- https://git.kernel.org/stable/c/883f309add55060233bf11c1ea6947140372920f
- https://git.kernel.org/stable/c/e70113b741ba253886cd71dbadfe3ea444bb2f5c
EPSS
CVE ID
Связанные уязвимости
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 log...
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-spe
drm/amdgpu: Fix NULL pointer dereference in VRAM logic for APU devices
In the Linux kernel, the following vulnerability has been resolved: d ...
ELSA-2026-50006: Unbreakable Enterprise kernel security update (IMPORTANT)
EPSS