CVE-2026-72020

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.