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

1216–1219

what's msg_namelen's type?

[trasz]

sys/compat/linux/linux_socket.c

1216–1219

It's socklen_t.

[kib]

sys/compat/linux/linux_socket.c

1199–1200

Is it fine to not check msg_namelen there ?

1216–1219

Fix the style while there, msg_name != NULL ?

[emaste]

sys/compat/linux/linux_socket.c

1216–1219

should it be > 0 not != 0?

[trasz]

Fix various issues.

[trasz]

sys/compat/linux/linux_socket.c

1216–1219

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

[kib]

sys/compat/linux/linux_socket.c

1201

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

1216–1219

Isn't msg_namelen > 0 recheck is redundant ?

[trasz]

sys/compat/linux/linux_socket.c

1201

Hah, good catch!

1216–1219

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

1219

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

1219

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.