CVE-2024-47141

What it actually does

Race condition in pinmux allows concurrent pin_request calls to increment mux_usecount without setting mux_owner, causing subsequent strcmp on a NULL mux_owner pointer.

Why it matters to the business

Kernel crashes and denial of service on Linux systems that use GPIO or pin control, leading to service disruption and potential data loss on affected hosts.

How an attack unfolds

Local attacker spawns multiple processes that simultaneously invoke pinctrl_select_state for the same pin, winning the race where one process updates usecount before the other reads the unset owner field.

How to fix it

Update the Linux kernel to a version containing commit 2da32aed4a97ca1d70fb8b77926f72f30ce5fb4b which adds mutex serialization around mux state updates.

How to confirm the fix worked

Confirm the mutex lock protects mux_usecount and mux_owner updates in pin_request, or verify the fixed commit is present in the running kernel source.

Typical attack path

1. Obtain local code execution
2. Launch concurrent processes calling pin_request on identical pin
3. Trigger unsynchronized access to mux_usecount and mux_owner
4. Induce NULL pointer dereference and kernel panic

How to detect it

Search kernel logs and crash dumps for NULL pointer dereference originating in pin_request or pinctrl_select_state functions involving mux_owner.

• NULL pointer dereference.*mux_owner
• pin_request.*strcmp
• desc->mux_usecount

What your security team should do

• Prioritize kernel upgrade to the fixed commit on all affected systems
• Reboot after patching to load the corrected module
• Monitor kernel logs for pinmux-related oops until remediation is complete