CVE-2026-64520

What it actually does

This is a Linux kernel memory-corruption flaw in the ARM FF-A firmware driver. The vulnerable PARTITION_INFO_GET register-based path trusted firmware-supplied descriptor counts and fragment indexes while copying partition descriptors into a kernel-allocated caller buffer. If those values are inconsistent, the kernel copy loop can write past the end of the allocated array. On affected ARM systems using the arm_ffa firmware interface, this can cause kernel memory corruption, potentially leading to local privilege escalation, kernel crash, or loss of confidentiality/integrity/availability.

Why it matters to the business

Successful exploitation can give an attacker who already has local code execution on an affected ARM Linux system a path to crash the host or potentially gain kernel-level control. For organizations running ARM-based servers, appliances, edge devices, mobile/embedded Linux platforms, or virtualized environments that rely on FF-A firmware services, the operational risk is high because kernel compromise can undermine isolation, expose sensitive data, and require host rebuilds. The issue is not currently listed in CISA KEV, has no known mature public exploit, and has a low EPSS score, but the CVSS impact is high because exploitation affects the kernel security boundary.

How an attack unfolds

An attacker first obtains the ability to run code locally on an affected ARM Linux system. They then trigger code paths that cause the kernel arm_ffa driver to request FF-A partition information through the register-based PARTITION_INFO_GET mechanism. If the firmware or FF-A response path provides inconsistent descriptor counts or fragment index progression, the vulnerable kernel code may copy more partition descriptors than the destination array can hold. That out-of-bounds write corrupts adjacent kernel memory. Depending on kernel build options, memory layout, mitigations, and attacker control over the corrupted data, the result may be an immediate kernel panic or a more controlled privilege-escalation primitive. No public exploitation campaign or named threat actor activity is currently associated with this vulnerability.

How to fix it

Upgrade to a Linux kernel version or vendor-provided kernel package that includes the fix for the arm_ffa PARTITION_INFO_GET bounds-checking issue. Because no fixed package versions were provided in the input, use the affected distribution, appliance, or device vendor advisory as the source of truth for the corrected kernel build. Prioritize ARM systems that expose or depend on FF-A firmware services. If immediate patching is not possible, reduce local code-execution exposure by restricting shell access, container escape opportunities, untrusted workloads, and user access to interfaces that can trigger FF-A/TEE-related operations. Reboot into the patched kernel after installation; merely installing the package is insufficient if the vulnerable kernel remains running.

How to confirm the fix worked

Confirm that systems are running a patched kernel, not only that a patched package is installed. Validate with the vendor advisory, kernel package changelog, or source tree that the arm_ffa firmware fix for bounded PARTITION_INFO_GET register copies is present. On Linux hosts, compare the running kernel from `uname -a` or `/proc/version` against the vendor-fixed kernel release, and verify the booted kernel after reboot. For source-based kernels, inspect the arm_ffa firmware driver changes to ensure inconsistent partition descriptor counts and fragment index progressions are rejected before descriptor copying. Also verify whether the system is ARM-based and whether the arm_ffa driver or FF-A firmware interface is present, since non-ARM systems and systems not using FF-A are unlikely to be exposed.

Typical attack path

1. Gain local code execution on an affected ARM Linux system.
2. Identify that the running kernel includes the vulnerable arm_ffa PARTITION_INFO_GET register-based implementation and that FF-A firmware services are present.
3. Trigger FF-A partition discovery or a subsystem that invokes the vulnerable PARTITION_INFO_GET path.
4. Cause or rely on inconsistent firmware-provided descriptor counts or index progression during fragmented partition-info handling.
5. Induce an out-of-bounds kernel write during descriptor copying.
6. Use the resulting kernel memory corruption to crash the system or attempt privilege escalation to kernel/root level.

How to detect it

There are no widely published exploit indicators or known threat-actor campaigns for this issue. Detection should focus on signs of attempted or successful kernel memory corruption on affected ARM systems. Review kernel logs, persistent journal entries, serial console output, crash dumps, hypervisor logs, and endpoint telemetry for arm_ffa or FF-A activity followed by Oops, panic, KASAN, slab corruption, or unexpected reboot events. Correlate crashes with local user activity, container workload starts, firmware/TEE interactions, or suspicious processes running shortly before the event. Preserve vmcore/kdump artifacts where available and compare the crashing kernel version against vendor-fixed releases. Because exploitation may result only in a kernel crash or unstable memory corruption, absence of a clear application-layer log entry does not rule out exploitation.

• arm_ffa
• ffa_partition_info_get
• PARTITION_INFO_GET
• KASAN: slab-out-of-bounds
• KASAN: out-of-bounds
• BUG: unable to handle kernel paging request
• Unable to handle kernel paging request at virtual address
• Internal error: Oops
• Kernel panic - not syncing
• general protection fault
• kernel BUG at
• slab-out-of-bounds
• memory corruption
• arm_ffa:

What your security team should do

• Inventory ARM Linux systems, appliances, edge devices, and embedded platforms that run kernels with the arm_ffa firmware driver or FF-A firmware support.
• Prioritize patching internet-adjacent, multi-user, container-hosting, edge, and high-availability ARM systems where local code execution by less-trusted users or workloads is plausible.
• Apply vendor kernel updates containing the fix and reboot systems into the corrected kernel.
• If patching is delayed, limit local interactive access and reduce the ability of untrusted users, containers, or workloads to invoke firmware/TEE-related interfaces.
• Monitor kernel logs for crashes, Oops events, KASAN reports, or memory-corruption messages involving arm_ffa or FF-A partition discovery.
• For high-assurance environments, treat unexplained kernel memory-corruption crashes on affected ARM systems as potentially security-relevant and preserve logs, crash dumps, and kernel versions for forensic review.