CVE-2026-43416

What it actually does

CVE-2026-43416 is a local denial-of-service flaw in the Linux kernel on PowerPC systems involving the perf subsystem's user call-chain collection path. When perf/BPF stack collection attempts to read a user call chain after the current task's memory descriptor has already been released, the kernel can dereference a NULL current->mm pointer and panic. The impact is loss of availability of the affected host; the vulnerability is not described as enabling privilege escalation, code execution, or data disclosure.

Why it matters to the business

An authenticated local user, container workload, or process with the ability to exercise perf/BPF profiling paths could crash an affected PowerPC Linux system, causing service interruption, workload failure, node reboot, or cluster capacity loss. The CVSS score is moderate, EPSS is very low, it is not listed in CISA KEV, and no public exploit maturity is reported, so prioritization should focus on exposed multi-user, shared compute, CI, HPC, and production PowerPC environments where local crashes have operational impact.

How an attack unfolds

An attacker first needs local execution capability on an affected PowerPC Linux host. They then trigger perf user call-chain collection through a profiling or tracing path, such as a BPF program that calls stack-collection helpers during perf events. By arranging for the target task's memory descriptor to be unavailable when the kernel attempts to collect the user call chain, the vulnerable kernel path reads through a NULL current->mm pointer. This causes a kernel oops/panic and results in denial of service. Exploitation is local and availability-focused; there is no indication from the advisory that remote network access alone is sufficient or that exploitation provides elevated privileges.

How to fix it

Upgrade the Linux kernel to a vendor-provided release that includes the upstream fix adding a current->mm NULL check in the PowerPC perf user call-chain path. Because exact fixed package versions were not provided, use the relevant distribution or appliance vendor advisory for the corrected kernel version. Where immediate patching is not possible, reduce exposure by restricting untrusted local access, limiting perf/eBPF use to trusted administrators, disabling or tightening unprivileged BPF and perf access where supported, and applying kernel hardening controls such as setting kernel.perf_event_paranoid to a restrictive value and disabling unprivileged BPF if not required. Validate mitigation settings carefully because operational observability tools may depend on perf or BPF functionality.

How to confirm the fix worked

Confirm that affected systems are PowerPC Linux hosts running a kernel version older than the vendor-fixed release. Verify the installed kernel package against the distribution advisory and reboot into the patched kernel after upgrade. Confirm runtime kernel version with uname -a and package manager queries. For mitigation validation, check sysctl settings that restrict perf and unprivileged BPF, such as kernel.perf_event_paranoid and kernel.unprivileged_bpf_disabled where available. Review whether profiling tools such as perf, bcc-tools, BPF-based agents, or custom eBPF programs can still trigger user stack collection from untrusted contexts. In a non-production test environment only, reproduce the previously failing perf/BPF profiling workload and confirm it no longer causes kernel oops or panic.

Typical attack path

1. Gain local code execution on an affected PowerPC Linux system, such as through a user shell, compromised workload, or permitted local job execution.
2. Use perf, eBPF, or a tracing/profiling mechanism that requests user stack or call-chain collection.
3. Trigger the vulnerable perf_callchain_user path while the current task no longer has a valid memory descriptor.
4. Cause a NULL pointer dereference in the kernel perf subsystem.
5. Force a kernel oops or panic, interrupting service availability until the system recovers or is rebooted.

How to detect it

Look for evidence of kernel crashes or oops events on PowerPC Linux systems that mention perf user call-chain handling or BPF stack collection. Relevant sources include journald, /var/log/kern.log, /var/log/messages, dmesg output, crash dump storage, kdump/vmcore records, audit logs for perf_event_open or BPF activity, and EDR telemetry showing execution of perf, bcc-tools, bpftrace, or custom eBPF loaders shortly before a crash. Search for call traces containing perf_callchain_user_64, perf_callchain_user, get_perf_callchain, bpf_get_stackid, and BPF perf event program names. Also look for the kernel messages shown in the advisory, including NULL pointer dereference on read and kernel attempted to read user page. Correlate these events with local users, containers, cron jobs, CI tasks, observability agents, or profiling sessions active immediately before the panic. Because this vulnerability results in a crash rather than persistent compromise, durable artifacts may be limited to kernel logs, crash dumps, audit records, and command/process execution history before reboot.

• Kernel attempted to read user page
• BUG: Kernel NULL pointer dereference on read
• Kernel access of bad area
• perf_callchain_user_64
• perf_callchain_user
• get_perf_callchain
• bpf_get_stackid
• bpf_prog_
• do_perf_event
• profile.py
• bcc-tools
• /var/crash
• /var/lib/systemd/coredump
• /proc/sys/kernel/perf_event_paranoid
• /proc/sys/kernel/unprivileged_bpf_disabled

What your security team should do

• Inventory PowerPC Linux systems and identify those running kernels without the vendor fix.
• Prioritize patching shared, multi-tenant, production, HPC, CI/CD, and container-host systems where local users or workloads can run profiling, tracing, or eBPF code.
• Apply the fixed kernel from the operating system or platform vendor and ensure hosts are rebooted into the corrected version.
• Until patched, restrict local shell/job access to trusted users and limit capabilities that allow perf, BPF, or advanced tracing operations.
• Set restrictive perf/eBPF sysctl controls where operationally feasible, including kernel.perf_event_paranoid and unprivileged BPF restrictions.
• Monitor for kernel oops/panic events referencing perf_callchain_user, get_perf_callchain, bpf_get_stackid, or BPF perf event programs.
• Treat unexpected crashes on affected PowerPC hosts as possible local denial-of-service attempts and preserve kernel logs for forensic review.