netdev - Panic in udp4_lib

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <eda8bfc80307abce79df504648c60eae@codeaurora.org>
Date:   Wed, 12 May 2021 23:51:30 +0530
From:   kapandey@...eaurora.org
To:     willemb@...gle.com, pabeni@...hat.com, netdev@...r.kernel.org,
        eric.dumazet@...il.com, sharathv@...eaurora.org,
        subashab@...eaurora.org
Subject: Panic in udp4_lib_lookup2

Hi All,

We observed panic in udp_lib_lookup with below call trace:
[136523.743271]  (7) Call trace:
[136523.743275]  (7)  udp4_lib_lookup2+0x88/0x1d8
[136523.743277]  (7)  __udp4_lib_lookup+0x168/0x194
[136523.743280]  (7)  udp4_lib_lookup+0x28/0x54
[136523.743285]  (7)  nf_sk_lookup_slow_v4+0x2b4/0x384
[136523.743289]  (7)  owner_mt+0xb8/0x248
[136523.743292]  (7)  ipt_do_table+0x28c/0x6a8
[136523.743295]  (7) iptable_filter_hook+0x24/0x30
[136523.743299]  (7)  nf_hook_slow+0xa8/0x148
[136523.743303]  (7)  ip_local_deliver+0xa8/0x14c
[136523.743305]  (7)  ip_rcv+0xe0/0x134


We suspect this might happen due to below sequence:
Time                                                   CPU X             
                                                                          
                                    CPU Y
t0                                inet_release -> udp_lib_close -> 
sk_common_release -> udp_lib_unhash                            
inet_diag_handler_cmd -> udp_diag_destroy -> __udp_diag_destroy -> 
udp_lib_rehash

t1                                if(sk hashed)                          
                                                                          
                         if(sk hashed)
                                          sk_del_node_init_rcu
                                          
hlist_del_init_rcu(udp_portaddr_node)

t2                                                                       
                                                                          
                                        if(hslot2 != nhslot2)
                                                                          
                                                                          
                                                   
hlist_del_init_rcu(udp_portaddr_node)
                                                                          
                                                                          
                                                   
hlist_add_head_rcu(udp_portaddr_node)

t3                                sk is freed here

After t3 any use of that added udp_portaddr_node  will cause panic.
Same happens in udp4_lib_lookup2/udp6_lib_lookup2.

We dont have any reproducer for this, getting hit during random testing.

Pls let us know how this be resolved.

Thanks,
KP