unix/stream: fix a race with MSG_PEEK on SOCK_SEQPACKET with MSG_EORHEADmain

The pr_soreceive method first scans the buffer holding the both I/O sx(9)
and socket buffer mutex(9) and after figuring out how much needs to be
copied out drops the mutex.  Since the other side may only append to the
buffer, it is safe to continue the operation holding the sx(9) only.
However, the code had a bug that it used pointer in the very last mbuf as
marker of the place where to stop.  This worked both in a case when we
drain a buffer completely (marker points at NULL) and in a case when we
wanted to stop at MSG_EOR (marker points at next mbuf after MSG_EOR).
However, this pointer is not consistent after we dropped the socket buffer
mutex.

Rewrite the logic to use the data length as bounds for the copyout cycle.

Provide a test case that reproduces the race.  Note that the race is very
hard to hit, thus test will pass on unmodified kernel as well.  In a
virtual machine I needed to add tsleep(9) for 10 nanoseconds into the
middle of function to be able to reproduce.

PR:			290658
Reviewed by:		markj
Differential Revision:	https://reviews.freebsd.org/D53632
Fixes:			d15792780760ef94647af9b377b5f0a80e1826bc

0 files changed, 0 insertions, 0 deletions