CVE-2026-31737

What it actually does

This is a local denial-of-service flaw in the Linux kernel ftgmac100 Ethernet driver. During network device open, the driver allocates transmit and receive ring resources in stages. If an intermediate allocation fails, older vulnerable code returns without freeing resources already allocated in earlier stages. Repeatedly triggering this failure path can leak kernel memory and associated network-driver resources, eventually causing memory exhaustion, network-interface instability, or a system-wide availability impact. The flaw does not provide code execution, data disclosure, or direct privilege escalation based on the available description.

Why it matters to the business

Systems using the affected Linux kernel driver can become unstable or unavailable if a local attacker or faulty automation repeatedly triggers the vulnerable network-interface initialization path. The most likely operational impact is degraded network connectivity, kernel memory pressure, service interruption, or a reboot caused by out-of-memory conditions. Current public exploitation indicators are low: EPSS is approximately 0.0013 with no 30-day increase, it is not listed in CISA KEV, and no ransomware use is reported. However, kernel availability bugs can still be important for appliances, embedded systems, and management controllers where downtime is operationally significant.

How an attack unfolds

An attacker first obtains local access to a system running an affected Linux kernel with the ftgmac100 driver in use. The attacker then attempts to repeatedly open or initialize the affected network interface under conditions that cause staged ring allocation to fail, such as memory pressure or constrained allocation behavior. On vulnerable kernels, the failure path does not release all previously allocated driver resources. By repeating the operation, the attacker can accumulate leaked kernel memory. Over time this can exhaust available memory or destabilize the network stack, resulting in interface failure, service degradation, OOM-killer activity, or system unavailability.

How to fix it

Upgrade to a Linux kernel version from the relevant distribution or vendor that includes the ftgmac100 allocation-unwind fix. Because no exact fixed upstream or package versions were provided in the input, use the fixed kernel advisory from the operating system, appliance, or board vendor and prioritize systems where the ftgmac100 driver is present and active. If immediate patching is not possible, reduce exposure by limiting local shell access, restricting users and automation capable of changing network-interface state, disabling unused ftgmac100-backed interfaces where operationally safe, and monitoring for repeated interface cycling or memory pressure. Rebooting may clear leaked resources temporarily, but it is not a durable fix.

How to confirm the fix worked

Confirm exposure by checking whether the running kernel includes the vulnerable ftgmac100 driver code and whether an interface is using that driver. Validate remediation by confirming the installed kernel package or image contains the vendor patch for the ftgmac100 ring-allocation unwind issue, then reboot into the fixed kernel if required. On Linux systems, inspect driver binding with commands such as `ethtool -i <interface>` or sysfs driver links, and verify the running kernel with `uname -a` or distribution package tools. After remediation, review kernel logs while cycling the affected interface in a controlled maintenance window and confirm there are no repeated allocation failures, resource leaks, or OOM events associated with ftgmac100.

Typical attack path

1. Gain local access to a Linux system using the affected ftgmac100 Ethernet driver.
2. Identify the network interface backed by the ftgmac100 driver.
3. Create or wait for memory-pressure conditions that make ring allocation failures more likely.
4. Repeatedly trigger network device open or initialization attempts, such as cycling the interface state.
5. Cause the vulnerable error path to leak previously allocated driver resources.
6. Continue until kernel memory pressure affects networking, services, or overall system availability.

How to detect it

Look for evidence of repeated local attempts to initialize or cycle an ftgmac100-backed network interface followed by kernel memory pressure. Useful log sources include `dmesg`, system journal kernel logs, `/var/log/kern.log`, `/var/log/messages`, audit logs for privileged network commands, EDR process telemetry, and configuration-management logs that may show repeated interface changes. Investigate clusters of events containing ftgmac100 driver messages, allocation failures, interface state changes, and OOM-killer activity. Potential exploitation is more plausible when these events are repeated over a short period and are associated with local user activity or scripts invoking network-management tools such as `ip`, `ifconfig`, `ifup`, `ifdown`, `systemctl restart networking`, or NetworkManager controls. Because this vulnerability is a resource leak rather than a payload-based compromise, there may be no unique file, registry, or network IOC; detection should focus on behavioral correlation of driver errors, memory exhaustion, and interface cycling.

• ftgmac100
• Cannot allocate memory
• -ENOMEM
• Out of memory
• invoked oom-killer
• Memory allocation failure
• NETDEV_UP
• NETDEV_DOWN
• link is not ready
• ip link set
• ifconfig
• ifup
• ifdown
• systemctl restart networking
• NetworkManager

What your security team should do

• Inventory Linux systems, appliances, embedded platforms, and management controllers that use the ftgmac100 Ethernet driver.
• Patch affected systems to a vendor-supported kernel containing the ftgmac100 cleanup fix, prioritizing systems where downtime would affect management access or production operations.
• Restrict local access and administrative network-interface controls to trusted users and services until patching is complete.
• Monitor kernel logs for ftgmac100 errors, repeated interface up/down activity, allocation failures, and OOM-killer events.
• Treat unexplained memory exhaustion on systems using ftgmac100 as a potential abuse case and preserve kernel logs for investigation.
• Because EPSS is low and the issue is not in KEV, prioritize based on asset criticality and driver presence rather than broad internet-exposure urgency.