[Bug 298995] rtw88: Panic on CURRENT when driver is unloaded with active connection

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=298995

            Bug ID: 298995
           Summary: rtw88: Panic on CURRENT when driver is unloaded with
                    active connection
           Product: Base System
           Version: 16.0-CURRENT
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Some People
          Priority: ---
         Component: wireless
          Assignee: wireless@FreeBSD.org
          Reporter: calebharp2005@gmail.com

Created attachment 275264
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=275264&action=edit
Backtraces of the panic occurring in two paths

I recently moved from 15.1-RELEASE to 16.0-CURRENT on my secondary laptop with
an RTL8723DE adapter, using the rtw88 driver. After this change, the driver
appears to cause a panic related to a use-after-free when unloading certain
data structures(I have notably observed this behavior on `kldunload if_rtw88`
and `service netif stop`). I've included backtraces for both reproduction paths
I've found(and would be happy to provide other debug info if that's useful,
since I do have full dumps).

The code here doesn't seem to have changed from STABLE, so I think it has to do
with a more subtle use-after-free scenario that happens to work with release
kernels. The actual panic occurs when trying to call a function pointer
somewhere around `0xdeadc0dedeadc0de`, which, as I understand it, would occur
on debug kernels but not release builds. Specifically, it seems that the VAP
has been freed before the driver can tear down all of its node objects, which
causes a panic when trying to call `vap->iv_rate->ir_node_deinit()`. I'm not
sure if this affects other linuxkpi drivers since I don't have a huge amount of
hardware to test with, but it might.

I'm decently experienced with C, but still quite green in this codebase. I'd be
willing to try my hand at working on this since it seems to be more
memory-related, but I understand if that would be considered unhelpful or if
I've underestimated the scope of the issue.

-- 
You are receiving this mail because:
You are the assignee for the bug.