CVE-2026-98546: arm64/boot: Disable trapping of PMZR_EL0 writes to EL2

Published Oct 18, 2026

Updated

In the Linux kernel, the following vulnerability has been resolved:

arm64/boot: Disable trapping of PMZREL0 writes to EL2

initel2fgt2() writes one mask to both HDFGRTR2EL2 and HDFGWTR2EL2. PMZREL0 is write-only, so its trap bit, nPMZREL0, exists only in HDFGWTR2EL2 and is therefore never set: a PMZREL0 write from the host traps to EL2, where the nVHE hypervisor has no handler and BUG()s. The kernel never writes PMZREL0, but kernel.perfuseraccess=1 has the PMU driver set PMUSERENREL0.UEN for a task with a user-read event, so a write from EL0 reaches the trap and takes the host down without a panic message.

Accumulate the HDFGWTR2EL2 bits separately, as initel2fgt() already does for HDFGWTREL2, and set nPMZREL0 with the other FEATPMUv3p9 bits.

Affected Software

1 affected component

Linux Linux kernel

Remediation

Recommended actions to resolve this vulnerability, in priority order.

Configuration
Disable trapping of PMZR_EL0 writes to EL2 by setting nPMZR_EL0 in HDFGWTR2_EL2.
Linux kernel arm64 EL2 fine-grained traps HDFGWTR2_EL2.nPMZR_EL0 = set

Event History

Oct 18, 2026

CVE Published

via MITRE·03:18 PM

Data Sourced

via MITRE·03:18 PM

Description

Data Sourced

via NVD·04:17 PM

Description

Frequently Asked Questions

Which systems are exposed to this issue?

The issue affects arm64 systems using the Linux kernel's nVHE hypervisor path, where PMZR_EL0 writes are trapped to EL2. It requires FEAT_PMUv3p9-related handling and a configuration that permits the relevant user PMU access.

What is required to trigger the failure?

A user-space task needs a user-read performance event while kernel.perf_user_access=1 causes the PMU driver to set PMUSERENR_EL0.UEN. A write to the write-only PMZR_EL0 register from EL0 can then trap to EL2, where the nVHE hypervisor has no handler and invokes BUG().

What is the operational impact of exploitation?

The host can be taken down by the trapped PMZR_EL0 write. The description notes that this occurs without a panic message.

Is the default kernel behavior affected?

The kernel itself does not write PMZR_EL0. The described trigger depends on kernel.perf_user_access=1 and a task with a user-read performance event, rather than ordinary kernel PMZR_EL0 use.

What mitigation is available if the fix cannot be applied immediately?

Avoid enabling kernel.perf_user_access=1 for workloads that could obtain user-read performance events. This removes the described condition in which the PMU driver enables PMUSERENR_EL0.UEN for the task.

CVE-2026-98546: arm64/boot: Disable trapping of PMZR_EL0 writes to EL2

Affected Software

Remediation

Event History

Frequently Asked Questions

Which systems are exposed to this issue?

What is required to trigger the failure?

What is the operational impact of exploitation?

Is the default kernel behavior affected?

What mitigation is available if the fix cannot be applied immediately?

Company

Resources

Contact

Frequently Asked Questions

Which systems are exposed to this issue?

What is required to trigger the failure?

What is the operational impact of exploitation?

Is the default kernel behavior affected?

What mitigation is available if the fix cannot be applied immediately?