Page MenuHomeFreeBSD

nd6: Reject routers on a prefix about to be freed

Authored by rstone on Wed, Oct 30, 7:14 PM.



When adding a new default router to an nd_prefix, it is possible
that pfxrtr_add() will be called just after another thread has
called nd6_prefix_unlink() in preparation for freeing it. Adding
the router at this point will lead to a reference on the router
structure being lost (or a KASSERT firing with INVARIANTS).
Prevent this by marking nd_prefixes that are about to be freed
with a dying flag and not adding routers to a dying prefix.

Diff Detail

Lint OK
No Unit Test Coverage
Build Status
Buildable 27283
Build 25544: arc lint + arc unit

Event Timeline

rstone created this revision.Wed, Oct 30, 7:14 PM
markj accepted this revision.Sun, Nov 3, 3:52 PM

I think this is fine. I spent some time trying to see if we could change nd6_prefix_unlink() to also remove the list of advertising routers, since that would eliminate the window in which the race can occur. That approach looks more difficult though.

Do you happen to have a test case for this? We don't have any ND6 regression tests at the moment. :(


Feel free to keep _DYING if you prefer it, but I think NDPRF_UNLINKED is a more descriptive name. (Or you could invert the sense of the flag and call it NDPRF_LINKED.)

This revision is now accepted and ready to land.Sun, Nov 3, 3:52 PM