On June 2024, a security issue was reported in the Linux kernel, specifically in the Industrial I/O (IIO) ADC driver for Atmel/Microchip AT91 systems. This flaw is now cataloged as CVE-2024-57904. It concerns a mistake when freeing resources on error paths, which could lead to a use-after-free vulnerability — an issue that could potentially be abused by attackers if exploited in the right context.

In this long read, we'll break down the bug, show you the relevant code, link you to the references, and discuss vulnerability details and exploitation risks, all in plain, clear language.

The Basics: What Went Wrong?

The vulnerability is in the "at91" ADC driver’s touch screen registration code in the Linux kernel. When the driver initialization fails, the kernel needs to clean up resources. In this routine, it was freeing the wrong pointer: instead of the most recently allocated input device (which failed), it was freeing a field st->ts_input that might point to something else, or not yet set, depending on where the error occurred.

This mismatch *looks harmless* but, in kernel code, can lead to use-after-free bugs, crashes, and could even give attackers a way to tamper with kernel memory.

Here's an annotated version of the relevant code from the buggy kernel (before the fix)

static int at91_ts_register(struct at91_adc_state *st)
{
    struct input_dev *input;
    int error;

    input = input_allocate_device();
    if (!input)
        return -ENOMEM;

    // .... (other setup code) ....

    st->ts_input = input;  // This happens further down, *not* at allocation

    // ... (registration, may fail at any stage) ...

    return ;

err_free_input:
    input_free_device(st->ts_input);  // <-- This is the bug!
    return error;
}

The function jumps to err_free_input on any error. However, if the code fails before st->ts_input = input; is set, then st->ts_input could still be NULL or, worse, pointing somewhere else. Instead, it should free the local input variable — the one just allocated.

The fix is simple but critical

err_free_input:
    input_free_device(input);  // Always free the correct device!
    return error;

This guarantees that the function never tries to free a wrong or uninitialized pointer, eliminating possible use-after-free bugs.

References

* Upstream Linux Patch:
linux/iio: adc: at91: call input_free_device() on allocated iio_dev

* CVE Entry:
(TBA, once published on NVD)

* Disclosure in Linux Kernel Mailing List:
LMKL Patch Review - at91 adc cleanup

Is this bug exploitable?

By itself, this type of bug is a cleanup path error — it hits when something already failed during initialization, so it’s not triggered during normal device usage. However, *if* an attacker controls the conditions for loading/unloading kernel modules, or can influence error handling in at91_ts_register() (directly or through crafted inputs), they could trigger this situation.

Use-after-free: Kernel code could reuse memory that now belongs to another structure.

- Information leaks: Something freed early could later be read/used, leaking sensitive data.
- Control flow corruption: In rare cases, it may allow some form of code execution, especially if the attacker can heap spray or manipulate memory allocations.

Realistic Attack Scenarios

This specific driver is for microprocessor boards (Atmel/Microchip) with touch screens using the IIO ADC interface. Attackers would need local access and the ability to repeatedly trigger device initialization failures — typically as root, so exploitation is limited in multi-user environments. However, in special embedded or kiosk systems, an attacker with such access could cause system instability or escalate their privileges.

How to Stay Safe

- Update your kernel: The fix for CVE-2024-57904 is included in Linux versions after the patch date (likely 6.10+ or backported to stable series).
- Audit embedded devices: If you're running devices with the at91 ADC driver, update or patch them fast.

Conclusion

CVE-2024-57904 highlights how even "small" errors in kernel driver cleanup code can have outsized security impact. By cleaning up after itself in the right way, the kernel helps prevent subtle memory safety issues — the kind that attackers might try to exploit for years to come.

Stay up to date, and keep your systems safe!

For more technical details and the latest patches, check out the official Linux kernel repository.

Timeline

Published on: 01/19/2025 12:15:23 UTC
Last modified on: 05/04/2025 10:06:18 UTC