dbcve.org
Linux KernelOperating system · Linux

CVE-2026-53339

MEDIUM · 5.5 CVSS v3.1 Published 2026-07-01
Fix available
A fix is available. Upgrade to 5.10.259 / 5.15.210 or later.
See remediation →
57/100
Remediation priority · Elevated
Zero-click 7 weeks old

Official description Straight from the sourceThe vendor's or NVD's own wording, published unedited. Authoritative, but often terse — it says what broke, rarely what to do.

NVD · unedited
In the Linux kernel, the following vulnerability has been resolved: i2c: qcom-cci: Fix NULL pointer dereference in cci_remove() On all modern platforms Qualcomm CCI controller provides two I2C masters, and on particular boards only one I2C master may be initialized, and in such cases the device unbinding or driver removal causes a NULL pointer dereference, because cci_halt() is called for all two I2C masters, but a completion is initialized only for the single enabled master: % rmmod i2c-qcom-cci Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 <snip> Call trace: __wait_for_common+0x194/0x1a8 (P) wait_for_completion_timeout+0x20/0x2c cci_remove+0xc4/0x138 [i2c_qcom_cci] platform_remove+0x20/0x30 device_remove+0x4c/0x80 device_release_driver_internal+0x1c8/0x224 driver_detach+0x50/0x98 bus_remove_driver+0x6c/0xbc driver_unregister+0x30/0x60 platform_driver_unregister+0x14/0x20 qcom_cci_driver_exit+0x18/0x1008 [i2c_qcom_cci] ....

Technical summary Written by usOur analysis, written from the advisory, the CVSS vector and the affected-version data. It adds context the advisory leaves out, and never invents facts that are not in the source.

dbcve analysis · high confidence

In the Qualcomm CCI (Camera Control Interface) I2C driver, cci_remove() attempts to halt both I2C masters regardless of whether they were initialized. On platforms where only one master is enabled, the completion structure for the second master remains uninitialized, causing a NULL pointer dereference when wait_for_completion_timeout() is called on it during driver removal.

MitigationApply the upstream kernel fix which adds a check to verify each I2C master is initialized before calling cci_halt() on it during driver removal. This prevents dereferencing NULL completion structures for uninitialized masters.

Verify against the referenced sources before acting — the references below are authoritative for this CVE, this summary is not.

Affected products & versions What the vendor confirmedThe version ranges the vendor confirmed as vulnerable. If your version sits inside a range here, treat yourself as exposed until you have upgraded.

NVD · CPE data
Linux KernelOperating system
Affected:>= 5.8, < 5.10.259>= 5.11, < 5.15.210>= 5.16, < 6.1.176>= 6.2, < 6.6.143>= 6.7, < 6.12.94>= 6.13, < 6.18.36>= 6.19, < 7.0.13= 7.1

CVSS breakdown How the score is builtThe industry scoring standard. It rates how the flaw is reached, what it takes to exploit, and what an attacker gains — the score is derived from those, not the other way round.

From the vector
Attack vector
Local
Complexity
Low
Privileges
Low
User interaction
None
Scope
Unchanged
Confidentiality
None
Integrity
None
Availability
High

CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

Am I affected? How to checkSteps we derive from the advisory and the affected-version data, so you can decide whether this CVE reaches your setup. They are a guide, not a scan — your own configuration is the authority.

dbcve checks

Work through these to decide whether this CVE applies to you.

  1. Check kernel version
    Run 'uname -r' or 'cat /proc/version' to get the running kernel version
    Affected if Kernel version falls within any of the affected ranges: >= 5.8 and < 5.10.259, >= 5.11 and < 5.15.210, >= 5.16 and < 6.1.176, >= 6.2 and < 6.6.143, >= 6.7 and < 6.12.94, >= 6.13 and < 6.18.36, >= 6.19 and < 7.0.13, or exactly 7.1
  2. Verify i2c-qcom-cci driver is present
    Check for the driver in /sys/bus/platform/drivers/i2c-qcom-cci or look for 'qcom,cci' in /proc/device-tree/ compatible strings
    Affected if The i2c-qcom-cci driver is compiled into or loaded by the kernel on the system
  3. Check CCI master configuration in device tree
    Examine the device tree source or /proc/device-tree for qcom,cci master nodes - look for 'qcom,cci-master' entries and whether both masters are defined as 'status = "okay"'
    Affected if Only ONE CCI master is enabled (status okay) while the other is disabled or not present, creating the condition where cci_remove() attempts to halt an uninitialized master
  4. Confirm driver removal path will be triggered
    Check if the i2c-qcom-cci device is currently bound by examining /sys/bus/platform/drivers/i2c-qcom-cci/uevent or checking if the device appears in 'lsmod' or /sys/modules
    Affected if The CCI driver is actively bound to a device and the system has performed or may perform a driver removal, unbinding, or module unload operation

