CVE-2025-38671

What it actually does

The i2c qup driver fails to break out of its polling loop on timeout when an I2C client holds the bus active, causing the kernel to spin indefinitely and return -ETIMEDOUT only after an external intervention.

Why it matters to the business

Systems using affected I2C hardware (such as PCA953x GPIO expanders) can experience complete kernel hangs, leading to denial of service and requiring manual reboot; the issue is widespread in Linux distributions but carries low exploitation likelihood.

How an attack unfolds

An attacker or a buggy client device keeps the I2C bus active during a transfer timeout; the driver sets a return value but continues looping instead of exiting, hanging the calling thread and the kernel until the system is reset.

How to fix it

Apply the upstream fix in commit cbec4406998185e0311ae97dfacc649f9cd79b0b. For Chainguard packages update openjdk-11-openj9 and related variants to 0.53.0-r0 or newer. Reboot after installing the updated kernel or package.

How to confirm the fix worked

Confirm the running kernel contains commit cbec4406998185e0311ae97dfacc649f9cd79b0b or verify package version is at or above the listed fixed releases; reproduce the original timeout scenario and ensure the driver now returns -ETIMEDOUT promptly.

Typical attack path

1. Attacker supplies or compromises an I2C client device connected to the target system
2. Trigger a bus transaction that enters the timeout path in the qup driver
3. Maintain bus activity so the loop condition never becomes false
4. Kernel thread blocks indefinitely, resulting in system hang

How to detect it

Inspect kernel logs for i2c qup timeout messages that precede system hangs; correlate with device trees or drivers using PCA953x or similar I2C GPIO expanders; review dmesg or journalctl entries around the time of observed freezes.

What your security team should do

• Patch Linux kernels to the fixed commit or later within normal maintenance windows
• Update Chainguard openjdk-11-openj9 packages to 0.53.0-r0
• Monitor I2C-related kernel logs for repeated timeout entries as an early indicator of problematic clients
• Test I2C hardware configurations in staging before production deployment