In this deep dive, we’ll break down CVE-2021-46909, a vulnerability found in the Linux kernel’s ARM Footbridge PCI interrupt handling. We’ll explore what caused the issue, how it was fixed, and what it means for users and system administrators. This explanation is exclusive and uses straightforward American English so you don’t need to be a kernel developer to follow along.

Impacted versions: Affected before the fix; check your distro’s release notes for details

- Fixed in: Kernel patches after the reported bug

Main risk: Kernel *oops* (crash) when PCI drivers are loaded after boot

- Severity: Potential Denial of Service (DoS), but exploitable only on relevant hardware/architectures

What Happened?

Linux supports a wide range of hardware, including many ARM boards using a “Footbridge” chipset. On these systems, connection between the CPU and PCI devices requires correct mapping of interrupts (IRQs), which are signals that let devices tell the CPU something needs attention.

A change in the Linux kernel in commit 30fdfb929e82 caused the kernel to call an IRQ mapping function every time a PCI driver is probed — not just at boot.

The catch? In the ARM Footbridge code, this IRQ mapping function was marked as __init. This tag tells the compiler that the function is only used during kernel initialization, so its code is thrown away after the system boots. If you try to call it later (like when loading a PCI driver as a module sometime after boot), it’ll crash the entire system. This is called an “oops” in kernel speak.

The Fix

Maintainers fixed this by removing the __init tag from the IRQ mapping function. This way, it remains available for the whole lifetime of the kernel, not just at boot.

Here is a simplified version of what changed.

Before

static int __init
footbridge_map_irq(const struct pci_dev *dev, u8 slot, u8 pin)
{
    // IRQ map logic
}

After

static int
footbridge_map_irq(const struct pci_dev *dev, u8 slot, u8 pin)
{
    // IRQ map logic, unchanged
}

Removing the __init makes sure this function is never discarded, so it can be called whenever needed — not just at startup.

Exploiting the Issue

It’s important to note that this is not a “remote exploit” in the traditional sense. Instead, an attacker or even just an administrator could trigger a kernel crash (oops) by loading a PCI driver (as a module or dynamically) after the system has booted. That would cause the kernel to call the now-missing code, leading to a crash.

Proof-of-concept (PoC) code would just be the act of loading a PCI driver as a module

modprobe some_footbridge_pci_driver

If the system oopses, you’re experiencing this bug.

References

- Original kernel commit that triggered the bug
- Kernel.org fix commit for ARM Footbridge
- Linux kernel CVE-2021-46909 on NVD

Should You Worry?

Only if you run Linux on ARM Footbridge hardware and regularly install or update PCI drivers after the system boots. Most people and even most cloud platforms are not affected. Embedded device vendors using this platform are most at risk.

Conclusion

CVE-2021-46909 is a classic example of how changes in one part of the kernel can ripple out and cause unexpected breakage elsewhere, especially in less-common hardware. The fix is straightforward — just don’t throw away code you’ll need later! Upgrade your kernel if you use ARM Footbridge systems.

For more technical and up-to-date details, always check the official Linux kernel git logs and your distribution’s security advisories.


*Exclusive, in-depth, and simplified for everyone; feel free to share or cite with credit!*

Timeline

Published on: 02/27/2024 07:15:07 UTC
Last modified on: 04/17/2024 16:57:37 UTC