Cloudanix VulnDB

CVE-2026-98940

None

CVSS

—

EPSS

0.2%

Published

Oct 23, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A coding mistake in Linux audio drivers for certain Qualcomm chips could let a local process crash the system or damage memory during startup.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Moderate
Impact
Privilege Gain
Component
OS kernel
Class
Buffer Overflow
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Out-of-bounds array write in the qcom lpass-cpu driver when sparse DAI IDs are used to index variant->dai_driver instead of the loop index during LPAIF_I2SCTL_MODE_QUAD01 constraint setup, allowing writes past the single allocated entry.

Why it matters to the business

Kernel memory corruption or crashes can occur on affected Qualcomm audio platforms during driver probe, leading to system instability or denial of service on devices using IPQ806x or similar sparse-ID hardware.

How an attack unfolds

An attacker triggers the lpass-cpu probe path by loading the driver or configuring a DAI with LPAIF_I2SCTL_MODE_QUAD01 on platforms where DAI IDs do not match table positions; the code then performs an out-of-bounds write via the incorrect dai_driver index.

How to fix it

Apply the upstream fix that replaces dai_id with the loop index i when updating playback channel constraints; rebuild and deploy the corrected kernel image on affected systems.

How to confirm the fix worked

Inspect the lpass-cpu probe code to confirm the loop index is used for dai_driver access while dai_id is retained only for the SD-line mode array; test probe on sparse-ID hardware configurations.

Typical attack path

  1. Load or cause probe of the lpass-cpu driver on vulnerable kernel
  2. Ensure the target DAI uses LPAIF_I2SCTL_MODE_QUAD01 mode
  3. Trigger the branch that indexes dai_driver with the raw dai_id
  4. Perform out-of-bounds write to corrupt adjacent kernel memory

How to detect it

Review kernel logs for oops or panic messages referencing lpass-cpu, dai_driver, or I2SCTL_MODE_QUAD01 shortly after module load or audio subsystem initialization.

What your security team should do

  • Prioritize kernel updates containing the lpass-cpu indexing correction within normal patch cycles given low EPSS and absence from KEV
  • Monitor for related kernel oops reports on Qualcomm audio platforms
  • Validate driver behavior on IPQ806x-class hardware after patching

The record

In the Linux kernel, the following vulnerability has been resolved: ASoC: qcom: lpass-cpu: use DAI table index for playback constraints The DAI ID is a hardware port ID and is not necessarily the index of the corresponding entry in variant->dai_driver. When configuring a DAI with LPAIF_I2SCTL_MODE_QUAD01, the probe code currently uses dai_id to index variant->dai_driver. This is incorrect for platforms where DAI IDs are sparse. For example, the IPQ806x MI2S DAI has ID 4 while it is the only entry in the DAI driver table. If that DAI is configured for QUAD01 and probe reaches this branch, the code writes beyond that single entry via dai_driver[4] instead of updating the DAI being processed. Use the loop index i when updating the current DAI's playback channel constraints, while retaining dai_id for indexing the hardware-port specific playback SD-line mode array. This fixes the incorrect DAI table access for platforms where the DAI ID does not match its position in the driver table.

Affected packages

Ecosystem Package Introduced Fixed