Wind River Support Network

Description

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

CREATE(Triage):(User=pbi-cn) [CVE-2025-38632 (https://nvd.nist.gov/vuln/detail/CVE-2025-38632)