linux-kernel - Re: lockup and kernel panic in linux-next-202505{09,12} when compiled with clang

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-prev] [day] [month] [year] [list]
Message-ID: <f109986d1c25c794f7f6a470722f1ea878d10b33.camel@web.de>
Date: Sun, 18 May 2025 16:41:48 +0200
From: Bert Karwatzki <spasswolf@....de>
To: Jason Xing <kerneljasonxing@...il.com>
Cc: Johannes Berg <johannes@...solutions.net>,
 "linux-kernel@...r.kernel.org"	 <linux-kernel@...r.kernel.org>,
 "linux-next@...r.kernel.org"	 <linux-next@...r.kernel.org>,
 "llvm@...ts.linux.dev" <llvm@...ts.linux.dev>,  Thomas Gleixner
 <tglx@...utronix.de>, linux-wireless@...r.kernel.org, spasswolf@....de
Subject: Re: lockup and kernel panic in linux-next-202505{09,12} when
 compiled with clang

Am Sonntag, dem 18.05.2025 um 16:15 +0200 schrieb Bert Karwatzki:
> Am Sonntag, dem 18.05.2025 um 14:43 +0200 schrieb Bert Karwatzki:
> > Am Sonntag, dem 18.05.2025 um 14:12 +0200 schrieb Bert Karwatzki:
> > > > > > 
> > > 
> > > I even tried this version of your patch, to keep the offset of skc_refcnt at 128,
> > > but it doesn't  work, either.
> > > 
> > > commit fca84c5cde713be480544a64ed6680afc3319670
> > > Author: Bert Karwatzki <spasswolf@....de>
> > > Date:   Sun May 18 13:32:36 2025 +0200
> > > 
> > >     include: net: sock: move skc_flags out of the union
> > >     
> > >     Signed-off-by: Bert Karwatzki <spasswolf@....de>
> > > 
> > > diff --git a/include/net/sock.h b/include/net/sock.h
> > > index 3e15d7105ad2..e73929a4da6e 100644
> > > --- a/include/net/sock.h
> > > +++ b/include/net/sock.h
> > > @@ -195,7 +195,6 @@ struct sock_common {
> > >  	 * for different kind of 'sockets'
> > >  	 */
> > >  	union {
> > > -		unsigned long	skc_flags;
> > >  		struct sock	*skc_listener; /* request_sock */
> > >  		struct inet_timewait_death_row *skc_tw_dr; /* inet_timewait_sock */
> > >  	};
> > > @@ -221,6 +220,9 @@ struct sock_common {
> > >  	};
> > >  
> > >  	refcount_t		skc_refcnt;
> > > +
> > > +	/* place skc_flags here to keep offset(struct sock, sk_refcnt) == 128 */
> > > +	unsigned long	skc_flags;
> > >  	/* private: */
> > >  	int                     skc_dontcopy_end[0];
> > >  	union {
> > > 
> > 
> > In the patch above I accidently put skc_flags in the part of struct sock_common
> > which does not get copied, but putting it below skc_dontcopy_end[0] does not work,
> > either:
> > 
> > diff --git a/include/net/sock.h b/include/net/sock.h
> > index 3e15d7105ad2..6d69753a205a 100644
> > --- a/include/net/sock.h
> > +++ b/include/net/sock.h
> > @@ -195,7 +195,6 @@ struct sock_common {
> >          * for different kind of 'sockets'
> >          */
> >         union {
> > -               unsigned long   skc_flags;
> >                 struct sock     *skc_listener; /* request_sock */
> >                 struct inet_timewait_death_row *skc_tw_dr; /* inet_timewait_sock */
> >         };
> > @@ -221,8 +220,12 @@ struct sock_common {
> >         };
> >  
> >         refcount_t              skc_refcnt;
> > +
> >         /* private: */
> >         int                     skc_dontcopy_end[0];
> > +       /* place skc_flags here to keep offset(struct sock, sk_refcnt) == 128 
> > +        * Also place it below skc_dontcopy_end[0] */
> > +       unsigned long   skc_flags;
> >         union {
> >                 u32             skc_rxhash;
> >                 u32             skc_window_clamp;
> > 
> > This locks up as usual.
> > 
> > Bert Karwatzki
> 
> So I did some more monitoring and found that even though skc_flags is removed from the union
> it can take strange values, e.g.:
> 
> Here the value is not even a pointer (perhaps unitialized memory?):
> [  T572] ieee80211_8023_xmit_clang_debug_helper: skb->sk = ffff88fc2abf4cc0 skb->sk->sk_flags = 0xa00f7fe57b16f7e1
> These could be pointers, but as pointers would only be aligned to a 2-byte boundary ...
> [  T572] ieee80211_8023_xmit_clang_debug_helper: skb->sk = ffff88fbd0bd3210 skb->sk->sk_flags = 0xffffc0f1c62dcc4e
> [  T572] ieee80211_8023_xmit_clang_debug_helper: skb->sk = ffff88fbd0bd3210 skb->sk->sk_flags = 0xffffc0f1c62dcc4e
> 
> Bert Karwatzki

I tried to set sk_flags to 0 in sk_prot_alloc() like this:

commit 269f21266477e74321e32e0b022dda8e98785589 (HEAD -> clang_panic)
Author: Bert Karwatzki <spasswolf@....de>
Date:   Sun May 18 16:28:39 2025 +0200

    net: core: sock: set initial sk_flags to 0 in sk_prot_alloc()
    
    Signed-off-by: Bert Karwatzki <spasswolf@....de>

diff --git a/net/core/sock.c b/net/core/sock.c
index f6589ad5ba36..acaa39ad18be 100644
--- a/net/core/sock.c
+++ b/net/core/sock.c
@@ -2216,6 +2216,7 @@ static struct sock *sk_prot_alloc(struct proto *prot, gfp_t priority,
                        goto out_free_sec;
        }
 
+       sk->sk_flags = 0;
        return sk;
 
 out_free_sec:

But that didn't work:
[   13.832282] [    T579] ieee80211_8023_xmit_clang_debug_helper: skb->sk = ffff8962805faee0 skb->sk->sk_flags = 0x4472000044f00000
[...]
[  124.165094] [    T579] ieee80211_8023_xmit_clang_debug_helper: skb->sk = ffff896280760550 skb->sk->sk_flags = 0x726f2e65746f7571
[...]
[  185.138202] [    T579] ieee80211_8023_xmit_clang_debug_helper: skb->sk = ffff8960c78b7a90 skb->sk->sk_flags = 0x8000000000000025
[...]
[  290.623998] [    T579] ieee80211_8023_xmit_clang_debug_helper: skb->sk = ffff8961936b7870 skb->sk->sk_flags = 0xffff8961936b78f0

Bert Karwatzki