Cloudanix VulnDB

CVE-2026-63883

High · 7.3

CVSS

7.3

EPSS

0.2%

Published

Jul 19, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A timing bug in Linux serial drivers for certain Qualcomm chips can let local programs send the wrong data over hardware connections, potentially causing crashes or leaks.

Exploitation
Local Privilege
Attacker needs
Low Privilege
Complexity
Moderate
Impact
Data Tampering
Component
OS kernel
Class
Race Condition
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Race condition in qcom_geni serial driver where uart_flush_buffer resets kfifo while tx_remaining still holds a prior DMA length; subsequent handle_tx_dma calls uart_xmit_advance on the empty FIFO, causing out-pointer wrap-around and DMA submission of stale buffer contents.

Why it matters to the business

Local processes can induce kernel-level serial data corruption or leakage on Qualcomm SoC platforms, risking device instability, unexpected output on consoles or modems, and potential escalation to broader system compromise.

How an attack unfolds

An attacker with local code execution opens a serial port backed by the qcom_geni driver, issues flush operations timed against pending DMA completion IRQs, and triggers the kfifo underflow path that re-submits stale DMA descriptors.

How to fix it

Apply the upstream fix that snapshots kfifo_len at the start of handle_tx_dma and skips uart_xmit_advance when fifo_len < tx_remaining; rebuild and deploy the patched kernel on all affected Qualcomm-based devices.

How to confirm the fix worked

Inspect the qcom_geni serial driver source for the kfifo_len snapshot guard in handle_tx_dma; confirm the patch is present by searching for the conditional skip of uart_xmit_advance when fifo_len < tx_remaining.

Typical attack path

  1. Obtain local execution on affected Linux system
  2. Open and configure qcom_geni-backed UART device
  3. Force concurrent uart_flush_buffer and DMA IRQ paths under uart_port_lock
  4. Observe kfifo_len underflow and subsequent stale DMA transfer

How to detect it

Review kernel logs for serial DMA or kfifo anomalies around the time of any unexplained UART behavior; examine audit trails of processes opening /dev/tty* devices on qcom_geni hardware.

What your security team should do

  • Prioritize kernel updates containing the qcom_geni race fix on all Qualcomm SoC deployments
  • Restrict unprivileged access to serial devices via device ACLs until patched
  • Monitor kernel changelogs for serial/qcom_geni commits after 2026-07-19

The record

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.

Affected packages

Ecosystem Package Introduced Fixed