CVE-2026-64236: i2c: davinci: fix division by zero on missing clock-frequency
In the Linux kernel, the following vulnerability has been resolved:
i2c: davinci: fix division by zero on missing clock-frequency
When the 'clock-frequency' property is missing from the device tree, the driver falls back to DAVINCII2CDEFAULTBUSFREQ. However, this macro was defined in kHz (100), whereas the device tree property is expected in Hz.
The probe function divided the fallback value by 1000, causing integer truncation that resulted in dev->busfreq = 0. This triggered a deterministic division-by-zero kernel panic when calculating clock dividers later in the probe sequence.
Fix this by redefining DAVINCII2CDEFAULTBUSFREQ in Hz (100000) to match the expected device tree property unit, allowing the existing division logic to work correctly for both cases.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
Redefine DAVINCI_I2C_DEFAULT_BUS_FREQ in Hz to 100000 so the driver's fallback value matches the device tree 'clock-frequency' unit and prevents bus_freq = 0/division-by-zero.
i2c: davinci driver DAVINCI_I2C_DEFAULT_BUS_FREQ = 100000
Event History
Frequently Asked Questions
Which systems are exposed to the panic?
Systems using the Linux kernel's DaVinci I2C driver are exposed when their device tree omits the clock-frequency property. The missing property causes the driver's fallback bus frequency to become zero during probe.
What is required to trigger the issue?
No user interaction is required. During driver probe, the missing clock-frequency property leads deterministically to a division-by-zero kernel panic while clock dividers are calculated.
Is there a temporary mitigation if the fix cannot be deployed immediately?
Provide a valid clock-frequency property in the affected I2C device tree, expressed in Hz. This avoids use of the faulty fallback value.