[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