All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jiri Slaby <jirislaby@kernel.org>
To: Pavel Begunkov <asml.silence@gmail.com>, io-uring@vger.kernel.org
Cc: Jens Axboe <axboe@kernel.dk>,
	syzbot+edfd15cd4246a3fc615a@syzkaller.appspotmail.com
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: <032f142f-8439-b2e2-5108-4f41e66e3b0c@kernel.org> (raw)
In-Reply-To: <c80c1e3f-800b-dc49-f2f5-acc8ceb34d51@gmail.com>

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: syzbot+edfd15cd4246a3fc615a@syzkaller.appspotmail.com
>> Fixes: 493108d95f146 ("io_uring/net: zerocopy sendmsg")
>> Signed-off-by: Pavel Begunkov <asml.silence@gmail.com>
> 
> 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 \
    --in-reply-to=032f142f-8439-b2e2-5108-4f41e66e3b0c@kernel.org \
    --to=jirislaby@kernel.org \
    --cc=asml.silence@gmail.com \
    --cc=axboe@kernel.dk \
    --cc=io-uring@vger.kernel.org \
    --cc=syzbot+edfd15cd4246a3fc615a@syzkaller.appspotmail.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.