You are affected if your kernel version is within the affected ranges AND your system uses the i2c-qcom-cci driver with only one CCI master enabled, as this creates the NULL completion structure condition when the driver is removed.

Generated from the published advisory. Verify against your own configuration.

Check your environment

Paste your version and any relevant configuration and it will be compared against the affected criteria above. Do not include secrets or credentials.

AI-assisted, checked against the advisory. Informational, not a guarantee.

Remediation Closing itWhat it takes to close this. Where a vendor fix exists we point at it; where none exists we say so plainly, and can build one. Effort estimates are scoped from the advisory, not from your codebase.

dbcve · scoped
Upgrade available Upgrade to 5.10.259 / 5.15.210 / 6.1.176 or later
Fixed in 5.10.2595.15.2106.1.176
Interim mitigation

Apply the upstream kernel fix which adds a check to verify each I2C master is initialized before calling cci_halt() on it during driver removal. This prevents dereferencing NULL completion structures for uninitialized masters.

Recommended fix High confidence

5.10.259, 5.15.210, 6.1.176, or 6.6.143 (depending on which major version branch is in use)

  1. Identify the current kernel version using `uname -r` or `cat /proc/version`
  2. Determine which version branch your current kernel belongs to based on the affected ranges provided
  3. Upgrade the kernel to a fixed version: For 5.10.x branch, upgrade to 5.10.259 or later; For 5.15.x branch, upgrade to 5.15.210 or later; For 6.1.x branch, upgrade to 6.1.176 or later; For 6.2+ branches, upgrade to 6.6.143 or later
  4. Reboot the system into the new kernel to apply the fix
  5. Verify the fix by unloading and reloading the i2c-qcom-cci module (or rebooting) to confirm the NULL pointer dereference no longer occurs during driver removal
Caveat Kernel upgrades may introduce changes to driver APIs or system behavior; ensure compatibility with user-space tools and custom drivers before deploying in production

Generated from the published advisory — verify against the referenced sources before acting.

Fix this in Linux Kernel Scoped from the published advisory
  • Consultation1.0 h
  • Implementation2.0 h
  • Testing2.0 h
  • Review / QA1.0 h
6.0 hours of engineering $1,040
Get the upgrade done

An estimate, not a bill — we confirm scope with you before any work starts. Need it this week? Rush from $1,664.

Scan for this in your stack

Free · runs locally
dbcve dependency scanner

Check whether your project pulls in CVE-2026-53339 — or any other known-vulnerable package — straight from your lock files. Free and open source; it runs locally and uploads nothing.

Get it on GitHub Scan in the browser

References Go to the primary sourcePrimary sources — vendor advisories, patches and trackers. Where our summary and a reference disagree, the reference wins.

Primary sources

Practitioner notes

Contributed

Peer-ranked notes from engineers who’ve handled CVE-2026-53339 in production — separate from our analysis above.

No notes yet

Be the first to add a field note for this CVE — a mitigation you’ve verified, a version caveat, or a link to a working fix. Sign in above to contribute.

What this is

A place for practitioners to share what actually worked: a mitigation you’ve tested, a configuration change, a version- or environment-specific caveat, or a link to a verified patch. The most useful notes rise to the top as peers upvote them, so the signal stays high.

What belongs here
  • Verified mitigations, workarounds, and config changes
  • Version or environment caveats, and links to real fixes
  • No weaponised exploit code, or anything meant to cause harm
  • No spam, self-promotion, credentials, or personal data