Re: regress caused by upstream commit 6650527444dadc63d84aa939d14ecba4fadb2f69

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 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 "O=
ops".
>
>
> [  344.465851][ T3715] BUG: kernel NULL pointer dereference, address: 000=
00000000000f8
[...]
[  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.