Re: git: 69f61cee2efb - main - unix/stream: fix a race with MSG_PEEK on SOCK_SEQPACKET with MSG_EOR

Am Tage des Herren Fri, 14 Nov 2025 13:18:34 -0300
Renato Botelho <garga@FreeBSD.org> schrieb:

> 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 <glebius@FreeBSD.org>
> > AuthorDate: 2025-11-14 02:39:48 +0000
> > Commit:     Gleb Smirnoff <glebius@FreeBSD.org>
> > 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
> 

Hello,

I also have a serious issue with most recent CURRENT as it bails out with a page fault, but I
can reproduce the issue according to

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279653 and
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=291003

(I have almost the same bridge setup and all boxes with bridges running CURRENT have this
"infection" while others not).

Just my thoughts. Sorry for the noise.

oh

-- 

A FreeBSD user