In early 2021, a security issue was identified and resolved in the Linux kernel. This vulnerability affected ARM systems using hardware breakpoints—a critical feature used in debugging and performance monitoring. The problem, now cataloged as CVE-2021-47006, could impact system stability and security. In this post, we’ll break down what went wrong, how it was fixed, and what it means for users and administrators.

1. Background: What are Hardware Breakpoints and Overflow Handlers?

In the context of Linux on ARM processors, "hardware breakpoints" are used primarily for monitoring execution flow, such as when debugging or profiling a running system. These breakpoints are monitored through the Linux performance event (perf event) subsystem, which allows the kernel to track specific activities.

- Overflow Handlers: Whenever a tracked event crosses a threshold (like a counter rolling over), an "overflow handler" function is called to handle the situation—logging, stepping, stopping, etc.

Let’s walk through what went wrong.

Previously, the kernel checked if event->overflow_handler was set (non-NULL) directly, to decide if a breakpoint’s handler should run. But, in kernel commit 1879445dfa7b, a default handler was introduced and event->overflow_handler was never NULL anymore. Instead of checking for NULL, kernel code was supposed to check if the handler was the "default" one using a helper function called is_default_overflow_handler().

Unfortunately, there was one spot—in the ARM code handling hardware breakpoints—where the check was still done via a direct NULL check:

if (!bp->overflow_handler)
    enable_single_step(bp, regs, info);

After the kernel changes, bp->overflow_handler is *never* NULL, so the block never runs and enable_single_step() is never called.

Why is This Bad?

- Certain hardware breakpoints, which rely on single-stepping (handling one instruction at a time after a hit), stopped functioning properly.

3. The Vulnerability: CVE-2021-47006

Link: NVD - CVE-2021-47006

The flaw was assigned CVE-2021-47006. It was not directly a privilege escalation bug or remote code execution hole, but rather a logical error causing part of the hardware breakpoint logic not to execute when expected. In rare cases, this could:

4. How Was It Fixed?

The fix was contributed by Zhen Lei (original patch discussion here), and merged to mainline Linux.

Core Change:
Instead of checking bp->overflow_handler != NULL, the code now calls !is_default_overflow_handler(bp->overflow_handler).

Before (Vulnerable)

if (!bp->overflow_handler)
    enable_single_step(bp, regs, info);

After (Patched)

if (!is_default_overflow_handler(bp->overflow_handler))
    enable_single_step(bp, regs, info);

This ensures enable_single_step() is only called for non-default (custom) handlers, as intended.

Reference:
- Linux ARM Hardware Breakpoint Patch on Patchwork
- Fix Commit in Kernel Source

Can this issue be exploited?

- Not directly for privilege escalation: It does not, by itself, allow code exec or privilege gain.
- Indirect security risk: If your defense, auditing, or tracing tools depend on single-stepping hardware breakpoints (such as for detecting exploits or kernel rootkits), they may silently fail to activate correctly. An attacker might exploit this gap—by relying on missing debug-triggered protections.

Proof-of-Concept

You could demonstrate the vulnerability by setting a hardware breakpoint via perf or gdb on an affected ARM kernel (before the patch). The breakpoint will not fire the single-step handler, making certain traces or debug actions ineffective.

Example snippet

# Set a hardware breakpoint via perf or a kernel module
perf record -e 'mem:x100:r' ./test-program
# The expected single-stepping after the hit never occurs!

Real attack scenarios would depend on system usage and defense-in-depth features.

ARM only: x86 or other architectures are not affected by this particular bug.

- Linux kernel versions: Check if your kernel is based on a version before the patch was merged (mainline fix in April 2021).
- Security-conscious setups: If you rely on hardware breakpoints for debugging or security, update!
- General servers/desktops: Less critical, unless you do kernel-level debugging.

7. Getting Protected

- Update your kernel to a version including the fix (after April 2021).
- Check with your distro: If you use a packaged kernel on Debian, Ubuntu, CentOS, etc., look for security advisories referencing CVE-2021-47006.

8. Summary for Admins

- What happened? Old Linux ARM kernels had a bug in hardware breakpoint handling after a perf event change, silencing some breakpoint actions.
- Can it be exploited? Mainly results in missed debug/tracing actions; not a direct attack, but a possible vector for defense evasion.
- How to fix: Upgrade your kernel past commit 910da25b.

Extra reading:

- Original Patch by Zhen Lei
- Kernel Commit
- NVD CVE Entry

9. Final Thoughts

This bug is a reminder that even small logic errors can undermine kernel-level security and debugging features. If you rely on hardware breakpoints for your ARM systems, double-check your kernel version and patch level. Staying updated protects you not just from "big" vulnerabilities, but also from these subtle logic hiccups that can have serious ripple effects.


*Feel free to share this post, and comment below if you have questions about detecting this bug or verifying your kernel.*

Timeline

Published on: 02/28/2024 09:15:38 UTC
Last modified on: 11/07/2024 16:35:03 UTC