A use-after-free (UAF) vulnerability has been identified and resolved in the Linux kernel's ALSA subsystem, specifically within the Dreamcast AICA sound card driver (sound/sh/aica.c). CVE-2024-26654 describes how improper cleanup order between timers and worker threads could let an attacker exploit a race condition, possibly leading to system instability, data leakage, or kernel panic.

Technical Analysis

The issue specifically impacts systems using the aica audio driver from the Dreamcast platform, which is not mainstream hardware, but still, the logic and fix are applicable to similar timer-workqueue intertwined code in other drivers.

The vulnerability becomes apparent during the cleanup process, where a timer (dreamcastcard->timer) and workqueue item (spu_dma_work) could reschedule each other. When the ALSA PCM hardware is closed (snd_aicapcm_pcm_close()), it frees up resources potentially still in use by these asynchronous components.

Below is an illustrative code snippet inspired by the vulnerable logic (simplified for clarity)

// In run_spu_dma() worker
if (should_reschedule) {
    mod_timer(&dreamcastcard->timer, jiffies + msecs_to_jiffies(10));
}

// In timer handler
aica_period_elapsed() {
    schedule_work(&dreamcastcard->spu_dma_work);
}

The main danger comes from the following sequence

(Thread 1) snd_aicapcm_pcm_close()
    flush_work(&dreamcastcard->spu_dma_work)
    del_timer(&dreamcastcard->timer)
    kfree(dreamcastcard)     // Frees 'channel'
    
(Thread 2) run_spu_dma() [worker thread]
    // Accesses dreamcastcard->channel (already freed!)

A key insight: del_timer() does not ensure the timer handler isn't currently running, so it's possible for the just-freed resource (dreamcastcard->channel) to be accessed immediately after kfree().

This subtle bug is particularly tricky to catch and reproduce — typical of many kernel UAF bugs.

Exploiting the UAF Flaw

While exploiting this bug on x86 desktop Linux is unlikely (as the Dreamcast AICA hardware is not common), the general exploitation path for such a UAF bug is:

1. Trigger rapid opening/closing of PCM substreams to increase the chance of the race.
2. Arrange system memory so that a new allocation reuses the recently freed aica_channel struct, which the old work/timer might reference.
3. If an attacker can control this new memory, they may achieve arbitrary kernel read/write, escalate privileges, or cause a DoS.

Example theoretical attacker simulation

// Pseudo-exploit idea
while (1) {
    ioctl(ALSA_IOCTL_OPEN_CHANNEL, ...);     // Open channel (allocates aica_channel)
    ioctl(ALSA_IOCTL_CLOSE_CHANNEL, ...);    // Close quickly (frees it)
    // Try to allocate something else at the same address - attacker controlled
    malloc(FAKE_CHANNEL_SIZE); 
}

On real platforms with exposed device nodes, an unprivileged user could potentially leverage this, but it's mostly of concern in niche embedded or emulation environments.

The upstream fix makes two key changes

- Conditional Rescheduling: run_spu_dma() only calls mod_timer() when resources are guaranteed valid — checking flags or device state.
- Synchronous Stop: Introduces a synchronous "stop" operation (PCM sync_stop) that cancels both the timer and worker before freeing memory.

Fixed logic example

// In run_spu_dma()
if (is_playback_active && !pcm_stopping) {
    mod_timer(&dreamcastcard->timer, ...);
}

// In PCM stop handler
pcm_sync_stop() {
    del_timer_sync(&dreamcastcard->timer);
    cancel_work_sync(&dreamcastcard->spu_dma_work);
}

This approach ensures no code path can race with kfree() and touch already-freed data.

Relevant patch:
- ALSA: sh: aica: reorder cleanup operations to avoid UAF bugs (LKML)

References

- Linux Kernel Mailing List: ALSA: sh: aica: reorder cleanup operations to avoid UAF bugs
- CVE Record: CVE-2024-26654
- Linux ALSA AICA Driver Source (Git)


Stay safe: Always update your Linux systems to the latest stable kernel, especially if you are using less-common hardware or drivers. This vulnerability shows even niche drivers can have critical bugs that set patterns for more widely-exploited classes of attacks.

Timeline

Published on: 04/01/2024 09:15:51 UTC
Last modified on: 02/03/2025 14:32:27 UTC