public inbox for [email protected]
 help / color / mirror / Atom feed
From: Jiri Slaby <[email protected]>
To: Pavel Begunkov <[email protected]>, [email protected]
Cc: Jens Axboe <[email protected]>,
	[email protected]
Subject: Re: User-triggerable 6.1 crash [was: io_uring/net: fix cleanup double free free_iov init]
Date: Mon, 19 Dec 2022 13:32:14 +0100	[thread overview]
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>

On 19. 12. 22, 11:23, Jiri Slaby wrote:
> On 26. 09. 22, 15:35, Pavel Begunkov wrote:
>> Having ->async_data doesn't mean it's initialised and previously we vere
>> relying on setting F_CLEANUP at the right moment. With zc sendmsg
>> though, we set F_CLEANUP early in prep when we alloc a notif and so we
>> may allocate async_data, fail in copy_msg_hdr() leaving
>> struct io_async_msghdr not initialised correctly but with F_CLEANUP
>> set, which causes a ->free_iov double free and probably other nastiness.
>>
>> Always initialise ->free_iov. Also, now it might point to fast_iov when
>> fails, so avoid freeing it during cleanups.
>>
>> Reported-by: [email protected]
>> Fixes: 493108d95f146 ("io_uring/net: zerocopy sendmsg")
>> Signed-off-by: Pavel Begunkov <[email protected]>
> 
> Hi,
> 
> it's rather easy to crash 6.1 with this patch now. Compile 
> liburing-2.2/test/send_recvmsg.c with -m32, run it as an ordinary user 
> and see the below WARNING followed by many BUGs.
> 
> It dies in this kfree() in io_recvmsg():
>          if (mshot_finished) {
>                  io_netmsg_recycle(req, issue_flags);
>                  /* fast path, check for non-NULL to avoid function call */
>                  if (kmsg->free_iov)
>                          kfree(kmsg->free_iov);
>                  req->flags &= ~REQ_F_NEED_CLEANUP;
>          }

I am attaching a KASAN report instead:

BUG: KASAN: invalid-free in __kmem_cache_free (mm/slub.c:3661 
mm/slub.c:3674)
Free of addr ffff8881049ff328 by task send_recvmsg.t/733

CPU: 3 PID: 733 Comm: send_recvmsg.t Not tainted 6.1.0-default #10 
fd86e1993b1e4baedde4c3e698b88971c38217a0
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015
Call Trace:
<TASK>
dump_stack_lvl (lib/dump_stack.c:107 (discriminator 1))
print_report (mm/kasan/report.c:285 mm/kasan/report.c:395)
kasan_report_invalid_free (mm/kasan/report.c:162 mm/kasan/report.c:462)
____kasan_slab_free (mm/kasan/common.c:217)
slab_free_freelist_hook (mm/slub.c:1750)
__kmem_cache_free (mm/slub.c:3661 mm/slub.c:3674)
io_recvmsg (io_uring/net.c:812)
io_issue_sqe (include/linux/audit.h:314 include/linux/audit.h:339 
io_uring/io_uring.c:1746)
io_req_task_submit (io_uring/io_uring.c:1922 io_uring/io_uring.c:1264)
handle_tw_list (io_uring/io_uring.c:1028)
tctx_task_work (include/linux/instrumented.h:87 io_uring/io_uring.c:1077 
io_uring/io_uring.c:1091)
task_work_run (kernel/task_work.c:180 (discriminator 1))
io_run_task_work_sig (io_uring/io_uring.h:250 io_uring/io_uring.h:239 
io_uring/io_uring.h:272 io_uring/io_uring.c:2351)
__do_sys_io_uring_enter (io_uring/io_uring.c:2367 
io_uring/io_uring.c:2449 io_uring/io_uring.c:3267)
__do_fast_syscall_32 (arch/x86/entry/common.c:112 
arch/x86/entry/common.c:178)
do_fast_syscall_32 (arch/x86/entry/common.c:203)
entry_SYSENTER_compat_after_hwframe (arch/x86/entry/entry_64_compat.S:122)
RIP: 0023:0xf7f6d549
Code: 03 74 c0 01 10 05 03 74 b8 01 10 06 03 74 b4 01 10 07 03 74 b0 01 
10 08 03 74 d8 01 00 00 00 00 00 51 52 55 89 e5 0f 34 cd 80 <5d> 5a 59 
c3 cc 90 90 90 8d b4 26 00 00 00 00 8d b4 26 00 00 00 00
All code
========
    0:   03 74 c0 01             add    0x1(%rax,%rax,8),%esi
    4:   10 05 03 74 b8 01       adc    %al,0x1b87403(%rip)        # 
