Fix Linux recvmsg(2) when msg_namelen returned is 0

[trasz]

Summary

Fix Linux recvmsg(2) when msg_namelen returned is 0. Previously it would fail with EINVAL, breaking some of the Python regression tests.

Note that the code doesn't seem to be copying out the new length in either (success or failure) case. This will be addressed separately.

[emaste]

sys/compat/linux/linux_socket.c

1202

what's msg_namelen's type?

[trasz]

sys/compat/linux/linux_socket.c

1202

It's socklen_t.

[kib]

sys/compat/linux/linux_socket.c

1188

Is it fine to not check msg_namelen there ?

1202

Fix the style while there, msg_name != NULL ?

[emaste]

sys/compat/linux/linux_socket.c

1202

should it be > 0 not != 0?

[trasz]

Fix various issues.

[trasz]

sys/compat/linux/linux_socket.c

1202

Not sure if the check is needed, but better safe than sorry.

[kib]

sys/compat/linux/linux_socket.c

1189

Is msg_namelen user-controlled ? Does it allow for arbitrary-sized allocations controlled by user ?

1202

Isn't msg_namelen > 0 recheck is redundant ?

[trasz]

sys/compat/linux/linux_socket.c

1189

Hah, good catch!

1202

It isn't, that's the whole point of this change: kern_recvit() updates it. I guess I should add a comment about it.

[trasz]

Add comment explaining the second check, and cap the buffer size.

[trasz]

(Tinderboxed.)

[kib]

sys/compat/linux/linux_socket.c

1205

What should the code do if msg->msg_name != NULL but msg->msg_namelen == 0 (after the kern_recvit()) ?

[trasz]

sys/compat/linux/linux_socket.c

1205

My guess is it should copyout the new length. But right now the code does not copyout the length in any case, and like previously, I prefer the small steps approach. I'll mention it in the commit message.