pf: Fix ioctls which copy out arrays

[markj]

Summary

A number of pf ioctls which copy out arrays have the following
structure:

• Caller specifies the size of the array
• ioctl handler allocates a buffer to store it
• ioctl handler populates the array, returning the actual number of items back to userland
• ioctl handler copies the array to userland

It can happen that the caller specified a size larger than the resulting
array. In this case we were leaving some entries uninitialized but
copying them out anyway. This change modifies the ioctl handlers to
copy out only the number of array entries that we return.

Reported by: KMSAN
Sponsored by: The FreeBSD Foundation

[markj]

Consistently use braces around multiline statements.

[kp]

This is clearly an improvement, but I think it doesn't cover everything.

All these call a function that can still fail to copy data into the buffer. If the provided size is too small they'll only update the size pointer and return 0. They will not write to the buffer. So we can still end up copying out an uninitialised array. (except for pfi_get_ifaces())
The easiest fix would be to add M_ZERO to the mallocarray() calls.

[markj]

In D31313#705343, @kp wrote:

This is clearly an improvement, but I think it doesn't cover everything.

All these call a function that can still fail to copy data into the buffer. If the provided size is too small they'll only update the size pointer and return 0. They will not write to the buffer. So we can still end up copying out an uninitialised array. (except for pfi_get_ifaces())
The easiest fix would be to add M_ZERO to the mallocarray() calls.

Ah, I hadn't noticed this. It's kind of strange that we copy out even when we have nothing to copy.I did it this way partly to avoid needless zeroing of arrays that we're going to overwrite anyway, but it's probably best to just keep things simple and zero the arrays.

[markj]

Simply zero arrays that get initialized by the kernel before being
copied out.