[syzbot] [mm?] BUG: unable to handle kernel paging request in copy_from_kernel_nofault

[syzbot] [mm?] BUG: unable to handle kernel paging request in copy_from_kernel_nofault

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit:    1fda5bb66ad8 bpf: Do not allocate percpu memory at init st..
git tree:       bpf
console+strace: https://syzkaller.appspot.com/x/log.txt?x=12d99420e80000
kernel config:  https://syzkaller.appspot.com/x/.config?x=2ae0ccd6bfde5eb0
dashboard link: https://syzkaller.appspot.com/bug?extid=72aa0161922eba61b50e
compiler:       gcc (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40
syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=16dff22f680000
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=1027dc70e80000

Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/3e24d257ce8d/disk-1fda5bb6.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/eaa9caffb0e4/vmlinux-1fda5bb6.xz
kernel image: https://storage.googleapis.com/syzbot-assets/16182bbed726/bzImage-1fda5bb6.xz

The issue was bisected to:

commit ca247283781d754216395a41c5e8be8ec79a5f1c
Author: Andy Lutomirski <luto@kernel.org>
Date:   Wed Feb 10 02:33:45 2021 +0000

    x86/fault: Don't run fixups for SMAP violations

bisection log:  https://syzkaller.appspot.com/x/bisect.txt?x=103d92db680000
final oops:     https://syzkaller.appspot.com/x/report.txt?x=123d92db680000
console output: https://syzkaller.appspot.com/x/log.txt?x=143d92db680000

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+72aa0161922eba61b50e@syzkaller.appspotmail.com
Fixes: ca247283781d ("x86/fault: Don't run fixups for SMAP violations")

BUG: unable to handle page fault for address: ffffffffff600000
#PF: supervisor read access in kernel mode
#PF: error_code(0x0000) - not-present page
PGD cd7a067 P4D cd7a067 PUD cd7c067 PMD cd9f067 PTE 0
Oops: 0000 [#1] PREEMPT SMP KASAN
CPU: 1 PID: 5071 Comm: syz-executor322 Not tainted 6.6.0-syzkaller-15867-g1fda5bb66ad8 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/10/2023
RIP: 0010:copy_from_kernel_nofault mm/maccess.c:36 [inline]
RIP: 0010:copy_from_kernel_nofault+0x86/0x240 mm/maccess.c:24
Code: ea 03 0f b6 14 02 48 89 f8 83 e0 07 83 c0 03 38 d0 7c 08 84 d2 0f 85 ab 01 00 00 41 83 85 6c 17 00 00 01 eb 1e e8 ba 23 cf ff <48> 8b 45 00 49 89 04 24 48 83 c5 08 49 83 c4 08 48 83 eb 08 e8 a1
RSP: 0018:ffffc900038d7ae8 EFLAGS: 00010293
RAX: 0000000000000000 RBX: 0000000000000008 RCX: ffffffff81b8690c
RDX: ffff888016ab0000 RSI: ffffffff81b868e6 RDI: 0000000000000007
RBP: ffffffffff600000 R08: 0000000000000007 R09: 0000000000000007
R10: 0000000000000008 R11: 0000000000000001 R12: ffffc900038d7b30
R13: ffff888016ab0000 R14: dffffc0000000000 R15: 0000000000000000
FS:  0000000000000000(0000) GS:ffff8880b9900000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ffffffffff600000 CR3: 000000000cd77000 CR4: 00000000003506f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
 <TASK>
 bpf_probe_read_kernel_common include/linux/bpf.h:2747 [inline]
 ____bpf_probe_read_kernel kernel/trace/bpf_trace.c:236 [inline]
 bpf_probe_read_kernel+0x26/0x70 kernel/trace/bpf_trace.c:233
 bpf_prog_bd8b22826c103b08+0x42/0x44
 bpf_dispatcher_nop_func include/linux/bpf.h:1196 [inline]
 __bpf_prog_run include/linux/filter.h:651 [inline]
 bpf_prog_run include/linux/filter.h:658 [inline]
 __bpf_trace_run kernel/trace/bpf_trace.c:2307 [inline]
 bpf_trace_run2+0x14e/0x410 kernel/trace/bpf_trace.c:2346
 trace_kfree include/trace/events/kmem.h:94 [inline]
 kfree+0xec/0x150 mm/slab_common.c:1043
 vma_numab_state_free include/linux/mm.h:638 [inline]
 __vm_area_free+0x3e/0x140 kernel/fork.c:525
 remove_vma+0x128/0x170 mm/mmap.c:146
 exit_mmap+0x453/0xa70 mm/mmap.c:3332
 __mmput+0x12a/0x4d0 kernel/fork.c:1349
 mmput+0x62/0x70 kernel/fork.c:1371
 exit_mm kernel/exit.c:567 [inline]
 do_exit+0x9ad/0x2ae0 kernel/exit.c:858
 do_group_exit+0xd4/0x2a0 kernel/exit.c:1021
 __do_sys_exit_group kernel/exit.c:1032 [inline]
 __se_sys_exit_group kernel/exit.c:1030 [inline]
 __x64_sys_exit_group+0x3e/0x50 kernel/exit.c:1030
 do_syscall_x64 arch/x86/entry/common.c:51 [inline]
 do_syscall_64+0x40/0x110 arch/x86/entry/common.c:82
 entry_SYSCALL_64_after_hwframe+0x63/0x6b
RIP: 0033:0x7fe1c24c2dc9
Code: Unable to access opcode bytes at 0x7fe1c24c2d9f.
RSP: 002b:00007ffd4d4b8dc8 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7
RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fe1c24c2dc9
RDX: 000000000000003c RSI: 00000000000000e7 RDI: 0000000000000000
RBP: 00007fe1c253e290 R08: ffffffffffffffb8 R09: 0000000000000006
R10: 0000000000000000 R11: 0000000000000246 R12: 00007fe1c253e290
R13: 0000000000000000 R14: 00007fe1c253ece0 R15: 00007fe1c2494030
 </TASK>
Modules linked in:
CR2: ffffffffff600000
---[ end trace 0000000000000000 ]---
RIP: 0010:copy_from_kernel_nofault mm/maccess.c:36 [inline]
RIP: 0010:copy_from_kernel_nofault+0x86/0x240 mm/maccess.c:24
Code: ea 03 0f b6 14 02 48 89 f8 83 e0 07 83 c0 03 38 d0 7c 08 84 d2 0f 85 ab 01 00 00 41 83 85 6c 17 00 00 01 eb 1e e8 ba 23 cf ff <48> 8b 45 00 49 89 04 24 48 83 c5 08 49 83 c4 08 48 83 eb 08 e8 a1
RSP: 0018:ffffc900038d7ae8 EFLAGS: 00010293
RAX: 0000000000000000 RBX: 0000000000000008 RCX: ffffffff81b8690c
RDX: ffff888016ab0000 RSI: ffffffff81b868e6 RDI: 0000000000000007
RBP: ffffffffff600000 R08: 0000000000000007 R09: 0000000000000007
R10: 0000000000000008 R11: 0000000000000001 R12: ffffc900038d7b30
R13: ffff888016ab0000 R14: dffffc0000000000 R15: 0000000000000000
FS:  0000000000000000(0000) GS:ffff8880b9900000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ffffffffff600000 CR3: 000000000cd77000 CR4: 00000000003506f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
----------------
Code disassembly (best guess), 1 bytes skipped:
   0:	03 0f                	add    (%rdi),%ecx
   2:	b6 14                	mov    $0x14,%dh
   4:	02 48 89             	add    -0x77(%rax),%cl
   7:	f8                   	clc
   8:	83 e0 07             	and    $0x7,%eax
   b:	83 c0 03             	add    $0x3,%eax
   e:	38 d0                	cmp    %dl,%al
  10:	7c 08                	jl     0x1a
  12:	84 d2                	test   %dl,%dl
  14:	0f 85 ab 01 00 00    	jne    0x1c5
  1a:	41 83 85 6c 17 00 00 	addl   $0x1,0x176c(%r13)
  21:	01
  22:	eb 1e                	jmp    0x42
  24:	e8 ba 23 cf ff       	call   0xffcf23e3
* 29:	48 8b 45 00          	mov    0x0(%rbp),%rax <-- trapping instruction
  2d:	49 89 04 24          	mov    %rax,(%r12)
  31:	48 83 c5 08          	add    $0x8,%rbp
  35:	49 83 c4 08          	add    $0x8,%r12
  39:	48 83 eb 08          	sub    $0x8,%rbx
  3d:	e8                   	.byte 0xe8
  3e:	a1                   	.byte 0xa1


---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.

syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
For information about bisection process see: https://goo.gl/tpsmEJ#bisection

If the report is already addressed, let syzbot know by replying with:
#syz fix: exact-commit-title

If you want syzbot to run the reproducer, reply with:
#syz test: git://repo/address.git branch-or-commit-hash
If you attach or paste a git patch, syzbot will apply it before testing.

If you want to overwrite report's subsystems, reply with:
#syz set subsystems: new-subsystem
(See the list of subsystem names on the web dashboard)

If the report is a duplicate of another one, reply with:
#syz dup: exact-subject-of-another-report

If you want to undo deduplication, reply with:
#syz undup

Re: [syzbot] [mm?] BUG: unable to handle kernel paging request in copy_from_kernel_nofault

[Thomas Gleixner]

On Sun, Nov 19 2023 at 09:53, syzbot wrote:
> HEAD commit:    1fda5bb66ad8 bpf: Do not allocate percpu memory at init st..
> git tree:       bpf
> console+strace: https://syzkaller.appspot.com/x/log.txt?x=12d99420e80000
> kernel config:  https://syzkaller.appspot.com/x/.config?x=2ae0ccd6bfde5eb0
> dashboard link: https://syzkaller.appspot.com/bug?extid=72aa0161922eba61b50e
> compiler:       gcc (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40
> syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=16dff22f680000
> C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=1027dc70e80000
>
> Downloadable assets:
> disk image: https://storage.googleapis.com/syzbot-assets/3e24d257ce8d/disk-1fda5bb6.raw.xz
> vmlinux: https://storage.googleapis.com/syzbot-assets/eaa9caffb0e4/vmlinux-1fda5bb6.xz
> kernel image: https://storage.googleapis.com/syzbot-assets/16182bbed726/bzImage-1fda5bb6.xz
>
> The issue was bisected to:
>
> commit ca247283781d754216395a41c5e8be8ec79a5f1c
> Author: Andy Lutomirski <luto@kernel.org>
> Date:   Wed Feb 10 02:33:45 2021 +0000
>
>     x86/fault: Don't run fixups for SMAP violations

Reverting that makes the Ooops go away, but wrongly so.

> bisection log:  https://syzkaller.appspot.com/x/bisect.txt?x=103d92db680000
> final oops:     https://syzkaller.appspot.com/x/report.txt?x=123d92db680000
> console output: https://syzkaller.appspot.com/x/log.txt?x=143d92db680000
>
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+72aa0161922eba61b50e@syzkaller.appspotmail.com
> Fixes: ca247283781d ("x86/fault: Don't run fixups for SMAP violations")
>
> BUG: unable to handle page fault for address: ffffffffff600000

This is VSYSCALL_ADDR.

So the real question is why the BPF program tries to copy from the
VSYSCALL page, which is not mapped.

Thanks,

        tglx

Re: [syzbot] [mm?] BUG: unable to handle kernel paging request in copy_from_kernel_nofault

[Jann Horn]

On Tue, Nov 21, 2023 at 6:13 PM Thomas Gleixner <tglx@linutronix.de> wrote:
> On Sun, Nov 19 2023 at 09:53, syzbot wrote:
> > HEAD commit:    1fda5bb66ad8 bpf: Do not allocate percpu memory at init st..
> > git tree:       bpf
> > console+strace: https://syzkaller.appspot.com/x/log.txt?x=12d99420e80000
> > kernel config:  https://syzkaller.appspot.com/x/.config?x=2ae0ccd6bfde5eb0
> > dashboard link: https://syzkaller.appspot.com/bug?extid=72aa0161922eba61b50e
> > compiler:       gcc (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40
> > syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=16dff22f680000
> > C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=1027dc70e80000
> >
> > Downloadable assets:
> > disk image: https://storage.googleapis.com/syzbot-assets/3e24d257ce8d/disk-1fda5bb6.raw.xz
> > vmlinux: https://storage.googleapis.com/syzbot-assets/eaa9caffb0e4/vmlinux-1fda5bb6.xz
> > kernel image: https://storage.googleapis.com/syzbot-assets/16182bbed726/bzImage-1fda5bb6.xz
> >
> > The issue was bisected to:
> >
> > commit ca247283781d754216395a41c5e8be8ec79a5f1c
> > Author: Andy Lutomirski <luto@kernel.org>
> > Date:   Wed Feb 10 02:33:45 2021 +0000
> >
> >     x86/fault: Don't run fixups for SMAP violations
>
> Reverting that makes the Ooops go away, but wrongly so.
>
> > bisection log:  https://syzkaller.appspot.com/x/bisect.txt?x=103d92db680000
> > final oops:     https://syzkaller.appspot.com/x/report.txt?x=123d92db680000
> > console output: https://syzkaller.appspot.com/x/log.txt?x=143d92db680000
> >
> > IMPORTANT: if you fix the issue, please add the following tag to the commit:
> > Reported-by: syzbot+72aa0161922eba61b50e@syzkaller.appspotmail.com
> > Fixes: ca247283781d ("x86/fault: Don't run fixups for SMAP violations")
> >
> > BUG: unable to handle page fault for address: ffffffffff600000
>
> This is VSYSCALL_ADDR.
>
> So the real question is why the BPF program tries to copy from the
> VSYSCALL page, which is not mapped.

The linked syz repro is:

r0 = bpf$PROG_LOAD(0x5, &(0x7f00000000c0)={0x11, 0xb,
&(0x7f0000000180)=@framed={{}, [@printk={@integer, {}, {}, {}, {},
{0x7, 0x0, 0xb, 0x3, 0x0, 0x0, 0xff600000}, {0x85, 0x0, 0x0, 0x71}}]},
&(0x7f0000000200)='GPL\x00', 0x0, 0x0, 0x0, 0x0, 0x0, '\x00', 0x0,
0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0},
0x90)
bpf$BPF_RAW_TRACEPOINT_OPEN(0x11,
&(0x7f0000000540)={&(0x7f0000000000)='kfree\x00', r0}, 0x10)

So syzkaller generated a BPF tracing program. 0x85 is BPF_JMP |
BPF_CALL, which is used to invoke BPF helpers; 0x71 is 113, which is
the number of the probe_read_kernel helper, which basically takes
arbitrary values as input and casts them to kernel pointers, and then
probe-reads them. And before that is some kinda ALU op with 0xff600000
as immediate.

So it looks like the answer to that question is "the BPF program tries
to copy from the VSYSCALL page because syzkaller decided to write BPF
code that does specifically that, and the BPF helper let it do that".

copy_from_kernel_nofault() does check
copy_from_kernel_nofault_allowed() to make sure the pointer really is
a kernel pointer, and the X86 version of that rejects anything in the
userspace part of the address space. But it does not know about the
vsyscall area.

Re: [syzbot] [mm?] BUG: unable to handle kernel paging request in copy_from_kernel_nofault

[Thomas Gleixner]

On Fri, Dec 08 2023 at 15:11, Jann Horn wrote:
> On Tue, Nov 21, 2023 at 6:13 PM Thomas Gleixner <tglx@linutronix.de> wrote:
>> > BUG: unable to handle page fault for address: ffffffffff600000
>>
>> This is VSYSCALL_ADDR.
>>
>> So the real question is why the BPF program tries to copy from the
>> VSYSCALL page, which is not mapped.
>
> The linked syz repro is:
>
> r0 = bpf$PROG_LOAD(0x5, &(0x7f00000000c0)={0x11, 0xb,
> &(0x7f0000000180)=@framed={{}, [@printk={@integer, {}, {}, {}, {},
> {0x7, 0x0, 0xb, 0x3, 0x0, 0x0, 0xff600000}, {0x85, 0x0, 0x0, 0x71}}]},
> &(0x7f0000000200)='GPL\x00', 0x0, 0x0, 0x0, 0x0, 0x0, '\x00', 0x0,
> 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0},
> 0x90)
> bpf$BPF_RAW_TRACEPOINT_OPEN(0x11,
> &(0x7f0000000540)={&(0x7f0000000000)='kfree\x00', r0}, 0x10)
>
> So syzkaller generated a BPF tracing program. 0x85 is BPF_JMP |
> BPF_CALL, which is used to invoke BPF helpers; 0x71 is 113, which is
> the number of the probe_read_kernel helper, which basically takes
> arbitrary values as input and casts them to kernel pointers, and then
> probe-reads them. And before that is some kinda ALU op with 0xff600000
> as immediate.
>
> So it looks like the answer to that question is "the BPF program tries
> to copy from the VSYSCALL page because syzkaller decided to write BPF
> code that does specifically that, and the BPF helper let it do that".

Indeed.

> copy_from_kernel_nofault() does check
> copy_from_kernel_nofault_allowed() to make sure the pointer really is
> a kernel pointer, and the X86 version of that rejects anything in the
> userspace part of the address space. But it does not know about the
> vsyscall area.

That's cureable. Untested fix below.

Thanks for the explanation!

       tglx

---
diff --git a/arch/x86/mm/maccess.c b/arch/x86/mm/maccess.c
index 6993f026adec..8e846833aa37 100644
--- a/arch/x86/mm/maccess.c
+++ b/arch/x86/mm/maccess.c
@@ -3,6 +3,8 @@
 #include <linux/uaccess.h>
 #include <linux/kernel.h>
 
+#include <uapi/asm/vsyscall.h>
+
 #ifdef CONFIG_X86_64
 bool copy_from_kernel_nofault_allowed(const void *unsafe_src, size_t size)
 {
@@ -15,6 +17,9 @@ bool copy_from_kernel_nofault_allowed(const void *unsafe_src, size_t size)
 	if (vaddr < TASK_SIZE_MAX + PAGE_SIZE)
 		return false;
 
+	if ((vaddr & PAGE_MASK) == VSYSCALL_ADDR)
+		return false;
+
 	/*
 	 * Allow everything during early boot before 'x86_virt_bits'
 	 * is initialized.  Needed for instruction decoding in early

Re: [syzbot] [mm?] BUG: unable to handle kernel paging request in copy_from_kernel_nofault

[Hou Tao]

Hi Thomas,

On 12/9/2023 5:01 AM, Thomas Gleixner wrote:
> diff --git a/arch/x86/mm/maccess.c b/arch/x86/mm/maccess.c
> index 6993f026adec..8e846833aa37 100644
> --- a/arch/x86/mm/maccess.c
> +++ b/arch/x86/mm/maccess.c
> @@ -3,6 +3,8 @@
>  #include <linux/uaccess.h>
>  #include <linux/kernel.h>
>  
> +#include <uapi/asm/vsyscall.h>
> +
>  #ifdef CONFIG_X86_64
>  bool copy_from_kernel_nofault_allowed(const void *unsafe_src, size_t size)
>  {
> @@ -15,6 +17,9 @@ bool copy_from_kernel_nofault_allowed(const void *unsafe_src, size_t size)
>  	if (vaddr < TASK_SIZE_MAX + PAGE_SIZE)
>  		return false;
>  
> +	if ((vaddr & PAGE_MASK) == VSYSCALL_ADDR)
> +		return false;
> +
>  	/*
>  	 * Allow everything during early boot before 'x86_virt_bits'
>  	 * is initialized.  Needed for instruction decoding in early

Tested-by: Hou Tao <houtao1@huawei.com>

Could you please post a formal patch for the fix ? The patch fixes the
oops when using bpf_probe_read_kernel() or similar bpf helpers [1] to
read from vsyscall address and you can take my tested-by tag if it is
necessary.

[1]:
https://lore.kernel.org/bpf/CABOYnLynjBoFZOf3Z4BhaZkc5hx_kHfsjiW+UWLoB=w33LvScw@mail.gmail.com/

Re: [syzbot] [mm?] BUG: unable to handle kernel paging request in copy_from_kernel_nofault

[Guilherme G. Piccoli]

Hi Thomas et.al,

I've been testing some syzkaller reports and found 2 other bugs that are
fixed by this patch (see other report at [0]).

So, is there anything we could do in order to get it properly submitted
/ merged? Lemme know if I can help in anything, I could submit it myself
if you prefer, keeping you as author and adding the tested tags.
BTW, feel free to add:

Tested-by: Guilherme G. Piccoli <gpiccoli@igalia.com>


Thanks,

Guilherme


[0] One is internal and the other I already mailed in:
https://lore.kernel.org/lkml/66cb411b-557a-6a70-57c9-457c969fec24@igalia.com/

Re: [syzbot] [mm?] BUG: unable to handle kernel paging request in copy_from_kernel_nofault

[Alexei Starovoitov]

On Thu, Feb 22, 2024 at 6:30 AM Guilherme G. Piccoli
<gpiccoli@igalia.com> wrote:
>
> Hi Thomas et.al,
>
> I've been testing some syzkaller reports and found 2 other bugs that are
> fixed by this patch (see other report at [0]).
>
> So, is there anything we could do in order to get it properly submitted
> / merged? Lemme know if I can help in anything, I could submit it myself
> if you prefer, keeping you as author and adding the tested tags.
> BTW, feel free to add:
>
> Tested-by: Guilherme G. Piccoli <gpiccoli@igalia.com>

The fix is bpf and net trees and probably will be sent to Linus today
as part of net PR.

Re: [syzbot] [mm?] BUG: unable to handle kernel paging request in copy_from_kernel_nofault

[Guilherme G. Piccoli]

On 22/02/2024 13:04, Alexei Starovoitov wrote:
> [...]
> The fix is bpf and net trees and probably will be sent to Linus today
> as part of net PR.

Thanks a lot Alexei!

So, for completeness / archiving, the patch was now split in 2 and the
links are:

https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=ee0e39a63b7
https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=32019c659ec

Cheers,


Guilherme

Re: [syzbot] [mm?] BUG: unable to handle kernel paging request in copy_from_kernel_nofault

[Alexei Starovoitov]

On Thu, Feb 22, 2024 at 5:09 PM Guilherme G. Piccoli
<gpiccoli@igalia.com> wrote:
>
> On 22/02/2024 13:04, Alexei Starovoitov wrote:
> > [...]
> > The fix is bpf and net trees and probably will be sent to Linus today
> > as part of net PR.
>
> Thanks a lot Alexei!
>
> So, for completeness / archiving, the patch was now split in 2 and the
> links are:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=ee0e39a63b7
> https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=32019c659ec

Correct.
Please double check with your two syzbot tests.

Re: [syzbot] [mm?] BUG: unable to handle kernel paging request in copy_from_kernel_nofault

[Guilherme G. Piccoli]

On 22/02/2024 22:11, Alexei Starovoitov wrote:
> [...]
> 
> Correct.
> Please double check with your two syzbot tests.

Thanks for confirming!

Tested the fixes both for 5.15.y and 6.1.y - working fine =)
Cheers,


Guilherme