GHSA-RPG5-5RC2-V629
Vulnerability from github – Published: 2025-08-22 18:31 – Updated: 2025-11-26 18:31In 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.
{
"affected": [],
"aliases": [
"CVE-2025-38632"
],
"database_specific": {
"cwe_ids": [
"CWE-362"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-08-22T16:15:37Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\npinmux: fix race causing mux_owner NULL with active mux_usecount\n\ncommit 5a3e85c3c397 (\"pinmux: Use sequential access to access\ndesc-\u003epinmux data\") tried to address the issue when two client of the\nsame gpio calls pinctrl_select_state() for the same functionality, was\nresulting in NULL pointer issue while accessing desc-\u003emux_owner.\nHowever, issue was not completely fixed due to the way it was handled\nand it can still result in the same NULL pointer.\n\nThe issue occurs due to the following interleaving:\n\n cpu0 (process A) cpu1 (process B)\n\n pin_request() { pin_free() {\n\n mutex_lock()\n desc-\u003emux_usecount--; //becomes 0\n ..\n mutex_unlock()\n\n mutex_lock(desc-\u003emux)\n desc-\u003emux_usecount++; // becomes 1\n desc-\u003emux_owner = owner;\n mutex_unlock(desc-\u003emux)\n\n mutex_lock(desc-\u003emux)\n desc-\u003emux_owner = NULL;\n mutex_unlock(desc-\u003emux)\n\nThis sequence leads to a state where the pin appears to be in use\n(`mux_usecount == 1`) but has no owner (`mux_owner == NULL`), which can\ncause NULL pointer on next pin_request on the same pin.\n\nEnsure that updates to mux_usecount and mux_owner are performed\natomically under the same lock. Only clear mux_owner when mux_usecount\nreaches zero and no new owner has been assigned.",
"id": "GHSA-rpg5-5rc2-v629",
"modified": "2025-11-26T18:31:00Z",
"published": "2025-08-22T18:31:22Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38632"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0b075c011032f88d1cfde3b45d6dcf08b44140eb"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/22b585cbd67d14df3b91529d1b990661c300faa9"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9b2a3e7189028aa7c4d53a84364f2ea9fb209787"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9ea3f6b9a67be3476e331ce51cac316c2614a564"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b7bd6e3971eb7f0e34d2fdce1b18b08094e0c804"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.