CVE-2026-68129

What it actually does

This flaw affects the Linux kernel gve network driver receive path. Under extreme memory pressure, receive buffer page allocation can fail while the driver is trying to refill Rx descriptors. If the number of buffers posted to the NIC falls below a critical threshold, the hardware may stop receiving packets because no descriptors are available. Since no packets are processed, no Rx completions are generated, NAPI is not rescheduled, and the refill loop may never run again even after memory becomes available. The result is a persistent receive-queue stall that can deny network connectivity until the interface, driver, or host is reset. The upstream fix adds a starvation recovery timer per Rx queue so NAPI is periodically rescheduled when descriptor availability is critically low.

Why it matters to the business

Affected Linux systems using the gve network driver can experience sustained network receive failure during memory pressure, causing service outages, dropped inbound traffic, failed health checks, application timeouts, and possible failover events. This is primarily an availability risk rather than a confidentiality or integrity issue. The issue is not listed in CISA KEV, is not marked as ransomware-associated, and has no reported exploit maturity in the supplied data, but it should still be prioritized for systems where gve-backed network connectivity is critical.

How an attack unfolds

An attacker does not need code execution on the target to benefit from the failure mode, but reliable exploitation depends on environmental conditions. The vulnerable system must be using the Linux gve driver and must enter severe memory pressure so that page allocations fail during Rx buffer refill. While the system is in that state, incoming traffic can consume or require receive descriptors. If descriptor availability falls below the safe threshold and allocation failures cause the refill loop to exit, the Rx queue can become starved. Because the queue stops processing packets, no completions are generated and NAPI is not naturally scheduled again, leaving the queue stalled even after memory pressure subsides. A remote actor could attempt to increase the likelihood of impact by sending high-volume inbound traffic while the host is memory constrained, but accidental operational memory pressure can trigger the same outcome. Recovery generally requires administrative intervention such as resetting the interface, reloading the driver, or rebooting unless the kernel contains the starvation recovery fix.

How to fix it

Upgrade to a Linux kernel or distribution kernel package that includes the gve Rx starvation recovery timer fix for CVE-2026-68129. No exact fixed package versions were provided in the input, so use the applicable Linux distribution, cloud image, appliance, or kernel vendor advisory to identify the corrected kernel build. Reboot into the updated kernel after installation. Where immediate patching is not possible, reduce the likelihood and impact by avoiding sustained memory pressure, enforcing memory limits for workloads, maintaining swap or other emergency memory headroom where appropriate, monitoring for page allocation failures, and having operational procedures to reset affected interfaces or reboot hosts if receive queues stall. For critical systems, consider failover capacity and redundancy so a single stalled receive queue does not cause a service outage.

How to confirm the fix worked

Confirm the running kernel includes the vendor fix, not merely that an updated package is installed. Validate with the distribution advisory, kernel changelog, or source package showing the gve starvation recovery timer change. After reboot, confirm the active kernel version with standard OS tooling such as uname and package-manager queries. On systems using gve, confirm interfaces remain healthy under controlled memory-pressure testing and that Rx queues recover after transient allocation failures. Monitor NIC and driver counters with tools such as ethtool -S, ip -s link, kernel logs, and service-level network checks to verify that receive drops, descriptor starvation, or persistent Rx inactivity do not recur.

Typical attack path

1. Identify or target a Linux system using the gve network driver.
2. Create or wait for severe memory pressure on the host so receive-buffer page allocations can fail.
3. Send sustained inbound network traffic to the affected interface while Rx buffers are depleted.
4. Trigger the Rx refill path to exit before enough descriptors are posted back to hardware.
5. Cause the device to drop incoming packets because the Rx queue lacks descriptors.
6. Rely on the absence of Rx completions to prevent NAPI from being rescheduled, leaving the queue permanently stalled.
7. Maintain availability impact until the interface, driver, or host is reset, or until a patched kernel prevents starvation.

How to detect it

There may be no definitive artifact proving malicious exploitation because the same condition can occur from ordinary memory exhaustion. Investigate for a combination of severe memory pressure followed by persistent inbound network failure on systems using the gve driver. Review kernel logs, journald, syslog, dmesg, cloud or platform serial console logs, NIC statistics, host memory metrics, and service/network telemetry. Look for page allocation failures, out-of-memory activity, high packet drops, stalled receive counters, failed health checks, and periods where outbound or host-level activity continues but inbound traffic stops. Use ethtool -S and ip -s link to compare Rx packet counters, drops, errors, and queue-specific counters before and after the suspected event. If malicious activity is suspected, correlate the onset with unusual inbound traffic volume, packet floods, repeated connection attempts, or traffic from a concentrated set of sources immediately before the stall. Preserve kernel logs and network telemetry before resetting interfaces or rebooting, because recovery actions may clear volatile evidence.

• gve
• page allocation failure
• alloc failure
• Out of memory
• invoked oom-killer
• NETDEV WATCHDOG
• napi
• Rx queue stall
• rx queue stall
• No buffer space available
• rx_dropped
• rx_errors
• dmesg | grep -i gve
• journalctl -k | grep -i gve
• ethtool -S

What your security team should do

• Inventory Linux systems using the gve network driver and prioritize internet-facing, load-balanced, latency-sensitive, or business-critical systems.
• Track vendor kernel advisories and deploy the first fixed kernel available for each affected platform; reboot into the fixed kernel.
• Because publication is recent and no known exploited status is reported, prioritize based on exposure and availability criticality, but do not defer patching on critical network paths.
• Add monitoring for memory pressure, kernel page allocation failures, gve driver messages, receive drops, and sudden loss of inbound traffic while the host remains otherwise running.
• Create an operational runbook for suspected Rx queue stalls, including collecting logs and counters before remediation, then resetting the interface, reloading the driver where safe, failing over, or rebooting.
• Review workload memory limits and capacity planning to reduce the chance of extreme host memory pressure.
• Test high-availability and failover behavior for services running on systems that depend on gve-backed network interfaces.