vhost_iotlb: bound map allocation in add_range

MITRE NVD CVE.ORG JSON API

Summary

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

Vendor Declared Affected Products

SourceVendorProductVersionPlatforms
CNA Linux Linux affected 0bbe30668d89ec8a309f28ced6d092c90fb23e8c ae128dd19040ee06a4f8143c7ced4d18080d7a9a git Not specified
CNA Linux Linux affected 0bbe30668d89ec8a309f28ced6d092c90fb23e8c 1ed35ac7f3fe2b4396bdd29ac3a7f0ebc0829e94 git Not specified
CNA Linux Linux affected 5.7 Not specified
CNA Linux Linux unaffected 5.7 semver Not specified
CNA Linux Linux unaffected 7.1.9 7.1.* semver Not specified
CNA Linux Linux unaffected 7.2 * original_commit_for_fix Not specified

References

ReferenceSourceLinkTags
git.kernel.org/stable/c/ae128dd19040ee06a4f8143c7ced4d18080d7a9a 416baaa9-dc9f-4396-8d5f-8c081fb06d67 git.kernel.org
git.kernel.org/stable/c/1ed35ac7f3fe2b4396bdd29ac3a7f0ebc0829e94 416baaa9-dc9f-4396-8d5f-8c081fb06d67 git.kernel.org
CVE Program record CVE.ORG www.cve.org canonical
NVD vulnerability detail NVD nvd.nist.gov canonical, analysis

© CVE.report 2026

Use of this information constitutes acceptance for use in an AS IS condition. There are NO warranties, implied or otherwise, with regard to this information or its use. Any use of this information is at the user's risk. It is the responsibility of user to evaluate the accuracy, completeness or usefulness of any information, opinion, advice or other content. EACH USER WILL BE SOLELY RESPONSIBLE FOR ANY consequences of his or her direct or indirect use of this web site. ALL WARRANTIES OF ANY KIND ARE EXPRESSLY DISCLAIMED. This site will NOT BE LIABLE FOR ANY DIRECT, INDIRECT or any other kind of loss.

CVE, CWE, and OVAL are registred trademarks of The MITRE Corporation and the authoritative source of CVE content is MITRE's CVE web site. This site includes MITRE data granted under the following license.

Free CVE JSON API cve.report/api

CVE.report and Source URL Uptime Status status.cve.report