CVE-2024-50070

What it actually does

Missing NULL check after devm_kasprintf() in the STM32 pinctrl driver allows a NULL pointer to be dereferenced on allocation failure, resulting in a kernel crash or memory corruption.

Why it matters to the business

Systems using affected Linux kernels on STM32 hardware may experience unexpected reboots or instability under low-memory conditions, increasing operational risk for embedded and IoT deployments.

How an attack unfolds

An attacker with local access or the ability to induce memory pressure can trigger the STM32 pinctrl initialization path; when devm_kasprintf() fails and returns NULL the subsequent dereference causes a kernel oops. No public exploits are known and EPSS remains low; listed threat actor references refer to broader kernel memory issues rather than this specific flaw.

How to fix it

Update to a kernel containing commit a8d52de0a6c6b091b2771bcb98ce408cf9d69fe3 or later; rebuild and deploy the fixed kernel for all STM32 platforms. Where package managers provide it, install the corrected kernel package; apply the same upgrade to any downstream distributions that consume the stable tree.

How to confirm the fix worked

Confirm the running kernel contains commit a8d52de0a6c6 or verify the source tree no longer lacks the NULL check after devm_kasprintf() in drivers/pinctrl/stm32/. Reboot into the updated kernel and exercise pinctrl initialization under memory pressure to ensure no NULL dereference occurs.

Typical attack path

1. Gain local execution or trigger memory exhaustion on target STM32-based Linux system
2. Cause the pinctrl-stm32 driver to allocate a string via devm_kasprintf()
3. Force the allocation to fail so that a NULL pointer is stored
4. Trigger subsequent code that dereferences the pointer, producing a kernel crash

How to detect it

Review kernel logs for oops or NULL pointer dereference messages originating from pinctrl-stm32.c; correlate with low-memory conditions or recent device-tree or pinctrl configuration changes. No specific post-exploitation artifacts are known.

What your security team should do

• Prioritize kernel upgrade on all STM32 Linux systems within the next maintenance window
• Monitor EPSS and KEV status for any future increase in exploit activity
• Include the fixed commit hash in internal kernel build validation pipelines