Answer in brief
CVE-2026-63883 records a High severity (CVSS 7.3) vulnerability in serial: qcom_geni: fix kfifo underflow when flush precedes DMA completion IRQ. The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
CVSS is 7.3. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | >=2aaa43c7077833301c237684cd7bc9ae5e3dec95 <c91ea13375f70f6271a0183445e34e83b8f4d8f7 || >=2aaa43c7077833301c237684cd7bc9ae5e3dec95 <b1159dce10b38eb795e4c96cdc4d34b83cec81c5 || >=2aaa43c7077833301c237684cd7bc9ae5e3dec95 <654f45a8569f3cd6ff20bd724a18e0cce65893ba || >=2aaa43c7077833301c237684cd7bc9ae5e3dec95 <0d2c41a8b00934ddf8a7c1b4cf72dffa1e629c46 || >=2aaa43c7077833301c237684cd7bc9ae5e3dec95 <452d6fa37ae9b021f4f6d397dbae077f7296f6f4 | c91ea13375f70f6271a0183445e34e83b8f4d8f7, b1159dce10b38eb795e4c96cdc4d34b83cec81c5, 654f45a8569f3cd6ff20bd724a18e0cce65893ba, 0d2c41a8b00934ddf8a7c1b4cf72dffa1e629c46, 452d6fa37ae9b021f4f6d397dbae077f7296f6f4 |
| Linux/Linuxgeneric | 6.3 | Not reported |
Published upstream
Jul 19, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Aug 5, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Aug 5, 2026
In the Linux kernel, the following vulnerability has been resolved: serial: qcom_geni: fix kfifo underflow when flush precedes DMA completion IRQ When uart_flush_buffer() runs before the DMA completion IRQ is delivered, the following race can occur (all steps serialized by uart_port_lock): 1. DMA starts: tx_remaining = N, kfifo contains N bytes 2. DMA completes in hardware; IRQ is pending but not yet delivered 3. uart_flush_buffer() acquires the port lock and calls kfifo_reset(), making kfifo_len() = 0 while tx_remaining remains N 4. uart_flush_buffer() releases the port lock 5. DMA IRQ fires; handle_tx_dma() acquires the port lock and calls uart_xmit_advance(uport, tx_remaining) on an empty kfifo uart_xmit_advance() increments kfifo->out by tx_remaining. Since kfifo_reset() already set both in and out to 0, out wraps past in, causing kfifo_len() to return UART_XMIT_SIZE - tx_remaining. The next start_tx_dma() call then submits a DMA transfer of stale buffer data. Fix this by snapshotting kfifo_len() at the start of handle_tx_dma() and skipping uart_xmit_advance() when fifo_len < tx_remaining, which indicates the kfifo was reset by a preceding flush.
Quoted source text, attributed separately from HOL analysis.