fuse: Fix GID when sending FUSE_INTERRUPT to a FUSE daemon

[olce]

Summary

Due to the partial-only changes of commit 46c07316f906 ("kern: adopt the
cr_gid macro for cr_groups[0] more widely"), subsequent commit
be1f7435ef218b1d ("kern: start tracking cr_gid outside of cr_groups[]")
caused a mismatch between filling cr_groups[0] in 'reused_creds' in
fuse_interrupt_send() and reading 'cr_gid' from it in
fuse_setup_ihead(), with the consequence that the kernel would send
a FUSE_INTERRUPT message to the FUSE deamon with an uninitialized GID in
its header (which, besides being wrong, would disclose 4 bytes from its
stack).

Fixes: be1f7435ef218b1d ("kern: start tracking cr_gid outside of cr_groups[]")
Sponsored by: The FreeBSD Foundation

[asomers]

What bug exactly does this "fix"? Did you encounter a bug in your work, or did you just discover this problem by inspection? If the former, we should add a test case to tests/sys/fs/fusefs.

[olce]

In D52255#1196962, @asomers wrote:

What bug exactly does this "fix"? Did you encounter a bug in your work, or did you just discover this problem by inspection? If the former, we should add a test case to tests/sys/fs/fusefs.

By inspection. Filling of reused_creds here is paired with reading it in fuse_setup_ihead(), and the two have been in mismatch since commit 46c07316f906 ("kern: adopt the cr_gid macro for cr_groups[0] more widely"). IIUC, this has the consequence that a header with a non-initialized GID value will be sent to the FUSE daemon when sending an interrupt. Which consequences this can have in the daemon itself, I don't know. Could you tell which consequences you foresee (out of curiosity)? In any case, the code is logically wrong, so has to be fixed.

[olce]

4th take to get the commit message accurate enough (I hope), sorry... I definitely need more caffeine this morning.