Check the setsockop value size passed by the user before copying it in.

[brooks]

Summary

The current sockoption processing code completely ignores the size of
the passed option when copying it in. This change rejects sizes that
aren't exactly what is expected to prevent bugs like passing size_t
where int is meant.

Test Plan

We should write tests to pass nonsense sizes.

[ngie]

net@ should be CCed on this

Should this logic be shoved into sooptcopyin, given that the appropriate lengths are passed in (just to avoid unnecessary duplication)?

sys/kern/uipc_socket.c

2681

Why not remove this, then remove the surrounding braces in the new code?

[brooks]

In D10519#217948, @ngie wrote:

Should this logic be shoved into sooptcopyin, given that the appropriate lengths are passed in (just to avoid unnecessary duplication)?

sooptcopyin has different and incompatible length checking (even if called with the available length it wouldn't return an error when a size_t is passed in place of an int). We should be calling it correctly, but that won't fix this bug.

sys/kern/uipc_socket.c

2681

What do you refer to by "this"?

[brooks]

In D10519#218051, @brooks wrote:

In D10519#217948, @ngie wrote:

Should this logic be shoved into sooptcopyin, given that the appropriate lengths are passed in (just to avoid unnecessary duplication)?

sooptcopyin has different and incompatible length checking (even if called with the available length it wouldn't return an error when a size_t is passed in place of an int). We should be calling it correctly, but that won't fix this bug.

Upon further reflection, I think we are calling sooptcopyin correctly, it just has a weird interface that isn't what we want here. A sensible approach might be to create an sooptcopyin_exact.

[brooks]

I believe this is the wrong approach, the right approach is likely a sooptcopyin_exact or sooptcopyin_flag. I've submitted https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218919 to track this issue.