CVE-2026-23154: Linux Kernel GSO/GRO Fraglist Forwarding Fix Explained

This Linux kernel fix is a small patch with an outsized networking lesson: when packet forwarding meets Generic Receive Offload and Generic Segmentation Offload, tiny assumptions about packet layout can turn into real-world throughput problems. CVE-2026-23154 tracks a fraglist forwarding bug in the Linux kernel’s networking stack, specifically around how segmented packets are handled after GRO aggregation and protocol translation. The issue matters most in forwarding paths that involve XLAT-style IPv4/IPv6 translation, where the head of an skb may be rewritten while frag_list members are left behind with stale protocol state. (spinics.net)

Background — full context​

Linux networking performance depends on a careful balance between offload and correctness. GRO combines incoming packets to reduce per-packet overhead, while GSO lets the kernel hand larger skbs to the transmit path and segment them later, often saving CPU cycles under heavy load. In the forwarding path, though, the kernel has to decide whether it can safely preserve a packet’s aggregated form or whether it must break it apart before transmission. That decision is where fraglist handling becomes critical. (spinics.net)
The CVE-2026-23154 fix centers on a specific class of skb: a GSO packet that also carries a frag_list. The upstream patch explains that skb_segment_list cannot correctly process GRO skbs that have been converted by XLAT, because XLAT only rewrites the header of the head skb. As a result, packets in the frag_list may remain untranslated, creating protocol inconsistency and degraded throughput. The patch therefore marks these packets as SKB_GSO_DODGY so the segmentation logic avoids the fraglist-specific path and falls back to the more conservative skb_segment routine. (spinics.net)
The practical trigger described in the patch is a station accessing IPv4 servers through hotspots with an IPv6-only upstream interface. That is a very modern networking shape: a translation boundary in the forwarding path, GSO/GRO acceleration enabled, and frag_list semantics that only remain safe if all parts of the packet share the same translation state. Once that assumption fails, throughput collapses or packets are handled inconsistently. (spinics.net)
The fix was introduced upstream in late January 2026 and then carried into stable branches. The mailing list trail shows the patch being posted as “[PATCH v4] net: fix segmentation of forwarding fraglist GRO” on January 26, 2026, and later queued for 6.12-stable on February 4, 2026. A 6.1.y backport also appears in early March 2026, demonstrating that maintainers considered this important enough to propagate across supported kernel lines. (spinics.net)

What CVE-2026-23154 actually changes​

The key idea: mark translated GSO packets as risky​

The heart of the patch is not a redesign of GRO or GSO. It is a guardrail. The kernel now sets SKB_GSO_DODGY in the BPF protocol translation helpers bpf_skb_proto_4_to_6 and bpf_skb_proto_6_to_4 whenever a GSO packet has been translated. That flag tells later code the skb may no longer be safe for the most optimized fraglist segmentation path. (spinics.net)

• Before the fix: translated GSO packets could still be treated as clean fraglist candidates.
• After the fix: translated GSO packets are tagged as potentially unsafe for skb_segment_list.
• Result: segmentation drops back to skb_segment, which is slower but safer. (spinics.net)

Why SKB_GSO_DODGY matters​

The SKB_GSO_DODGY bit is effectively a “don’t trust this packet’s geometry” indicator. In the stable patch, the transport offload paths for TCP and UDP check both packet length and this flag before deciding whether to call the fraglist segmentation helper. If the flag is set, the kernel avoids the fraglist-specialized path even if the size comparison looks correct. That extra check is the entire point of the CVE fix. (spinics.net)

The code paths involved​

The stable patch touches four files:

• net/core/filter.c
• net/ipv4/tcp_offload.c
• net/ipv4/udp_offload.c
• net/ipv6/tcpv6_offload.c (spinics.net)

That spread is important. This is not a single protocol bug; it is a forwarding and segmentation consistency issue that crosses IPv4, IPv6, TCP, and UDP paths. The broad footprint also helps explain why the fix was backported rather than left to a single release line. (spinics.net)

How fraglist GRO/GSO works​

GRO first, GSO later​

GRO aggregates inbound traffic to reduce processing overhead. Instead of handling a flood of small packets one by one, the kernel can fold them into a larger skb. GSO then lets the stack defer segmentation until transmission, which can improve efficiency if the outbound path can segment intelligently. The frag_list variant is a memory-efficient way to keep packet pieces linked together without fully linearizing data. (spinics.net)

Why forwarding is harder than local delivery​

Local delivery lets the stack keep more context about the packet’s destination and transformations. Forwarding is tougher because the packet may already have been modified by routing, encapsulation, NAT-like translation, or BPF helpers. Once the kernel is forwarding traffic, the packet may need to be re-segmented, and any mismatch between the head skb and the frag_list can become a correctness problem. (spinics.net)

The fraglist assumption that breaks​

The fraglist fast path assumes the packet geometry is still coherent. In this CVE, XLAT changes the protocol header but only on the head skb. That means the frag_list may no longer accurately reflect the packet’s translated protocol state. In other words, the packet still looks efficient, but it is no longer uniform. That mismatch is what the fix prevents. (spinics.net)

Why this bug mattered in practice​

Throughput rather than classic crash behavior​

Unlike many kernel vulnerabilities that manifest as crashes, memory corruption, or privilege escalation, this one is described primarily as a low throughput and protocol-consistency issue. That can make it easy to miss in testing: the system stays up, traffic still flows, but performance silently drops under the exact conditions that exercise the bug. (spinics.net)

Hotspots and IPv6-only uplinks are a realistic trigger​

The patch text is unusually specific: a station accesses IPv4 servers via hotspots with an IPv6-only upstream interface. That is not an academic corner case. It reflects real carrier and tethering architectures where translation is common, and where forwarding paths have to bridge protocol eras without exposing packet handling shortcuts. (spinics.net)

BPF translation raises the stakes​

Because the fix lives in filter.c, it intersects with BPF-based protocol translation helpers. That means the issue is not limited to vanilla routing. The kernel’s programmable networking layer can feed packets into offload and forwarding code with altered semantics, and the safety checks have to survive that flexibility. This is a good example of how programmable networking broadens the attack surface for subtle correctness bugs, even when no exploit primitive is obvious. (spinics.net)

The upstream and stable journey​

From patch to stable queue​

The upstream patch was posted in late January 2026 and quickly moved into stable review. The 6.12-stable queue shows the fix as part of a larger batch, with Greg Kroah-Hartman circulating it as patch 55 of 87 in the review set. The patch is credited upstream to Jibin Zhang and signed off through the usual Linux networking maintainer chain. (spinics.net)

A clear fix lineage​

The stable notes cite upstream commit 426ca15c7f6cb6562a081341ca88893a50c59fa2, and the patch’s Fixes: tag points back to 9fd1ff5d2ac7 with the subject “udp: Support UDP fraglist GRO/GSO.” That tells us the bug is not a wholly new networking mechanism; it is a corner-case regression or omission that surfaced in the evolution of fraglist handling. (spinics.net)

Broad backporting suggests moderate severity​

The fact that the fix appeared in both 6.12-stable and 6.1.y stable streams is a strong indicator that maintainers considered it broadly relevant, not just an edge-case cleanup. When Linux stable takes a patch across multiple trains, it usually means the issue affects deployed systems in ways that justify conservative remediation. (spinics.net)

Relationship to earlier Linux fraglist bugs​

A recurring theme in networking​

Linux has had several fraglist-related fixes over the years, and the pattern is consistent: once packets are aggregated, transformed, and then segmented again, the kernel must be extremely careful about geometry, checksum state, and reference lifetimes. That makes fraglist code both performance-sensitive and fragile. (spinics.net)

Similarity to other segmentation issues​

The surrounding search results show earlier fixes in the same family, including problems involving skb_segment_list, UDP GSO fraglist segmentation after pull-from-frag_list, and null-pointer or memory-leak issues in related code paths. While those are different CVEs, they all point to the same architectural challenge: fraglist shortcuts are useful, but they become dangerous when packet state mutates mid-flight. (ubuntu.com)

The lesson for kernel networking​

If a packet is being translated, encapsulated, or otherwise altered after aggregation, the kernel should assume the most optimized segmentation path may be invalid. The CVE-2026-23154 fix makes that policy explicit by turning a hidden assumption into a flag check. That is the kind of surgical robustness change Linux networking often needs. (spinics.net)

What administrators should know​

This is a kernel update issue, not a user-space patch​

The remediation is not an application upgrade or config tweak. The affected logic is in the kernel networking stack, so resolution depends on installing a kernel build that includes the upstream backport. For administrators, this means watching vendor advisories and kernel changelogs rather than chasing package-level workarounds. (spinics.net)

