CVE-2026-53366 fixes a Linux IPv4 packet-construction flaw that can write past a socket buffer’s allocated linear area when an application combines
The National Vulnerability Database published the record on July 16, 2026, with kernel.org as the source. The record has no CVSS score, CWE classification, or NVD exploit assessment yet, but the underlying kernel discussion describes a concrete out-of-bounds write condition in IPv4’s
Kernel maintainers fixed the issue upstream on June 21 in the networking tree. The patch was authored by Wongi Lee, reviewed by NVIDIA’s Ido Schimmel, and accepted by network maintainer Jakub Kicinski. It corrects handling of fraggap, data carried from a preceding socket buffer into the next packet fragment.
The vulnerable path is used when Linux assembles IPv4 output using paged allocations rather than keeping all payload data in a conventional linear buffer. This matters for zero-copy-oriented send patterns, where applications can ask the kernel to append data and reuse pages rather than repeatedly copying payloads.
Before the fix, the paged path allocated its linear region from the combined header lengths, then assigned the rest of the payload to paged storage. That arithmetic overlooked
The result was a mismatch: the linear region was too small by the size of the fragment gap, while the paged portion was correspondingly too large. Subsequent copying could therefore continue beyond the intended end of the linear allocation and into adjacent
That is the security-relevant distinction. A bad length calculation in packet output is not automatically remotely reachable or trivially exploitable, but an out-of-bounds write in kernel networking code deserves prompt patching—particularly on systems that run untrusted workloads, container tenants, build agents, or developer tooling capable of exercising advanced socket APIs.
The upstream correction is small and direct: add
That narrowed trigger should guide prioritization. Workstations that merely run a Linux distribution in WSL 2 are less exposed than multi-user Linux hosts or container platforms where locally controlled workloads can invoke specialized networking behavior. But narrower is not the same as harmless: many modern high-performance services, proxy stacks, storage pipelines, and application runtimes deliberately use zero-copy features.
The original vulnerable IPv4 behavior was introduced by the Linux commit labeled “ipv4: avoid partial copy for zc,” with the affected code present from Linux 6.0 onward. The issue has a related IPv6 counterpart, CVE-2026-53362, covering the analogous IPv6 paged-allocation path. Administrators should not mistake patching one for coverage of the other.
The practical rule is to consult the distribution’s advisory and installed package changelog, then patch through the normal vendor channel. Do not conclude a system is safe or vulnerable solely from the leading kernel version number.
The June 24 stable request asked for both the IPv4 and IPv6 corrections to be applied through Linux 6.1, 6.6, 6.12, 6.18, 7.0, and 7.1 maintenance trees. The requester noted that the IPv4 fix needed small context-only backports on 6.1, 6.6, and 6.12, another reason distribution-specific patch status may vary.
As of July 17, Microsoft’s WSL2-Linux-Kernel repository identifies
That does not establish a practical WSL 2 exploit. Microsoft may have separately backported the commit, its kernel configuration and virtualization boundary may limit applicable scenarios, and no public exploit has been identified in the NVD entry. But it does make the version gap worth tracking for developers and administrators who use WSL 2 with locally untrusted code, experimental networking tools, or custom kernels.
Run
For native Linux fleets, the next action is straightforward: deploy the vendor kernel update that incorporates the upstream repair and separately verify coverage for CVE-2026-53362. For WSL 2, the outstanding milestone is a Microsoft kernel build at—or explicitly backporting—the Linux 6.18.38 fix.
MSG_MORE with MSG_SPLICE_PAGES. For Windows users, the immediate concern is WSL 2, which runs a real Linux kernel inside its lightweight VM; WSL 1 does not use that kernel architecture.The National Vulnerability Database published the record on July 16, 2026, with kernel.org as the source. The record has no CVSS score, CWE classification, or NVD exploit assessment yet, but the underlying kernel discussion describes a concrete out-of-bounds write condition in IPv4’s
__ip_append_data() path—not merely a cosmetic accounting error.Kernel maintainers fixed the issue upstream on June 21 in the networking tree. The patch was authored by Wongi Lee, reviewed by NVIDIA’s Ido Schimmel, and accepted by network maintainer Jakub Kicinski. It corrects handling of fraggap, data carried from a preceding socket buffer into the next packet fragment.
A zero-copy fast path miscounted its buffer space
The vulnerable path is used when Linux assembles IPv4 output using paged allocations rather than keeping all payload data in a conventional linear buffer. This matters for zero-copy-oriented send patterns, where applications can ask the kernel to append data and reuse pages rather than repeatedly copying payloads.Before the fix, the paged path allocated its linear region from the combined header lengths, then assigned the rest of the payload to paged storage. That arithmetic overlooked
fraggap bytes that had already been included in the total data length but still needed to be copied into the new socket buffer’s linear region.The result was a mismatch: the linear region was too small by the size of the fragment gap, while the paged portion was correspondingly too large. Subsequent copying could therefore continue beyond the intended end of the linear allocation and into adjacent
skb_shared_info data.That is the security-relevant distinction. A bad length calculation in packet output is not automatically remotely reachable or trivially exploitable, but an out-of-bounds write in kernel networking code deserves prompt patching—particularly on systems that run untrusted workloads, container tenants, build agents, or developer tooling capable of exercising advanced socket APIs.
The upstream correction is small and direct: add
fraggap to the linear allocation length, subtract it from the paged length, and remove an obsolete comment that described the old arithmetic. The non-paged allocation path already accounted for the same bytes, which made the discrepancy easier to isolate.The trigger is narrower than “all IPv4 traffic”
This is not a flaw that ordinary web browsing or a standard inbound IPv4 packet can be assumed to trigger. The stable-backport request sent to Linux maintainers states that the problematic condition occurs whenMSG_MORE is used together with MSG_SPLICE_PAGES.MSG_MORE tells the kernel that additional outbound data will follow, allowing it to defer packet construction. MSG_SPLICE_PAGES is tied to newer zero-copy and page-splicing mechanisms, enabling data pages to be passed into the networking stack without the usual copy. The combination puts the code onto the paged allocation route where the fragment-gap count was wrong.That narrowed trigger should guide prioritization. Workstations that merely run a Linux distribution in WSL 2 are less exposed than multi-user Linux hosts or container platforms where locally controlled workloads can invoke specialized networking behavior. But narrower is not the same as harmless: many modern high-performance services, proxy stacks, storage pipelines, and application runtimes deliberately use zero-copy features.
The original vulnerable IPv4 behavior was introduced by the Linux commit labeled “ipv4: avoid partial copy for zc,” with the affected code present from Linux 6.0 onward. The issue has a related IPv6 counterpart, CVE-2026-53362, covering the analogous IPv6 paged-allocation path. Administrators should not mistake patching one for coverage of the other.
Fixed upstream releases are already identified
According to the NVD’s current kernel.org data, the IPv4 issue is fixed in these upstream release lines:- Linux 6.6.144 and later within the 6.6 series.
- Linux 6.12.95 and later within the 6.12 series.
- Linux 6.18.38 and later within the 6.18 series.
- Linux 7.1.3 and later within the 7.1 series.
- Linux 7.2-rc1 and later in the development line.
uname -r version is lower than one of the upstream release numbers.The practical rule is to consult the distribution’s advisory and installed package changelog, then patch through the normal vendor channel. Do not conclude a system is safe or vulnerable solely from the leading kernel version number.
The June 24 stable request asked for both the IPv4 and IPv6 corrections to be applied through Linux 6.1, 6.6, 6.12, 6.18, 7.0, and 7.1 maintenance trees. The requester noted that the IPv4 fix needed small context-only backports on 6.1, 6.6, and 6.12, another reason distribution-specific patch status may vary.
WSL 2 users should watch Microsoft’s kernel servicing cadence
Windows itself is not affected in the same way as a native Linux host. The Windows networking stack is not Linuxnet/ipv4/ip_output.c. However, WSL 2 runs the Microsoft-maintained Linux kernel, and Microsoft’s own WSL documentation confirms that WSL 2 uses a full Linux kernel delivered separately from the Windows OS image.As of July 17, Microsoft’s WSL2-Linux-Kernel repository identifies
6.18.35.2 as its latest released kernel source package, dated June 19. That is below upstream Linux 6.18.38, the version kernel.org currently marks as fixed for CVE-2026-53366. Microsoft has not, at publication time, publicly listed this CVE as resolved in a WSL release.That does not establish a practical WSL 2 exploit. Microsoft may have separately backported the commit, its kernel configuration and virtualization boundary may limit applicable scenarios, and no public exploit has been identified in the NVD entry. But it does make the version gap worth tracking for developers and administrators who use WSL 2 with locally untrusted code, experimental networking tools, or custom kernels.
Run
wsl --version or wsl --status to inspect the installed kernel, and use wsl --update to obtain Microsoft’s latest servicing release. Organizations that pin WSL packages, block Microsoft Store servicing, or deploy custom .wslconfig kernels should treat that update path as an operational task rather than assuming Windows Update alone will cover it.For native Linux fleets, the next action is straightforward: deploy the vendor kernel update that incorporates the upstream repair and separately verify coverage for CVE-2026-53362. For WSL 2, the outstanding milestone is a Microsoft kernel build at—or explicitly backporting—the Linux 6.18.38 fix.
References
- Primary source: NVD / Linux Kernel
Published: 2026-07-17T01:01:26-07:00
NVD - CVE-2026-53366
nvd.nist.gov
- Security advisory: MSRC
Published: 2026-07-17T01:01:26-07:00
Original feed URL
Security Update Guide - Microsoft Security Response Center
msrc.microsoft.com