[syzbot] [trace?] KASAN: use-after-free Read in ring_buffer_map

[syzbot] [trace?] KASAN: use-after-free Read in ring_buffer_map

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit:    f932fb9b4074 Merge tag 'v6.13-rc2-ksmbd-server-fixes' of g..
git tree:       upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=109b2d44580000
kernel config:  https://syzkaller.appspot.com/x/.config?x=99a5586995ec03b2
dashboard link: https://syzkaller.appspot.com/bug?extid=345e4443a21200874b18
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=13ca24f8580000
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=14514730580000

Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/f0d0c95f5364/disk-f932fb9b.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/201cf3c7a7b5/vmlinux-f932fb9b.xz
kernel image: https://storage.googleapis.com/syzbot-assets/fcb972084579/bzImage-f932fb9b.xz

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+345e4443a21200874b18@syzkaller.appspotmail.com

==================================================================
BUG: KASAN: slab-out-of-bounds in __rb_map_vma+0x9ab/0xae0 kernel/trace/ring_buffer.c:7058
Read of size 8 at addr ffff8880767dd2b8 by task syz-executor187/5836

CPU: 0 UID: 0 PID: 5836 Comm: syz-executor187 Not tainted 6.13.0-rc2-syzkaller-00159-gf932fb9b4074 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/25/2024
Call Trace:
 <TASK>
 __dump_stack lib/dump_stack.c:94 [inline]
 dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120
 print_address_description mm/kasan/report.c:378 [inline]
 print_report+0xc3/0x620 mm/kasan/report.c:489
 kasan_report+0xd9/0x110 mm/kasan/report.c:602
 __rb_map_vma+0x9ab/0xae0 kernel/trace/ring_buffer.c:7058
 ring_buffer_map+0x56e/0x9b0 kernel/trace/ring_buffer.c:7138
 tracing_buffers_mmap+0xa6/0x120 kernel/trace/trace.c:8482
 call_mmap include/linux/fs.h:2183 [inline]
 mmap_file mm/internal.h:124 [inline]
 __mmap_new_file_vma mm/vma.c:2291 [inline]
 __mmap_new_vma mm/vma.c:2355 [inline]
 __mmap_region+0x1786/0x2670 mm/vma.c:2456
 mmap_region+0x127/0x320 mm/mmap.c:1348
 do_mmap+0xc00/0xfc0 mm/mmap.c:496
 vm_mmap_pgoff+0x1ba/0x360 mm/util.c:580
 ksys_mmap_pgoff+0x32c/0x5c0 mm/mmap.c:542
 __do_sys_mmap arch/x86/kernel/sys_x86_64.c:89 [inline]
 __se_sys_mmap arch/x86/kernel/sys_x86_64.c:82 [inline]
 __x64_sys_mmap+0x125/0x190 arch/x86/kernel/sys_x86_64.c:82
 do_syscall_x64 arch/x86/entry/common.c:52 [inline]
 do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f3a0489e9f9
Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 c1 17 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007ffd1dfacbc8 EFLAGS: 00000246 ORIG_RAX: 0000000000000009
RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f3a0489e9f9
RDX: 0000000000000040 RSI: 0000000000000009 RDI: 0000000000000000
RBP: 00007f3a049115f0 R08: 0000000000000003 R09: 0000000000008000
R10: 0000000000000013 R11: 0000000000000246 R12: 0000000000000001
R13: 431bde82d7b634db R14: 0000000000000001 R15: 0000000000000001
 </TASK>

Allocated by task 5836:
 kasan_save_stack+0x33/0x60 mm/kasan/common.c:47
 kasan_save_track+0x14/0x30 mm/kasan/common.c:68
 poison_kmalloc_redzone mm/kasan/common.c:377 [inline]
 __kasan_kmalloc+0xaa/0xb0 mm/kasan/common.c:394
 kasan_kmalloc include/linux/kasan.h:260 [inline]
 __do_kmalloc_node mm/slub.c:4283 [inline]
 __kmalloc_noprof+0x21a/0x4f0 mm/slub.c:4295
 kmalloc_noprof include/linux/slab.h:905 [inline]
 kmalloc_array_noprof include/linux/slab.h:946 [inline]
 ring_buffer_map+0x1e1/0x9b0 kernel/trace/ring_buffer.c:7120
 tracing_buffers_mmap+0xa6/0x120 kernel/trace/trace.c:8482
 call_mmap include/linux/fs.h:2183 [inline]
 mmap_file mm/internal.h:124 [inline]
 __mmap_new_file_vma mm/vma.c:2291 [inline]
 __mmap_new_vma mm/vma.c:2355 [inline]
 __mmap_region+0x1786/0x2670 mm/vma.c:2456
 mmap_region+0x127/0x320 mm/mmap.c:1348
 do_mmap+0xc00/0xfc0 mm/mmap.c:496
 vm_mmap_pgoff+0x1ba/0x360 mm/util.c:580
 ksys_mmap_pgoff+0x32c/0x5c0 mm/mmap.c:542
 __do_sys_mmap arch/x86/kernel/sys_x86_64.c:89 [inline]
 __se_sys_mmap arch/x86/kernel/sys_x86_64.c:82 [inline]
 __x64_sys_mmap+0x125/0x190 arch/x86/kernel/sys_x86_64.c:82
 do_syscall_x64 arch/x86/entry/common.c:52 [inline]
 do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83
 entry_SYSCALL_64_after_hwframe+0x77/0x7f

