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)

The remote Oracle Linux 10 / 9 host has packages installed that are affected by multiple vulnerabilities as referenced in the ELSA-2026-50006 advisory.

    - xfrm: delete x->tunnel as we delete x (Sabrina Dubroca)   {CVE-2025-40215}

Tenable has extracted the preceding description block directly from the Oracle Linux security advisory.

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

The remote Debian 11 host has packages installed that are affected by multiple vulnerabilities as referenced in the dla-4436 advisory.

    -------------------------------------------------------------------------     Debian LTS Advisory DLA-4436-1                debian-lts@lists.debian.org     https://www.debian.org/lts/security/                        Ben Hutchings     January 14, 2026                              https://wiki.debian.org/LTS
    -------------------------------------------------------------------------

    Package        : linux-6.1     Version        : 6.1.159-1~deb11u1     CVE ID         : CVE-2024-47666 CVE-2025-37899 CVE-2025-38057 CVE-2025-38556                      CVE-2025-38593 CVE-2025-38678 CVE-2025-39805 CVE-2025-40083                      CVE-2025-40211 CVE-2025-40214 CVE-2025-40248 CVE-2025-40252                      CVE-2025-40253 CVE-2025-40254 CVE-2025-40257 CVE-2025-40258                      CVE-2025-40259 CVE-2025-40261 CVE-2025-40262 CVE-2025-40263                      CVE-2025-40264 CVE-2025-40269 CVE-2025-40271 CVE-2025-40272                      CVE-2025-40273 CVE-2025-40275 CVE-2025-40277 CVE-2025-40278                      CVE-2025-40279 CVE-2025-40280 CVE-2025-40281 CVE-2025-40282                      CVE-2025-40283 CVE-2025-40284 CVE-2025-40285 CVE-2025-40286                      CVE-2025-40288 CVE-2025-40292 CVE-2025-40293 CVE-2025-40294                      CVE-2025-40297 CVE-2025-40301 CVE-2025-40304 CVE-2025-40306                      CVE-2025-40308 CVE-2025-40309 CVE-2025-40312 CVE-2025-40313                      CVE-2025-40314 CVE-2025-40315 CVE-2025-40317 CVE-2025-40318                      CVE-2025-40319 CVE-2025-40321 CVE-2025-40322 CVE-2025-40323                      CVE-2025-40324 CVE-2025-40331 CVE-2025-40341 CVE-2025-40342                      CVE-2025-40343 CVE-2025-40345 CVE-2025-40360 CVE-2025-40363                      CVE-2025-68168 CVE-2025-68171 CVE-2025-68173 CVE-2025-68176                      CVE-2025-68177 CVE-2025-68185 CVE-2025-68191 CVE-2025-68192                      CVE-2025-68194 CVE-2025-68200 CVE-2025-68204 CVE-2025-68214                      CVE-2025-68217 CVE-2025-68218 CVE-2025-68220 CVE-2025-68227                      CVE-2025-68229 CVE-2025-68231 CVE-2025-68233 CVE-2025-68237                      CVE-2025-68238 CVE-2025-68241 CVE-2025-68244 CVE-2025-68245                      CVE-2025-68246 CVE-2025-68282 CVE-2025-68283 CVE-2025-68284                      CVE-2025-68285 CVE-2025-68286 CVE-2025-68287 CVE-2025-68288                      CVE-2025-68289 CVE-2025-68290 CVE-2025-68295 CVE-2025-68301                      CVE-2025-68302 CVE-2025-68303 CVE-2025-68307 CVE-2025-68308                      CVE-2025-68310 CVE-2025-68312 CVE-2025-68321 CVE-2025-68327                      CVE-2025-68328 CVE-2025-68330 CVE-2025-68331 CVE-2025-68339                      CVE-2025-68343 CVE-2025-68734     Debian Bug     : 919350 1106411 1114557 1119232 1120602 1120680

    Several vulnerabilities have been discovered in the Linux kernel that     may lead to a privilege escalation, denial of service or information     leaks.

    For Debian 11 bullseye, these problems have been fixed in version     6.1.159-1~deb11u1.  This update also fixes several bugs reported to     Debian.  It additionally includes many more bug fixes from stable     update 6.1.159.

    We recommend that you upgrade your linux-6.1 packages.

    For the detailed security status of linux-6.1 please refer to     its security tracker page at:
    https://security-tracker.debian.org/tracker/linux-6.1

    Further information about Debian LTS security advisories, how to apply     these updates to your system and frequently asked questions can be     found at: https://wiki.debian.org/LTS     Attachment:
    signature.asc     Description: PGP signature

Tenable has extracted the preceding description block directly from the Debian security advisory.

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

An update of the linux package has been released.

The Linux/Unix host has one or more packages installed that are impacted by a vulnerability without a vendor supplied patch available.

  - 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 APUssince 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 immediatelyskipping 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) (CVE-2025-40288)

Note that Nessus relies on the presence of the package as reported by the vendor.

ID	Name	Product	Family	Severity
296481	SUSE SLES15 Security Update : kernel (SUSE-SU-2026:0278-1)	Nessus	SuSE Local Security Checks	high
284515	Oracle Linux 10 / 9 : Unbreakable Enterprise kernel (ELSA-2026-50006)	Nessus	Oracle Linux Local Security Checks	high
284514	Debian dla-4436 : linux-config-6.1 - security update	Nessus	Debian Local Security Checks	high
278075	Photon OS 5.0: Linux PHSA-2025-5.0-0708	Nessus	PhotonOS Local Security Checks	high
277677	Linux Distros Unpatched Vulnerability : CVE-2025-40288	Nessus	Misc.	medium

Detections

Analytics

CVE-2025-40288

medium

Tenable Plugins

high

high

high

high

medium