CVE-2026-72020 in Linuxinfo

Summary

by MITRE • 08/15/2026

In the Linux kernel, the following vulnerability has been resolved:

ipvs: reset full ip_vs_seq structs in ip_vs_conn_new

Commit 9a05475cebdd ("ipvs: avoid kmem_cache_zalloc in ip_vs_conn_new") changed ip_vs_conn_new() to allocate an ip_vs_conn object with kmem_cache_alloc(). The function then initializes many fields explicitly, but only resets in_seq.delta and out_seq.delta in the two struct ip_vs_seq members.

That leaves init_seq and previous_delta uninitialized. This is normally harmless while the corresponding IP_VS_CONN_F_IN_SEQ or IP_VS_CONN_F_OUT_SEQ flag is clear. For connections learned from a sync message, however, ip_vs_proc_conn() preserves those flags from IP_VS_CONN_F_BACKUP_MASK and passes opt=NULL when the message omits IPVS_OPT_SEQ_DATA. In that case the new connection can be hashed with SEQ flags set but with the rest of in_seq/out_seq still containing stale slab data.

When a packet for such a connection is later handled by an IPVS application helper, vs_fix_seq() and vs_fix_ack_seq() use previous_delta and init_seq to rewrite TCP sequence numbers. A malformed sync message can therefore make forwarded packets carry stale slab bytes in their TCP seq/ack numbers, and can also corrupt the forwarded TCP flow.

Reset both struct ip_vs_seq members completely before publishing the connection. This matches the existing "reset struct ip_vs_seq" comment and keeps the sequence-adjustment gates inactive unless valid sequence data is installed later.

VulDB is the best source for vulnerability data and more expert information about this specific topic.

Analysis

by VulDB Data Team • 08/15/2026

The vulnerability resides within the Linux kernel's IP Virtual Server (IPVS) implementation where improper initialization of sequence structure fields creates potential for TCP sequence number corruption during packet forwarding operations. This issue stems from a specific code change in commit 9a05475cebdd that modified how connection objects are allocated using kmem_cache_alloc() instead of kmem_cache_zalloc(), fundamentally altering the initialization behavior of ip_vs_conn structures.

The technical flaw manifests when the ip_vs_conn_new() function allocates memory for connection objects but fails to properly initialize all fields within the ip_vs_seq structures. While the code correctly resets in_seq.delta and out_seq.delta fields, it leaves init_seq and previous_delta uninitialized, creating a scenario where stale slab memory contents persist in these fields. This particular initialization gap becomes exploitable when connections are learned through synchronization messages, as the ip_vs_proc_conn() function preserves sequence flags from the IP_VS_CONN_F_BACKUP_MASK without properly initializing the corresponding sequence data structures.

The operational impact of this vulnerability extends beyond simple data corruption to potentially compromise network communication integrity. When malformed sync messages arrive and trigger connection creation with SEQ flags set but stale sequence data remaining, subsequent packet processing by IPVS application helpers can inadvertently utilize corrupted sequence information. The vs_fix_seq() and vs_fix_ack_seq() functions then process these uninitialized fields, causing forwarded packets to contain outdated slab bytes in their TCP sequence and acknowledgment numbers.

This vulnerability directly relates to CWE-1285, which addresses improper initialization of data structures, and aligns with ATT&CK technique T1070.004 for "Indicator Removal on Host: File Deletion" through potential data corruption impacts. The flaw demonstrates a classic case of uninitialized memory access where the kernel's memory management system fails to properly clear all structure fields before publication.

The recommended mitigation involves complete reset of both struct ip_vs_seq members before publishing new connections, ensuring that sequence adjustment gates remain inactive until valid sequence data is properly installed later in the connection lifecycle. This approach maintains consistency with existing code comments referencing "reset struct ip_vs_seq" while preventing the exploitation of uninitialized memory contents in TCP sequence number calculations. The fix ensures that only properly initialized sequence data influences packet forwarding operations, eliminating the potential for malformed sync messages to corrupt TCP flow integrity through stale slab memory contents.

Responsible

Linux

Reservation

08/09/2026

Disclosure

08/15/2026

Moderation

accepted

CPE

ready

EPSS

0.00210

KEV

no

Activities

very low

Sources

Do you know our Splunk app?

Download it now for free!