CVE-2024-50238

What it actually does

Missing driver data initialization in qcom-qmp-usbc probe causes NULL pointer dereference inside runtime PM suspend/resume callbacks when runtime power management is later enabled.

Why it matters to the business

Systems using Qualcomm USB PHY drivers may experience kernel crashes or instability when runtime PM is manually activated via sysfs, resulting in denial of service on affected Linux kernels; impact is limited because runtime PM is not enabled by default.

How an attack unfolds

An attacker with local access enables runtime PM through sysfs on a system with the vulnerable qmp-usbc driver, then triggers a runtime suspend event that executes the callback using uninitialized driver data, dereferencing a NULL pointer and crashing the kernel.

How to fix it

Update the Linux kernel to a version containing commit a38297e3fb012ddfa7ce0321a7e5a8daeb1872b6 or later; rebuild and deploy the fixed qcom-qmp-usbc driver.

How to confirm the fix worked

Confirm the patch is present by checking for restored dev_set_drvdata call in qmp_usbc_probe; test by enabling runtime PM and exercising suspend paths without observing NULL dereference oops.

Typical attack path

1. Obtain local shell or code execution on target Linux system
2. Write 1 to /sys/bus/platform/devices/.../power/control to enable runtime PM
3. Induce runtime suspend via power management interfaces or device removal
4. Trigger NULL dereference in qmp_usbc runtime callback leading to kernel panic

How to detect it

Search kernel logs and dmesg for NULL pointer dereference oops mentioning qmp_usbc_runtime_suspend, qmp_usbc_runtime_resume, or qcom-qmp-usbc driver data; correlate with sysfs writes enabling runtime PM on platform devices.

• qmp_usbc_runtime_suspend
• qmp_usbc_runtime_resume
• NULL pointer dereference.*qcom-qmp-usbc
• dev_set_drvdata.*qmp_usbc_probe

What your security team should do

• Apply the referenced kernel commit immediately on all systems using qcom USB PHY drivers
• Audit sysfs runtime PM settings to ensure they remain disabled unless explicitly required
• Monitor kernel logs for oops involving qmp_usbc or qcom-qmp-usb runtime callbacks
• Plan kernel upgrades across fleets within standard patch windows given low EPSS and no KEV listing