CVE-2026-98674

What it actually does

Missing mutex initialization in the AXI ADC driver probe allows register access paths to operate without proper serialization via st->lock, enabling potential race conditions during device setup.

Why it matters to the business

Systems using affected ADC hardware may encounter instability, crashes, or data corruption during initialization, disrupting measurement and control operations with low overall risk given minimal exploitation likelihood.

How an attack unfolds

An attacker with local access triggers the driver probe concurrently with register transactions; because the lock is uninitialized, this can result in undefined kernel behavior such as panics or memory corruption, though no public exploits or threat actors are associated.

How to fix it

Apply the upstream kernel commit that initializes the state mutex before backend registration; rebuild and deploy the updated kernel on affected systems.

How to confirm the fix worked

Inspect the driver source for mutex_init call on st->lock prior to backend registration and confirm successful probe without lock-related warnings in dmesg.

Typical attack path

1. Gain local access to load or trigger the adi-axi-adc driver
2. Induce concurrent register access during probe execution
3. Exploit uninitialized mutex state to cause kernel instability

How to detect it

Search kernel logs and dmesg for oops/panic entries referencing adi-axi-adc, uninitialized locks, or mutex errors during module load or device probe.

What your security team should do

• Prioritize kernel updates for systems using adi-axi-adc hardware
• Review kernel logs for mutex or ADC-related faults post-update
• Test driver functionality on representative hardware after patching