The buggy address belongs to the object at ffff8880767dd280
 which belongs to the cache kmalloc-32 of size 32
The buggy address is located 32 bytes to the right of
 allocated 24-byte region [ffff8880767dd280, ffff8880767dd298)

The buggy address belongs to the physical page:
page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x767dd
flags: 0xfff00000000000(node=0|zone=1|lastcpupid=0x7ff)
page_type: f5(slab)
raw: 00fff00000000000 ffff88801ac41780 dead000000000122 0000000000000000
raw: 0000000000000000 0000000080400040 00000001f5000000 0000000000000000
page dumped because: kasan: bad access detected
page_owner tracks the page as allocated
page last allocated via order 0, migratetype Unmovable, gfp_mask 0x52800(GFP_NOWAIT|__GFP_NORETRY|__GFP_COMP), pid 5833, tgid 5833 (sshd), ts 84990303308, free_ts 79508073557
 set_page_owner include/linux/page_owner.h:32 [inline]
 post_alloc_hook+0x2d1/0x350 mm/page_alloc.c:1556
 prep_new_page mm/page_alloc.c:1564 [inline]
 get_page_from_freelist+0xfce/0x2f80 mm/page_alloc.c:3474
 __alloc_pages_noprof+0x223/0x25b0 mm/page_alloc.c:4751
 alloc_pages_mpol_noprof+0x2c9/0x610 mm/mempolicy.c:2269
 alloc_slab_page mm/slub.c:2408 [inline]
 allocate_slab mm/slub.c:2574 [inline]
 new_slab+0x2c9/0x410 mm/slub.c:2627
 ___slab_alloc+0xce2/0x1650 mm/slub.c:3815
 __slab_alloc.constprop.0+0x56/0xb0 mm/slub.c:3905
 __slab_alloc_node mm/slub.c:3980 [inline]
 slab_alloc_node mm/slub.c:4141 [inline]
 __kmalloc_cache_noprof+0xf6/0x420 mm/slub.c:4309
 kmalloc_noprof include/linux/slab.h:901 [inline]
 slab_free_hook mm/slub.c:2290 [inline]
 slab_free mm/slub.c:4598 [inline]
 kmem_cache_free+0x2ef/0x4c0 mm/slub.c:4700
 file_free fs/file_table.c:76 [inline]
 fput+0x3ad/0x440 fs/file_table.c:505
 path_openat+0xec1/0x2d60 fs/namei.c:3996
 do_filp_open+0x20c/0x470 fs/namei.c:4014
 do_sys_openat2+0x17a/0x1e0 fs/open.c:1402
 do_sys_open fs/open.c:1417 [inline]
 __do_sys_openat fs/open.c:1433 [inline]
 __se_sys_openat fs/open.c:1428 [inline]
 __x64_sys_openat+0x175/0x210 fs/open.c:1428
 do_syscall_x64 arch/x86/entry/common.c:52 [inline]
 do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
page last free pid 5832 tgid 5832 stack trace:
 reset_page_owner include/linux/page_owner.h:25 [inline]
 free_pages_prepare mm/page_alloc.c:1127 [inline]
 free_unref_page+0x661/0x1080 mm/page_alloc.c:2657
 __folio_put+0x32a/0x450 mm/swap.c:112
 folio_put include/linux/mm.h:1488 [inline]
 put_page+0x21e/0x280 include/linux/mm.h:1560
 anon_pipe_buf_release+0x11a/0x240 fs/pipe.c:128
 pipe_buf_release include/linux/pipe_fs_i.h:219 [inline]
 pipe_update_tail fs/pipe.c:224 [inline]
 pipe_read+0x641/0x13f0 fs/pipe.c:344
 new_sync_read fs/read_write.c:484 [inline]
 vfs_read+0xa4c/0xbe0 fs/read_write.c:565
 ksys_read+0x207/0x250 fs/read_write.c:708
 do_syscall_x64 arch/x86/entry/common.c:52 [inline]
 do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83
 entry_SYSCALL_64_after_hwframe+0x77/0x7f

Memory state around the buggy address:
 ffff8880767dd180: fa fb fb fb fc fc fc fc fa fb fb fb fc fc fc fc
 ffff8880767dd200: fa fb fb fb fc fc fc fc 00 00 00 fc fc fc fc fc
>ffff8880767dd280: 00 00 00 fc fc fc fc fc fc fc fc fc fc fc fc fc
                                        ^
 ffff8880767dd300: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
 ffff8880767dd380: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
==================================================================


---
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.

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

[PATCH] ring-buffer: Fix a oob in __rb_map_vma

[Edward Adam Davis]

syzbot report a slab-out-of-bounds in __rb_map_vma. [1]

Overflow occurred when performing the following calculation:
nr_pages = ((nr_subbufs + 1) << subbuf_order) - pgoff;

Add a check before the calculation to avoid this problem.

[1]
BUG: KASAN: slab-out-of-bounds in __rb_map_vma+0x9ab/0xae0 kernel/trace/ring_buffer.c:7058
Read of size 8 at addr ffff8880767dd2b8 by task syz-executor187/5836

