CVE-2025-38632
Unknown Unknown - Not Provided
BaseFortify

Publication date: 2025-08-22

Last updated on: 2025-11-26

Assigner: kernel.org

Description
In the Linux kernel, the following vulnerability has been resolved: pinmux: fix race causing mux_owner NULL with active mux_usecount commit 5a3e85c3c397 ("pinmux: Use sequential access to access desc->pinmux data") tried to address the issue when two client of the same gpio calls pinctrl_select_state() for the same functionality, was resulting in NULL pointer issue while accessing desc->mux_owner. However, issue was not completely fixed due to the way it was handled and it can still result in the same NULL pointer. The issue occurs due to the following interleaving: cpu0 (process A) cpu1 (process B) pin_request() { pin_free() { mutex_lock() desc->mux_usecount--; //becomes 0 .. mutex_unlock() mutex_lock(desc->mux) desc->mux_usecount++; // becomes 1 desc->mux_owner = owner; mutex_unlock(desc->mux) mutex_lock(desc->mux) desc->mux_owner = NULL; mutex_unlock(desc->mux) This sequence leads to a state where the pin appears to be in use (`mux_usecount == 1`) but has no owner (`mux_owner == NULL`), which can cause NULL pointer on next pin_request on the same pin. Ensure that updates to mux_usecount and mux_owner are performed atomically under the same lock. Only clear mux_owner when mux_usecount reaches zero and no new owner has been assigned.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2025-08-22
Last Modified
2025-11-26
Generated
2026-05-27
AI Q&A
2025-08-22
EPSS Evaluated
2026-05-25
NVD
CVE-2025-38632
Affected Vendors & Products
Showing 4 associated CPEs
Vendor Product Version / Range
linux linux_kernel From 5.15.160 (inc) to 5.16 (inc)
linux linux_kernel From 5.15.160 (inc) to 5.16 (inc)
linux linux_kernel From 5.15.160 (inc) to 5.16 (inc)
linux linux_kernel From 5.15.160 (inc) to 5.16 (inc)
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-362 The product contains a concurrent code sequence that requires temporary, exclusive access to a shared resource, but a timing window exists in which the shared resource can be modified by another code sequence operating concurrently.
CWE-476 The product dereferences a pointer that it expects to be valid but is NULL.
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

This vulnerability in the Linux kernel's pinmux subsystem is a race condition that can cause a NULL pointer dereference. It happens when two clients simultaneously access the same GPIO pin functionality, leading to an inconsistent state where the pin's use count is non-zero but its owner pointer is NULL. This occurs because updates to the pin's use count and owner are not done atomically, causing the system to potentially access a NULL pointer during subsequent pin requests.


How can this vulnerability impact me? :

The vulnerability can cause the Linux kernel to dereference a NULL pointer when accessing GPIO pinmux data, potentially leading to kernel crashes or system instability. This can affect system reliability and availability, especially in environments relying on GPIO pins for hardware control.


What immediate steps should I take to mitigate this vulnerability?

To mitigate this vulnerability, ensure that the Linux kernel is updated to a version where the pinmux race condition is fixed. The fix involves making updates to mux_usecount and mux_owner atomic under the same lock and only clearing mux_owner when mux_usecount reaches zero and no new owner has been assigned. Applying the patch or kernel update that addresses commit 5a3e85c3c397 will resolve the issue.


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart