From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: passt.top; dmarc=fail (p=quarantine dis=none) header.from=redhat.com Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by passt.top (Postfix) with ESMTPS id 034E15A0271 for ; Wed, 11 Nov 2026 08:03:28 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1794380607; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=WWSg/cwAQYFj7vDROOkbUr6aGod3wi5dUoDor+PbW3k=; b=cgRTiXLsQw/29QiQLPJvTK29oridsXuJOWg2xqDTaAE2nuQzn53tFhnON1HRWgHip8He8+ TVdweJbsBevvOyVaI4dfbiWXzcqyJg1emLuVA4eZeB03RNvbphWgWMeEnx2sAkEVcbiG7S Pe2Kb56CMFRzBFjhv70QNXMEVfnSGnw= Received: from mail-wm1-f70.google.com (mail-wm1-f70.google.com [209.85.128.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-358-q7ec8Y3hO0Sq-A6S2xK5Ng-1; Wed, 11 Nov 2026 02:03:26 -0500 X-MC-Unique: q7ec8Y3hO0Sq-A6S2xK5Ng-1 X-Mimecast-MFC-AGG-ID: q7ec8Y3hO0Sq-A6S2xK5Ng_1794380605 Received: by mail-wm1-f70.google.com with SMTP id 5b1f17b1804b1-4afef353dd2so28337295e9.1 for ; Tue, 10 Nov 2026 23:03:26 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1794380605; x=1794985405; h=date:content-transfer-encoding:content-type:mime-version :organization:references:in-reply-to:message-id:subject:cc:to:from :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to:content-type; bh=WWSg/cwAQYFj7vDROOkbUr6aGod3wi5dUoDor+PbW3k=; b=DZLn4FgXe31gypDaHZ1sm610l+ceE1LWTKQoT6d7MpQaxBLNZj4i/d/UZ5Ox94dWJJ Dhq27cFkRVoN0TZmiP8eItu+V2an3WzSmwjpxxKwLaQnNa7mAoErQ6vnIOjVsiSmZSp9 riaBZ3vBC8abauCU41hIv5uP9PGIgwfM+8eS2yJuKiRHPACg6pFoN03x9Lx8fJvWVoDk +UkuECAAsxv+zzYKS9x/Oz6get4jrfYfZ5+mdch8T9+3jRgXMj/0ew/jTlzvoZsi2Iel 81KW2Tu6LWJP8OU2YincgmQ9gW9/S6p/PQdJ/sbpMznyEZsX+g7TB2hwRb5hdt8/V4eR 6MKg== X-Gm-Message-State: APuU4Z/S23dUQzWt5sjrPnQ4zVIwmzyCq9o8PXp+0t6bsaaxnfDj5nWB 6s1k02JBH+lxVzMrcYbdr3pfknUMQk/oFiggsvktn7Ne8IHHjKh7Saf3D9UrFom7gXHnTetmfjQ AqP8E2S3BuQg5EvH8Zj2gdmVkQNyZqXRYWc5A8MgUAcixJTIBNd10cuhRdVuJ6y5YSSQszSL2+H zrlg06Y59zwlBWzMflhlp4F9/lyNB6eUFsIxVe X-Gm-Gg: AYBFou0wWUTH76Q1t8LM37y4YIkw11gdUjiGF56oON1SZ6R45AcpSoGiFiJmyzU+O6+ iuu+0qmNfNuoxuSqgAzLQawDQKGtgcBYM1QnNSsVfKEYHQz/s5gE4zRHWif3oYveipyufNPOhv5 wyYxB2SJfhTJsZFJHSThxLj59AuVCv84MskIrWxP/RtRpcxyjemNU7pbEWsNktSsfQXvCwvjoqV 68DspUOuOsMoj+X0LD/RdHcl+O6wP6gieh4+O9a2O0saJCT5NA+Ke+1vimJ+qjp/f/sVm6pe+jX cHS23CV+GhYf3Bi9iNbBtfyCQOyEWQuS91wuZ36mRSIdmaqUIvYLp+WzDfsrvWhs3dYbT7PP2ax XfPiSyzPuf9DKydEa4Cnub04Re/qZcCS9Sv2HddJ6q90qUPeFLZN5rjzlaEnj8oz6qFtKfAAYdh gdhEtDsF7w X-Received: by 2002:a05:600c:19d0:b0:4a2:150f:1610 with SMTP id 5b1f17b1804b1-4ba09380561mr22989675e9.23.1794380604852; Tue, 10 Nov 2026 23:03:24 -0800 (PST) X-Received: by 2002:a05:600c:19d0:b0:4a2:150f:1610 with SMTP id 5b1f17b1804b1-4ba09380561mr22988805e9.23.1794380604116; Tue, 10 Nov 2026 23:03:24 -0800 (PST) Received: from maya.myfinge.rs (ifcgrfdd.trafficplex.cloud. [176.103.220.4]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4ba01fe2f09sm132253205e9.4.2026.11.10.23.03.20 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 10 Nov 2026 23:03:20 -0800 (PST) From: Stefano Brivio To: Anshu Kumari Subject: Re: [PATCH v2] tcp: Avoid division by zero with small MSS values Message-ID: <20261111080319.2d2fccb8@elisabeth> In-Reply-To: <20261026111820.1600260-1-anskuma@redhat.com> References: <20261026111820.1600260-1-anskuma@redhat.com> Organization: Red Hat X-Mailer: Claws Mail 4.2.0 (GTK 3.24.49; x86_64-pc-linux-gnu) MIME-Version: 1.0 Date: Wed, 11 Nov 2026 08:03:19 +0100 (CET) X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: XKtNEL4w_p0xtjj63e6ea6mGW5TRwWbjUkgVwK9sXQ0_1794380605 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Message-ID-Hash: YTRK2V4CH44P5KHFBIAC3SB77ZMCTFTR X-Message-ID-Hash: YTRK2V4CH44P5KHFBIAC3SB77ZMCTFTR X-MailFrom: sbrivio@redhat.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: passt-dev@passt.top X-Mailman-Version: 3.3.8 Precedence: list List-Id: Development discussion and patches for passt Archived-At: Archived-At: List-Archive: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: On Mon, 26 Oct 2026 16:48:20 +0530 Anshu Kumari wrote: > Fuzz testing with AFL++ persistent mode found that > tcp_buf_data_from_sock() terminates the process with SIGFPE > (signal 8) from division by zero at: >=20 > fill_bufs =3D DIV_ROUND_UP(wnd_scaled - already_sent, mss); >=20 > when MSS is small enough (less than four) to round down to 0 > during the bit-shift in MSS_SET(). The termination itself is > clean (not memory corruption or data leakage), but we can > handle this condition more gracefully. >=20 > We considered resetting connections with a zero or very low > MSS, but concluded this is not RFC-compliant: RFC 9293, > section 3.1 (MUST-7), states: "TCP implementations MUST be > prepared to handle an illegal option length (e.g., zero); a > suggested procedure is to reset the connection and log the > error cause." However, this applies only to option *lengths*, > not *values* =E2=80=94 no standard RFC defines a minimum MSS value. > Section 3.5.2 further states: "A reset must not be sent if > it is not clear that this is the case." Very low MSS values > also have legitimate uses in microcontroller applications > with limited buffers, and a zero MSS could represent a > unidirectional connection. >=20 > Rounding a low MSS upward is also not an option: emitting > segments larger than the peer advertised violates the > effective send MSS requirement in RFC 9293, section 3.7.1. >=20 > Instead, preserve the actual MSS: >=20 > - Adjust MSS_SET() to clamp non-zero values below 4 to 1, > avoiding the round-to-zero in bit-field storage. > - Adjust MSS_GET() to return 1 when tap_mss is 1, so we > never inflate the MSS beyond what the peer advertised. > - When MSS is zero, don't send data: > tcp_buf_data_from_sock() returns early. The peer will > eventually determine the connection is unusable and > reset it. >=20 > Signed-off-by: Anshu Kumari > --- > v2: > - added comment for both MSS_SET() and MSS_GET() macro. > - fixed/modified MSS_GET(). > - fixed commit message by explaining why we are not > resetting the connection. >=20 > NOTE: let the fuzzer run for more than a day with this > fix but till now, haven't found any issue. Applied. --=20 Stefano