1. 05 Feb, 2021 2 commits
    • David Howells's avatar
      rxrpc: Fix clearance of Tx/Rx ring when releasing a call · 7b5eab57
      David Howells authored
      At the end of rxrpc_release_call(), rxrpc_cleanup_ring() is called to clear
      the Rx/Tx skbuff ring, but this doesn't lock the ring whilst it's accessing
      it.  Unfortunately, rxrpc_resend() might be trying to retransmit a packet
      concurrently with this - and whilst it does lock the ring, this isn't
      protection against rxrpc_cleanup_call().
      
      Fix this by removing the call to rxrpc_cleanup_ring() from
      rxrpc_release_call().  rxrpc_cleanup_ring() will be called again anyway
      from rxrpc_cleanup_call().  The earlier call is just an optimisation to
      recycle skbuffs more quickly.
      
      Alternative solutions include rxrpc_release_call() could try to cancel the
      work item or wait for it to complete or rxrpc_cleanup_ring() could lock
      when accessing the ring (which would require a bh lock).
      
      This can produce a report like the following:
      
        BUG: KASAN: use-after-free in rxrpc_send_data_packet+0x19b4/0x1e70 net/rxrpc/output.c:372
        Read of size 4 at addr ffff888011606e04 by task kworker/0:0/5
        ...
        Workqueue: krxrpcd rxrpc_process_call
        Call Trace:
         ...
         kasan_report.cold+0x79/0xd5 mm/kasan/report.c:413
         rxrpc_send_data_packet+0x19b4/0x1e70 net/rxrpc/output.c:372
         rxrpc_resend net/rxrpc/call_event.c:266 [inline]
         rxrpc_process_call+0x1634/0x1f60 net/rxrpc/call_event.c:412
         process_one_work+0x98d/0x15f0 kernel/workqueue.c:2275
         ...
      
        Allocated by task 2318:
         ...
         sock_alloc_send_pskb+0x793/0x920 net/core/sock.c:2348
         rxrpc_send_data+0xb51/0x2bf0 net/rxrpc/sendmsg.c:358
         rxrpc_do_sendmsg+0xc03/0x1350 net/rxrpc/sendmsg.c:744
         rxrpc_sendmsg+0x420/0x630 net/rxrpc/af_rxrpc.c:560
         ...
      
        Freed by task 2318:
         ...
         kfree_skb+0x140/0x3f0 net/core/skbuff.c:704
         rxrpc_free_skb+0x11d/0x150 net/rxrpc/skbuff.c:78
         rxrpc_cleanup_ring net/rxrpc/call_object.c:485 [inline]
         rxrpc_release_call+0x5dd/0x860 net/rxrpc/call_object.c:552
         rxrpc_release_calls_on_socket+0x21c/0x300 net/rxrpc/call_object.c:579
         rxrpc_release_sock net/rxrpc/af_rxrpc.c:885 [inline]
         rxrpc_release+0x263/0x5a0 net/rxrpc/af_rxrpc.c:916
         __sock_release+0xcd/0x280 net/socket.c:597
         ...
      
        The buggy address belongs to the object at ffff888011606dc0
         which belongs to the cache skbuff_head_cache of size 232
      
      Fixes: 248f219c ("rxrpc: Rewrite the data and ack handling code")
      Reported-by: syzbot+174de899852504e4a74a@syzkaller.appspotmail.com
      Reported-by: syzbot+3d1c772efafd3c38d007@syzkaller.appspotmail.com
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      cc: Hillf Danton <hdanton@sina.com>
      Link: https://lore.kernel.org/r/161234207610.653119.5287360098400436976.stgit@warthog.procyon.org.ukSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      7b5eab57
    • Raju Rangoju's avatar
  2. 04 Feb, 2021 3 commits
  3. 03 Feb, 2021 1 commit
  4. 02 Feb, 2021 29 commits
  5. 01 Feb, 2021 5 commits