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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <a0728eea0f9f2718a6c4bc0f12ba129f1ed411b7.camel@redhat.com>
Date:   Thu, 13 May 2021 10:05:37 +0200
From:   Paolo Abeni <pabeni@...hat.com>
To:     kapandey@...eaurora.org, willemb@...gle.com,
        netdev@...r.kernel.org, eric.dumazet@...il.com,
        sharathv@...eaurora.org, subashab@...eaurora.org
Subject: Re: Panic in udp4_lib_lookup2

Hello,

On Wed, 2021-05-12 at 23:51 +0530, kapandey@...eaurora.org wrote:
> 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

It would be helpful if you could provide a full, decoded, stack trace
and the relevant kernel version.

> We suspect this might happen due to below sequence:

Some email formatting made the "graph" very hard to read...

> 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

... but it looks like udp_lib_close() is missing a
lock_sock()/release_sock() pair. Something alike:
---
diff --git a/include/net/udp.h b/include/net/udp.h
index 360df454356c..06586b42db3f 100644
--- a/include/net/udp.h
+++ b/include/net/udp.h
@@ -209,7 +209,9 @@ void udp_lib_rehash(struct sock *sk, u16 new_hash);
 
 static inline void udp_lib_close(struct sock *sk, long timeout)
 {
+	lock_sock(sk);
 	sk_common_release(sk);
+	release_sock(sk);
 }
 
 int udp_lib_get_port(struct sock *sk, unsigned short snum,
---

could u please give the above a spin in your testbed?

Thanks!

Paolo


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