Database/Kernel, userspace & hypervisor
Linux kernel arm_ffa: use-after-free racing a notifier unregister against notification delivery
Impact
Both FF-A notification handlers look up a notifier entry under notify_lock, drop the lock, then dereference the entry. A concurrent unregister can free that entry in the gap, leaving the handler on stale memory - host kernel use-after-free with a scope-changed vector. This only concerns Arm64 hosts whose firmware exposes the Arm Firmware Framework (FF-A) and where the arm_ffa driver is bound with FF-A clients registering and unregistering notifiers; that is the Grace/Ampere-class Arm server population, not x86 GPU nodes, where the driver is absent and the code is unreachable. The fix snapshots the callback pointer and data while the lock is held.
Who can reach it
Local, and narrower than local-user: it needs in-kernel FF-A notifier registration and unregistration racing notification delivery on an Arm64 host with FF-A firmware. The record does not identify an unprivileged userspace trigger. Scored AV:L/PR:N/S:C by the kernel CNA.
What to do
On Arm64 GPU hosts, take a stable kernel with the fix commits listed in the record and reboot the node; the driver is built in on most Arm server configs, so there is no module reload shortcut. x86 fleets can ignore this - confirm with a check for the arm_ffa driver before scheduling anything. The record names commits, not a fixed release number.
References
Related entries
- Linux xen-scsiback: guest can underflow a command refcount and exhaust a LUN's command tagsCVE-2026-72085 · Linux kernel Xen pvSCSI backend (scsiback unsubmitted command free)Critical
- Linux KVM arm64 vgic: use-after-free racing LPI disable against interrupt affinity changeCVE-2026-72288 · Linux kernel KVM arm64 vgic (LPI disable vs affinity change race)Critical
- Linux KVM arm64 vgic: double list_del when an LPI leaves the ap_list during migrationCVE-2026-72289 · Linux kernel KVM arm64 vgic (ap_list ownership check before LPI migration)Critical
- Linux vhost/net: use-after-free when a cloned zerocopy skb completes after backend resetCVE-2026-74310 · Linux kernel vhost/net (zerocopy ubuf_info completion)Critical
- Linux kernel (drivers/iommu/intel): The VT-d scalable-mode context entry is zeroed while its Present bit is still setCVE-2026-74439 · Linux kernel (drivers/iommu/intel)Critical
- Linux kernel (arch/x86/kvm): The I/O APIC's delayed EOI work was cancelled only after vCPUs were freed, so the workCVE-2026-74517 · Linux kernel (arch/x86/kvm)Critical
This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.