On Sun, Apr 19, 2026 at 7:55 PM Jiayuan Chen <[email protected]> wrote: > > RFC 5961 Section 5.2 validates an incoming segment's ACK value > against the range [SND.UNA - MAX.SND.WND, SND.NXT] and states: > > "All incoming segments whose ACK value doesn't satisfy the above > condition MUST be discarded and an ACK sent back." > > Commit 354e4aa391ed ("tcp: RFC 5961 5.2 Blind Data Injection Attack > Mitigation") opted Linux into this mitigation and implements the > challenge ACK on the lower side (SEG.ACK < SND.UNA - MAX.SND.WND), > but the symmetric upper side (SEG.ACK > SND.NXT) still takes the > pre-RFC-5961 path and silently returns > SKB_DROP_REASON_TCP_ACK_UNSENT_DATA, even though RFC 793 Section 3.9 > (now RFC 9293 Section 3.10.7.4) has always required: > > "If the ACK acknowledges something not yet sent (SEG.ACK > SND.NXT) > then send an ACK, drop the segment, and return." > > Complete the mitigation by sending a challenge ACK on that branch, > reusing the existing tcp_send_challenge_ack() path which already > enforces the per-socket RFC 5961 Section 7 rate limit via > __tcp_oow_rate_limited(). FLAG_NO_CHALLENGE_ACK is honoured for > symmetry with the lower-edge case. > > Fixes: 354e4aa391ed ("tcp: RFC 5961 5.2 Blind Data Injection Attack > Mitigation") > Signed-off-by: Jiayuan Chen <[email protected]> > > --- > I'm not sure if 'blamed commit' is appropriate, because I think > it's due to missing parts of the implementation, or it might be > directly targeted to net-next.
The Fixes: tag seems appropriate, and net tree LGTM. Reviewed-by: Eric Dumazet <[email protected]> Thanks!
