CVE-2026-90270

What it actually does

The arm_mpam driver allows unbinding the final MSC for a component, freeing the mpam_component structure while the resctrl filesystem still holds references; subsequent reads of the schemata file invoke resctrl_arch_get_config() on the freed object, producing a classic use-after-free.

Why it matters to the business

Systems running the affected kernel on ARM platforms with MPAM hardware can experience crashes or memory corruption when administrators or scripts manipulate resctrl or driver bindings, raising the risk of denial of service or privilege escalation in shared or containerized environments.

How an attack unfolds

An attacker with sufficient privileges to write to the driver’s sysfs unbind attribute removes the last MSC for a component, triggering free of the mpam_component; the attacker then reads the resctrl schemata file, causing the kernel to dereference the now-freed structure and potentially control execution flow.

How to fix it

Apply the upstream fix that removes the unbind sysfs interface for the arm_mpam driver; rebuild and deploy the patched kernel; until the patch is installed, avoid any manual unbind operations on MPAM devices and restrict write access to the relevant sysfs paths.

How to confirm the fix worked

Confirm the kernel source contains the commit that deletes the unbind attribute creation; verify that /sys/.../unbind no longer exists for arm_mpam devices; run regression tests that attempt unbind followed by schemata reads and confirm no use-after-free warnings appear in the kernel log.

Typical attack path

1. Obtain privileges to modify sysfs entries under the arm_mpam driver
2. Write to the unbind attribute for the final MSC of a component
3. Trigger resctrl_arch_get_config() by reading the resctrl schemata file
4. Leverage the resulting use-after-free for memory corruption or code execution

How to detect it

Search kernel logs and audit trails for writes to arm_mpam unbind attributes followed immediately by reads of resctrl schemata files; look for slab-use-after-free or KASAN reports mentioning mpam_component; correlate with resctrl filesystem activity around the time of any driver unbind events.

• write.*unbind.*arm_mpam
• resctrl_arch_get_config
• mpam_component
• slab_use_after_free.*mpam

What your security team should do

• Prioritize patching kernels on all ARM MPAM systems within the next maintenance window
• Audit resctrl and sysfs permissions to ensure only trusted processes can modify bindings
• Monitor kernel logs for use-after-free warnings related to mpam_component
• Test the patched kernel in a staging environment before broad deployment