CVE-2025-71199: Linux Kernel Use-After-Free Vulnerability

CVE-2025-71199 Overview

A use-after-free vulnerability has been identified in the Linux kernel's IIO (Industrial I/O) subsystem, specifically within the at91-sama5d2_adc driver used for Atmel SAMA5D2 analog-to-digital converter hardware. The vulnerability occurs due to improper synchronization between the ADC interrupt handler's workqueue scheduling and the module removal cleanup path, potentially leading to memory corruption or system instability.

Critical Impact

This use-after-free vulnerability in the Linux kernel ADC driver could allow a local attacker with module unloading privileges to cause system crashes, denial of service, or potentially achieve privilege escalation through memory corruption.

Affected Products

• Linux kernel with at91-sama5d2_adc driver compiled
• Atmel SAMA5D2-based embedded systems
• Systems using IIO ADC subsystem with touch input functionality

Discovery Timeline

• 2026-02-04 - CVE CVE-2025-71199 published to NVD
• 2026-02-05 - Last updated in NVD database

Technical Details for CVE-2025-71199

Vulnerability Analysis

The vulnerability exists in the at91-sama5d2_adc driver's module removal path. When the at91_adc_interrupt function handles an ADC interrupt, it may invoke at91_adc_touch_data_handler, which schedules work via schedule_work(&st->touch_st.workq). This scheduled work runs asynchronously and eventually calls iio_push_to_buffers(indio_dev) to push data to the IIO buffer subsystem.

The race condition manifests when module removal is initiated while the workqueue handler is still pending or executing. The at91_adc_remove function calls iio_device_unregister(indio_dev), which eventually frees the indio_dev structure. However, if the workqueue handler at91_adc_workq_handler runs after this deallocation but before the work is properly canceled, it will attempt to access the freed indio_dev memory, resulting in a use-after-free condition.

Root Cause

The root cause is a missing work cancellation operation in the at91_adc_remove function. Before the fix, the module cleanup path did not ensure that all pending workqueue items were canceled before freeing the indio_dev structure. This creates a classic Time-of-Check Time-of-Use (TOCTOU) race condition where the validity of the indio_dev pointer is implicitly assumed but not guaranteed during asynchronous workqueue execution.

The fix ensures that cancel_work_sync(&st->touch_st.workq) is called before proceeding with the cleanup in at91_adc_remove, guaranteeing that no pending work can access the freed memory.

Attack Vector

The attack scenario involves a race condition between two CPU operations:

CPU0 (Module Removal Path):

1. at91_adc_remove is called during module unload
2. iio_device_unregister(indio_dev) begins freeing the device structure

CPU1 (Workqueue Handler):

1. at91_adc_workq_handler executes from previously scheduled work
2. Calls iio_push_to_buffers(indio_dev) with the now-freed pointer
3. Use-after-free occurs, potentially corrupting memory

An attacker with the ability to trigger module unloads could potentially exploit this timing window to achieve memory corruption, though practical exploitation would require precise timing control and additional vulnerabilities to achieve meaningful code execution.

Detection Methods for CVE-2025-71199

Indicators of Compromise

• Kernel panic or oops messages referencing at91_adc_workq_handler or iio_push_to_buffers
• KASAN (Kernel Address Sanitizer) reports indicating use-after-free in the IIO ADC subsystem
• System instability or crashes during ADC module unload operations
• Unexpected memory corruption warnings in kernel logs involving indio_dev structures

Detection Strategies

• Enable KASAN in kernel builds to detect use-after-free conditions at runtime
• Monitor kernel logs for oops or panic messages related to the at91-sama5d2_adc driver
• Implement kernel tracing on iio_device_unregister and at91_adc_workq_handler functions to identify race conditions
• Use kernel memory debugging tools like SLUB debugging to detect memory corruption

Monitoring Recommendations

• Deploy kernel log monitoring for IIO subsystem errors on affected embedded systems
• Implement automated alerting for kernel panic events on SAMA5D2-based platforms
• Track module load/unload events on production systems to correlate with potential exploitation attempts
• Consider running memory sanitizer-enabled kernels in staging environments to catch similar issues

How to Mitigate CVE-2025-71199

Immediate Actions Required

• Update the Linux kernel to a patched version containing the fix commits
• Avoid unnecessary module unloading of the at91-sama5d2_adc driver on production systems until patched
• Consider building the ADC driver as built-in rather than a loadable module to eliminate the removal code path
• Review system access controls to ensure only authorized users can trigger module operations

Patch Information

The vulnerability has been addressed through multiple commits to the stable Linux kernel tree. The fix ensures that the workqueue is properly canceled before cleanup proceeds in the at91_adc_remove function.

Patch Commits:

• Kernel Git Commit - Fix
• Kernel Git Commit - Update
• Kernel Git Commit - Security
• Kernel Git Commit - Improvement

The fix adds a cancel_work_sync() call before the iio_device_unregister() to ensure all pending work is completed or canceled before freeing the device structure.

Workarounds

• Compile the at91-sama5d2_adc driver as a built-in kernel component (CONFIG_AT91_SAMA5D2_ADC=y) rather than a module to prevent the vulnerable removal path from being exercised
• Restrict module loading/unloading capabilities using kernel lockdown or LSM policies
• On systems where the ADC functionality is not required, blacklist the module to prevent it from loading
• Implement operational procedures to avoid ADC module removal during active data acquisition

# Configuration example
# Blacklist the vulnerable module if ADC functionality is not required
echo "blacklist at91_sama5d2_adc" >> /etc/modprobe.d/blacklist-adc.conf

# Alternatively, restrict module operations with kernel parameters
# Add to kernel command line: module.sig_enforce=1

# Monitor for module unload attempts
auditctl -w /sbin/rmmod -p x -k module_removal
auditctl -w /sbin/modprobe -p x -k module_operations