Description

In the Linux kernel, the following vulnerability has been resolved: iommu/arm-smmu-v3-iommufd: Require exactly one Stream ID for a vDEVICE arm_vsmmu_vsid_to_sid() maps a guest's vSID to a single physical Stream ID taken from master->streams[0], assuming a device has exactly one stream. A device with several streams gets only its first one mapped, so a guest vSID invalidation cannot reach the others' ATC and IOTLB entries; a device with none makes master->streams a ZERO_SIZE_PTR, read out of bounds. Add an arm_vsmmu_vdevice_init() op to reject the vDEVICE with -EOPNOTSUPP when master->num_streams is not one, rather than mapping it silently.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "9.3",
  "pubDate": "2026-08-15T13:18:02.963Z",
  "pubdate": "2026-08-15T13:18:02.963Z",
  "executiveSummary": "An input validation vulnerability exists within the Linux kernel's arm-smmu-v3-iommufd driver component, specifically affecting how virtual devices (vDEVICES) and their associated Stream IDs are handled. The vulnerability arises from inadequate constraint checks on the number of physical Stream IDs mapped to a guest vDEVICE during initialization. When a device is configured with multiple streams, only the first stream is mapped, rendering guest vSID invalidation operations ineffective for subsequent streams and leaving Address Translation Cache (ATC) and Input-Output Translation Lookaside Buffer (IOTLB) entries out of sync. Conversely, when a device is configured with zero streams, the pointer dereferences as a ZERO_SIZE_PTR, leading to an out-of-bounds memory read condition. This architectural deficiency impacts Linux kernel systems utilizing Arm SMMU v3 with IOMMUFD and virtualized hardware passthrough configurations. The risk implications include potential denial of service via kernel panics from out-of-bounds reads, as well as cache synchronization failures that could lead to stale address translations and memory safety violations in virtualized environments. Exploitation requires an authenticated entity with capabilities to configure virtual devices and manage IOMMUFD bindings within the guest-host interface boundaries.",
  "technicalDetails": "The vulnerability resides in the arm_vsmmu_vsid_to_sid() function and associated initialization routines within the Linux kernel's arm-smmu-v3-iommufd subsystem. The root cause of the flaw is the improper assumption that any given physical device mapped to a guest vDEVICE will invariably possess exactly one Stream ID located at master->streams[0].\nDuring the mapping process, the driver fails to validate master->num_streams prior to translating guest virtual Stream IDs (vSIDs) to physical Stream IDs (SIDs). If a device is provisioned with multiple Stream IDs, the driver silently maps only the initial stream index (master->streams[0]). As a consequence, any subsequent vSID invalidation requests issued by the guest operating system fail to propagate to the ATC and IOTLB entries of the unmapped streams. This creates a state desynchronization between the guest's view of device translation caches and the actual hardware SMMU state, potentially allowing stale translation caching.\nFurthermore, if a device is initialized with zero Stream IDs, the master->streams pointer evaluates to a ZERO_SIZE_PTR. Subsequent attempts to read or resolve stream mappings result in an out-of-bounds memory access, triggering kernel crashes or unstable memory reads.\nThe attack flow involves an adversary or misconfigured guest environment provisioning a virtual device with either zero Stream IDs or multiple Stream IDs bound to the arm_smmu-v3-iommufd interface. By triggering an invalidation sequence or forcing the driver to parse the stream array via arm_vsmmu_vsid_to_sid(), the execution flow encounters the out-of-bounds memory reference (in the zero-stream scenario) or causes cache management failures across unmapped streams (in the multi-stream scenario).\nThe vulnerable component is the arm_vsmmu_vsid_to_sid routine and vDEVICE initialization logic within the arm-smmu-v3-iommufd driver. Exploitation requires local administrative or hypervisor-level capabilities to define and initialize vDEVICES with invalid stream configurations, depending on whether the impact vector targets kernel availability via memory corruption or cache synchronization anomalies."
}