CVE-2026-64472 in Linux
Summary
by MITRE • 07/25/2026
In the Linux kernel, the following vulnerability has been resolved:
vfio/mlx5: Fix racy bitfields and tighten struct layout
Bitfield operations are not atomic, they use a read-modify-write pattern, therefore we should be careful not to pack bitfields that can be concurrently updated into the same storage unit.
This split takes a binary approach: flags that are only modified pre/post open/close remain bitfields, flags modified from user action, including actions that reach across to another device (ex. reset) use dedicated storage units.
Note mlx5_vhca_page_tracker.status is relocated to fill the alignment hole this split exposes.
Bitfield justifications:
migrate_cap: written only in mlx5vf_cmd_set_migratable() at probe chunk_mode: written only in mlx5vf_cmd_set_migratable() at probe mig_state_cap: written only in mlx5vf_cmd_set_migratable() at probe
Dedicated storage units:
mdev_detach: written in the VF attach/detach event notifier mlx5fv_vf_event() at runtime log_active: written in mlx5vf_start_page_tracker()/ mlx5vf_stop_page_tracker() during runtime dirty tracking deferred_reset: written in mlx5vf_state_mutex_unlock()/ mlx5vf_pci_aer_reset_done() during runtime reset handling is_err: set by tracker error handling and dirty-log polling at runtime object_changed: set by tracker event handling and cleared by dirty-log polling at runtime
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 07/26/2026
The vulnerability addressed in this linux kernel update relates to race conditions within the vfio/mlx5 driver component that handles mellanox mlx5 network devices. This issue specifically targets bitfield operations that are not atomic in nature, utilizing read-modify-write patterns that create potential for data corruption when multiple threads or processes attempt concurrent access to the same memory storage unit. The flaw manifests when bitfields that should remain separate are packed together in the same storage location, creating scenarios where simultaneous updates can interfere with each other. According to common weakness enumeration standards, this vulnerability maps to cwe-367, which describes time-of-check time-of-use issues and race conditions that can lead to improper access control or data corruption.
The technical implementation of this fix involves a strategic reorganization of the memory layout for device status tracking structures within the mlx5 driver. The solution adopts a binary approach that categorizes flags based on their modification patterns, separating those that are only updated during initialization or device lifecycle events from those that experience runtime modifications. This approach directly addresses the underlying atomicity issues by ensuring that concurrently modified fields occupy distinct memory locations rather than sharing storage units. The specific changes include relocating the mlx5_vhca_page_tracker.status field to fill alignment gaps exposed by this restructuring, thereby optimizing memory usage while eliminating race conditions.
The operational impact of this vulnerability extends beyond simple data corruption to potentially affect device reliability and system stability in virtualized environments. When multiple concurrent operations attempt to modify shared bitfields, the system may experience inconsistent state reporting, improper device behavior during migration scenarios, or failure to properly handle reset operations. This is particularly critical in high-performance computing and data center environments where mlx5 devices are commonly deployed. The fix ensures that runtime modifications to device states such as mdev_detach, log_active, deferred_reset, is_err, and object_changed occur through dedicated storage units, preventing interference between different subsystems that might simultaneously access device status information.
Mitigation strategies for this vulnerability involve updating kernel versions that include the patched vfio/mlx5 driver implementation, ensuring that all system components using mlx5 devices operate with the corrected memory layout. System administrators should verify that their kernel versions contain the specific bitfield reorganization fixes, particularly focusing on the separation of runtime-modified flags from initialization-only flags. The solution aligns with attack technique frameworks by addressing potential privilege escalation paths through device state manipulation and ensures proper synchronization mechanisms are in place for concurrent access to device management structures. Organizations relying on virtualization platforms should validate that their hypervisor and kernel configurations properly implement these memory layout changes to maintain consistent device behavior during migration, reset, and attach/detach operations.