linux-kernel - Re: KASAN: use-after-free Read in cipso_v4

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CACT4Y+YEu3f059=nGu9KxTi4sg6-POtziQ+0jx-KN2adjGJHRg@mail.gmail.com>
Date:   Tue, 2 Mar 2021 20:14:54 +0100
From:   Dmitry Vyukov <dvyukov@...gle.com>
To:     Paul Moore <paul@...l-moore.com>
Cc:     syzbot <syzbot+9ec037722d2603a9f52e@...kaller.appspotmail.com>,
        David Miller <davem@...emloft.net>, dsahern@...nel.org,
        Jakub Kicinski <kuba@...nel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        linux-security-module <linux-security-module@...r.kernel.org>,
        netdev <netdev@...r.kernel.org>,
        syzkaller-bugs <syzkaller-bugs@...glegroups.com>,
        Hideaki YOSHIFUJI <yoshfuji@...ux-ipv6.org>
Subject: Re: KASAN: use-after-free Read in cipso_v4_genopt

On Tue, Mar 2, 2021 at 5:10 PM Paul Moore <paul@...l-moore.com> wrote:
>
> On Tue, Mar 2, 2021 at 6:03 AM Dmitry Vyukov <dvyukov@...gle.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:
https://elixir.bootlin.com/linux/v5.12-rc1/source/net/ipv4/cipso_ipv4.c#L522
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?