Summary:
_CVE-2021-47631_ is a vulnerability resolved in the Linux kernel affecting ARM-based boards, notably the DA850 EVM (Evaluation Module). The bug could lead to a kernel panic (system crash) due to a null pointer dereference when the kernel is running on unsupported hardware, especially under emulation or with certain toolchains.

Background and Discovery

The vulnerability was discovered when running the kernel with the multi_v5_defconfig configuration in QEMU, using the palmetto-bmc emulation machine. Newer versions of GCC triggered a kernel panic due to a NULL pointer dereference in the da850_evm_config_emac() function:

Unable to handle kernel NULL pointer dereference at virtual address 00000020
pgd = (ptrval)
[00000020] *pgd=00000000
Internal error: Oops: 5 [#1] PREEMPT ARM
Modules linked in:
CPU:  PID: 1 Comm: swapper Not tainted 5.15. #1
Hardware name: Generic DT based system
PC is at da850_evm_config_emac+x1c/x120
LR is at do_one_initcall+x50/x1e

The crash happens because the function assumes certain device-specific data pointers are valid, which isn’t the case on all machines the kernel can boot on.

Technical Roots of the Issue

The DA850 EVM board-specific initialization function, da850_evm_config_emac(), was being called for all machines as part of device_initcall(), not just DA850-based hardware:

static int __init da850_evm_config_emac(void)
{
    ...
    soc_info = soc_device_match(da850_soc_devices);
    rmii_en = soc_info->emac_pdata->rmii_en; // <--- soc_info->emac_pdata is NULL on non-DA850 hardware
    ...
}

Problem:
- On unsupported hardware runs, such as under QEMU or with certain dev configs, soc_device_match returns a soc_info struct with a NULL emac_pdata pointer.
- The code immediately dereferences soc_info->emac_pdata->rmii_en, causing a kernel Oops (fatal error).

The Fix

The maintainers moved the assignment and usage of the rmii_en pointer below a check confirming that the SOC is actually supported:

static int __init da850_evm_config_emac(void)
{
    ...
    soc_info = soc_device_match(da850_soc_devices);
    if (!soc_info)
        return -ENODEV;

    /* Only dereference emac_pdata if soc_info is valid */
    rmii_en = soc_info->emac_pdata->rmii_en;
    ...
}

In short: Now, the code checks if soc_info is non-NULL before touching emac_pdata, preventing the crash.

What could an attacker do?

- Likelihood of remote exploitation: Low. This is a local bug—triggered during system boot by the kernel itself, not easily by remote code.

Local impact:

- On affected capsuled or embedded devices with DA850 code active on unsupported platforms, or when misconfigured, an attacker could repeatedly crash the device by causing boots to hit this path.
- This might be used for local denial-of-service by a user with physical or privileged access (e.g., in a multi-tenant testing environment on ARM platforms).

Proof of concept

Simply running the kernel on a palmetto-bmc QEMU machine with inappropriate configs will trigger the bug:

Observe the kernel panic above.

No complex input or escalation is required; it will crash on boot.

Practicality

This is a bug triggered by kernel and board configuration mismatch. It's unlikely to be a main avenue for security-focused attackers, but it can cause a denial of service, notably in test pipelines or misconfigured devices.

Fixed in:

- Linux mainline commit 1f383dcc1754 (Link)

References:

- LKML Patch Discussion
- CVE record

Here’s the essence of the patch

- soc_info = soc_device_match(da850_soc_devices);
- rmii_en = soc_info->emac_pdata->rmii_en;
+ soc_info = soc_device_match(da850_soc_devices);
+ if (!soc_info)
+     return -ENODEV;
+ rmii_en = soc_info->emac_pdata->rmii_en;

Prevention and Mitigation

- Update your kernel on ARM-based boards to a version including this fix (post-5.15-stable or relevant vendor backport).
- Only enable board-specific code (da850-evm and similar) on systems you know will run on that hardware, or ensure defconfigs do not run untested hardware paths.
- When writing device initcall functions, always check for valid pointers from match functions before using them.

Conclusion

While not an RCE or privilege escalation, CVE-2021-47631 is a good example of how cross-platform, board-specific code in the Linux kernel can introduce instability and reliability issues—even kernel panics—if not carefully checked. It’s also a great reminder for kernel and driver authors to defensively check all pointers, especially when mixing SoC and device-specific codepaths.

- Patch in mainline repo
- CVE Record
- Full Discussion on LKML

If you use or test ARM hardware with custom or broad Linux configs, be sure to keep your tree updated!

Timeline

Published on: 02/26/2025 06:37:04 UTC
Last modified on: 03/18/2025 19:35:26 UTC