CVE-2025-40288 Affecting kernel-uek-doc package, versions <0:6.12.0-107.59.3.2.el9uek
Threat Intelligence
The probability is the direct output of the EPSS model, and conveys an overall sense of the threat of exploitation in the wild. The percentile measures the EPSS probability relative to all known EPSS scores. Note: This data is updated daily, relying on the latest available EPSS model version. Check out the EPSS documentation for more details.
Do your applications use this vulnerable package?
In a few clicks we can analyze your entire application and see what components are vulnerable in your application, and suggest you quick fixes.
Test your applications- Snyk IDSNYK-ORACLE9-KERNELUEKDOC-15008050
- published16 Jan 2026
- disclosed6 Dec 2025
Introduced: 6 Dec 2025
CVE-2025-40288 (opens in a new tab)How to fix?
Upgrade Oracle:9 kernel-uek-doc to version 0:6.12.0-107.59.3.2.el9uek or higher.
This issue was patched in ELSA-2026-50006.
NVD Description
Note: Versions mentioned in the description apply only to the upstream kernel-uek-doc package and not the kernel-uek-doc package as distributed by Oracle.
See How to fix? for Oracle:9 relevant fixed versions and status.
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)
References
- https://linux.oracle.com/cve/CVE-2025-40288.html
- https://linux.oracle.com/errata/ELSA-2026-50006.html
- 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