[Bug 222308] ip_multicast: Panic due to VNET being invalid on lagg during SIOCDELMULTI

bugzilla-noreply at freebsd.org bugzilla-noreply at freebsd.org
Wed Sep 13 19:07:15 UTC 2017


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

            Bug ID: 222308
           Summary: ip_multicast: Panic due to VNET being invalid on lagg
                    during SIOCDELMULTI
           Product: Base System
           Version: 11.1-RELEASE
          Hardware: amd64
                OS: Any
            Status: New
          Severity: Affects Only Me
          Priority: ---
         Component: kern
          Assignee: freebsd-bugs at FreeBSD.org
          Reporter: brent at beanfield.com

Issue is detailed in a patch to FreeNAS by Chris Torek, seen here:
https://github.com/freenas/os/commit/34462da8e3b1089311dd4627953d558929cc04fc#diff-c9065ed6e74837c7cb1ded9eb39e7fb9

I believe this panic is currently affecting me on nas4free 11.1.0.4 which
utilizes FreeBSD 11.1-RELEASE-P1

Copying his comments:

In in_leavegroup_locked(), when we're shedding a multicast
group, we may (or may not) delete it from an interface via
the igmp_change_state() call.  This is where we currently
set the multicast's vnet, and then restore the old vnet on
return.

However, a few lines later we use inm_release_locked() to
release the inet multicast data structure, and that in turn
may -- not necessarily will, only if the inm really is being
freed -- call if_delmulti_ifma(), which may -- not necessarily
will, again -- call the interface's SIOCDELMULTI ioctl
(if and only if there is an interface and this was the last
ref to this multicast address).

For (at least) the lagg interface, we still need the current
vnet to be valid during the SIOCDELMULTI.  So, don't restore
the old vnet until we've not only finished the IGMP code but
also inm_release_locked().

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


More information about the freebsd-bugs mailing list