CVE-2026-46273

What it actually does

This is a network-triggerable denial-of-service flaw in the Linux kernel ibmveth network driver used on IBM Power virtual Ethernet configurations. Certain physical adapters cannot safely perform segmentation offload when a TCP packet has a maximum segment size below 224 bytes and requires hardware segmentation. If the driver passes such a packet to hardware with Generic Segmentation Offload enabled, the adapter can freeze, stopping network traffic until the adapter is manually reset. The flaw affects availability only; it does not directly provide code execution or data disclosure.

Why it matters to the business

Systems using affected Linux kernels with ibmveth on IBM Power networking can lose network connectivity when they process specially shaped TCP traffic. For business services, this can mean application outages, failed client connections, interrupted cluster communication, and operational intervention to reset the affected adapter. The issue is not currently listed in CISA KEV, has low EPSS at this time, and has no reported public exploit maturity in the supplied data, but the CVSS availability impact is high because exploitation can be unauthenticated and remote where vulnerable networking paths are exposed.

How an attack unfolds

An attacker targets a service reachable over the network on a system using the vulnerable ibmveth driver. During TCP connection setup, the attacker advertises or induces an unusually small MSS value below 224 bytes, then causes the target to send a response large enough that the kernel prepares a segmented transmit packet. If the packet requires more than one segment and GSO remains enabled, the vulnerable driver can hand the small-MSS segmentation workload to hardware that does not support it. The physical adapter then freezes, halting traffic through that adapter until an operator resets it. Exploitation is most practical against services that can be made to send larger responses after a small-MSS TCP negotiation.

How to fix it

Apply a vendor-supplied Linux kernel update that includes the ibmveth fix adding an ndo_features_check path to disable GSO for packets with MSS below 224 bytes and to correctly process VLAN feature checks. No exact fixed package versions were provided in the input, so use the relevant distribution or hardware vendor advisory to identify the corrected kernel build. Where patching cannot be completed immediately, reduce exposure by disabling segmentation offload on affected ibmveth interfaces, for example with ethtool to disable GSO/TSO where operationally acceptable, and consider filtering or normalizing inbound TCP SYN packets that advertise MSS values below 224 bytes at network boundaries. Because disabling offload can affect throughput and CPU utilization, test mitigation changes before broad production rollout.

How to confirm the fix worked

Confirm that affected systems are running a kernel build containing the ibmveth small-MSS GSO fix or the corresponding distribution backport. Verify the host uses the ibmveth driver before prioritizing emergency testing. Check driver and kernel details with standard Linux tools such as uname, modinfo where available, ethtool -i, and vendor package metadata. In a controlled lab or maintenance window, validate that small-MSS traffic no longer freezes the adapter: create TCP traffic with MSS below 224 bytes that causes multi-segment transmission and confirm packets are segmented in software and connectivity remains stable. Also validate VLAN and QinQ configurations if used, because the fix includes VLAN feature handling. For mitigations, confirm that offload settings are disabled or that network controls block/adjust MSS below 224 bytes, then monitor for transmit timeouts or adapter resets.

Typical attack path

1. Identify a reachable Linux system running on IBM Power virtual Ethernet using the ibmveth driver or a dependent SEA-style networking configuration.
2. Open TCP connections to an exposed service while advertising a TCP MSS value below 224 bytes, or otherwise force small-MSS traffic.
3. Trigger the service to send enough data back that the kernel creates a GSO packet requiring hardware segmentation.
4. The vulnerable ibmveth transmit path passes the small-MSS GSO packet to hardware instead of forcing software segmentation.
5. The adapter freezes and network traffic through that interface stops until manually reset.

How to detect it

To determine whether this was already exploited or triggered, review kernel logs, system journals, hypervisor or platform management logs, and network monitoring around periods of unexplained connectivity loss on ibmveth interfaces. Look for transmit timeouts, adapter freezes, interface resets, link-down/link-up events, and sudden drops of all traffic on the affected interface without a corresponding administrative change. Correlate those events with packet captures, IDS logs, firewall logs, load balancer logs, or NetFlow showing TCP sessions that advertised MSS values below 224 bytes shortly before the outage. Pay particular attention to repeated small-MSS TCP SYNs followed by requests that cause large responses from exposed services. Because this flaw causes denial of service rather than host compromise, durable host artifacts may be limited to network-driver logs, interface counters, adapter reset records, and packet/network telemetry.

• ibmveth
• NETDEV WATCHDOG
• transmit queue timed out
• Transmit timed out
• adapter freeze
• adapter frozen
• resetting adapter
• interface reset
• link down
• link up
• TCP MSS < 224
• tcp.options.mss < 224
• MSS 223
• MSS 222
• MSS 128
• gso_segs
• Generic Segmentation Offload

What your security team should do

• Inventory Linux systems on IBM Power platforms and identify those using the ibmveth driver or virtual Ethernet paths backed by affected physical adapters.
• Prioritize kernel updates for externally reachable services, high-availability infrastructure, virtualization hosts, and systems where loss of network connectivity has significant operational impact.
• If immediate patching is not possible, temporarily disable GSO/TSO on affected ibmveth interfaces or enforce a minimum TCP MSS of 224 bytes at appropriate network controls.
• Monitor kernel logs and network telemetry for ibmveth transmit stalls, NETDEV WATCHDOG messages, sudden interface-wide traffic loss, and repeated low-MSS TCP connections.
• Test remediation in VLAN, QinQ, and SEA-like configurations, because offload behavior can differ by encapsulation and adapter path.
• Document operational runbooks for safely resetting affected adapters if a freeze occurs before remediation is complete.