NULL Pointer Dereference Affecting libperf package, versions *


Severity

Recommended
low

Based on CentOS security rating.

Threat Intelligence

EPSS
0.02% (5th 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-CENTOS10-LIBPERF-13366863
  • published7 Oct 2025
  • disclosed4 Oct 2025

Introduced: 4 Oct 2025

CVE-2025-39937  (opens in a new tab)
CWE-476  (opens in a new tab)

How to fix?

There is no fixed version for Centos:10 libperf.

NVD Description

Note: Versions mentioned in the description apply only to the upstream libperf package and not the libperf package as distributed by Centos. See How to fix? for Centos:10 relevant fixed versions and status.

In the Linux kernel, the following vulnerability has been resolved:

net: rfkill: gpio: Fix crash due to dereferencering uninitialized pointer

Since commit 7d5e9737efda ("net: rfkill: gpio: get the name and type from device property") rfkill_find_type() gets called with the possibly uninitialized "const char *type_name;" local variable.

On x86 systems when rfkill-gpio binds to a "BCM4752" or "LNV4752" acpi_device, the rfkill->type is set based on the ACPI acpi_device_id:

    rfkill->type = (unsigned)id->driver_data;

and there is no "type" property so device_property_read_string() will fail and leave type_name uninitialized, leading to a potential crash.

rfkill_find_type() does accept a NULL pointer, fix the potential crash by initializing type_name to NULL.

Note likely sofar this has not been caught because:

  1. Not many x86 machines actually have a "BCM4752"/"LNV4752" acpi_device
  2. The stack happened to contain NULL where type_name is stored

CVSS Base Scores

version 3.1