From nobody Tue Jun 15 19:34:49 2021 X-Original-To: standards@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4AD7B11E01DF for ; Tue, 15 Jun 2021 19:34:49 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4G4JRs1PT1z4vVM for ; Tue, 15 Jun 2021 19:34:49 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 18C9B625F for ; Tue, 15 Jun 2021 19:34:49 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 15FJYnYP083915 for ; Tue, 15 Jun 2021 19:34:49 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 15FJYn7r083914 for standards@FreeBSD.org; Tue, 15 Jun 2021 19:34:49 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: standards@FreeBSD.org Subject: [Bug 191586] FreeBSD doesn't validate negative edgecases in bind(2)/connect(2)/listen(2) like POSIX requires Date: Tue, 15 Jun 2021 19:34:49 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: standards X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: markj@FreeBSD.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: standards@FreeBSD.org X-Bugzilla-Flags: mfc-stable10? mfc-stable9? mfc-stable8? X-Bugzilla-Changed-Fields: bug_status cc resolution Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Standards compliance List-Archive: https://lists.freebsd.org/archives/freebsd-standards List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-standards@freebsd.org X-BeenThere: freebsd-standards@freebsd.org MIME-Version: 1.0 X-ThisMailContainsUnwantedMimeParts: N https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D191586 Mark Johnston changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Open |Closed CC| |markj@FreeBSD.org Resolution|--- |FIXED --- Comment #14 from Mark Johnston --- I don't think there is anything left to do here, so I'll preemptively close= the PR. Please feel free to re-open if necessary. On top of the commited patch, we recently added more validation for sa_fami= ly and sa_len in various protocols. This was because missing sa_len checks allowed programs to trigger out-of-bounds accesses in the kernel when exami= ning protocol-specific sockaddr fields. As a part of that, I moved checks out of the inpcb code and into specific procotol implementations. In comment 4 we have: ----- It's arguable that the check should actually be happening in a higher level protocol family function, or even based on protocol family metadata at one higher level than that, where the dispatch to the protocol family via AF_IN= ET as the value got it into the protocol family code in the first place. In other words, the upper layer bind/connect code prior to the protocol dispatch, based on a "check address family first" bit in the protocol family descriptor. ----- which I agree with, but as I understand would be an enhancement rather than= a bug fix. We still deviate from POSIX in at least a couple of ways. First, protocol implementations for connect(2) return ENOAFSUPPORT rather than EINVAL if the address family doesn't match what they expect. I believe that is consistent with MacOS and Linux. Second, the TCP and UDP implementations permit bind(= 2) on AF_INET sockets when sa_family =3D=3D AF_UNSPEC and sin_addr =3D=3D INAD= DR_ANY. In other words, the check referenced in comment 7 is now enabled (albeit at a different layer), with this one exception required to avoid breaking some popular software, notably ttcp. --=20 You are receiving this mail because: You are the assignee for the bug.=