Re: User-triggerable 6.1 crash [was: io_uring/net: fix cleanup double free free_iov init]

[Pavel Begunkov <asml.silence@gmail.com>]

On 12/19/22 12:32, Jiri Slaby wrote:
> 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

Thanks for letting us know, I'll take a look


-- 
Pavel Begunkov