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.129.124]) by passt.top (Postfix) with ESMTPS id C00CC5A0265 for ; Wed, 21 Oct 2026 10:48:15 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1792572494; 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=hI+qzH2Gob0L8x+PQKxYBbHYy+8nCRCM5/qRnIsjmrI=; b=XfwQcdlwm+gV1i/h/Rzk/LCVSRajsEAhsU7X5wwfKFPpI5rZ3MTkXGdg82+jG8lsEkTPsl gvJmchWLJycw8ReBOXXV6iKZ5zEPsCoMx9KleUW3rVHc78JAi+DMLe5sou1bKmuHEIIf6L /CRy4gpZPpLq9cJWYXseV2SYoEoNNqk= Received: from mail-wr1-f72.google.com (mail-wr1-f72.google.com [209.85.221.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-645-jzVXVz58Od6lg4xN0xrTaA-1; Wed, 21 Oct 2026 08:48:13 +0000 X-MC-Unique: jzVXVz58Od6lg4xN0xrTaA-1 X-Mimecast-MFC-AGG-ID: jzVXVz58Od6lg4xN0xrTaA_1792572492 Received: by mail-wr1-f72.google.com with SMTP id ffacd0b85a97d-48b01a74792so321853f8f.0 for ; Wed, 21 Oct 2026 01:48:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1792572492; x=1793177292; 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=w58K/5XhQz7yvVFL0g2PEOYtVtWwiAkOhbFAfjCKIrw=; b=oW6ON5e6T1kRJgr8wYlRrwmv64sSQEiVjHORgtVplESp4R6qOS8aWiTH1YpWKYBYjJ wDguqvTIlQusdTVPjhd4hQlB4k7kv1zxku2QxEbOn5QvhyfJdpFebL5vJ5mertIrOgxz fWkg1YUEAwRzNu+FLFSVf5HeWSMCcEHtKOQC3O/OiXR7HGT2e7czg8akdb1OKLbWXFYI 0UzAmlWls8OiHTFDhOEpLs5hu835r3MVWBm0XGV/vH1PhD/QKLHY+wXkSbMwtohv3aMr ofk2Z11F+Qu/ebtingcXsG9S8qULAndYXenrSt2EpI9Hqr3/QGLj+oBPGnhJDs1zy2dZ vUXw== X-Forwarded-Encrypted: i=1; AKwUvBymThWfPk0FLOBdmlwUmu1OKb4yAST/0Wx+OKN6/kH9Neo+rr9/N96MvKzAo4NoLGUbdoyxhgKD46w=@passt.top X-Gm-Message-State: AFq9FYKUx3zddpS5ZNvXWZMmHttGjEsSQ56+qGLX0S5NO9Qy8GY4qiFN 6De8/lfW62sVmyT0d6WZj8KKtNH8JmsXxeRX2WvzeCm8yrt2BcWU87H2ha0JMTAiQJ/5I/DEi0B KZQ2Ge0jrE3jWhjE0cIgoFkjHXJd35Qf30wd89HoJoE4hsu5u8akaDA== X-Gm-Gg: AYBFou0Kc9yMWN68sERincd4Qpx4WadVGqk5ZY3I7M+9i6T5RsbyNPbqJMS+yDi5UjD pL0M7Fi4Rw7h9oZ3e11pcmd+qWqwG0q9ztP1Zg7qAHXUoB6Th3pGHiBEUsMjPLlHZ2bamt80/4a ab7yKDhUo+jl97zwLKdvj8nTolES+SuivtVEBLplE3fsiwndpF+kzFwvN3wkdKgV3mrLAnVRkwI Y8TIGOzaBHQH0aXURHcnqf5UUKlzt0iMCCHqxNgVDsXJqefPOzaeQSzysE/5Yy5lueRnypYm4iO /bOtWBw2+VxRtI72UqQC/Pu/HAUs3cD0ieUv12MzG9v6i8GCj0FRt82j2EOpzMk2+1PQZijFtCp KrJoFWTIUGPjKi07F06BRJwjSKAs= X-Received: by 2002:a5d:5d09:0:b0:487:342:d141 with SMTP id ffacd0b85a97d-48e2649da0dmr2969543f8f.23.1792572491703; Wed, 21 Oct 2026 01:48:11 -0700 (PDT) X-Received: by 2002:a5d:5d09:0:b0:487:342:d141 with SMTP id ffacd0b85a97d-48e2649da0dmr2969488f8f.23.1792572491123; Wed, 21 Oct 2026 01:48:11 -0700 (PDT) Received: from maya.myfinge.rs (ifcgrfdd.trafficplex.cloud. [176.103.220.4]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-48e2581eed3sm4422449f8f.12.2026.10.21.01.48.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 21 Oct 2026 01:48:10 -0700 (PDT) From: Stefano Brivio To: David Gibson Subject: Re: [PATCH] tcp: Avoid division by zero with small MSS values Message-ID: <20261021104809.0db3d744@elisabeth> In-Reply-To: References: <20261016112811.4176811-1-anskuma@redhat.com> <20261021021112.385ea997@elisabeth> 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, 21 Oct 2026 10:48:09 +0200 (CEST) X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: NgISduPpFEL9DSYfmM_IvpP3Poe2qJnv0lOGVfbdnsc_1792572492 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Message-ID-Hash: XAH2JAGT4X4C3GMDOBUQ6MLQ7Y6YWI6X X-Message-ID-Hash: XAH2JAGT4X4C3GMDOBUQ6MLQ7Y6YWI6X 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: Anshu Kumari , 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 Wed, 21 Oct 2026 12:38:42 +1100 David Gibson wrote: > On Wed, Oct 21, 2026 at 02:11:13AM +0200, Stefano Brivio wrote: > > On Fri, 16 Oct 2026 16:58:11 +0530 > > Anshu Kumari wrote: > > =20 > > > Fuzz testing with AFL++ persistent mode found a crash =20 > >=20 > > Yay, that's quite an achievement! > > =20 > > > in > > > tcp_buf_data_from_sock(), SIGFPE (signal 8) from division > > > by zero at: > > >=20 > > > fill_bufs =3D DIV_ROUND_UP(wnd_scaled - already_sent, mss); > > >=20 > > > when we split buffers on MSS boundaries, if the MSS is small > > > enough (less than four, rounded down to 0). > > >=20 > > > A guest advertising such a small MSS indicates unusual > > > behaviour because the minimum usable MSS is > > > MTU - IP header - TCP header (28 bytes for the minimum > > > IPv4 MTU of 68). To improve robustness: > > >=20 > > > - Fix MSS_SET() to round up when MSS is between 1 and 3, > > > storing tap_mss as 1 (recovered as 4 by MSS_GET()). =20 > >=20 > > This introduces a subtle problem though: if the MSS is between 1 and 3 > > (silly but I guess legitimate), we would overflow it now. > >=20 > > I think we should rather adjust MSS_GET() as well, to always use 1 for > > values 0 < x < 4. > > =20 > > > - In case of zero MSS, don't send data: tcp_buf_data_from_sock() > > > now returns early. > > >=20 > > > This is not a security issue: the effect of a zero MSS from > > > a guest input was a clean process termination (SIGFPE), not > > > memory corruption or data leakage. =20 > >=20 > > And, actually, a rather convenient termination because the guest might > > be doing something nasty here, so much that an assert() could also be a > > reasonable choice instead (even though I still think that trying to be > > robust against this condition makes more sense). =20 >=20 > assert() seems dubious to me, but resetting the connection would > certainly be reasonable. In fact, it might be best to send an RST > immediately to a SYN with MSS of 0, since such a connection would be > useless. We pondered with Anshu about that for a long while (and a summary of this should probably be part of the commit message): it was actually my favourite solution when we started looking into it, but then realised that: 1. from a use case perspective: a. very low MSSes are not uncommon in microcontroller applications (let's say you have just 100-200 bytes available to process at a given time, and short commands, or want the peer to split messages / commands for you onto specific boundaries) b. what about 0 though? It might be a "probe" connection, and that would be legitimate (we looked into all possible RFCs and couldn't find a single sentence preventing that). It might also be meant as a unidirectional connection 2. from a RFC perspective: a. from RFC 9293, section 3.1: "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 (MUST-7)." But this is just about illegal option *lengths*, there's no such thing as an illegal option *value*. And not even RFC 9293 sets a minimum legal or expected value for the MSS b. again from RFC 9293, 3.5.2: "A reset must not be sent if it is not clear that this is the case." This requirement seems to be overridden here and there in the same RFC, but in very specific ways. >From this we concluded that it's not really compliant to reset the connection in this case. The next concern was going for transparency as much as we could: what's the minimum for TCP_MAXSEG we can advertise to the peer? It was January 2000, and the definition of TCP_MIN_MSS as 88 bytes appeared in Linux 2.3.41pre2. We looked up related discussions but couldn't find anything, except for: https://unix.stackexchange.com/questions/22410/minimal-tcp-mss-in-linux and there's a rather insightful answer there, based on the _maximum_ possible size of headers. On the other hand, we read and read, and nowhere it's written that all IP implementations must support the maximum size for TCP headers. If a segment is too big, it can be dropped. So, good, we can't reflect this 0 MSS to the peer. The peer might send us data. What can we do at this point? The best we could come up with is: pile it up. Don't send it (because we would overflow a 0 MSS if we send anything). The sender will figure it out. If it wasn't meant to be that way, they will reset the connection, but we don't want to take that responsibility. --=20 Stefano