CPU: 0 UID: 0 PID: 5836 Comm: syz-executor187 Not tainted 6.13.0-rc2-syzkaller-00159-gf932fb9b4074 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/25/2024
Call Trace:
 <TASK>
 __dump_stack lib/dump_stack.c:94 [inline]
 dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120
 print_address_description mm/kasan/report.c:378 [inline]
 print_report+0xc3/0x620 mm/kasan/report.c:489
 kasan_report+0xd9/0x110 mm/kasan/report.c:602
 __rb_map_vma+0x9ab/0xae0 kernel/trace/ring_buffer.c:7058
 ring_buffer_map+0x56e/0x9b0 kernel/trace/ring_buffer.c:7138
 tracing_buffers_mmap+0xa6/0x120 kernel/trace/trace.c:8482
 call_mmap include/linux/fs.h:2183 [inline]
 mmap_file mm/internal.h:124 [inline]
 __mmap_new_file_vma mm/vma.c:2291 [inline]
 __mmap_new_vma mm/vma.c:2355 [inline]
 __mmap_region+0x1786/0x2670 mm/vma.c:2456
 mmap_region+0x127/0x320 mm/mmap.c:1348
 do_mmap+0xc00/0xfc0 mm/mmap.c:496
 vm_mmap_pgoff+0x1ba/0x360 mm/util.c:580
 ksys_mmap_pgoff+0x32c/0x5c0 mm/mmap.c:542
 __do_sys_mmap arch/x86/kernel/sys_x86_64.c:89 [inline]
 __se_sys_mmap arch/x86/kernel/sys_x86_64.c:82 [inline]
 __x64_sys_mmap+0x125/0x190 arch/x86/kernel/sys_x86_64.c:82
 do_syscall_x64 arch/x86/entry/common.c:52 [inline]
 do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83
 entry_SYSCALL_64_after_hwframe+0x77/0x7f

Reported-by: syzbot+345e4443a21200874b18@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=345e4443a21200874b18
Tested-by: syzbot+345e4443a21200874b18@syzkaller.appspotmail.com
Signed-off-by: Edward Adam Davis <eadavis@qq.com>
---
 kernel/trace/ring_buffer.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/kernel/trace/ring_buffer.c b/kernel/trace/ring_buffer.c
