1. 05 Feb, 2021 3 commits
    • Xie He's avatar
      net: hdlc_x25: Return meaningful error code in x25_open · 81b8be68
      Xie He authored
      It's not meaningful to pass on LAPB error codes to HDLC code or other
      parts of the system, because they will not understand the error codes.
      
      Instead, use system-wide recognizable error codes.
      
      Fixes: f362e5fe ("wan/hdlc_x25: make lapb params configurable")
      Fixes: 1da177e4 ("Linux-2.6.12-rc2")
      Signed-off-by: default avatarXie He <xie.he.0141@gmail.com>
      Acked-by: default avatarMartin Schiller <ms@dev.tdt.de>
      Link: https://lore.kernel.org/r/20210203071541.86138-1-xie.he.0141@gmail.comSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      81b8be68
    • 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 4 commits