CVE-2026-68414

In the Linux kernel, the following vulnerability has been resolved:

wifi: cfg80211: cancel sched scan results work on unregister

cfg80211schedscanresults() can queue rdev->schedscanreswk from a driver result notification while a scheduled scan request is present. The work callback recovers the containing cfg80211registereddevice and then locks the wiphy and walks the scheduled-scan request list.

wiphyunregister() already makes the wiphy unreachable and drains rdev work items before cfg80211devfree() can release the object, but it does not drain schedscanreswk. A queued or running result work item can therefore cross the unregister/free boundary and access freed rdev state.

The buggy scenario involves two paths, with each column showing the order within that path:

scheduled-scan result path: unregister/free path: 1. cfg80211schedscanresults() 1. interface teardown stops and queues rdev->schedscanreswk. removes the scheduled scan request. 2. cfg80211wq starts the work 2. wiphyunregister() drains other item and recovers rdev. rdev work items. 3. The worker locks rdev->wiphy 3. cfg80211devfree() destroys and and walks rdev state. frees rdev.

Cancel schedscanreswk in wiphyunregister() alongside the other rdev work items. cancelworksync() removes a pending result notification and waits for an already running callback, so cfg80211devfree() cannot free rdev while this work item is still active.

Validation reproduced this kernel report: BUG: KASAN: use-after-free in cfg80211schedscanresultswk+0x4a6/0x530 Workqueue: cfg80211 cfg80211schedscanresultswk [cfg80211] Read of size 8 Call trace: dumpstacklvl+0x66/0xa0 printreport+0xce/0x630 cfg80211schedscanresultswk+0x4a6/0x530 srsoaliasreturnthunk+0x5/0xfbef5 __virtaddrvalid+0x224/0x430 kasanreport+0xac/0xe0 lockdephardirqsonprepare+0xea/0x1a0 processonework+0x8d0/0x18f0 (kernel/workqueue.c:3212) lockisheldtype+0x8f/0x100 workerthread+0x5ad/0xfd0 __kthreadparkme+0xc6/0x200 kthread+0x31e/0x410 tracehardirqson+0x1a/0x170 retfrom_fork+0x576/0x810 __switch_to+0x57e/0xe20 _switchtoasm+0x33/0x70 retfromforkasm+0x1a/0x30