[BUG] ath9k_htc_tx_cleanup_timer -- ODEBUG free-active-timer and use-after-free on USB unplug

[BUG] ath9k_htc_tx_cleanup_timer -- ODEBUG free-active-timer and use-after-free on USB unplug

[Farhad Alemi]

Hello,

As part of the kernel research at ASU's SEFCOM
lab, we hit the crash below. Crash reports can be found here:

  https://github.com/farhad-alemi/public_bug_reports/tree/main/137-ath9k_htc-timer-outlives-wiphy/

  usb 1-1: USB disconnect, device number 5
  ODEBUG: free active (active state 0) object: ffff88811ead3940 object
type: timer_list hint: ath9k_htc_tx_cleanup_timer+0x0/0x4d0
  WARNING: lib/debugobjects.c:632 at debug_print_object+0xec/0x230,
CPU#0: kworker/0:3/2242
  Workqueue: usb_hub_wq hub_event
  Call Trace:
   debug_check_no_obj_freed+0x3a2/0x470
   __free_frozen_pages+0x5d1/0xd90
   device_release+0xc4/0x1f0
   kobject_put+0x228/0x560
   ath9k_hif_usb_disconnect+0x135/0x240
   usb_unbind_interface+0x26e/0x910
   device_release_driver_internal+0x4d9/0x870
   bus_remove_device+0x455/0x570
   device_del+0x527/0x8f0

  BUG: KASAN: slab-use-after-free in _raw_spin_lock+0x2e/0x40
  Read of size 1 at addr ffff888105d701c0 by task kworker/0:3/2242
  Call Trace:
   <IRQ>
   lock_acquire+0x84/0x350
   _raw_spin_lock+0x2e/0x40
   ath9k_htc_tx_cleanup_timer+0x57/0x4d0
   call_timer_fn+0x18d/0x5f0
   __run_timer_base+0x652/0x8b0
   run_timer_softirq+0xb7/0x170
   handle_softirqs+0x22c/0x860
   </IRQ>

Our reproducer.c is available upon request.

Happy to test a patch if that would help.

Regards,

Re: [BUG] ath9k_htc_tx_cleanup_timer -- ODEBUG free-active-timer and use-after-free on USB unplug

[Chad Aldreda]

Hi Farhad,

Could you share the reproducer for this one?

Two paths in the code would fit the report. Both end the same way:
the timer re-arms itself (ath9k_htc_tx_cleanup_timer()), and nothing
deletes it before ath9k_htc_disconnect_device() frees the hw.

1. ath9k_fatal_work() calls ath9k_htc_reset(), which re-arms
   tx.cleanup_timer without checking ATH_OP_INVALID. A WMI_FATAL_EVENTID
   (or beacon-stuck SWBA) that arrives after ath9k_htc_stop() has
   finished still queues fatal_work, since WMI events are processed
   until ath9k_stop_wmi(). The timer is then armed on a stopped device,
   and ieee80211_unregister_hw() does not call stop again.

2. Inside ath9k_htc_stop(), the timer is deleted and priv->mutex is
   dropped before cancel_work_sync(&priv->fatal_work). A fatal_work
   already waiting on the mutex runs the reset in that gap and re-arms
   the timer.

I'd like to know which one your reproducer hits before proposing a
fix. Does it send WMI_FATAL_EVENTID (or let beacons go stuck in
AP/IBSS/mesh mode), and is the interface up or down when it does?

The code reading above was done with an AI assistant (Claude). Nothing
has been tested yet.

Thanks,
Chad