CVE-2026-74653 in Linux
Résumé
par VulDB • 23/08/2026
Dans le noyau Linux, la vulnérabilité suivante a été corrigée :
serial: 8250_of : effacer l'interruption de délai d'expiration RX bloquée sur FIFO vide pour LPC32xx
L'UART NXP LPC32xx (PORT_LPC3220) peut verrouiller une interruption de délai d'expiration de caractère RX alors que la FIFO RX est vide : IIR rapporte UART_IIR_RX_TIMEOUT (0x0c), mais LSR.DR est effacé. Un délai d'expiration de caractère n'est effacé qu'en lisant RHR, mais serial8250_rx_chars() ne lit RHR que lorsque LSR.DR est défini ; la condition n'est donc jamais résolue. L'interruption étant à seuil (level-triggered), elle se déclenche immédiatement de nouveau, ce qui provoque un orage d'interruptions bloquant le CPU en livelock sur un ARM926 monocœur.
Le problème est reproductible lorsque l'espace utilisateur ouvre répétitivement le port du panneau avant (ttyS1) : serial8250_do_set_termios() réactive les interruptions lors de la libération, et le gestionnaire tourne alors indéfiniment avec iir=0xcc, lsr=0x60, ier=0x05, déclenchant le détecteur de blocage logiciel (soft-lockup) dans serial8250_handle_irq_locked().
LPC32xx ne dispose pas d'un pilote glue 8250 dédié ; il est géré par le pilote générique 8250_of. Ajoutons un gestionnaire handle_irq spécifique au matériel pour PORT_LPC3220, configuré dans of_platform_serial_setup() de la même manière que fsl8250_handle_irq est installé. Le gestionnaire suit dw8250_handle_irq : en cas de délai d'expiration RX avec une FIFO vide (LSR.DR et LSR.BI effacés), il effectue une lecture RHR jetable pour résoudre la condition, puis appelle serial8250_handle_irq_locked(). Aucune donnée réellement reçue n'est jamais ignorée, et cette opération est un non-op sur les UART sains qui ne rapportent jamais de délai d'expiration avec DR effacé.
Il s'agit du même type de bogue déjà contourné dans d'autres pilotes 8250 ; voir le commit 424d79183af0 ("serial: 8250_dw : Éviter un « trop grand nombre de tâches » provenant d'une interruption de délai d'expiration rx erronée") qui rapporte les mêmes valeurs iir=0xcc/lsr=0x60. Voir également UART_RX_TIMEOUT_QUIRK dans 8250_omap, ainsi que la note dans 8250_bcm7271.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.