CVE-2026-74463 in Linux
Resumen
por VulDB • 2026-08-15
En el kernel de Linux se ha resuelto la siguiente vulnerabilidad:
i2c: jz4780: Almacenar en caché la frecuencia del reloj principal durante la fase probe para evitar un bloqueo mutuo (deadlock) prepare_lock en Common Clock Framework (CCF).
Se corrige un grave deadlock AB/BA entre el Common Clock Framework (CCF) y el lock del adaptador I2C, que se activa cuando un cliente generador de relojes controlado por I2C (como el Si5351) se registra o modifica bajo CCF.
Durante un cambio en la frecuencia del reloj del cliente i2c (generador), el CCF adquiere su mutex global 'prepare_lock' y el driver llama a i2c_transfer() para actualizar los registros de chip del cliente, quedando bloqueado esperando por el lock del bus I2C del adaptador.
Concurrentemente, una transferencia independiente y paralela en el mismo bus (por ejemplo, un expansor GPIO que gestiona LEDs) puede mantener el lock del adaptador I2C. Dentro de esta ruta de transferencia paralela, jz4780_i2c_set_speed() llama a clk_get_rate() sobre el reloj de entrada del controlador principal para calcular los tiempos del bus. Esta llamada intenta adquirir el 'prepare_lock' bloqueado por CCF, creando una dependencia circular que congela el sistema.
El propio reloj del controlador host jz4780 es estático y nunca cambia en tiempo de ejecución.
Sin embargo, llamar a clk_get_rate() dentro de la ruta de transferencia activa introduce una dependencia innecesaria sobre los locks internos de CCF.
Se elimina esta llamada sincrónica a clk_get_rate() de la ruta de transferencia activa almacenando en caché la frecuencia estática del reloj periférico principal una sola vez: dentro de la estructura privada jz4780_i2c durante jz4780_i2c_probe(). Se actualiza jz4780_i2c_set_speed() para utilizar este valor en caché, desacoplando con seguridad las transacciones I2C activas de los locks internos de CCF sin riesgo de obtener tiempos desactualizados.
Asistido por inteligencia artificial basada en web (Google AI) (para identificar el bug y redactar el mensaje).
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.