Page MenuHomeFreeBSD

Make getnameinfo(3) salen requirement less strict
ClosedPublic

Authored by hrs on Mar 5 2018, 3:20 PM.

Details

Summary

getnameinfo(3) currently returns EAI_FAIL when salen is not equal to
the length corresponding to the value specified by sa->sa_family.
However, POSIX does not require it and RFC 4038 Sec.6.2.3 shows
an example passing sizeof(struct sockaddr_storage) to salen.

This patch makes the requirement less strict by accepting
salen up to sizeof(struct sockaddr_storage). It also includes
two more changes: one is to fix return values because SUSv4 requires
EAI_FAMILY when the address length is invalid, another is to fix
sa_len dependency in PF_LOCAL.

Diff Detail

Repository
rS FreeBSD src repository
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.

Event Timeline

hrs created this revision.Mar 5 2018, 3:20 PM
ae added a subscriber: ae.Mar 5 2018, 5:28 PM
ae added inline comments.
lib/libc/net/getnameinfo.c
131 ↗(On Diff #39957)

I'm not sure that this check is useful. Why we need to restrict the size of this buffer if it is enough to keep needed structure?

hrs added inline comments.Mar 6 2018, 7:29 AM
lib/libc/net/getnameinfo.c
131 ↗(On Diff #39957)

It is because salen argument must contain the length of the address pointed to by sa, not an arbitrarily long buffer (this is what SUSv4 specifies). In practice, it is harmless to have a longer salen as far as sa actually points the longer buffer, but such a longer salen is naturally not equal to the actual length of the address. I think the address-family-independent nature of this API implies that the length of the address is equal to or shorter than sizeof(struct sockaddr_storage) at least. This is the reason why I think it is still reasonable to loosen the restriction to the range of (afd->a_socklen <= salen < sizeof(struct sockaddr_storage)) while I still believe the programmer should set salen to the exact value depending on sa_family from the beginning.

ae accepted this revision.Mar 6 2018, 12:51 PM
This revision is now accepted and ready to land.Mar 6 2018, 12:51 PM
This revision was automatically updated to reflect the committed changes.