KASAN: use-after-free Read in cipso_v4_genopt
dvyukov at google.com
Tue Mar 2 19:14:54 UTC 2021
On Tue, Mar 2, 2021 at 5:10 PM Paul Moore <paul at paul-moore.com> wrote:
> On Tue, Mar 2, 2021 at 6:03 AM Dmitry Vyukov <dvyukov at google.com> wrote:
> > Besides these 2 crashes, we've also seen one on a 4.19 based kernel, see below.
> > Based on the reports with mismatching stacks, it looks like
> > cipso_v4_genopt is doing some kind of wild pointer access (uninit
> > pointer?).
> Hmm, interesting. Looking quickly at the stack dump, it appears that
> the problem occurs (at least in the recent kernel) when accessing the
> cipso_v4_doi.tags array which is embedded in the cipso_v4_doi
> struct. Based on the code in cipso_v4_genopt() it doesn't appear that
> we are shooting past the end of the array/struct and the cipso_v4_doi
> struct appears to be refcounted correctly in cipso_v4_doi_getdef() and
> cipso_v4_doi_putdef(). I'll look at it some more today to see if
> something jumps out at me, but obviously a reproducer would be very
> helpful if you are able to find one.
> It's also worth adding that this code really hasn't changed much in a
> *long* time, not that this means it isn't broken, just that it might
> also be worth looking at other odd memory bugs to see if there is
> chance they are wandering around and stomping on memory ...
Not sure if it's the root cause or not, but I am looking at this
reference drop in cipso_v4_doi_remove:
The thing is that it does not remove from the list if reference is not
0, right? So what if I send 1000 of netlink remove messages? Will it
drain refcount to 0?
I did not read all involved code, but the typical pattern is to drop
refcount and always remove from the list. Then the last use will
delete the object.
Does it make any sense?
More information about the Linux-security-module-archive