CVE-2024-47141

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;

} }

This vulnerability is rated as having a Moderate impact because it requires local access with precise race timing to trigger, and successful exploitation results in a kernel crash (denial of service) without compromising confidentiality or integrity. The flaw is rooted in unsynchronized state updates within the kernel's pin control subsystem when multiple clients request the same pin simultaneously. Standard Red Hat Enterprise Linux server installations rarely expose direct pin multiplexing interfaces to untrusted users, substantially limiting the real-world attack surface.

The CVSS score(s) listed for this vulnerability do not reflect the associated product's status, and are included for informational purposes to better understand the severity of this vulnerability.