CVE-2026-43150

What it actually does

This is a local Linux kernel memory-corruption flaw in the ARM CMN perf driver. The vulnerable driver can accept unknown CMN models or unknown revisions of known CMN hardware and then apply internal assumptions about maximum topology sizes, node counts, and array bounds. On unsupported hardware configurations, those assumptions may be wrong, leading to out-of-bounds memory access or array overflow in kernel context. Successful exploitation can compromise kernel memory integrity and may allow local privilege escalation, information disclosure, or denial of service. The issue is limited to systems using affected Linux kernels on ARM platforms with the relevant CMN interconnect/perf driver exposure.

Why it matters to the business

An attacker who already has local access to an affected ARM Linux system may be able to crash the system or potentially gain elevated privileges, which could lead to service disruption or full host compromise. The current EPSS is very low and stable, the issue is not listed in CISA KEV, and no public exploit maturity is indicated, so broad opportunistic exploitation is not currently expected. However, kernel memory-corruption flaws should still be prioritized on exposed multi-user systems, shared compute platforms, build hosts, appliances, and production ARM infrastructure because a successful exploit can bypass normal account boundaries.

How an attack unfolds

An attacker first obtains low-privileged local access to a vulnerable ARM Linux system where the ARM CMN perf driver is present and the hardware configuration is unsupported or not correctly recognized by the vulnerable kernel. The attacker then interacts with the kernel performance monitoring subsystem, typically through perf tooling or direct perf_event_open-style access, to exercise the arm-cmn driver paths that enumerate or program CMN nodes. Because the driver accepts an unsupported model or revision, it may calculate indexes or iterate structures using assumptions that are too small for the actual hardware layout. This can corrupt adjacent kernel memory. Depending on kernel layout, hardening, and reliability of the corruption primitive, the result may be a kernel crash, leakage of sensitive kernel data, or privilege escalation to root/kernel execution. Exploitation requires local privileges and the right hardware/driver conditions, which materially limits mass exploitability compared with remotely reachable kernel bugs.

How to fix it

Upgrade to a Linux kernel or vendor kernel package that includes the fix for the ARM CMN perf driver behavior, specifically the change that rejects unsupported CMN hardware configurations instead of attempting to run with unsafe assumptions. No exact fixed package versions were provided, so use the affected distribution or appliance vendor’s security advisory, kernel changelog, or backport notes to identify the corrected release. Where immediate patching is not possible, reduce exposure by restricting perf access to trusted administrators only, for example by setting kernel.perf_event_paranoid to the most restrictive supported value and requiring CAP_PERFMON, CAP_SYS_ADMIN, or equivalent administrative control for performance monitoring. If the arm_cmn driver is modular and not required, unload or blacklist the module until patched. For built-in drivers, consider disabling related perf/PMU functionality through platform policy or boot-time configuration if supported. Prioritize remediation on ARM servers, appliances, or shared systems where untrusted local users can execute code.

How to confirm the fix worked

Confirm the running kernel is a vendor-fixed build by checking the distribution advisory, package changelog, or kernel source/backport notes for the ARM CMN change that rejects unsupported hardware configurations. Verify the active kernel version with uname -r and ensure the system has rebooted into the fixed kernel, not merely installed it. On systems with the driver present, review dmesg or journalctl -k output after boot: fixed behavior should reject unsupported CMN models, revisions, or node types rather than continuing to initialize them with warnings. Confirm perf access is restricted as intended by checking sysctl kernel.perf_event_paranoid and by testing whether an unprivileged account can create perf events. If the driver is mitigated by removal, verify it is not loaded with lsmod and that blacklist or boot configuration persists across reboot.

Typical attack path

1. Gain local access to an affected ARM Linux system as an unprivileged or low-privileged user.
2. Confirm that the ARM CMN perf driver is present and that unprivileged or delegated perf access is available.
3. Trigger CMN perf enumeration or event programming through perf tooling or equivalent perf_event_open interactions.
4. Cause the vulnerable driver to process an unsupported CMN model, revision, or topology that violates its internal size assumptions.
5. Exploit the resulting out-of-bounds kernel memory corruption to crash the host, disclose data, or attempt privilege escalation.

How to detect it

Retrospective detection should focus on evidence of local attempts to exercise the ARM CMN perf driver and signs of kernel memory corruption. Review kernel logs from dmesg, journalctl -k, /var/log/kern.log, and /var/log/messages for arm-cmn initialization warnings, unsupported CMN hardware messages, unknown node type errors, kernel oopses, BUG splats, panics, KASAN reports, or crashes temporally associated with perf usage. If auditd, eBPF telemetry, or EDR process telemetry is available, search for non-administrative execution of perf, perf_event_open system calls, unusual access to PMU-related sysfs paths, or performance-monitoring commands shortly before kernel instability. On multi-user systems, correlate suspicious perf activity with privilege changes, new setuid files, unexpected root shells, modified kernel modules, or persistence artifacts. There are no known public threat actors or ransomware campaigns associated with this CVE in the supplied intelligence, and exploitation artifacts are likely to be host-specific rather than network-visible.

• arm-cmn
• arm_cmn
• perf_event_open
• /sys/bus/event_source/devices/arm_cmn
• /sys/bus/event_source/devices/arm-cmn
• unsupported CMN
• unknown CMN
• Unknown CMN
• unknown node type
• Unknown node type
• kernel: Oops
• BUG: kernel
• kernel panic
• KASAN:
• general protection fault
• Unable to handle kernel paging request
• perf stat
• perf record
• perf top

What your security team should do

• Inventory ARM Linux systems and identify where the arm_cmn perf driver or ARM CMN PMU support is present.
• Prioritize kernel updates for shared ARM hosts, production appliances, CI/build workers, container hosts, and any system where untrusted local users can run code.
• Restrict unprivileged perf access until all affected systems are patched, and review exceptions granted through CAP_PERFMON, CAP_SYS_ADMIN, privileged containers, or performance-monitoring agents.
• If the driver is not operationally required and is modular, blacklist or unload arm_cmn as a temporary mitigation.
• Monitor kernel logs for arm-cmn errors, unsupported CMN hardware messages, kernel oopses, and suspicious perf_event_open activity from non-administrative users.
• Because the CVE is not in KEV, has very low stable EPSS, and has no known public exploit maturity, treat this as important defense-in-depth rather than an emergency internet-scale incident unless local untrusted access exists.