CVE-2025-38632

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> pinmux: fix race causing mux_owner NULL with active mux_usecount<br /> <br /> commit 5a3e85c3c397 ("pinmux: Use sequential access to access<br /> desc-&gt;pinmux data") tried to address the issue when two client of the<br /> same gpio calls pinctrl_select_state() for the same functionality, was<br /> resulting in NULL pointer issue while accessing desc-&gt;mux_owner.<br /> However, issue was not completely fixed due to the way it was handled<br /> and it can still result in the same NULL pointer.<br /> <br /> The issue occurs due to the following interleaving:<br /> <br /> cpu0 (process A) cpu1 (process B)<br /> <br /> pin_request() { pin_free() {<br /> <br /> mutex_lock()<br /> desc-&gt;mux_usecount--; //becomes 0<br /> ..<br /> mutex_unlock()<br /> <br /> mutex_lock(desc-&gt;mux)<br /> desc-&gt;mux_usecount++; // becomes 1<br /> desc-&gt;mux_owner = owner;<br /> mutex_unlock(desc-&gt;mux)<br /> <br /> mutex_lock(desc-&gt;mux)<br /> desc-&gt;mux_owner = NULL;<br /> mutex_unlock(desc-&gt;mux)<br /> <br /> This sequence leads to a state where the pin appears to be in use<br /> (`mux_usecount == 1`) but has no owner (`mux_owner == NULL`), which can<br /> cause NULL pointer on next pin_request on the same pin.<br /> <br /> Ensure that updates to mux_usecount and mux_owner are performed<br /> atomically under the same lock. Only clear mux_owner when mux_usecount<br /> reaches zero and no new owner has been assigned.