linux-kernel - [Bug] soft lockup in ieee80211_handle_queued

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: <CAP=Rh=PV2nqPkBV8rALZRHLO4n58XwKTYRGYkS5snNc0Zo0YuQ@mail.gmail.com>
Date: Thu, 22 May 2025 00:32:23 +0800
From: John <john.cs.hey@...il.com>
To: Johannes Berg <johannes@...solutions.net>
Cc: linux-wireless@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: [Bug] soft lockup in ieee80211_handle_queued_frames in Linux kernel v6.15-rc5

Dear Linux Kernel Maintainers,

I hope this message finds you well.

I am writing to report a potential vulnerability I encountered during
testing of the Linux Kernel version v6.15-rc5.

Git Commit: 92a09c47464d040866cf2b4cd052bc60555185fb (tag: v6.15-rc5)

Bug Location: ieee80211_handle_queued_frames+0xd9/0x130 net/mac80211/main.c

Bug report: https://hastebin.com/share/itequxofas.yaml

Complete log: https://hastebin.com/share/opasimohab.perl

Entire kernel config:  https://hastebin.com/share/padecilimo.ini

Root Cause Analysis:
This entire chain is triggered indirectly by
cfg80211_update_known_bss() from the wireless networking stack, as it
tries to update BSS (Basic Service Set) entries for scanned wireless
networks.
This function uses kvfree_rcu() to deallocate stale BSS data, which in
turn invokes kasan_record_aux_stack() and then stack_trace_save() for
KASAN quarantine bookkeeping. That leads to complex locking and
backtrace operations, especially involving lockdep.
The deeper root causes include:
Lockdep recursion while handling RCU-related memory free paths
(kvfree_rcu) in cfg80211_update_known_bss().
Excessive softirq processing time in tasklet_action_common() and
handle_softirqs() due to high BSS update rate or malformed wireless
frame processing in a fuzzing context.
Potential deadlock or pathological behavior in lock_acquire() due to
corrupted lock dependency chains or misused locks in the wireless
networking stack.
This loop fails to yield CPU time or reschedule, triggering the
watchdog soft lockup detector.

At present, I have not yet obtained a minimal reproducer for this
issue. However, I am actively working on reproducing it, and I will
promptly share any additional findings or a working reproducer as soon
as it becomes available.

Thank you very much for your time and attention to this matter. I
truly appreciate the efforts of the Linux kernel community.

Best regards,
John