index 7e257e855dd1..15c43d7415d5 100644
--- a/kernel/trace/ring_buffer.c
+++ b/kernel/trace/ring_buffer.c
@@ -7019,6 +7019,9 @@ static int __rb_map_vma(struct ring_buffer_per_cpu *cpu_buffer,
 	lockdep_assert_held(&cpu_buffer->mapping_lock);
 
 	nr_subbufs = cpu_buffer->nr_pages + 1; /* + reader-subbuf */
+	if (((nr_subbufs + 1) << subbuf_order) < pgoff)
+		return -EINVAL;
+
 	nr_pages = ((nr_subbufs + 1) << subbuf_order) - pgoff; /* + meta-page */
 
 	nr_vma_pages = vma_pages(vma);
-- 
2.47.0

Re: [PATCH] ring-buffer: Fix a oob in __rb_map_vma

[Steven Rostedt]

On Mon, 16 Dec 2024 22:07:57 +0800
Edward Adam Davis <eadavis@qq.com> wrote:

> syzbot report a slab-out-of-bounds in __rb_map_vma. [1]
> 
> Overflow occurred when performing the following calculation:
> nr_pages = ((nr_subbufs + 1) << subbuf_order) - pgoff;
> 
> Add a check before the calculation to avoid this problem.
> 
> [1]
> BUG: KASAN: slab-out-of-bounds in __rb_map_vma+0x9ab/0xae0 kernel/trace/ring_buffer.c:7058
> Read of size 8 at addr ffff8880767dd2b8 by task syz-executor187/5836
> 
> CPU: 0 UID: 0 PID: 5836 Comm: syz-executor187 Not tainted 6.13.0-rc2-syzkaller-00159-gf932fb9b4074 #0
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/25/2024
> Call Trace:
>  <TASK>
>  __dump_stack lib/dump_stack.c:94 [inline]
>  dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120
>  print_address_description mm/kasan/report.c:378 [inline]
>  print_report+0xc3/0x620 mm/kasan/report.c:489
>  kasan_report+0xd9/0x110 mm/kasan/report.c:602
>  __rb_map_vma+0x9ab/0xae0 kernel/trace/ring_buffer.c:7058
>  ring_buffer_map+0x56e/0x9b0 kernel/trace/ring_buffer.c:7138
>  tracing_buffers_mmap+0xa6/0x120 kernel/trace/trace.c:8482
>  call_mmap include/linux/fs.h:2183 [inline]
>  mmap_file mm/internal.h:124 [inline]
>  __mmap_new_file_vma mm/vma.c:2291 [inline]
>  __mmap_new_vma mm/vma.c:2355 [inline]
>  __mmap_region+0x1786/0x2670 mm/vma.c:2456
>  mmap_region+0x127/0x320 mm/mmap.c:1348
>  do_mmap+0xc00/0xfc0 mm/mmap.c:496
>  vm_mmap_pgoff+0x1ba/0x360 mm/util.c:580
>  ksys_mmap_pgoff+0x32c/0x5c0 mm/mmap.c:542
>  __do_sys_mmap arch/x86/kernel/sys_x86_64.c:89 [inline]
>  __se_sys_mmap arch/x86/kernel/sys_x86_64.c:82 [inline]
>  __x64_sys_mmap+0x125/0x190 arch/x86/kernel/sys_x86_64.c:82
>  do_syscall_x64 arch/x86/entry/common.c:52 [inline]
>  do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83
>  entry_SYSCALL_64_after_hwframe+0x77/0x7f
> 
> Reported-by: syzbot+345e4443a21200874b18@syzkaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?extid=345e4443a21200874b18
> Tested-by: syzbot+345e4443a21200874b18@syzkaller.appspotmail.com
> Signed-off-by: Edward Adam Davis <eadavis@qq.com>
> ---
>  kernel/trace/ring_buffer.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/kernel/trace/ring_buffer.c b/kernel/trace/ring_buffer.c
> index 7e257e855dd1..15c43d7415d5 100644
> --- a/kernel/trace/ring_buffer.c
> +++ b/kernel/trace/ring_buffer.c
> @@ -7019,6 +7019,9 @@ static int __rb_map_vma(struct ring_buffer_per_cpu *cpu_buffer,
>  	lockdep_assert_held(&cpu_buffer->mapping_lock);
>  
>  	nr_subbufs = cpu_buffer->nr_pages + 1; /* + reader-subbuf */
> +	if (((nr_subbufs + 1) << subbuf_order) < pgoff)
> +		return -EINVAL;
> +

A proper fix is being discussed here:

https://lore.kernel.org/linux-trace-kernel/20241216164931.57323-1-aha310510@gmail.com/

Thank you,

-- Steve

>  	nr_pages = ((nr_subbufs + 1) << subbuf_order) - pgoff; /* + meta-page */
>  
>  	nr_vma_pages = vma_pages(vma);

Re: [PATCH] ring-buffer: Fix a oob in __rb_map_vma

[Edward Adam Davis]

On Tue, 17 Dec 2024 12:46:02 -0500, Steven Rostedt wrote:
> On Mon, 16 Dec 2024 22:07:57 +0800
> Edward Adam Davis <eadavis@qq.com> wrote:
> 
> > syzbot report a slab-out-of-bounds in __rb_map_vma. [1]
> > 
> > Overflow occurred when performing the following calculation:
> > nr_pages = ((nr_subbufs + 1) << subbuf_order) - pgoff;
> > 
> > Add a check before the calculation to avoid this problem.
> > 
> > [1]
> > BUG: KASAN: slab-out-of-bounds in __rb_map_vma+0x9ab/0xae0 kernel/trace/ring_buffer.c:7058
> > Read of size 8 at addr ffff8880767dd2b8 by task syz-executor187/5836
> > 
> > CPU: 0 UID: 0 PID: 5836 Comm: syz-executor187 Not tainted 6.13.0-rc2-syzkaller-00159-gf932fb9b4074 #0
> > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/25/2024
> > Call Trace:
> >  <TASK>
> >  __dump_stack lib/dump_stack.c:94 [inline]
> >  dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120
> >  print_address_description mm/kasan/report.c:378 [inline]
> >  print_report+0xc3/0x620 mm/kasan/report.c:489
> >  kasan_report+0xd9/0x110 mm/kasan/report.c:602
> >  __rb_map_vma+0x9ab/0xae0 kernel/trace/ring_buffer.c:7058
> >  ring_buffer_map+0x56e/0x9b0 kernel/trace/ring_buffer.c:7138
> >  tracing_buffers_mmap+0xa6/0x120 kernel/trace/trace.c:8482
> >  call_mmap include/linux/fs.h:2183 [inline]
> >  mmap_file mm/internal.h:124 [inline]
> >  __mmap_new_file_vma mm/vma.c:2291 [inline]
> >  __mmap_new_vma mm/vma.c:2355 [inline]
> >  __mmap_region+0x1786/0x2670 mm/vma.c:2456
> >  mmap_region+0x127/0x320 mm/mmap.c:1348
> >  do_mmap+0xc00/0xfc0 mm/mmap.c:496
> >  vm_mmap_pgoff+0x1ba/0x360 mm/util.c:580
> >  ksys_mmap_pgoff+0x32c/0x5c0 mm/mmap.c:542
> >  __do_sys_mmap arch/x86/kernel/sys_x86_64.c:89 [inline]
> >  __se_sys_mmap arch/x86/kernel/sys_x86_64.c:82 [inline]
> >  __x64_sys_mmap+0x125/0x190 arch/x86/kernel/sys_x86_64.c:82
> >  do_syscall_x64 arch/x86/entry/common.c:52 [inline]
> >  do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83
> >  entry_SYSCALL_64_after_hwframe+0x77/0x7f
> > 
> > Reported-by: syzbot+345e4443a21200874b18@syzkaller.appspotmail.com
> > Closes: https://syzkaller.appspot.com/bug?extid=345e4443a21200874b18
> > Tested-by: syzbot+345e4443a21200874b18@syzkaller.appspotmail.com
> > Signed-off-by: Edward Adam Davis <eadavis@qq.com>
> > ---
> >  kernel/trace/ring_buffer.c | 3 +++
> >  1 file changed, 3 insertions(+)
> > 
> > diff --git a/kernel/trace/ring_buffer.c b/kernel/trace/ring_buffer.c
> > index 7e257e855dd1..15c43d7415d5 100644
> > --- a/kernel/trace/ring_buffer.c
> > +++ b/kernel/trace/ring_buffer.c
> > @@ -7019,6 +7019,9 @@ static int __rb_map_vma(struct ring_buffer_per_cpu *cpu_buffer,
> >  	lockdep_assert_held(&cpu_buffer->mapping_lock);
> >  
> >  	nr_subbufs = cpu_buffer->nr_pages + 1; /* + reader-subbuf */
> > +	if (((nr_subbufs + 1) << subbuf_order) < pgoff)
> > +		return -EINVAL;
> > +
> 
> A proper fix is being discussed here:
First, my fix is the first one.
Second, the root cause of the problem is an overflow when calculating nr_pages.
> 
> https://lore.kernel.org/linux-trace-kernel/20241216164931.57323-1-aha310510@gmail.com/
> 
> Thank you,
> 
> -- Steve
> 
The calculation of nr_pages below overflows because the pgoff value is 8,
the nr_subbufs value is 3, and the subbuf_order value is 0.
> >  	nr_pages = ((nr_subbufs + 1) << subbuf_order) - pgoff; /* + meta-page */
> >  
> >  	nr_vma_pages = vma_pages(vma);
BR,
Edward

Re: [PATCH] ring-buffer: Fix a oob in __rb_map_vma

[Steven Rostedt]

On Wed, 18 Dec 2024 07:43:46 +0800
Edward Adam Davis <eadavis@qq.com> wrote:

> > 
> > A proper fix is being discussed here:  
> First, my fix is the first one.

Yes I saw that.

> Second, the root cause of the problem is an overflow when calculating nr_pages.
> > 
> > https://lore.kernel.org/linux-trace-kernel/20241216164931.57323-1-aha310510@gmail.com/
> > 
> > Thank you,
> > 
> > -- Steve
> >   
> The calculation of nr_pages below overflows because the pgoff value is 8,
> the nr_subbufs value is 3, and the subbuf_order value is 0.

So basically you are saying that passing in the the mmap with the pgoff is
what's causing it.

> > >  	nr_pages = ((nr_subbufs + 1) << subbuf_order) - pgoff; /* + meta-page */
> > >  
> > >  	nr_vma_pages = vma_pages(vma);  


Thanks, I believe I now have a reproducer. And yes, I'll take your patch.
(If Vincent is OK with it).

Here's the reproducer:

------------------------8<-------------------------
#include <fcntl.h>
#include <stdlib.h>
#include <unistd.h>
#include <asm/types.h>
#include <sys/mman.h>

int main(int argc, char **argv)
{
	int page_size = getpagesize();
	int fd;
	void *meta;

	system("echo 1 > /sys/kernel/tracing/buffer_size_kb");
	fd = open("/sys/kernel/tracing/per_cpu/cpu0/trace_pipe_raw", O_RDONLY);

	meta = mmap(NULL, page_size, PROT_READ, MAP_SHARED, fd, page_size * 5);
}
------------------------>8-------------------------

Thanks,


-- Steve

Re: [PATCH] ring-buffer: Fix a oob in __rb_map_vma

[Jeongjun Park]

> Steven Rostedt <rostedt@goodmis.org> wrote:
> 
> On Wed, 18 Dec 2024 07:43:46 +0800
> Edward Adam Davis <eadavis@qq.com> wrote:
> 
>>> 
>>> A proper fix is being discussed here:  
>> First, my fix is the first one.
> 
> Yes I saw that.
> 
>> Second, the root cause of the problem is an overflow when calculating nr_pages.
>>> 
>>> https://lore.kernel.org/linux-trace-kernel/20241216164931.57323-1-aha310510@gmail.com/
>>> 
>>> Thank you,
>>> 
>>> -- Steve
>>> 

Oh, I did not propose a patch that fixes the root cause of this oob. My patch 
is a separate patch that fixes the wrong order, such as reading the array 
before checking the variable s with the WARN function in the loop. So I think 
both of these patches should be applied.

Regards,

Jeongjun Park

>> The calculation of nr_pages below overflows because the pgoff value is 8,
>> the nr_subbufs value is 3, and the subbuf_order value is 0.
> 
> So basically you are saying that passing in the the mmap with the pgoff is
> what's causing it.
> 
>>>>    nr_pages = ((nr_subbufs + 1) << subbuf_order) - pgoff; /* + meta-page */
>>>> 
>>>>    nr_vma_pages = vma_pages(vma);  
> 
> 
> Thanks, I believe I now have a reproducer. And yes, I'll take your patch.
> (If Vincent is OK with it).
> 
> Here's the reproducer:
> 
> ------------------------8<-------------------------
> #include <fcntl.h>
> #include <stdlib.h>
> #include <unistd.h>
> #include <asm/types.h>
> #include <sys/mman.h>
> 
> int main(int argc, char **argv)
> {
>    int page_size = getpagesize();
>    int fd;
>    void *meta;
> 
>    system("echo 1 > /sys/kernel/tracing/buffer_size_kb");
>    fd = open("/sys/kernel/tracing/per_cpu/cpu0/trace_pipe_raw", O_RDONLY);
> 
>    meta = mmap(NULL, page_size, PROT_READ, MAP_SHARED, fd, page_size * 5);
> }
> ------------------------>8-------------------------
> 
> Thanks,
> 
> 
> -- Steve

Re: [PATCH] ring-buffer: Fix a oob in __rb_map_vma

[Vincent Donnefort]

On Tue, Dec 17, 2024 at 07:40:15PM -0500, Steven Rostedt wrote:
> On Wed, 18 Dec 2024 07:43:46 +0800
> Edward Adam Davis <eadavis@qq.com> wrote:
> 
> > > 
> > > A proper fix is being discussed here:  
> > First, my fix is the first one.
> 
> Yes I saw that.
> 
> > Second, the root cause of the problem is an overflow when calculating nr_pages.
> > > 
> > > https://lore.kernel.org/linux-trace-kernel/20241216164931.57323-1-aha310510@gmail.com/
> > > 
> > > Thank you,
> > > 
> > > -- Steve
> > >   
> > The calculation of nr_pages below overflows because the pgoff value is 8,
> > the nr_subbufs value is 3, and the subbuf_order value is 0.
> 
> So basically you are saying that passing in the the mmap with the pgoff is
> what's causing it.
> 
> > > >  	nr_pages = ((nr_subbufs + 1) << subbuf_order) - pgoff; /* + meta-page */
> > > >  
> > > >  	nr_vma_pages = vma_pages(vma);  
> 
> 
> Thanks, I believe I now have a reproducer. And yes, I'll take your patch.
> (If Vincent is OK with it).

I wanted to look at the reproducer sent by Jeongjung yesterday but got
preempted. My bad.

To avoid repeating the (nr_subbufs + 1) << subbuf_order How about?

-       nr_pages = ((nr_subbufs + 1) << subbuf_order) - pgoff; /* + meta-page */
+       nr_pages = ((nr_subbufs + 1) << subbuf_order); /* + meta-page */
+
+       if (pgoff > nr_pages)
+               return -EINVAL;
+
+       nr_pages -= pgoff;


And probably also 

Fixes: 117c39200d9d ("ring-buffer: Introducing ring-buffer mapping functions")

> 
> Here's the reproducer:
> 
> ------------------------8<-------------------------
> #include <fcntl.h>
> #include <stdlib.h>
> #include <unistd.h>
> #include <asm/types.h>
> #include <sys/mman.h>
> 
> int main(int argc, char **argv)
> {
> 	int page_size = getpagesize();
> 	int fd;
> 	void *meta;
> 
> 	system("echo 1 > /sys/kernel/tracing/buffer_size_kb");
> 	fd = open("/sys/kernel/tracing/per_cpu/cpu0/trace_pipe_raw", O_RDONLY);
> 
> 	meta = mmap(NULL, page_size, PROT_READ, MAP_SHARED, fd, page_size * 5);
> }
> ------------------------>8-------------------------
> 
> Thanks,
> 
> 
> -- Steve

[PATCH V2] ring-buffer: fix overflow in __rb_map_vma

[Edward Adam Davis]

syzbot report a slab-out-of-bounds in __rb_map_vma. [1]

Overflow occurred when performing the following calculation:
nr_pages = ((nr_subbufs + 1) << subbuf_order) - pgoff;

Add a check before the calculation to avoid this problem.

[1]
BUG: KASAN: slab-out-of-bounds in __rb_map_vma+0x9ab/0xae0 kernel/trace/ring_buffer.c:7058
Read of size 8 at addr ffff8880767dd2b8 by task syz-executor187/5836

CPU: 0 UID: 0 PID: 5836 Comm: syz-executor187 Not tainted 6.13.0-rc2-syzkaller-00159-gf932fb9b4074 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/25/2024
Call Trace:
 <TASK>
 __dump_stack lib/dump_stack.c:94 [inline]
 dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120
 print_address_description mm/kasan/report.c:378 [inline]
 print_report+0xc3/0x620 mm/kasan/report.c:489
 kasan_report+0xd9/0x110 mm/kasan/report.c:602
 __rb_map_vma+0x9ab/0xae0 kernel/trace/ring_buffer.c:7058
 ring_buffer_map+0x56e/0x9b0 kernel/trace/ring_buffer.c:7138
 tracing_buffers_mmap+0xa6/0x120 kernel/trace/trace.c:8482
 call_mmap include/linux/fs.h:2183 [inline]
 mmap_file mm/internal.h:124 [inline]
 __mmap_new_file_vma mm/vma.c:2291 [inline]
 __mmap_new_vma mm/vma.c:2355 [inline]
 __mmap_region+0x1786/0x2670 mm/vma.c:2456
 mmap_region+0x127/0x320 mm/mmap.c:1348
 do_mmap+0xc00/0xfc0 mm/mmap.c:496
 vm_mmap_pgoff+0x1ba/0x360 mm/util.c:580
 ksys_mmap_pgoff+0x32c/0x5c0 mm/mmap.c:542
 __do_sys_mmap arch/x86/kernel/sys_x86_64.c:89 [inline]
 __se_sys_mmap arch/x86/kernel/sys_x86_64.c:82 [inline]
 __x64_sys_mmap+0x125/0x190 arch/x86/kernel/sys_x86_64.c:82
 do_syscall_x64 arch/x86/entry/common.c:52 [inline]
 do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83
 entry_SYSCALL_64_after_hwframe+0x77/0x7f

Reported-by: syzbot+345e4443a21200874b18@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=345e4443a21200874b18
Signed-off-by: Edward Adam Davis <eadavis@qq.com>
---
V1 -> V2: updated according to Vincent Donnefort's suggestion, to avoid repeating the (nr_subbufs + 1) << subbuf_order

 kernel/trace/ring_buffer.c | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/kernel/trace/ring_buffer.c b/kernel/trace/ring_buffer.c
index 7e257e855dd1..20f0e01b7a50 100644
--- a/kernel/trace/ring_buffer.c
+++ b/kernel/trace/ring_buffer.c
@@ -7019,7 +7019,11 @@ static int __rb_map_vma(struct ring_buffer_per_cpu *cpu_buffer,
 	lockdep_assert_held(&cpu_buffer->mapping_lock);
 
 	nr_subbufs = cpu_buffer->nr_pages + 1; /* + reader-subbuf */
-	nr_pages = ((nr_subbufs + 1) << subbuf_order) - pgoff; /* + meta-page */
+	nr_pages = ((nr_subbufs + 1) << subbuf_order); /* + meta-page */
+	if (nr_pages < pgoff)
+		return -EINVAL;
+
+	nr_pages -= pgoff;
 
 	nr_vma_pages = vma_pages(vma);
 	if (!nr_vma_pages || nr_vma_pages > nr_pages)
-- 
2.47.0

Re: [PATCH V2] ring-buffer: fix overflow in __rb_map_vma

[Steven Rostedt]

On Wed, 18 Dec 2024 19:42:22 +0800
Edward Adam Davis <eadavis@qq.com> wrote:

> diff --git a/kernel/trace/ring_buffer.c b/kernel/trace/ring_buffer.c
> index 7e257e855dd1..20f0e01b7a50 100644
> --- a/kernel/trace/ring_buffer.c
> +++ b/kernel/trace/ring_buffer.c
> @@ -7019,7 +7019,11 @@ static int __rb_map_vma(struct ring_buffer_per_cpu *cpu_buffer,
>  	lockdep_assert_held(&cpu_buffer->mapping_lock);
>  
>  	nr_subbufs = cpu_buffer->nr_pages + 1; /* + reader-subbuf */
> -	nr_pages = ((nr_subbufs + 1) << subbuf_order) - pgoff; /* + meta-page */
> +	nr_pages = ((nr_subbufs + 1) << subbuf_order); /* + meta-page */
> +	if (nr_pages < pgoff)

That probably should be <= as if it was equal...

> +		return -EINVAL;
> +
> +	nr_pages -= pgoff;

nr_pages would be zero and

>  
>  	nr_vma_pages = vma_pages(vma);
>  	if (!nr_vma_pages || nr_vma_pages > nr_pages)

this would return true, which the next line is:

		return -EINVAL;

Why not catch it before going through all that?

-- Steve


> -- 

[PATCH V3] ring-buffer: fix overflow in __rb_map_vma

[Edward Adam Davis]

syzbot report a slab-out-of-bounds in __rb_map_vma. [1]

Overflow occurred when performing the following calculation:
nr_pages = ((nr_subbufs + 1) << subbuf_order) - pgoff;

Add a check before the calculation to avoid this problem.

[1]
BUG: KASAN: slab-out-of-bounds in __rb_map_vma+0x9ab/0xae0 kernel/trace/ring_buffer.c:7058
Read of size 8 at addr ffff8880767dd2b8 by task syz-executor187/5836

CPU: 0 UID: 0 PID: 5836 Comm: syz-executor187 Not tainted 6.13.0-rc2-syzkaller-00159-gf932fb9b4074 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/25/2024
Call Trace:
 <TASK>
 __dump_stack lib/dump_stack.c:94 [inline]
 dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120
 print_address_description mm/kasan/report.c:378 [inline]
 print_report+0xc3/0x620 mm/kasan/report.c:489
 kasan_report+0xd9/0x110 mm/kasan/report.c:602
 __rb_map_vma+0x9ab/0xae0 kernel/trace/ring_buffer.c:7058
 ring_buffer_map+0x56e/0x9b0 kernel/trace/ring_buffer.c:7138
 tracing_buffers_mmap+0xa6/0x120 kernel/trace/trace.c:8482
 call_mmap include/linux/fs.h:2183 [inline]
 mmap_file mm/internal.h:124 [inline]
 __mmap_new_file_vma mm/vma.c:2291 [inline]
 __mmap_new_vma mm/vma.c:2355 [inline]
 __mmap_region+0x1786/0x2670 mm/vma.c:2456
 mmap_region+0x127/0x320 mm/mmap.c:1348
 do_mmap+0xc00/0xfc0 mm/mmap.c:496
 vm_mmap_pgoff+0x1ba/0x360 mm/util.c:580
 ksys_mmap_pgoff+0x32c/0x5c0 mm/mmap.c:542
 __do_sys_mmap arch/x86/kernel/sys_x86_64.c:89 [inline]
 __se_sys_mmap arch/x86/kernel/sys_x86_64.c:82 [inline]
 __x64_sys_mmap+0x125/0x190 arch/x86/kernel/sys_x86_64.c:82
 do_syscall_x64 arch/x86/entry/common.c:52 [inline]
 do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83
 entry_SYSCALL_64_after_hwframe+0x77/0x7f

Reported-by: syzbot+345e4443a21200874b18@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=345e4443a21200874b18
Signed-off-by: Edward Adam Davis <eadavis@qq.com>
---
V1 -> V2: updated according to Vincent Donnefort's suggestion, to avoid repeating the (nr_subbufs + 1) << subbuf_order
V2 -> V3: Add equal condition judgment

 kernel/trace/ring_buffer.c | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/kernel/trace/ring_buffer.c b/kernel/trace/ring_buffer.c
index 7e257e855dd1..20f0e01b7a50 100644
--- a/kernel/trace/ring_buffer.c
+++ b/kernel/trace/ring_buffer.c
@@ -7019,7 +7019,11 @@ static int __rb_map_vma(struct ring_buffer_per_cpu *cpu_buffer,
 	lockdep_assert_held(&cpu_buffer->mapping_lock);
 
 	nr_subbufs = cpu_buffer->nr_pages + 1; /* + reader-subbuf */
-	nr_pages = ((nr_subbufs + 1) << subbuf_order) - pgoff; /* + meta-page */
+	nr_pages = ((nr_subbufs + 1) << subbuf_order); /* + meta-page */
+	if (nr_pages <= pgoff)
+		return -EINVAL;
+
+	nr_pages -= pgoff;
 
 	nr_vma_pages = vma_pages(vma);
 	if (!nr_vma_pages || nr_vma_pages > nr_pages)
-- 
2.47.0

Re: [PATCH V2] ring-buffer: fix overflow in __rb_map_vma

[Steven Rostedt]

On Wed, 18 Dec 2024 19:42:22 +0800
Edward Adam Davis <eadavis@qq.com> wrote:

> Reported-by: syzbot+345e4443a21200874b18@syzkaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?extid=345e4443a21200874b18
> Signed-off-by: Edward Adam Davis <eadavis@qq.com>
> ---
> V1 -> V2: updated according to Vincent Donnefort's suggestion, to avoid repeating the (nr_subbufs + 1) << subbuf_order
> 
>  kernel/trace/ring_buffer.c | 6 +++++-
>  1 file changed, 5 insertions(+), 1 deletion(-)


Also, when sending a new version of a patch, do not reply to the previous
version as that hides the new patch. It should start a new thread.
Otherwise it screws up tooling and also hides patches. I've missed patches
because they were replied to the previous patch. It makes it much harder on
the maintainer when someone does that.

What I usually do to maintain a history chain is have:

Signed-off-by: ...
---
Changes since v1: https://lore.kernel.org/all/tencent_E036A29600368E4A2075A7774D67023CFD09@qq.com/

- Updated according to Vincent Donnefort's suggestion, to avoid repeating
  the (nr_subbufs + 1) << subbuf_order


-- Steve

Re: [PATCH] ring-buffer: Fix a oob in __rb_map_vma

[Steven Rostedt]

On Wed, 18 Dec 2024 09:13:43 +0000
Vincent Donnefort <vdonnefort@google.com> wrote:

> And probably also 
> 
> Fixes: 117c39200d9d ("ring-buffer: Introducing ring-buffer mapping functions")

I don't require patch submitters to add Fixes tags. It's more the
responsibility of the maintainer to do that. I still have to validate it as
there's been several times someone adds a Fixes tag which wasn't the right
commit that it fixed.

-- Steve

Re: [PATCH] ring-buffer: Fix a oob in __rb_map_vma

[Vincent Donnefort]

On Wed, Dec 18, 2024 at 08:19:58AM -0500, Steven Rostedt wrote:
> On Wed, 18 Dec 2024 09:13:43 +0000
> Vincent Donnefort <vdonnefort@google.com> wrote:
> 
> > And probably also 
> > 
> > Fixes: 117c39200d9d ("ring-buffer: Introducing ring-buffer mapping functions")
> 
> I don't require patch submitters to add Fixes tags. It's more the
> responsibility of the maintainer to do that. I still have to validate it as
> there's been several times someone adds a Fixes tag which wasn't the right
> commit that it fixed.
> 
> -- Steve

Ack.

Aside, there's a selftest to check for the overflow of subbufs with the
mapping... but of course it didn't test with offset > nr_subbufs.

Do you think it is worth to extend it to cover this case? I'm happy to do a
quick patch.

-- 
Vincent

Re: [PATCH] ring-buffer: Fix a oob in __rb_map_vma

[Steven Rostedt]

On Wed, 18 Dec 2024 14:31:31 +0000
Vincent Donnefort <vdonnefort@google.com> wrote:

> Aside, there's a selftest to check for the overflow of subbufs with the
> mapping... but of course it didn't test with offset > nr_subbufs.
> 
> Do you think it is worth to extend it to cover this case? I'm happy to do a
> quick patch.

Yes, it should check that case.

Thanks,

-- Steve