On 13/11/25 23:40, Gleb Smirnoff wrote:
The branch main has been updated by glebius:
URL:
https://cgit.FreeBSD.org/src/commit/?id=69f61cee2efb1eec0640ca7de9b2d51599569a5d
commit 69f61cee2efb1eec0640ca7de9b2d51599569a5d
Author: Gleb Smirnoff <[email protected]>
AuthorDate: 2025-11-14 02:39:48 +0000
Commit: Gleb Smirnoff <[email protected]>
CommitDate: 2025-11-14 02:39:48 +0000
unix/stream: fix a race with MSG_PEEK on SOCK_SEQPACKET with MSG_EOR
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
Hi Gleb!
It looks like Thunderbird decided to encrypt my previous message, lets
try again :)
I've updated my laptop this morning and it crashed at boot as you can
see at [1]. I suspect it may be related to this commit.
[1] https://imgur.com/a/opfN6Ta
--
Renato Botelho
