[Bug 267159] SO_REUSEPORT_LB race conditions

From: <bugzilla-noreply_at_freebsd.org>
Date: Mon, 17 Oct 2022 19:40:05 UTC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=267159

            Bug ID: 267159
           Summary: SO_REUSEPORT_LB race conditions
           Product: Base System
           Version: CURRENT
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Only Me
          Priority: ---
         Component: kern
          Assignee: bugs@FreeBSD.org
          Reporter: markj@FreeBSD.org

net_epoch permits in_pcblookup_lbgroup() and in_pcbremlbgrouphash() to run
concurrently, but they weren't written with this in mind.  The latter may
remove entries in an LB group, after which it compacts the group.  If a new
group structure is allocated, in_pcbremlbgrouphash() puts it at the head of the
hash chain before copying the contents of the old group over, so there's a
small window where we have a group of size 0, which can cause problems in the
lookup path (kernel panics or inexplicable connection setup failures).

I think there's a similar problem when growing a group structure.

Finally, the group structures are not really protected by SMR, only by
net_epoch.

We should probably never shrink the group structure, I don't think it's worth
the complexity.  When growing the structure, we should populate the new one and
issue a memory barrier before making it visible to other CPUs (i.e., before
adding it to the hash chain).

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