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

[bugzilla-noreply at freebsd.org]

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

--- Comment #5 from Kevin Lo <kevlo at FreeBSD.org> ---
(In reply to Terry Lambert from comment #4)
> Since this isn't a "MAY", this is a "SHALL", I still *totally agree* with
> you that it's a missing mandatory check, and can't be ignored, but this is
> not necessarily the proper place for it, without the side effect testing.
> 
> --
> 
> It's reasonable, but it would need some better testing.  My initial
> objection to a "just make it all work" was only based on the unit test not
> testing what it claimed it was testing.
> 
> --
> 
> Extra unit testing would be needed because doing the test in
> in_pcbbind_setup() like this also impacts other callers besides in_pcbbind():
> 
>     in_pcbbind()
>     in_pcbconnect_setup(()
> 
> and, as a consequence, their callers:
> 
>     tcp_connect() <- this is where you want it to hit
>     udp_output()
>     udp6_bind()
>     div_bind() <- specifically references that it will be passed a valid
> address
> 
> ...and any other third party connection oriented protocols layered on top of
> IP.
> 
> I also think that POSIX is not specifically concerned with AF_INET, so doing
> the check at this specific location might be simultaneously too narrow in
> scope.
> 
> 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.
> 
> A valid argument against that approach might be that this would add general
> code path overhead for protocols that don't care/don't want the check by
> adding a single bit check and an interior dereference to get the flag bit
> and compare family, but it'd let you throw the right error for "AF_MAX + 10"
> EAFNOSUPPORT, which the code doesn't do, before or after the patch, in some
> circumstances.

In case you missed it, the indentical test in the in6_pcbbind() function 
is performed.  The same check in in_pcbconnect_setup() and in6_pcbladdr()
are also actived.  As comments say if old programs incorrectly fail to 
initialize it, they will return EAFNOSUPPORT.

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