CVE-2026-53114

What it actually does

This flaw is a Linux kernel denial-of-service issue in the AMD Instruction-Based Sampling (IBS) performance monitoring path. The vulnerable code can call perf_allow_kernel() from a non-maskable interrupt (NMI) handler, which is unsafe in that execution context and can cause a fatal kernel failure. Systems using affected Linux kernels on AMD hardware with IBS/perf functionality are the relevant exposure area. The practical impact is kernel instability or crash when IBS perf events are exercised under vulnerable conditions.

Why it matters to the business

Successful exploitation can crash affected Linux systems, causing service interruption, workload failure, and potential loss of availability for applications running on those hosts. The risk is highest for multi-user Linux systems, shared compute platforms, build servers, research/HPC environments, and any environment where users or workloads are allowed to create performance monitoring events. This issue is not known to be in CISA KEV, is not known to be used in ransomware campaigns, and currently has very low EPSS likelihood, so remediation should be prioritized as part of normal kernel maintenance unless the affected systems expose perf access to untrusted local users or tenants.

How an attack unfolds

An attacker first needs the ability to run code locally on a vulnerable Linux system, or otherwise cause creation of relevant AMD IBS perf events. If kernel perf access policy allows the attacker to open performance monitoring events, they can attempt to configure IBS sampling so that the vulnerable NMI handler path is reached. When an IBS NMI fires, the vulnerable kernel may call perf_allow_kernel() from NMI context. Because that operation is unsafe in NMI context, the system can panic, lock up, or otherwise fail, producing a denial of service. There is no indication from the supplied intelligence that public weaponized exploitation is currently mature, and exploitation is primarily availability-focused rather than data theft or privilege escalation.

How to fix it

Upgrade to a Linux kernel version that includes the upstream fix for the AMD IBS perf NMI handling issue. The fix changes the implementation so that the perf_allow_kernel() permission decision is captured at event initialization time and cached in event->hw.flags, rather than being evaluated inside the NMI handler. If vendor fixed package versions are not yet identified, obtain patched kernels from the relevant Linux distribution or kernel vendor and monitor vendor advisories for backported fixes. As interim mitigation, restrict access to performance monitoring features on systems exposed to untrusted local users. Consider setting a restrictive kernel.perf_event_paranoid value, disabling unneeded perf access, limiting shell/job execution for untrusted users, and applying workload isolation controls. Where operationally feasible, limit AMD IBS usage until patched kernels are deployed.

How to confirm the fix worked

Confirm the running kernel includes the vendor or upstream patch for the AMD IBS perf NMI change. Validate by checking the installed kernel package changelog or vendor advisory for references to the AMD IBS/perf NMI fix. Confirm the active booted kernel is the patched version, not merely installed on disk. On Linux, compare `uname -r` with the patched package version from the distribution, and verify systems were rebooted after kernel installation. For mitigation validation, check perf restrictions with `sysctl kernel.perf_event_paranoid` and confirm untrusted users cannot create sensitive perf events. On AMD systems where IBS is used operationally, run controlled performance monitoring tests after patching to ensure perf functionality remains stable and no kernel warnings, oopses, or panics occur.

Typical attack path

1. Gain local code execution on an affected Linux system, such as through a shell, job scheduler, container escape-adjacent workload access, or compromised low-privilege account.
2. Check whether the system is AMD-based and whether perf events / IBS sampling can be accessed under current kernel policy.
3. Create or trigger AMD IBS perf events using perf_event_open-compatible tooling or custom code.
4. Drive sampling activity so that IBS NMIs are generated.
5. Trigger the vulnerable NMI handler path that calls an unsafe function from NMI context.
6. Cause a kernel panic, lockup, or fatal system instability, resulting in denial of service.

How to detect it

Detection should focus on signs of local attempts to exercise AMD IBS perf functionality followed by kernel instability. Review kernel logs, system journal, crash dumps, audit logs, and process execution telemetry. Useful sources include `journalctl -k`, `/var/log/kern.log`, `/var/log/messages`, `/var/log/syslog`, auditd execve records, EDR process telemetry, kdump/vmcore artifacts, and system watchdog/reset records. Look for use of `perf`, custom binaries invoking `perf_event_open`, AMD IBS-related kernel messages, NMI warnings, kernel oopses, soft/hard lockups, panics, or abrupt reboots. Correlate any crash with recent local user activity, job executions, container workloads, CI jobs, or benchmarking/profiling commands. Because this is a kernel availability flaw and no mature public exploitation is indicated, many detections will be circumstantial; the strongest signal is a crash or panic temporally associated with IBS/perf activity on an AMD system.

• perf record
• perf stat
• perf_event_open
• amd_ibs
• AMD IBS
• ibs_op
• ibs_fetch
• NMI handler
• kernel panic
• Kernel panic
• BUG: kernel NULL pointer dereference
• Oops:
• general protection fault
• hard LOCKUP
• soft lockup
• NMI watchdog
• perf/amd/ibs
• perf_allow_kernel
• /proc/sys/kernel/perf_event_paranoid
• /sys/bus/event_source/devices/ibs_op
• /sys/bus/event_source/devices/ibs_fetch
• /var/crash/
• /var/lib/systemd/coredump/

What your security team should do

• Inventory Linux systems running on AMD hardware, especially systems where local users, build jobs, CI workloads, containers, or research workloads can invoke perf or performance monitoring features.
• Prioritize patching shared or multi-tenant Linux hosts, HPC clusters, developer jump hosts, and systems with permissive perf_event settings.
• Deploy vendor-patched kernels when available and ensure systems are rebooted into the fixed kernel.
• As a temporary mitigation, restrict perf access using kernel.perf_event_paranoid and local access controls where untrusted users can execute code.
• Monitor kernel logs for NMI, perf, AMD IBS, kernel oops, panic, or lockup messages that may indicate attempted triggering or accidental exposure.
• Do not treat this as a remote code execution or data compromise issue based on current information; focus response on availability risk and local misuse prevention.
• Track distribution advisories for exact fixed kernel package versions because no product-specific fixed versions were supplied.