Re: regress caused by upstream commit 6650527444dadc63d84aa939d14ecba4fadb2f69

On Wed, Jul 29, 2026 at 3:45=E2=80=AFPM Jann Horn <[email protected]> wrote:
> On Wed, Jul 29, 2026 at 11:08=E2=80=AFAM Pasha Boroffski
> <[email protected]> wrote:
> > Hello.
> > I believe 6650527444dadc63d84aa939d14ecba4fadb2f69 has a bug in it as i=
t 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: 0=
0000000000000f8
> [...]
> [  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 =3D mm_access(task, PTRACE_MODE_READ_FSCREDS);
> > if (IS_ERR(mm)) {
> >   result =3D ERR_CAST(mm);
> >   goto out_put_task;
> > }
> >
> > should be fixed like
> > mm =3D mm_access(task, PTRACE_MODE_READ_FSCREDS);
> > if (IS_ERR_OR_NULL(mm)) {
> >   result =3D 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"