Description

In the Linux kernel, the following vulnerability has been resolved: vdpa_sim_net: check TX pull result before RX copy vringh_iov_pull_iotlb() returns a signed byte count. A failed TX pull is currently added to the unsigned byte counter and then passed as a size_t length to receive_filter() and vringh_iov_push_iotlb(). A negative error can therefore become a large length in the RX path. Handle non-positive pull results before every length use. Count the TX error and complete the consumed TX descriptor with zero bytes. I found this bug myself, though the patch was written with AI assistance.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.5",
  "pubDate": "2026-09-25T11:17:27.113Z",
  "pubdate": "2026-09-25T11:17:27.113Z",
  "executiveSummary": "The vdpa_sim_net driver in the Linux kernel is susceptible to an integer handling vulnerability arising from improper validation of return values from vringh_iov_pull_iotlb().\nThe vulnerability occurs when a negative error code returned by the pull function is treated as an unsigned size_t value, leading to an integer underflow.\nThis resulting large, incorrect length value is subsequently passed to critical functions such as receive_filter() and vringh_iov_push_iotlb().\nAn attacker capable of interacting with the vDPA simulation network device can potentially trigger memory corruption, out-of-bounds access, or a kernel panic due to the erroneous length calculation.\nThe flaw highlights a failure in bounds checking during descriptor processing, which allows malformed TX descriptors to influence the internal state of the RX path.\nThis vulnerability primarily affects kernel-level components and requires local access or the ability to communicate with the virtual device, posing a risk of privilege escalation or denial of service.",
  "technicalDetails": "The vulnerability resides within the packet processing logic of the vdpa_sim_net driver, specifically where it handles descriptor chains using vringh_iov_pull_iotlb(). This function, designed to pull data from a vring into an I/O vector, returns a signed integer representing the number of bytes pulled or a negative value upon failure.\nThe root cause is an improper type conversion during the transition between the TX processing phase and the RX processing phase. The driver captures the return value of vringh_iov_pull_iotlb() into an unsigned size_t length counter without first validating the sign of the result. When a TX operation fails, the function returns a negative error code (e.g., -EFAULT or -EINVAL). Because the code treats this negative integer as an unsigned value, it is interpreted as a massive positive integer due to the underlying two's complement representation (e.g., -1 becomes a very large positive number).\nFollowing this incorrect calculation, the driver passes the corrupted length value as an argument to receive_filter() and vringh_iov_push_iotlb(). This uncontrolled value acts as a length parameter for subsequent memory operations. During the RX path, the driver attempts to process or move data based on this inflated size, leading to out-of-bounds memory accesses or processing logic errors.\nThe attack flow involves an adversary crafting a malformed TX descriptor that intentionally causes a failure in vringh_iov_pull_iotlb(). Upon failure, the driver's failure to sanitize the error code ensures the subsequent RX logic operates on arbitrary, large lengths rather than the expected zero-length outcome. By controlling these inputs, an attacker may trigger kernel memory corruption by forcing the driver to read or write data beyond the intended buffer limits in the RX path.\nThe affected components are restricted to the vdpa_sim_net kernel module. Exploitation does not necessarily require high-level privileges if the vDPA device is exposed to unprivileged users, though it generally requires interaction with the kernel-level virtio infrastructure. The impact is significant, as it could allow for kernel memory disclosure, arbitrary memory writes, or a complete system crash (Denial of Service) through a kernel panic."
}