CVE-2026-53339

What it actually does

This vulnerability is a NULL pointer dereference in the Linux kernel Qualcomm CCI I2C controller driver during driver removal or device unbinding. On Qualcomm platforms where the CCI controller exposes two I2C masters but only one is initialized by the board configuration, the removal path attempts to halt both masters even though synchronization state was initialized only for the enabled master. This can cause the kernel to dereference a NULL completion pointer while waiting in the removal path, leading to a kernel oops or panic and resulting in a local denial of service.

Why it matters to the business

Successful exploitation can crash affected Linux-based systems running impacted Qualcomm hardware, causing service interruption, device reboot, or loss of availability. The practical risk is highest for embedded, mobile, IoT, appliance, or edge systems where Qualcomm camera/I2C controller support is enabled and where local administrative access, driver-management capabilities, or automated hardware reconfiguration workflows exist. There is no indication of known exploitation, ransomware use, or inclusion in the CISA KEV catalog, and the low EPSS score suggests limited observed exploitation likelihood at this time.

How an attack unfolds

An attacker must first obtain sufficient local privileges to trigger removal of the Qualcomm CCI I2C driver or unbind the platform device, such as root access, CAP_SYS_MODULE, or write access to relevant sysfs driver binding interfaces. On an affected Qualcomm-based system where only one of the two CCI I2C masters is initialized, the attacker initiates driver removal, for example by unloading the kernel module or unbinding the device. During cleanup, the vulnerable driver calls its halt logic for both possible masters. Because one master was never initialized, the code attempts to wait on an uninitialized or NULL completion object. The kernel then hits a NULL pointer dereference in the removal path, producing an oops or panic depending on kernel configuration, which can reboot or hang the system.

How to fix it

Apply a Linux kernel update that includes the upstream fix for the Qualcomm CCI I2C controller removal path. If using a vendor kernel, obtain the corrected kernel package or board support package from the device, SoC, distribution, or appliance vendor. Where immediate patching is not possible, reduce exposure by preventing untrusted users or processes from unloading kernel modules or writing to sysfs driver bind/unbind interfaces, disabling unnecessary module autoloading, enforcing least privilege for administrative tooling, and monitoring or restricting CAP_SYS_MODULE. Avoid operational workflows that remove or rebind the i2c-qcom-cci driver on affected platforms until patched.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel or vendor kernel build includes the fixed qcom-cci driver change. On representative affected Qualcomm hardware, validate that unloading or unbinding the i2c-qcom-cci driver no longer produces a kernel oops, panic, or NULL pointer dereference. Review package changelogs, kernel commit history, distribution advisories, or vendor BSP release notes for the Qualcomm CCI removal-path fix. Also confirm that non-administrative users cannot unload kernel modules or write to platform-driver unbind interfaces.

Typical attack path

1. Gain local privileged access to an affected Linux system, or obtain the ability to manage kernel modules or platform device bindings.
2. Confirm that the system uses the Qualcomm CCI I2C controller driver and is configured with only one initialized CCI I2C master.
3. Trigger driver removal or device unbinding using module unload or sysfs driver unbind mechanisms.
4. Cause the vulnerable cleanup path to call halt handling for an uninitialized master.
5. Induce a kernel NULL pointer dereference, resulting in a crash, panic, reboot, or denial of service.

How to detect it

Look for evidence of attempted or successful driver removal followed by kernel crash activity. Useful sources include kernel logs, journald, dmesg buffers, persistent crash logs, pstore/ramoops records, kdump/vmcore artifacts, auditd records for module unload or sysfs writes, and endpoint telemetry showing use of rmmod, modprobe -r, or writes to driver unbind files. Search for kernel oops or panic messages referencing i2c_qcom_cci, cci_remove, cci_halt, wait_for_completion_timeout, __wait_for_common, or NULL pointer dereference at address 0x0. Correlate these events with privileged commands that remove the i2c-qcom-cci module or unbind Qualcomm CCI platform devices. Repeated crashes during maintenance, device unbinding, module removal, or camera/I2C subsystem reconfiguration may indicate attempted triggering, although benign administrative activity can produce similar traces.

• Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000
• NULL pointer dereference
• cci_remove
• cci_halt
• wait_for_completion_timeout
• __wait_for_common
• i2c_qcom_cci
• i2c-qcom-cci
• qcom_cci_driver_exit
• rmmod i2c-qcom-cci
• modprobe -r i2c-qcom-cci
• /sys/bus/platform/drivers/*/unbind
• /sys/bus/platform/drivers/i2c-qcom-cci/unbind

What your security team should do

• Prioritize patching affected Qualcomm-based Linux systems where the i2c-qcom-cci driver is present, especially embedded, edge, mobile, camera-enabled, or appliance deployments requiring high availability.
• Inventory systems for use of the Qualcomm CCI I2C driver by checking loaded modules, kernel configuration, device tree contents, and platform device bindings.
• Restrict kernel module unload and sysfs driver unbind permissions to trusted administrators only, and review use of CAP_SYS_MODULE in services, containers, and automation.
• Monitor kernel logs for NULL pointer dereferences involving cci_remove, cci_halt, wait_for_completion_timeout, or i2c_qcom_cci.
• For systems that cannot be patched quickly, document operational risk and avoid maintenance tasks that unload or rebind the vulnerable driver.
• Because this issue is not currently known to be exploited and has low EPSS, handle it as a targeted availability risk rather than an internet-scale emergency, unless the affected platform is safety-critical or highly available.