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] [thread-next>] [day] [month] [year] [list]

Message-ID: <2d8c1929bf5ab5260dacf9aa390456b3b49ce465.camel@sipsolutions.net>
Date: Wed, 14 May 2025 12:23:38 +0200
From: Johannes Berg <johannes@...solutions.net>
To: Bert Karwatzki <spasswolf@....de>, "linux-kernel@...r.kernel.org"
	 <linux-kernel@...r.kernel.org>
Cc: "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
Subject: Re: lockup and kernel panic in linux-next-202505{09,12} when
 compiled with clang

+ linux-wireless

On Wed, 2025-05-14 at 09:32 +0000, Bert Karwatzki wrote:

> Then I reapplied commit 76a853f86c97 hunk by hunk and found the one hunk that
> causes the problem:
> 
> diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
> index 3e751dd3ae7b..63df21228029 100644
> --- a/net/mac80211/tx.c
> +++ b/net/mac80211/tx.c
> @@ -4648,8 +4648,7 @@ static void ieee80211_8023_xmit(struct
> ieee80211_sub_if_data *sdata,
>                         memcpy(IEEE80211_SKB_CB(seg), info, sizeof(*info));
>         }
> 
> -       if (unlikely(skb->sk &&
> -                    skb_shinfo(skb)->tx_flags & SKBTX_WIFI_STATUS)) {
> +       if (unlikely(skb->sk && sock_flag(skb->sk, SOCK_WIFI_STATUS))) {
>                 info->status_data = ieee80211_store_ack_skb(local, skb,
>                                                             &info->flags, NULL);
>                 if (info->status_data)

I think it crashed later on the status, but this inserts the skb into
the IDR so the status can pick it up to return the status and afaict
_that's_ where it crashed.

Still I don't really know what could go wrong? The (copied) skb should
still have been keeping the socket alive.

> This is enough to cause a kernel panic when compiled with clang (clang-19.1.7
> from debian sid). Compiling the same kernel with gcc (gcc-14.2.0 from debian
> sid) shows no problem.

Right, even stranger. But I can't even say you should look at this place
(which inserts) or the other (which takes it out again and crashed) to
compare the code :-/


johannes