NULL Pointer Dereference Affecting kernel-default-base package, versions <5.14.21-150500.55.110.1.150500.6.51.3


Severity

Recommended
0.0
medium
0
10

Based on SUSE Linux Enterprise Server security rating.

Threat Intelligence

EPSS
0.03% (4th percentile)

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 Learn

Learn about NULL Pointer Dereference vulnerabilities in an interactive lesson.

Start learning
  • Snyk IDSNYK-SLES155-KERNELDEFAULTBASE-10571362
  • published1 Jul 2025
  • disclosed30 Jun 2025

Introduced: 30 Jun 2025

CVE-2023-53095  (opens in a new tab)
CWE-476  (opens in a new tab)

How to fix?

Upgrade SLES:15.5 kernel-default-base to version 5.14.21-150500.55.110.1.150500.6.51.3 or higher.

NVD Description

Note: Versions mentioned in the description apply only to the upstream kernel-default-base package and not the kernel-default-base package as distributed by SLES. See How to fix? for SLES:15.5 relevant fixed versions and status.

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().

CVSS Base Scores

version 3.1