CVE-2023-53095
published 2025-05-02CVE-2023-53095: In the Linux kernel, the following vulnerability has been resolved: drm/ttm: Fix a NULL pointer dereference The LRU mechanism may look up a resource in the…
PriorityP419medium5.5CVSS 3.1
AVLACLPRLUINSUCNINAH
EPSS
0.19%
8.4th percentile
In the Linux kernel, the following vulnerability has been resolved:
drm/ttm: Fix a NULL pointer dereference
The LRU mechanism may look up a resource in the process of being removed
from an object. The locking rules here are a bit unclear but it looks
currently like res->bo assignment is protected by the LRU lock, whereas
bo->resource is protected by the object lock, while *clearing* of
bo->resource is also protected by the LRU lock. This means that if
we check that bo->resource points to the LRU resource under the LRU
lock we should be safe.
So perform that check before deciding to swap out a bo. That avoids
dereferencing a NULL bo->resource in ttm_bo_swapout().
Affected
11 ranges
| Vendor | Product | Version range | Fixed in |
|---|---|---|---|
| debian | linux | < linux 6.1.25-1 (bookworm) | linux 6.1.25-1 (bookworm) |
| linux | linux | — | — |
| linux | linux | >= 6a9b028994025f5033f10d1da30b29dfdc713384 < 9ba1720f6c4a0f13c3f3cb5c28132ee75555d04f | 9ba1720f6c4a0f13c3f3cb5c28132ee75555d04f |
| linux | linux | >= 6a9b028994025f5033f10d1da30b29dfdc713384 < 9d9b1f9f7a72d83ebf173534e76b246349f32374 | 9d9b1f9f7a72d83ebf173534e76b246349f32374 |
| linux | linux | >= 6a9b028994025f5033f10d1da30b29dfdc713384 < 9a9a8fe26751334b7739193a94eba741073b8a55 | 9a9a8fe26751334b7739193a94eba741073b8a55 |
| linux | linux_kernel | — | — |
| linux | linux_kernel | >= 0 < 6.1.25-1 | 6.1.25-1 |
| linux | linux_kernel | >= 0 < 6.1.25-1 | 6.1.25-1 |
| linux | linux_kernel | >= 0 < 6.1.25-1 | 6.1.25-1 |
| linux | linux_kernel | >= 5.19 < 6.1.21 | 6.1.21 |
| linux | linux_kernel | >= 6.2 < 6.2.8 | 6.2.8 |
CVSS provenance
nvdv3.15.5MEDIUMCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
osv5.5MEDIUM
vendor_debian5.5MEDIUM
vendor_redhat5.5MEDIUM
Stop checking back — get the weekly exploitation signal.
Every Monday: what got weaponized or added to CISA KEV in the last seven days — each CVE cross-linked to its PoC, Nuclei template, and detection rule. Free, one email a week, unsubscribe in one click.
Red Hat
kernel: drm/ttm: Fix a NULL pointer dereference
vendor_redhat·2025-05-02·CVSS 5.5
CVE-2023-53095 [MEDIUM] kernel: drm/ttm: Fix a NULL pointer dereference
kernel: drm/ttm: Fix a NULL pointer dereference
In the Linux kernel, the following vulnerability has been resolved:
drm/ttm: Fix a NULL pointer dereference
The LRU mechanism may look up a resource in the process of being removed
from an object. The locking rules here are a bit unclear but it looks
currently like res->bo assignment is protected by the LRU lock, whereas
bo->resource is protected by the object lock, while *clearing* of
bo->resource is also protected by the LRU lock. This means that if
we check that bo->resource points to the LRU resource under the LRU
lock we should be safe.
So perform that check before deciding to swap out a bo. That avoids
dereferencing a NULL bo->resource in ttm_bo_swapout().
Package: kernel (Red Hat Enterprise Linux 10) - Not affected
Package: kernel (
Debian
CVE-2023-53095: linux - In the Linux kernel, the following vulnerability has been resolved: drm/ttm: Fi...
vendor_debian·2023·CVSS 5.5
CVE-2023-53095 [MEDIUM] CVE-2023-53095: linux - In the Linux kernel, the following vulnerability has been resolved: drm/ttm: Fi...
In the Linux kernel, the following vulnerability has been resolved: drm/ttm: Fix a NULL pointer dereference The LRU mechanism may look up a resource in the process of being removed from an object. The locking rules here are a bit unclear but it looks currently like res->bo assignment is protected by the LRU lock, whereas bo->resource is protected by the object lock, while *clearing* of bo->resource is also protected by the LRU lock. This means that if we check that bo->resource points to the LRU resource under the LRU lock we should be safe. So perform that check before deciding to swap out a bo. That avoids dereferencing a NULL bo->resource in ttm_bo_swapout().
Scope: local
bookworm: resolved (fixed in 6.1.25-1)
bullseye: resolved
forky: resolved (fixed in 6.1.25-1)
sid: resolved (fixed i
GHSA
GHSA-qq4h-f4qp-wr7q: In the Linux kernel, the following vulnerability has been resolved:
drm/ttm: Fix a NULL pointer dereference
The LRU mechanism may look up a resource
ghsa_unreviewed·2025-05-02
CVE-2023-53095 [MEDIUM] CWE-476 GHSA-qq4h-f4qp-wr7q: In the Linux kernel, the following vulnerability has been resolved:
drm/ttm: Fix a NULL pointer dereference
The LRU mechanism may look up a resource
In the Linux kernel, the following vulnerability has been resolved:
drm/ttm: Fix a NULL pointer dereference
The LRU mechanism may look up a resource in the process of being removed
from an object. The locking rules here are a bit unclear but it looks
currently like res->bo assignment is protected by the LRU lock, whereas
bo->resource is protected by the object lock, while *clearing* of
bo->resource is also protected by the LRU lock. This means that if
we check that bo->resource points to the LRU resource under the LRU
lock we should be safe.
So perform that check before deciding to swap out a bo. That avoids
dereferencing a NULL bo->resource in ttm_bo_swapout().
OSV
CVE-2023-53095: In the Linux kernel, the following vulnerability has been resolved: drm/ttm: Fix a NULL pointer dereference The LRU mechanism may look up a resource i
osv·2025-05-02·CVSS 5.5
CVE-2023-53095 [MEDIUM] CVE-2023-53095: In the Linux kernel, the following vulnerability has been resolved: drm/ttm: Fix a NULL pointer dereference The LRU mechanism may look up a resource i
In the Linux kernel, the following vulnerability has been resolved: drm/ttm: Fix a NULL pointer dereference The LRU mechanism may look up a resource in the process of being removed from an object. The locking rules here are a bit unclear but it looks currently like res->bo assignment is protected by the LRU lock, whereas bo->resource is protected by the object lock, while *clearing* of bo->resource is also protected by the LRU lock. This means that if we check that bo->resource points to the LRU resource under the LRU lock we should be safe. So perform that check before deciding to swap out a bo. That avoids dereferencing a NULL bo->resource in ttm_bo_swapout().
No detection rules found.
No public exploits indexed.
2025-05-02
Published