[Bug 191586] FreeBSD doesn't validate negative edgecases in bind(2)/connect(2)/listen(2) like POSIX requires

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=191586

Mark Johnston <markj@FreeBSD.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|Open                        |Closed
                 CC|                            |markj@FreeBSD.org
         Resolution|---                         |FIXED

--- Comment #14 from Mark Johnston <markj@FreeBSD.org> ---
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_family
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 examining
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_INET
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 == AF_UNSPEC and sin_addr == INADDR_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.

-- 
You are receiving this mail because:
You are the assignee for the bug.