Skip to content
Snippets Groups Projects
  1. Nov 12, 2024
  2. Nov 11, 2024
    • Wang Liang's avatar
      net: fix data-races around sk->sk_forward_alloc · 073d8980
      Wang Liang authored
      
      Syzkaller reported this warning:
       ------------[ cut here ]------------
       WARNING: CPU: 0 PID: 16 at net/ipv4/af_inet.c:156 inet_sock_destruct+0x1c5/0x1e0
       Modules linked in:
       CPU: 0 UID: 0 PID: 16 Comm: ksoftirqd/0 Not tainted 6.12.0-rc5 #26
       Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
       RIP: 0010:inet_sock_destruct+0x1c5/0x1e0
       Code: 24 12 4c 89 e2 5b 48 c7 c7 98 ec bb 82 41 5c e9 d1 18 17 ff 4c 89 e6 5b 48 c7 c7 d0 ec bb 82 41 5c e9 bf 18 17 ff 0f 0b eb 83 <0f> 0b eb 97 0f 0b eb 87 0f 0b e9 68 ff ff ff 66 66 2e 0f 1f 84 00
       RSP: 0018:ffffc9000008bd90 EFLAGS: 00010206
       RAX: 0000000000000300 RBX: ffff88810b172a90 RCX: 0000000000000007
       RDX: 0000000000000002 RSI: 0000000000000300 RDI: ffff88810b172a00
       RBP: ffff88810b172a00 R08: ffff888104273c00 R09: 0000000000100007
       R10: 0000000000020000 R11: 0000000000000006 R12: ffff88810b172a00
       R13: 0000000000000004 R14: 0000000000000000 R15: ffff888237c31f78
       FS:  0000000000000000(0000) GS:ffff888237c00000(0000) knlGS:0000000000000000
       CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
       CR2: 00007ffc63fecac8 CR3: 000000000342e000 CR4: 00000000000006f0
       DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
       DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
       Call Trace:
        <TASK>
        ? __warn+0x88/0x130
        ? inet_sock_destruct+0x1c5/0x1e0
        ? report_bug+0x18e/0x1a0
        ? handle_bug+0x53/0x90
        ? exc_invalid_op+0x18/0x70
        ? asm_exc_invalid_op+0x1a/0x20
        ? inet_sock_destruct+0x1c5/0x1e0
        __sk_destruct+0x2a/0x200
        rcu_do_batch+0x1aa/0x530
        ? rcu_do_batch+0x13b/0x530
        rcu_core+0x159/0x2f0
        handle_softirqs+0xd3/0x2b0
        ? __pfx_smpboot_thread_fn+0x10/0x10
        run_ksoftirqd+0x25/0x30
        smpboot_thread_fn+0xdd/0x1d0
        kthread+0xd3/0x100
        ? __pfx_kthread+0x10/0x10
        ret_from_fork+0x34/0x50
        ? __pfx_kthread+0x10/0x10
        ret_from_fork_asm+0x1a/0x30
        </TASK>
       ---[ end trace 0000000000000000 ]---
      
      Its possible that two threads call tcp_v6_do_rcv()/sk_forward_alloc_add()
      concurrently when sk->sk_state == TCP_LISTEN with sk->sk_lock unlocked,
      which triggers a data-race around sk->sk_forward_alloc:
      tcp_v6_rcv
          tcp_v6_do_rcv
              skb_clone_and_charge_r
                  sk_rmem_schedule
                      __sk_mem_schedule
                          sk_forward_alloc_add()
                  skb_set_owner_r
                      sk_mem_charge
                          sk_forward_alloc_add()
              __kfree_skb
                  skb_release_all
                      skb_release_head_state
                          sock_rfree
                              sk_mem_uncharge
                                  sk_forward_alloc_add()
                                  sk_mem_reclaim
                                      // set local var reclaimable
                                      __sk_mem_reclaim
                                          sk_forward_alloc_add()
      
      In this syzkaller testcase, two threads call
      tcp_v6_do_rcv() with skb->truesize=768, the sk_forward_alloc changes like
      this:
       (cpu 1)             | (cpu 2)             | sk_forward_alloc
       ...                 | ...                 | 0
       __sk_mem_schedule() |                     | +4096 = 4096
                           | __sk_mem_schedule() | +4096 = 8192
       sk_mem_charge()     |                     | -768  = 7424
                           | sk_mem_charge()     | -768  = 6656
       ...                 |    ...              |
       sk_mem_uncharge()   |                     | +768  = 7424
       reclaimable=7424    |                     |
                           | sk_mem_uncharge()   | +768  = 8192
                           | reclaimable=8192    |
       __sk_mem_reclaim()  |                     | -4096 = 4096
                           | __sk_mem_reclaim()  | -8192 = -4096 != 0
      
      The skb_clone_and_charge_r() should not be called in tcp_v6_do_rcv() when
      sk->sk_state is TCP_LISTEN, it happens later in tcp_v6_syn_recv_sock().
      Fix the same issue in dccp_v6_do_rcv().
      
      Suggested-by: default avatarEric Dumazet <edumazet@google.com>
      Reviewed-by: default avatarEric Dumazet <edumazet@google.com>
      Fixes: e994b2f0 ("tcp: do not lock listener to process SYN packets")
      Signed-off-by: default avatarWang Liang <wangliang74@huawei.com>
      Link: https://patch.msgid.link/20241107023405.889239-1-wangliang74@huawei.com
      
      
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      073d8980
  3. Nov 10, 2024
  4. Nov 09, 2024
    • Stefan Wahren's avatar
      net: vertexcom: mse102x: Fix tx_bytes calculation · e68da664
      Stefan Wahren authored
      
      The tx_bytes should consider the actual size of the Ethernet frames
      without the SPI encapsulation. But we still need to take care of
      Ethernet padding.
      
      Fixes: 2f207cbf ("net: vertexcom: Add MSE102x SPI support")
      Signed-off-by: default avatarStefan Wahren <wahrenst@gmx.net>
      Link: https://patch.msgid.link/20241108114343.6174-3-wahrenst@gmx.net
      
      
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      e68da664
    • Eric Dumazet's avatar
      sctp: fix possible UAF in sctp_v6_available() · eb72e7fc
      Eric Dumazet authored
      
      A lockdep report [1] with CONFIG_PROVE_RCU_LIST=y hints
      that sctp_v6_available() is calling dev_get_by_index_rcu()
      and ipv6_chk_addr() without holding rcu.
      
      [1]
       =============================
       WARNING: suspicious RCU usage
       6.12.0-rc5-virtme #1216 Tainted: G        W
       -----------------------------
       net/core/dev.c:876 RCU-list traversed in non-reader section!!
      
      other info that might help us debug this:
      
      rcu_scheduler_active = 2, debug_locks = 1
       1 lock held by sctp_hello/31495:
       #0: ffff9f1ebbdb7418 (sk_lock-AF_INET6){+.+.}-{0:0}, at: sctp_bind (./arch/x86/include/asm/jump_label.h:27 net/sctp/socket.c:315) sctp
      
      stack backtrace:
       CPU: 7 UID: 0 PID: 31495 Comm: sctp_hello Tainted: G        W          6.12.0-rc5-virtme #1216
       Tainted: [W]=WARN
       Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
       Call Trace:
        <TASK>
       dump_stack_lvl (lib/dump_stack.c:123)
       lockdep_rcu_suspicious (kernel/locking/lockdep.c:6822)
       dev_get_by_index_rcu (net/core/dev.c:876 (discriminator 7))
       sctp_v6_available (net/sctp/ipv6.c:701) sctp
       sctp_do_bind (net/sctp/socket.c:400 (discriminator 1)) sctp
       sctp_bind (net/sctp/socket.c:320) sctp
       inet6_bind_sk (net/ipv6/af_inet6.c:465)
       ? security_socket_bind (security/security.c:4581 (discriminator 1))
       __sys_bind (net/socket.c:1848 net/socket.c:1869)
       ? do_user_addr_fault (./include/linux/rcupdate.h:347 ./include/linux/rcupdate.h:880 ./include/linux/mm.h:729 arch/x86/mm/fault.c:1340)
       ? do_user_addr_fault (./arch/x86/include/asm/preempt.h:84 (discriminator 13) ./include/linux/rcupdate.h:98 (discriminator 13) ./include/linux/rcupdate.h:882 (discriminator 13) ./include/linux/mm.h:729 (discriminator 13) arch/x86/mm/fault.c:1340 (discriminator 13))
       __x64_sys_bind (net/socket.c:1877 (discriminator 1) net/socket.c:1875 (discriminator 1) net/socket.c:1875 (discriminator 1))
       do_syscall_64 (arch/x86/entry/common.c:52 (discriminator 1) arch/x86/entry/common.c:83 (discriminator 1))
       entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)
       RIP: 0033:0x7f59b934a1e7
       Code: 44 00 00 48 8b 15 39 8c 0c 00 f7 d8 64 89 02 b8 ff ff ff ff eb bd 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 b8 31 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 09 8c 0c 00 f7 d8 64 89 01 48
      All code
      ========
         0:	44 00 00             	add    %r8b,(%rax)
         3:	48 8b 15 39 8c 0c 00 	mov    0xc8c39(%rip),%rdx        # 0xc8c43
         a:	f7 d8                	neg    %eax
         c:	64 89 02             	mov    %eax,%fs:(%rdx)
         f:	b8 ff ff ff ff       	mov    $0xffffffff,%eax
        14:	eb bd                	jmp    0xffffffffffffffd3
        16:	66 2e 0f 1f 84 00 00 	cs nopw 0x0(%rax,%rax,1)
        1d:	00 00 00
        20:	0f 1f 00             	nopl   (%rax)
        23:	b8 31 00 00 00       	mov    $0x31,%eax
        28:	0f 05                	syscall
        2a:*	48 3d 01 f0 ff ff    	cmp    $0xfffffffffffff001,%rax		<-- trapping instruction
        30:	73 01                	jae    0x33
        32:	c3                   	ret
        33:	48 8b 0d 09 8c 0c 00 	mov    0xc8c09(%rip),%rcx        # 0xc8c43
        3a:	f7 d8                	neg    %eax
        3c:	64 89 01             	mov    %eax,%fs:(%rcx)
        3f:	48                   	rex.W
      
      Code starting with the faulting instruction
      ===========================================
         0:	48 3d 01 f0 ff ff    	cmp    $0xfffffffffffff001,%rax
         6:	73 01                	jae    0x9
         8:	c3                   	ret
         9:	48 8b 0d 09 8c 0c 00 	mov    0xc8c09(%rip),%rcx        # 0xc8c19
        10:	f7 d8                	neg    %eax
        12:	64 89 01             	mov    %eax,%fs:(%rcx)
        15:	48                   	rex.W
       RSP: 002b:00007ffe2d0ad398 EFLAGS: 00000202 ORIG_RAX: 0000000000000031
       RAX: ffffffffffffffda RBX: 00007ffe2d0ad3d0 RCX: 00007f59b934a1e7
       RDX: 000000000000001c RSI: 00007ffe2d0ad3d0 RDI: 0000000000000005
       RBP: 0000000000000005 R08: 1999999999999999 R09: 0000000000000000
       R10: 00007f59b9253298 R11: 0000000000000202 R12: 00007ffe2d0ada61
       R13: 0000000000000000 R14: 0000562926516dd8 R15: 00007f59b9479000
        </TASK>
      
      Fixes: 6fe1e524 ("sctp: check ipv6 addr with sk_bound_dev if set")
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Cc: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
      Acked-by: default avatarXin Long <lucien.xin@gmail.com>
      Link: https://patch.msgid.link/20241107192021.2579789-1-edumazet@google.com
      
      
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      eb72e7fc
  5. Nov 07, 2024
  6. Nov 06, 2024
  7. Nov 05, 2024
Loading