Linux, as powerful as it is, is not immune to security bugs. CVE-2023-52802 is one of those subtle yet important issues that could have led to unwanted Linux kernel panic or even security incidents—if left unpatched. This vulnerability was found and patched in the STM32 ADC driver (Analog-to-Digital Converter) under the IIO (Industrial I/O) subsystem. It specifically deals with a missing check after calling of_match_device() in the stm32_adc_probe() function.

Even though attackers can't currently exploit this bug under normal circumstances, let's dive into what happened, why it matters, and how kernel devs fixed it.

Using a NULL pointer causes a kernel crash (NULL pointer dereference).

- There’s no known real-world way to trigger this bug currently, but in software, it’s always best to fix vulnerabilities before someone finds a way to trigger them maliciously.

Vulnerable Code Example

Here’s a simplified version of what the buggy code looked like in drivers/iio/adc/stm32-adc-core.c:

static int stm32_adc_probe(struct platform_device *pdev)
{
    const struct of_device_id *match;
    // ...

    match = of_match_device(stm32_adc_of_match, &pdev->dev);
    const struct stm32_adc_ops *ops = match->data; // BAD: match might be NULL!

    // ... use "ops" assuming match is never NULL, not safe!

    return ;
}

If of_match_device() did fail (rare, but possible), match would be NULL, and dereferencing it would cause an oops or panic.

The Patch: Adding a NULL Check

The fix is straightforward: add a NULL check before using the pointer. Here’s what the improved, hardened code looks like:

static int stm32_adc_probe(struct platform_device *pdev)
{
    const struct of_device_id *match;
    // ...

    match = of_match_device(stm32_adc_of_match, &pdev->dev);
    if (!match) {
        dev_err(&pdev->dev, "Failed to find device match\n");
        return -ENODEV;
    }

    const struct stm32_adc_ops *ops = match->data; // SAFE: match validated.

    // ... rest of the probe code

    return ;
}

By checking for NULL and returning an error, the kernel remains safe, even if the function somehow starts returning NULL in the future.

Why fix a bug no one can currently trigger in real life? Here’s why

- Defense in depth: Small errors today can be entry points for major attacks tomorrow, especially if other changes make the bug triggerable.

How Would An Exploit Work? (Hypothetical)

Right now, there is "no known reasonable way to trigger this," according to upstream Linux maintainers. But think about a future where, by specializing the device tree or changing how drivers are loaded, an attacker manages to have of_match_device() return NULL. This could:

Open the door for more creative exploits as kernel structures change.

That’s why this sort of “preemptive hardening” is so important.

References

- CVE-2023-52802: NVD Summary Page

Linux commit fixing the vulnerability:

https://github.com/torvalds/linux/commit/7e1181a39e01a1dfd5e14dff7b3eaec3e47d8ec
(Or search for the commit message: iio: adc: stm32-adc: harden against NULL pointer deref in stm32_adc_probe())

Linux kernel source (STM32 ADC driver):

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/iio/adc/stm32-adc-core.c

Bottom Line

CVE-2023-52802 shows how even “untouchable” code can benefit from extra safety checks. By simply validating a pointer, Linux maintainers added another layer of reliability to devices using STM32 microcontrollers. Security isn't just about fixing big bugs—sometimes, it's the attention to small, theoretical issues that really pays off.

For everyone writing drivers or kernel code: never assume a function can't fail. A simple pointer check can save you a world of trouble down the road.

Timeline

Published on: 05/21/2024 16:15:18 UTC
Last modified on: 05/24/2024 01:14:17 UTC