CVE-2026-74713

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vhost_iotlb: bound map allocation in add_range<br /> <br /> vhost_iotlb_add_range_ctx() only retires an old entry when the table<br /> has a non-zero limit, has exactly reached that limit and has<br /> VHOST_IOTLB_FLAG_RETIRE set. Non-retiring tables can keep allocating<br /> entries after reaching their configured limit.<br /> <br /> Existing vhost devices allocate their IOTLB with max_iotlb_entries from<br /> vhost.c, which defaults to 2048 and is tunable by module parameter. Use<br /> the caller-provided limit at the allocation point instead of adding a<br /> separate default in the common IOTLB helper, and reject non-positive<br /> values in vhost paths that can report an error.<br /> <br /> Other vhost IOTLB users should not create zero-limit tables when entries<br /> can be populated from userspace or guest-controlled requests. Add<br /> caller-side max_iotlb_entries parameters for mlx5 vDPA, VDUSE and<br /> vhost-vDPA. Reject non-positive VDUSE and vhost-vDPA values, and require<br /> at least two entries for vdpa_sim and mlx5 vDPA paths that install<br /> full-range mappings, since those mappings are split into two IOTLB<br /> entries.<br /> <br /> Handle full-range mappings in the common helper by checking that the<br /> IOTLB can hold both split entries before inserting the first half. This<br /> avoids returning an error after leaving a half mapping behind.<br /> <br /> When the table is full, keep the existing retire behavior for retiring<br /> tables and return -ENOSPC for non-retiring tables. Reuse the retired map<br /> node instead of freeing it and allocating a replacement, so a stream of<br /> IOTLB updates cannot keep forcing GFP_ATOMIC allocations after the table<br /> has reached its limit. If a zero-limit IOTLB still reaches the common<br /> helper, treat it as a configuration error and return -EINVAL.<br /> <br /> I found this bug myself, though the patch was written with AI assistance.