Cloudanix VulnDB

CVE-2026-90306

None

CVSS

—

EPSS

0.2%

Published

Sep 17, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A fix ensures that certain debugging breakpoints on ARM Linux systems work properly for regular programs instead of being blocked by an always-on handler.

Exploitation
Other
Attacker needs
Local User
Complexity
Theoretical
Impact
Other
Component
OS kernel
Class
Other
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Unconditionally registered hw_breakpoint_cfi_handler on ARM stole breakpoint type 0x03 (ARM_ENTRY_CFI_BREAKPOINT) even when CFI was disabled, causing hw_breakpoint_pending to never return the unhandled fault path required for userspace breakpoints.

Why it matters to the business

On ARM Linux systems, debugging tools, fuzzers, and user-mode crash handlers that rely on that breakpoint type could fail silently, increasing troubleshooting time and potentially masking memory-safety issues during development or testing.

How an attack unfolds

An attacker or test harness issues a type-0x03 breakpoint from userspace or a non-CFI kernel context; the stub handler claims it, the fault is marked handled, and userspace never receives the expected signal or crash report, allowing continued execution or evasion of instrumentation.

How to fix it

Apply the upstream commit that removes the unconditional stub (ARM 9481/2) so the breakpoint is only claimed when CFI is actively enabled; rebuild and deploy the fixed kernel on affected ARM systems.

How to confirm the fix worked

Boot the patched kernel, confirm CFI is disabled, issue a type-0x03 breakpoint via LKDTM or a userspace debugger, and verify the fault propagates to userspace as an unhandled breakpoint.

Typical attack path

  1. Trigger a breakpoint instruction of type 0x03 from userspace or non-CFI kernel path
  2. hw_breakpoint_cfi_handler intercepts and returns without propagating the fault
  3. Userspace receives no signal or debug event, allowing continued execution or masking of crashes

How to detect it

Review kernel boot logs and dmesg for references to hw_breakpoint_cfi_handler; on unpatched systems, attempts to use type-0x03 breakpoints will show no userspace signal delivery in strace or debugger output.

What your security team should do

  • Prioritize patching ARM-based Linux kernels that ship this stub handler
  • Verify that custom or LTS kernels include the equivalent change before deployment
  • Re-test debugging and fuzzing workflows that rely on breakpoint type 0x03 after the update

The record

In the Linux kernel, the following vulnerability has been resolved: ARM: 9481/2: breakpoint: CFI breakpoints only on demand This removes the stub hw_breakpoint_cfi_handler() from ARM, making it not steal breakpoint type 0x03 (ARM_ENTRY_CFI_BREAKPOINT) unless CFI is actively used in the kernel. When not instrumenting with CFI, or when a breakpoint is issued in userspace, we fall through to return 1 from hw_breakpoint_pending() "unhandled fault" so userspace can make use of this breakpoint. Tested with LKDTM and this command line: echo CFI_FORWARD_PROTO > /sys/kernel/debug/provoke-crash/DIRECT still works as expected.

Affected packages

Ecosystem Package Introduced Fixed