0x1b8740d
    a:   10 06                   adc    %al,(%rsi)
    c:   03 74 b4 01             add    0x1(%rsp,%rsi,4),%esi
   10:   10 07                   adc    %al,(%rdi)
   12:   03 74 b0 01             add    0x1(%rax,%rsi,4),%esi
   16:   10 08                   adc    %cl,(%rax)
   18:   03 74 d8 01             add    0x1(%rax,%rbx,8),%esi
   1c:   00 00                   add    %al,(%rax)
   1e:   00 00                   add    %al,(%rax)
   20:   00 51 52                add    %dl,0x52(%rcx)
   23:   55                      push   %rbp
   24:   89 e5                   mov    %esp,%ebp
   26:   0f 34                   sysenter
   28:   cd 80                   int    $0x80
   2a:*  5d                      pop    %rbp             <-- trapping 
instruction
   2b:   5a                      pop    %rdx
   2c:   59                      pop    %rcx
   2d:   c3                      ret
   2e:   cc                      int3
   2f:   90                      nop
   30:   90                      nop
   31:   90                      nop
   32:   8d b4 26 00 00 00 00    lea    0x0(%rsi,%riz,1),%esi
   39:   8d b4 26 00 00 00 00    lea    0x0(%rsi,%riz,1),%esi

Code starting with the faulting instruction
===========================================
    0:   5d                      pop    %rbp
    1:   5a                      pop    %rdx
    2:   59                      pop    %rcx
    3:   c3                      ret
    4:   cc                      int3
    5:   90                      nop
    6:   90                      nop
    7:   90                      nop
    8:   8d b4 26 00 00 00 00    lea    0x0(%rsi,%riz,1),%esi
    f:   8d b4 26 00 00 00 00    lea    0x0(%rsi,%riz,1),%esi
RSP: 002b:00000000f7bff10c EFLAGS: 00000206 ORIG_RAX: 00000000000001aa
RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 0000000000000000
RDX: 0000000000000001 RSI: 0000000000000001 RDI: 0000000000000000
RBP: 0000000000000008 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000206 R12: 0000000000000000
R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
</TASK>

Allocated by task 733:
kasan_save_stack (mm/kasan/common.c:46)
kasan_set_track (mm/kasan/common.c:52)
__kasan_slab_alloc (mm/kasan/common.c:325)
kmem_cache_alloc (mm/slab.h:737 mm/slub.c:3398 mm/slub.c:3406 
mm/slub.c:3413 mm/slub.c:3422)
sk_prot_alloc (net/core/sock.c:2024)
sk_alloc (net/core/sock.c:2083)
inet_create (net/ipv4/af_inet.c:319 net/ipv4/af_inet.c:245)
__sock_create (net/socket.c:1516)
__sys_socket (net/socket.c:1605 net/socket.c:1588 net/socket.c:1636)
__ia32_compat_sys_socketcall (net/compat.c:447 net/compat.c:421 
net/compat.c:421)
__do_fast_syscall_32 (arch/x86/entry/common.c:112 
arch/x86/entry/common.c:178)
do_fast_syscall_32 (arch/x86/entry/common.c:203)
entry_SYSENTER_compat_after_hwframe (arch/x86/entry/entry_64_compat.S:122)

The buggy address belongs to the object at ffff8881049ff300
which belongs to the cache UDP of size 1152
The buggy address is located 40 bytes inside of
1152-byte region [ffff8881049ff300, ffff8881049ff780)

The buggy address belongs to the physical page:
page:000000005bc2cfe2 refcount:1 mapcount:0 mapping:0000000000000000 
index:0xffff8881049fe400 pfn:0x1049f8
head:000000005bc2cfe2 order:3 compound_mapcount:0 compound_pincount:0
memcg:ffff888107526401
flags: 0x17ffffc0010200(slab|head|node=0|zone=2|lastcpupid=0x1fffff)
raw: 0017ffffc0010200 0000000000000000 dead000000000122 ffff8881018cc140
raw: ffff8881049fe400 0000000080190018 00000001ffffffff ffff888107526401
page dumped because: kasan: bad access detected

Memory state around the buggy address:
ffff8881049ff200: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
ffff8881049ff280: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
 >ffff8881049ff300: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
^
ffff8881049ff380: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ffff8881049ff400: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=========================================================

-- 
js
suse labs


  reply	other threads:[~2022-12-19 12:33 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-26 13:35 [PATCH for-next 1/1] io_uring/net: fix cleanup double free free_iov init Pavel Begunkov
2022-09-26 14:37 ` Jens Axboe
2022-12-19 10:23 ` User-triggerable 6.1 crash [was: io_uring/net: fix cleanup double free free_iov init] Jiri Slaby
2022-12-19 12:32   ` Jiri Slaby [this message]
2022-12-19 13:42     ` Pavel Begunkov
2022-12-19 13:41   ` Jens Axboe

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox