linux-kernel - Re: Linux 5.8-rc1 BUG unable to handle page fault (snd

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:   Mon, 15 Jun 2020 15:23:24 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Shuah Khan <skhan@...uxfoundation.org>
Cc:     Sasha Levin <sashal@...nel.org>,
        Konstantin Khlebnikov <koct9i@...il.com>,
        Joerg Roedel <jroedel@...e.de>,
        Andy Lutomirski <luto@...nel.org>,
        "Peter Zijlstra (Intel)" <peterz@...radead.org>,
        Takashi Iwai <tiwai@...e.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        "the arch/x86 maintainers" <x86@...nel.org>
Subject: Re: Linux 5.8-rc1 BUG unable to handle page fault (snd_pcm)

On Mon, Jun 15, 2020 at 2:18 PM Shuah Khan <skhan@...uxfoundation.org> wrote:
>
> Yeah. I should have thought about adding module path. With module path
> added, I get better results:
>
> [   15.341267] ? snd_pcm_hw_params (./include/linux/string.h:391
> /home/shuah/lkml/linux_5.8/sound/core/pcm_native.c:759) snd_pcm
> [   15.341272] snd_pcm_common_ioctl (sound/core/pcm_native.c:792
> /home/shuah/lkml/linux_5.8/sound/core/pcm_native.c:3210) snd_pcm

Yeah, now it gives the complete path and you see exactly which
memset() it ends up being, ie it's that

        /* clear the buffer for avoiding possible kernel info leaks */
        if (runtime->dma_area && !substream->ops->copy_user)
                memset(runtime->dma_area, 0, runtime->dma_bytes);

Quite often  with all the inlining the compiler does it can be really
hard to figure out where things come from when you just see the symbol
and offset.

Ok, in this case there aren't that many calls to memset() in that
file, and it might have been obvious which one it was in this case.
But sometimes they just come from various inline helper functions too,
and when automation can give us the answer easily, it's the thing to
do.

> > Maybe even just a warning about lacking a module path when there are
> > module symbols present?
> >
>
> It does tell you the usage.

Yes, it's more that it's very easy to overlook it, and then get a
partial decode.

Once you know how to use that script, it's very convenient, but the
problem tends to be that too few people are aware of it in the first
place.

                 Linus