Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 15 Nov 2014 16:17:35 -0500
From:      Ryan Stone <rysto32@gmail.com>
To:        Mark Johnston <markj@freebsd.org>
Cc:        Hans Petter Selasky <hps@bitfrost.no>, FreeBSD Current <freebsd-current@freebsd.org>
Subject:   Re: General Protection Fault in prelist_remove()
Message-ID:  <CAFMmRNz23KBBmBCm3qrwuiooLcRNaw5BRAGeKsDbCNAzFHfV%2Bg@mail.gmail.com>
In-Reply-To: <20130916171016.GA1509@charmander>
References:  <52372362.10506@bitfrost.no> <20130916171016.GA1509@charmander>

next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Sep 16, 2013 at 1:10 PM, Mark Johnston <markj@freebsd.org> wrote:
> I've partially fixed this at work by adding a rw lock to protect access
> to the the prefix, default router, and DAD lists. The patch is here:
> http://people.freebsd.org/~markj/patches/ndp-locking.diff

Hi Mark,

I've hit a bug in this patch today.  The problem is in the locking of
the DAD list.  Many functions (e.g.
nd6_dad_duplicated) call nd6_dad_find() to look up a dadq structure,
and then manipulate the structure with no lock held.  The problem that
once nd6_dad_find() releases the ND lock there is nothing preventing
another thread from going in and free'ing the structure.  This causes
a use-after-free in nd6_dad_duplicated.  I have a setup which is
somehow triggering DAD on link-local addresses (I don't understand
why; I don't have duplicate mac addresses on the network as best that
I can tell) and with INVARIANTS on I very frequently get a crash in
nd6_dad_duplicated.


It looks to me that the only way to fix it is either introduce
referencing counting into the structure, or push the locking out of
nd6_dad_find() and into the callers.  Any opinions?



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAFMmRNz23KBBmBCm3qrwuiooLcRNaw5BRAGeKsDbCNAzFHfV%2Bg>