linux-kernel - Re: [gcov] 1391efa952: BUG:KASAN:slab-out-of-bounds_in_gcov_info

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]

Date:   Thu, 25 Nov 2021 09:48:17 -0800
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Johannes Berg <johannes@...solutions.net>,
        Greg Hackmann <ghackmann@...roid.com>,
        Tri Vo <trong@...roid.com>,
        Peter Oberparleiter <oberpar@...ux.ibm.com>
Cc:     "Sang, Oliver" <oliver.sang@...el.com>,
        Nick Desaulniers <ndesaulniers@...gle.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        LKML <linux-kernel@...r.kernel.org>,
        "lkp@...ts.01.org" <lkp@...ts.01.org>, lkp <lkp@...el.com>
Subject: Re: [gcov] 1391efa952: BUG:KASAN:slab-out-of-bounds_in_gcov_info_add

On Thu, Nov 25, 2021 at 7:45 AM Johannes Berg <johannes@...solutions.net> wrote:
>
> In any case, reviewing my commit again I see nothing wrong there, and I
> don't understand the code/clang well enough to see what might be the
> issue.

Yeah, looks like the kvmalloc() conversion simply tightened the
checking boundaries, now that it might be using kmalloc() instead of
full pages.

The report isn't wonderful (the KASAN report is garbled, and the "code
disassembly" is not from the actual KASAN report, it's from the return
to user space code), but it blames a 8-byte read at

    gcov_info_add (kernel/gcov/clang.c:328)

which in that kernel version (1391efa952e8) is that

        for (i = 0; i < sfn_ptr->num_counters; i++)
->              dfn_ptr->counters[i] += sfn_ptr->counters[i];

and so it looks like that 'sfn_ptr->counters[i]' access is the problem case.

The allocation was

    gcov_info_dup (include/linux/mm.h:804 kernel/gcov/clang.c:371
kernel/gcov/clang.c:404)

and in particular, it's the inlined gcov_fn_info_dup() at line 371:

        cv_size = fn->num_counters * sizeof(fn->counters[0]);
        fn_dup->counters = kvmalloc(cv_size, GFP_KERNEL);

but I'm not seeing how that could fail.

Sure, that code doesn't explicitly ever set "fn_dup->num_counters",
but it should get set thanks to the

        fn_dup = kmemdup(fn, sizeof(*fn), GFP_KERNEL);

so I don't see anything wrong there, but I'm adding some of the
involved people to the participants in case they see what's going on..

                  Linus