Re: regress caused by upstream commit 6650527444dadc63d84aa939d14ecba4fadb2f69

On Wed, Jul 29, 2026 at 03:59:18PM +0200, Jann Horn wrote:
> On Wed, Jul 29, 2026 at 3:45 PM Jann Horn <[email protected]> wrote:
> > On Wed, Jul 29, 2026 at 11:08 AM Pasha Boroffski
> > <[email protected]> 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