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: <CAHC9VhTxrGgBDW_439HeSP=_F9Jt2_cYrrQ7DtAXtKG4evGb9g@mail.gmail.com>
Date:   Tue, 2 Mar 2021 11:10:15 -0500
From:   Paul Moore <paul@...l-moore.com>
To:     Dmitry Vyukov <dvyukov@...gle.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 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 ...

-- 
paul moore
www.paul-moore.com

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