[Bug 287135] Large Unix SOCK_SEQPACKET messages do not get truncated

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=287135

            Bug ID: 287135
           Summary: Large Unix SOCK_SEQPACKET messages do not get
                    truncated
           Product: Base System
           Version: CURRENT
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Some People
          Priority: ---
         Component: kern
          Assignee: bugs@FreeBSD.org
          Reporter: ccaulfie@redhat.com
 Attachment #260781 text/plain
         mime type:

Created attachment 260781
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=260781&action=edit
Reproducer, returns 2 packets on CURRENT and MSG_TRUNC on earlier kernels (and
other OSs that I tried)

Copied from 279354

--- Comment #8 from Gleb Smirnoff <glebius@FreeBSD.org> ---
On Wed May 28 12:54:59  2025 UTC, ccaulfie@redhat.com wrote:
> I have a similar issue with unix SEQPACKETs in recent freebsd-devel. If I send a
> packet longer than the receive buffer then it gets fragmented in recv (so I get
> it in two parts) rather than MSG_TRUNC being set as used to be the case on
> earlier kernels - and as seems to happen on other OSs.
>
> I can post a reproducer here if that's helpful, or raise another BZ if you'd
> prefer.

Well, the specification contradicts self :( I made the SOCK_SEQPACKET following
this guidance:

"The SOCK_SEQPACKET socket type is similar to the SOCK_STREAM type, and is also
connection-oriented. The only difference between these types is that record
boundaries are maintained using the SOCK_SEQPACKET type. A record can be sent
using one or more output operations and received using one or more input
operations, but a single operation never transfers parts of more than one
record. Record boundaries are visible to the receiver via the MSG_EOR flag in
the received message flags returned by the recvmsg() function. It is protocol-
specific whether a maximum record size is imposed."

https://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html

However, after your report, I was looking for more into and in the recvmsg()
specfication found this:

"For message-based sockets, such as SOCK_DGRAM and SOCK_SEQPACKET, the entire
message shall be read in a single operation. If a message is too long to fit in
the supplied buffers, and MSG_PEEK is not set in the flags argument, the excess
bytes shall be discarded, and MSG_TRUNC shall be set in the msg_flags member of
the msghdr structure. "

https://pubs.opengroup.org/onlinepubs/9699919799/functions/recvmsg.html

This really sucks, to be fair :( IMHO, the specification from V2_chap02
makes a useful kind of socket, while following what recvmsg() says would
basically create an alias for SOCK_DGRAM.  That's what SOCK_SEQPACKET was
before my changes, and hence it wasn't passing random_eor_and_waitall test.

-- 
You are receiving this mail because:
You are the assignee for the bug.