CVE-2026-74626: NTB: ntb_netdev: Preserve RX queue depth on allocation failure
In the Linux kernel, the following vulnerability has been resolved:
NTB: ntbnetdev: Preserve RX queue depth on allocation failure
ntbnetdevrxhandler() hands the received skb to the network stack before allocating its replacement. If the allocation fails, nothing is reposted. Every failure therefore takes one buffer out of the RX queue while the interface remains up, and enough failures eventually stall reception.
A retry path could refill the queue later, but ntbnetdev has none. Allocate the replacement first instead. If that fails, drop the packet and repost the same skb. This keeps the queue full and lets packet delivery resume as soon as memory is available again.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
ubuntu/linux-nvidia-tegrato a version that resolves this vulnerability.Fixed in 6.8.0-1036.39 - Upgrade
Upgrade
debian/linuxto a version that resolves this vulnerability.Fixed in 6.1.190-1Fixed in 6.12.107-1Fixed in 6.12.113-1Fixed in 7.2.12-1Fixed in 7.2.14-1 - Upgrade
Upgrade
debian/linux-6.12to a version that resolves this vulnerability.Fixed in 6.12.113-1~deb12u1 - Compensating control
Modify ntb_netdev_rx_handler() to allocate the replacement RX buffer before handing the received skb to the network stack; if allocation fails, drop the packet and repost the same skb so the RX queue depth is preserved.
Event History
Frequently Asked Questions
Which systems are exposed to this issue?
Systems using the Linux kernel NTB network device driver are exposed when ntb_netdev is in use. The issue affects packet reception on the NTB network interface rather than all network interfaces generally.
What conditions cause reception to stall?
The failure occurs when allocation of a replacement receive skb fails during packet handling. Each allocation failure removes one buffer from the RX queue without reposting it, so repeated failures can eventually exhaust the queue and stall reception while the interface remains up.
Is an attacker required to trigger the problem?
The described trigger is memory allocation failure while processing received packets. The provided information does not establish that an external attacker can directly cause those allocation failures.
What happens after the fix when memory allocation fails?
The packet is dropped and the existing skb is reposted to the RX queue. This preserves queue depth, allowing packet delivery to resume once memory is available.