CVE-2026-64166

What it actually does

This flaw is a NULL pointer dereference in the Linux kernel Arm Firmware Framework for Arm A-profile (FF-A) bus driver registration and matching logic. The FF-A bus match callback assumes each FF-A client driver supplies a valid ID table and dereferences it without checking. A malformed, buggy, or intentionally crafted FF-A client driver that registers without an ID table can cause the kernel to dereference NULL during device-driver matching, resulting in an Oops or kernel panic. The impact is denial of service rather than code execution based on the available information.

Why it matters to the business

Systems using affected Linux kernel builds on Arm platforms with FF-A support could be crashed if an invalid FF-A client driver is introduced, causing service interruption, reboot cycles, or loss of workload availability. Exploitation likelihood appears low because it generally requires the ability to load or register kernel-level driver code, and there is no known exploitation, KEV listing, or ransomware association at this time. The main operational risk is instability from vulnerable kernel builds combined with third-party, custom, or experimental FF-A-related kernel modules.

How an attack unfolds

An attacker would first need a path to introduce or cause registration of an FF-A client driver in the kernel, such as the ability to load a kernel module, abuse an already privileged management path, or influence deployment of a defective FF-A driver. The malicious or malformed driver omits the expected FF-A ID table and registers with the FF-A bus. When the kernel later performs FF-A bus device-driver matching, the match callback dereferences the missing ID table. Because the pointer is NULL, the kernel triggers a NULL pointer dereference, producing an Oops or panic depending on system configuration. The attacker’s practical outcome is system denial of service, not direct privilege escalation, unless combined with a separate vulnerability that provides the ability to load or manipulate kernel drivers.

How to fix it

Upgrade to a Linux kernel version from the relevant distribution or device vendor that includes the upstream fix enforcing the FF-A driver ID-table contract at registration time. Because no specific affected product or fixed package versions were provided, use vendor kernel advisories and changelogs for CVE-2026-64166 or the related Arm FF-A driver-registration fix. Where immediate patching is not possible, reduce exposure by preventing untrusted kernel module loading, disabling loading of unsigned modules, enforcing Secure Boot or kernel lockdown where supported, restricting administrative access, and avoiding unvalidated third-party or custom FF-A client drivers.

How to confirm the fix worked

Confirm the running kernel contains the fix by checking the vendor advisory, package changelog, or source tree for the Arm FF-A registration-side validation that rejects FF-A drivers with a missing ID table. Verify the running kernel version after reboot, not just the installed package version. On systems that support module signing or lockdown, validate that unsigned or untrusted kernel modules cannot be loaded. For exposure assessment, identify Arm Linux systems with FF-A support enabled and review whether custom, out-of-tree, or vendor-specific FF-A client drivers are present.

Typical attack path

1. Gain privileged local access or another mechanism capable of loading/registering kernel driver code.
2. Introduce a malformed FF-A client driver that does not provide the required FF-A ID table.
3. Trigger FF-A bus device-driver matching, for example through module loading or device probing.
4. Cause the FF-A bus match callback to dereference the NULL ID table pointer.
5. Crash the kernel or destabilize the host, producing denial of service.

How to detect it

Look for evidence of prior exploitation or triggering in kernel logs, persistent journal entries, crash dumps, and module-loading audit trails. Relevant log sources include dmesg output, /var/log/kern.log, /var/log/messages, systemd journal kernel facility logs, kdump/vmcore records, auditd logs for module loading, and EDR telemetry for privileged module operations. Investigate kernel Oops or panic events that mention FF-A, arm_ffa, driver matching, or NULL pointer dereference around the time of module insertion or device probing. Review loaded modules and recent module installation paths for custom or unexpected FF-A client drivers. Because this issue does not have a known public exploit pattern and primarily produces crashes, detection should focus on crash artifacts and suspicious privileged attempts to load kernel modules rather than network indicators.

• arm_ffa
• FF-A
• ffa_driver_register
• NULL pointer dereference
• Unable to handle kernel NULL pointer dereference
• Kernel panic - not syncing
• Oops:
• BUG: kernel NULL pointer dereference
• firmware: arm_ffa
• /var/log/kern.log
• /var/log/messages
• /proc/modules
• /lib/modules/
• init_module
• finit_module
• module verification failed

What your security team should do

• Prioritize patching Arm-based Linux systems that use FF-A, especially systems running custom, vendor-supplied, or out-of-tree kernel modules.
• Confirm whether the vulnerability is applicable before emergency remediation; non-Arm systems or kernels without FF-A support are unlikely to be exposed.
• Restrict kernel module loading to trusted administrators and enforce signed modules, Secure Boot, or kernel lockdown where feasible.
• Inventory third-party and custom FF-A-related kernel modules and remove or replace any that are unmaintained or not vendor-supported.
• Monitor kernel logs for NULL pointer dereferences, Oops events, or panics involving arm_ffa or FF-A driver matching.
• Treat unexpected crashes on affected Arm platforms as potentially security-relevant until kernel logs and module-loading activity are reviewed.