CVE-2026-97990: vdpa_sim_net: check TX pull result before RX copy
In the Linux kernel, the following vulnerability has been resolved:
vdpasimnet: check TX pull result before RX copy
vringhiovpulliotlb() returns a signed byte count. A failed TX pull is currently added to the unsigned byte counter and then passed as a sizet length to receivefilter() and vringhiovpushiotlb(). 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.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Compensating control
In vdpa_sim_net, check the signed result from vringh_iov_pull_iotlb() before using it as a length in the RX path; handle non-positive pull results as errors and complete the consumed TX descriptor with zero bytes before any RX copy or length use.
Event History
Frequently Asked Questions
What condition triggers the vulnerable RX-path length handling?
The condition occurs when vringh_iov_pull_iotlb() fails during TX processing and returns a negative error. That signed result is added to an unsigned byte counter and can then be interpreted as a very large size_t length.
What is the intended safe behavior when a TX pull fails?
Non-positive TX pull results should be handled before they are used as lengths. The TX error should be counted, and the consumed TX descriptor should be completed with zero bytes.