The environments most likely to care​

Systems most likely to be affected include:

• mobile hotspot and tethering gateways,
• IPv6-only upstream deployments,
• routers or edge devices doing protocol translation,
• systems using BPF/XLAT style packet translation,
• hosts with GRO/GSO acceleration enabled in the forwarding path. (spinics.net)

Symptoms may look like performance bugs​

Because the issue presents as poor throughput rather than an overt security failure, operators may misclassify it as congestion, MTU trouble, NIC offload weirdness, or a temporary hotspot problem. If the network stack is forwarding translated fraglist traffic, the kernel itself may be the real bottleneck. (spinics.net)

Strengths and Opportunities​

A narrow, well-targeted fix​

One of the strengths of the patch is its restraint. It does not disable fraglist support broadly, and it does not punish all GSO traffic. It simply marks translated packets as dodgy when translation may have broken the assumptions needed for the specialized path. That keeps the performance cost limited to the traffic that actually needs it. (spinics.net)

Better correctness under programmable networking​

The change is also a useful example of how BPF and kernel offloads can coexist more safely. By forcing translated packets to re-enter the conservative path, the kernel acknowledges that programmable packet mutation should be accompanied by clear metadata. That is a mature design direction for Linux networking. (spinics.net)

Helps stabilize real-world translated networks​

The most visible opportunity here is reliability for deployments that sit at translation boundaries. IPv6 transition setups, hotspot backhauls, and mixed-protocol edge networks all benefit from a kernel that prefers safe segmentation when packet state becomes ambiguous. That should reduce silent performance degradation in the field. (spinics.net)

Risks and Concerns​

Performance penalty in the fallback path​

The obvious tradeoff is that skb_segment is more conservative than skb_segment_list. On workloads that hit this code path often, the fix may reduce peak throughput compared to an ideal fraglist fast path. That is acceptable for correctness, but it is still a cost. (spinics.net)

Harder-to-detect exposure​

Because the bug is data-plane subtle, organizations may not realize they were vulnerable until they compare throughput before and after patching. This kind of issue does not produce the dramatic indicators that draw immediate attention, which can delay remediation. (spinics.net)

Broad networking complexity remains​

The deeper concern is that this CVE is another reminder that GRO/GSO, fraglist handling, BPF translation, and forwarding all compose into a system where every optimization depends on hidden invariants. Each new fast path increases the burden on metadata correctness. In that sense, CVE-2026-23154 is less an isolated defect than evidence of an ongoing maintenance challenge. (spinics.net)

What to Watch Next​

Vendor backports and kernel release notes​

The immediate thing to watch is how Linux distributors fold the fix into their supported kernels. The stable-mailing-list trail shows upstream movement, but enterprise exposure depends on vendor release timing and whether they inherit the patch cleanly. (spinics.net)

Follow-on fixes in related offload code​

Another area to monitor is whether adjacent TCP and UDP offload paths receive further hardening around fraglist detection. The current patch already touches TCP, UDP, and IPv6 TCP offload paths, which suggests maintainers are watching for additional mismatches in segmentation logic. (spinics.net)

Whether similar assumptions surface elsewhere​

The larger question is whether other kernel subsystems make comparable assumptions after transformation helpers alter packet state. If one path needed the SKB_GSO_DODGY safeguard, others may need analogous flags or checks in future releases. That is the kind of preventive engineering Linux tends to accumulate after a bug is fully understood. (spinics.net)

The broader lesson for Linux networking​

• Optimizations must advertise their assumptions.
• Translation should leave metadata breadcrumbs.
• Forwarding code should distrust geometry after mutation.
• Stable backports are a sign of real operator impact.
• Performance regressions can still be security-relevant when they alter trust boundaries. (spinics.net)

The most interesting thing about CVE-2026-23154 is that it is not a flashy exploit story; it is a lesson in the limits of packet fast paths. Linux networking is built on carefully stacked optimizations, and the fraglist forwarding fix shows what happens when one layer of that stack assumes another layer did not mutate the packet enough to matter. By tagging translated GSO traffic as SKB_GSO_DODGY, the kernel chooses correctness over overconfidence, which is exactly the kind of tradeoff a mature networking stack should make.

---

Source: Microsoft Security Response Center Security Update Guide - Microsoft Security Response Center