CVE-2023-52765

What it actually does

The Qualcomm SPMI PMIC revid implementation assumes sibling devices are always bound to drivers and accesses their driver data without locking, enabling NULL-pointer dereference, use-after-free, and reference leaks during probe deferral, asynchronous probe, or unbind.

Why it matters to the business

Systems using Qualcomm PMICs may experience kernel crashes or instability during device initialization, resulting in unplanned downtime and requiring reboots on affected Linux deployments.

How an attack unfolds

An attacker with local access crafts probe timing or concurrent device operations to trigger the race in revid lookup, causing the kernel to dereference a NULL pointer from an unbound sibling device.

How to fix it

Update the Linux kernel to the fixed commit db98de0809f12b0edb9cd1be78e1ec1bfeba8f40 or later stable versions that reimplement revid lookup at PMIC probe time with proper caching and locking.

How to confirm the fix worked

Confirm the presence of the fix commit in the kernel source, verify no direct sibling driver data access remains in qcom-spmi-pmic, and test device probe sequences under deferral conditions.

Typical attack path

1. Trigger SPMI PMIC device registration with probe deferral enabled
2. Cause a sibling device to remain unbound or be unbound during access
3. Invoke revid function from a child device probe path
4. Trigger NULL dereference or access freed driver data

How to detect it

Review kernel logs for NULL pointer dereference oops involving qcom-spmi-pmic or revid functions; inspect dmesg and syslog for probe deferral patterns around SPMI device registration.

What your security team should do

• Apply the kernel patch containing db98de0809f12b0edb9cd1be78e1ec1bfeba8f40 immediately on all affected systems
• Prioritize updates for Android and embedded devices using Qualcomm PMICs
• Monitor kernel logs for related oops after patching to validate stability