CVE-2021-47006

What it actually does

The missed update after perf_event_alloc began setting a default overflow_handler means bp->overflow_handler is never NULL, so enable_single_step is never called for ARM hardware breakpoints.

Why it matters to the business

ARM Linux systems may experience unreliable hardware breakpoint and single-step behavior in debuggers, tracers, or security tooling, increasing operational risk for development and monitoring workloads.

How an attack unfolds

An attacker or legitimate user configures a hardware breakpoint via perf; because the default handler is always present the kernel skips enable_single_step, leaving the breakpoint in an incorrect state that can cause missed events or incorrect kernel behavior.

How to fix it

Apply the upstream commit 9064/1 (or equivalent backport) that replaces the direct overflow_handler check with is_default_overflow_handler; rebuild and boot the fixed kernel on affected ARM systems.

How to confirm the fix worked

Confirm the is_default_overflow_handler call is present in the hw_breakpoint enable path; test breakpoint single-step functionality with perf or kgdb on ARM after the update.

Typical attack path

1. Attach perf hardware breakpoint event on ARM
2. Kernel allocates event and installs default overflow_handler
3. Breakpoint enable path checks overflow_handler and skips enable_single_step
4. Single-step mode is never activated for the breakpoint

How to detect it

Search kernel logs and perf traces for unexpected breakpoint behavior or missing single-step events on ARM; no specific post-exploitation artifacts are known.

What your security team should do

• Prioritize kernel update on ARM servers and embedded devices that rely on perf breakpoints or hardware watchpoints
• Monitor upstream stable kernel releases for the backported fix
• Review any custom breakpoint or perf tooling that may be affected by the handler change