Bug 207703
| Summary: | kernel BUG at mm/slub.c:306! | ||
|---|---|---|---|
| Product: | Networking | Reporter: | LI AR (sexxxenator) |
| Component: | Wireless | Assignee: | Brian Norris (briannorris) |
| Status: | RESOLVED PATCH_ALREADY_AVAILABLE | ||
| Severity: | high | CC: | briannorris, nadpher |
| Priority: | P1 | ||
| Hardware: | x86-64 | ||
| OS: | Linux | ||
| Kernel Version: | 5.4.0-29-generic #33-Ubuntu SMP | Subsystem: | |
| Regression: | Yes | Bisected commit-id: | |
| Attachments: | Crash due to bug in ath9k | ||
I believe you're hitting a double-free in a kfree_skb() added by this commit, which first appeared in 5.4: commit 728c1e2a05e4b5fc52fab3421dce772a806612a2 Author: Navid Emamdoost <navid.emamdoost@gmail.com> Date: Fri Sep 6 13:59:30 2019 -0500 ath9k: release allocated buffer if timed out It would seem that this patch is buggy and probably should be reverted. IIUC, we've already "submitted" the SKB to another layer at that point, and that layer should be responsible for freeing it (e.g., in hif_usb_regout_cb). I wonder about the author's other patches, which all seem to be the same sort of mechanical (likely-untested) "leak-fixing" patches... It looks like this is already reverted in linux-next: commit ced21a4c726bdc60b1680c050a284b08803bc64c Author: Qiujun Huang <hqjagain@gmail.com> Date: Sat Apr 4 12:18:34 2020 +0800 ath9k: Fix use-after-free Read in htc_connect_service https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next.git/commit/?id=ced21a4c726bdc60b1680c050a284b08803bc64c It's on its way to 5.8: https://lkml.kernel.org/linux-wireless/878shwtiw3.fsf@kamboji.qca.qualcomm.com/T/#t If you have the ability to apply that patch to your own kernel, you might give it a try. Hopefully we can get it queued to -stable eventually. *** Bug 207797 has been marked as a duplicate of this bug. *** For the record, the patch was merged to v5.4.47 (and other newer kernels) |
Created attachment 289093 [details] Crash due to bug in ath9k Hi, I've upgraded my XUbuntu to 20.04. Since then I've encountered several crashes. Apparently, there's a bug in ath9k... See attached kernel trace