Bug 239250

Summary: need to define limits on unix socket control messages
Product: Base System Reporter: Mark Johnston <markj>
Component: kernAssignee: freebsd-bugs (Nobody) <bugs>
Status: New ---    
Severity: Affects Only Me    
Priority: ---    
Version: CURRENT   
Hardware: Any   
OS: Any   

Description Mark Johnston freebsd_committer freebsd_triage 2019-07-16 15:58:50 UTC
There are some undocumented limits that apply to control messages over unix domain sockets, and SCM_RIGHTS messages in particular.

- Control messages must fit in an mbuf cluster, which is MCLBYTES (2KB) in size.
- Control message data must be natively aligned, so 64-bit kernels are limited to fewer rights per message than 32-bit kernels.  This can be problematic when running 32-bit applications on a 64-bit kernel.
- SCM_RIGHTS message contents must be translated to an internalized format before they can be transmitted.  Specifically, a 4-byte file descriptor is converted to a pointer, and internalized messages must fit in an mbuf cluster as well.  So even though we can pack (2048-16)/sizeof(int) FDs in a single SCM_RIGHTS message on amd64, the kernel can only handle (2048-16)/sizeof(void *) FDs.
Comment 1 commit-hook freebsd_committer freebsd_triage 2022-05-25 20:31:12 UTC
A commit in branch main references this bug:

URL: https://cgit.FreeBSD.org/src/commit/?id=23402c83f4fc2db45f0435ed106791828a6522df

commit 23402c83f4fc2db45f0435ed106791828a6522df
Author:     Gleb Smirnoff <glebius@FreeBSD.org>
AuthorDate: 2022-05-25 20:28:40 +0000
Commit:     Gleb Smirnoff <glebius@FreeBSD.org>
CommitDate: 2022-05-25 20:28:40 +0000

    tests/unix_passfd: sending many and too many SCM_RIGHTS

    o Exercise bounds checking when sending large set of file descriptors,
      that can't fit into single control mbuf.
    o Exercise resource limits checks when receiving a large sets.
    o Check that socket isn't left in a completely stuck state when we can't
      receive SCM_RIGHTS due to limits.  Current SOCK_STREAM socket would
      free the control, but leave the data in.  This seems to be a legit
      behavior for a stream socket, as we don't want holes in the data.

    PR:                     239250
    Reviewed by:            markj
    Differential revision:  https://reviews.freebsd.org/D35315

 tests/sys/kern/unix_passfd_test.c | 69 ++++++++++++++++++++++++++++++++++++++-
 1 file changed, 68 insertions(+), 1 deletion(-)