Bug 222308 - ip_multicast: Panic due to VNET being invalid on lagg during SIOCDELMULTI
Summary: ip_multicast: Panic due to VNET being invalid on lagg during SIOCDELMULTI
Status: New
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: 11.1-RELEASE
Hardware: amd64 Any
: --- Affects Only Me
Assignee: freebsd-net mailing list
Depends on:
Reported: 2017-09-13 19:07 UTC by brent
Modified: 2017-09-14 21:36 UTC (History)
0 users

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description brent 2017-09-13 19:07:14 UTC
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 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

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().
Comment 1 brent 2017-09-13 19:40:15 UTC
I'll mention as well that Chris has two other fixes for issues in the in_mcast.c code that are worth looking at:

"Turning on multicast debug made multicast failure worse
because the strings and #define values no longer matched
up.  Fix them, and make sure they stay matched-up.":


"During if_detach(), we get a race where a closing socket is
releasing multicast data (via inp_freemoptions()) at the same
time as igmp_ifdetach() is releasing all multicast data for
the interface, resulting in a potential double teardown and
double free. ...":