CVE-2026-74653 in Linux
Riassunto
di VulDB • 23/08/2026
Nel kernel Linux è stata risolta la seguente vulnerabilità:
serial: 8250_of: risolvere il timeout RX bloccato per FIFO vuota su LPC32xx
L'UART NXP LPC32xx (PORT_LPC3220) può generare un interrupt di timeout del carattere RX mentre la FIFO RX è vuota: IIR riporta UART_IIR_RX_TIMEOUT (0x0c), ma LSR.DR è azzerato. Un timeout del carattere viene cancellato solo leggendo RHR, ma serial8250_rx_chars() legge RHR solo quando LSR.DR è impostato; di conseguenza, la condizione non viene mai risolta. Poiché l'interrupt è a livello (level-triggered) e si riattiva immediatamente, su un ARM926 single-core il conseguente interrupt storm livelocks la CPU.
Il problema è riproducibile quando userspace apre ripetutamente la porta del pannello frontale (ttyS1): serial8250_do_set_termios() riabilita gli interrupt al rilascio e l'handler quindi gira all'infinito con iir=0xcc, lsr=0x60, ier=0x05, attivando il rilevatore di soft-lockup in serial8250_handle_irq_locked().
LPC32xx non dispone di un driver glue 8250 dedicato; è gestito dal generico 8250_of. Aggiungere una gestione handle_irq specifica per l'hardware per PORT_LPC3220, collegata in of_platform_serial_setup() allo stesso modo in cui viene installato fsl8250_handle_irq. L'handler segue dw8250_handle_irq(): su un timeout RX con FIFO vuota (LSR.DR e LSR.BI azzerati) esegue una lettura RHR di sola eliminazione per risolvere la condizione, quindi chiama serial8250_handle_irq_locked(). Non vengono mai scartati dati ricevuti reali ed è un'operazione nulla (no-op) su UART sane che non riportano mai un timeout con DR azzerato.
Si tratta della stessa classe di bug già aggirata in altri driver 8250; vedere il commit 424d79183af0 ("serial: 8250_dw: Avoid "too much work" from bogus rx timeout interrupt") che riporta l'identico iir=0xcc/lsr=0x60. Vedere anche UART_RX_TIMEOUT_QUIRK in 8250_omap e la nota in 8250_bcm7271.
If you want to get best quality of vulnerability data, you may have to visit VulDB.