Homepage

Improper Locking The advisory has been revoked - it doesn't affect any version of package bpftool  (opens in a new tab)

Threat Intelligence

EPSS
0.17% (7th 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 IDSNYK-CENTOS9-BPFTOOL-8806826
  • published28 Feb 2025
  • disclosed11 Jan 2025
Report a new vulnerability Found a mistake?

Introduced: 11 Jan 2025

CVE-2024-47141  (opens in a new tab)
CWE-667  (opens in a new tab)

Amendment

The Centos security team deemed this advisory irrelevant for Centos:9.

NVD Description

Note: Versions mentioned in the description apply only to the upstream bpftool package and not the bpftool package as distributed by Centos.

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

pinmux: Use sequential access to access desc->pinmux data

When two client of the same gpio call pinctrl_select_state() for the same functionality, we are seeing NULL pointer issue while accessing desc->mux_owner.

Let's say two processes A, B executing in pin_request() for the same pin and process A updates the desc->mux_usecount but not yet updated the desc->mux_owner while process B see the desc->mux_usecount which got updated by A path and further executes strcmp and while accessing desc->mux_owner it crashes with NULL pointer.

Serialize the access to mux related setting with a mutex lock.

cpu0 (process A)			cpu1(process B)

pinctrl_select_state() { pinctrl_select_state() { pin_request() { pin_request() { ... .... } else { desc->mux_usecount++; desc->mux_usecount && strcmp(desc->mux_owner, owner)) {

     if (desc->mux_usecount > 1)
           return 0;
     desc->mux_owner = owner;

} }