Re: regress caused by upstream commit 6650527444dadc63d84aa939d14ecba4fadb2f69

Re: regress caused by upstream commit 6650527444dadc63d84aa939d14ecba4fadb2f69

[Jann Horn]

On Wed, Jul 29, 2026 at 3:45 PM Jann Horn <jannh@google.com> wrote:
> On Wed, Jul 29, 2026 at 11:08 AM Pasha Boroffski
> <hex.dec.bin.oct@gmail.com> wrote:
> > Hello.
> > I believe 6650527444dadc63d84aa939d14ecba4fadb2f69 has a bug in it as it causes "kernel bug" with PREEMPT_RT enabled.
> > How to reproduce the bug:
> > i used 'find /proc/ | grep 123'. When scanning, the kernel triggers an "Oops".
> >
> >
> > [  344.465851][ T3715] BUG: kernel NULL pointer dereference, address: 00000000000000f8
> [...]
> [  344.465888][ T3715] CPU: 0 UID: 0 PID: 3715 Comm: find Tainted: G
>    D    O       6.12.98 #9
> [...]
> > [  344.465905][ T3715] RIP: 0010:down_read_killable+0x9/0x40
> [...]
> > [  344.465974][ T3715]  proc_map_files_readdir+0xc7/0x500
> [...]
> > I think calls
> > mm = mm_access(task, PTRACE_MODE_READ_FSCREDS);
> > if (IS_ERR(mm)) {
> >   result = ERR_CAST(mm);
> >   goto out_put_task;
> > }
> >
> > should be fixed like
> > mm = mm_access(task, PTRACE_MODE_READ_FSCREDS);
> > if (IS_ERR_OR_NULL(mm)) {
> >   result = ERR_CAST(mm);
> >   goto out_put_task;
> > }
>
> Ugh, yes. This is not an issue on mainline, but the API contract of
> mm_access() changed in commit cd3f8467afd4 ("mm: refactor mm_access()
> to not return NULL"), which landed in 6.13. So we'll need a
> stable-specific fixup for 6.12 and lower.
>
> I'll try to come up with a patch for stable later today.

I've reproduced this, triggering this NULL deref on 6.12.98 is as easy
as "ls /proc/2/map_files"

Re: regress caused by upstream commit 6650527444dadc63d84aa939d14ecba4fadb2f69

[Greg Kroah-Hartman]

On Wed, Jul 29, 2026 at 03:59:18PM +0200, Jann Horn wrote:
> On Wed, Jul 29, 2026 at 3:45 PM Jann Horn <jannh@google.com> wrote:
> > On Wed, Jul 29, 2026 at 11:08 AM Pasha Boroffski
> > <hex.dec.bin.oct@gmail.com> wrote:
> > > Hello.
> > > I believe 6650527444dadc63d84aa939d14ecba4fadb2f69 has a bug in it as it causes "kernel bug" with PREEMPT_RT enabled.
> > > How to reproduce the bug:
> > > i used 'find /proc/ | grep 123'. When scanning, the kernel triggers an "Oops".
> > >
> > >
> > > [  344.465851][ T3715] BUG: kernel NULL pointer dereference, address: 00000000000000f8
> > [...]
> > [  344.465888][ T3715] CPU: 0 UID: 0 PID: 3715 Comm: find Tainted: G
> >    D    O       6.12.98 #9
> > [...]
> > > [  344.465905][ T3715] RIP: 0010:down_read_killable+0x9/0x40
> > [...]
> > > [  344.465974][ T3715]  proc_map_files_readdir+0xc7/0x500
> > [...]
> > > I think calls
> > > mm = mm_access(task, PTRACE_MODE_READ_FSCREDS);
> > > if (IS_ERR(mm)) {
> > >   result = ERR_CAST(mm);
> > >   goto out_put_task;
> > > }
> > >
> > > should be fixed like
> > > mm = mm_access(task, PTRACE_MODE_READ_FSCREDS);
> > > if (IS_ERR_OR_NULL(mm)) {
> > >   result = ERR_CAST(mm);
> > >   goto out_put_task;
> > > }
> >
> > Ugh, yes. This is not an issue on mainline, but the API contract of
> > mm_access() changed in commit cd3f8467afd4 ("mm: refactor mm_access()
> > to not return NULL"), which landed in 6.13. So we'll need a
> > stable-specific fixup for 6.12 and lower.
> >
> > I'll try to come up with a patch for stable later today.
> 
> I've reproduced this, triggering this NULL deref on 6.12.98 is as easy
> as "ls /proc/2/map_files"

Ugh, ok, let me go do some "quick" releases with just this fix in it
right now, sorry about that!

greg k-h