linux-kernel - Re: radeon.ko/i586: BUG: kernel NULL pointer dereference, address:00000004

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: <20230714100019.6bf9b1ab@gandalf.local.home>
Date:   Fri, 14 Jul 2023 10:00:19 -0400
From:   Steven Rostedt <rostedt@...dmis.org>
To:     <kkabe@...a.pgw.jp>
Cc:     regressions@...ts.linux.dev, bagasdotme@...il.com,
        alexander.deucher@....com, christian.koenig@....com,
        Xinhui.Pan@....com, tglx@...utronix.de, mingo@...hat.com,
        bp@...en8.de, dave.hansen@...ux.intel.com, hpa@...or.com,
        linux-kernel@...r.kernel.org, amd-gfx@...ts.freedesktop.org
Subject: Re: radeon.ko/i586: BUG: kernel NULL pointer dereference,
 address:00000004

On Fri, 14 Jul 2023 14:34:04 +0900
<kkabe@...a.pgw.jp> wrote:

> >> > So I'm confused about why it's mentioned. Was it backported?  
> >> 
> >> Taketo Kabe, could you please help to clean this confusion up? Did you
> >> mean 5.19 in https://bugzilla.kernel.org/show_bug.cgi?id=217669#c5 ? And
> >> BTW: did you really use a vanilla kernel for your bisection?  
> 
> 
> Reporter Me:
> I bisected using freedesktop.org kernel tree, which git commit ID is
> in sync with kernel.org
> but version number in ./Makefile could be slighty behind. 
> 
> Patch in
> https://bugzilla.kernel.org/show_bug.cgi?id=217669#c4
> fixed the problem in freedesktop.org kernel 5.18.0-rc2 .
> This may explain that in kernel.org tree, the said commit is in kernel-5.19.

Even if the bisect did land on this commit, it doesn't make sense. I would
think that one of the results of the bisect was incorrect (a pass that
should have failed?), as that would lead the bisect down to the wrong
conclusion.

Now if you you remove this commit and everything works fine, and add it
back again and it fails reliably, then I can't argue it is not the commit.

But the commit in question kicks off a worker thread at boot up to search
for weak functions that were tagged to be traced by the function tracer and
sets them to "disabled" to never be traced.

Is the function tracer used at all here? I really do not see how this
commit affects the code that is crashing. Unless there's something wrong
with the way the kworker was set up and it corrupted other kworkers :-/

-- Steve