CVE-2023-53281: drivers: staging: rtl8723bs: Fix locking in _rtw_join_timeout_handler()
In the Linux kernel, the following vulnerability has been resolved:
drivers: staging: rtl8723bs: Fix locking in _rtw_join_timeout_handler()
Commit 041879b12ddb ("drivers: staging: rtl8192bs: Fix deadlock in
rtw_joinbss_event_prehandle()") besides fixing the deadlock also
modified _rtw_join_timeout_handler() to use spin_[un]lock_irq()
instead of spin_[un]lock_bh().
_rtw_join_timeout_handler() calls rtw_do_join() which takes
pmlmepriv->scanned_queue.lock using spin_[un]lock_bh(). This
spin_unlock_bh() call re-enables softirqs which triggers an oops in
kernel/softirq.c: __local_bh_enable_ip() when it calls
lockdep_assert_irqs_enabled():
[ 244.506087] WARNING: CPU: 2 PID: 0 at kernel/softirq.c:376 __local_bh_enable_ip+0xa6/0x100
...
[ 244.509022] Call Trace:
[ 244.509048] <IRQ>
[ 244.509100] _rtw_join_timeout_handler+0x134/0x170 [r8723bs]
[ 244.509468] ? __pfx__rtw_join_timeout_handler+0x10/0x10 [r8723bs]
[ 244.509772] ? __pfx__rtw_join_timeout_handler+0x10/0x10 [r8723bs]
[ 244.510076] call_timer_fn+0x95/0x2a0
[ 244.510200] __run_timers.part.0+0x1da/0x2d0
This oops is causd by the switch to spin_[un]lock_irq() which disables
the IRQs for the entire duration of _rtw_join_timeout_handler().
Disabling the IRQs is not necessary since all code taking this lock
runs from either user contexts or from softirqs, switch back to
spin_[un]lock_bh() to fix this.
Security readout for executives and security teams
Plain-English summary
This Linux kernel issue can crash affected systems when the rtl8723bs staging Wi-Fi driver hits a join timeout path. It is a local availability risk, not a data theft issue. Business urgency is highest for devices that actually ship, load, or depend on this driver.
Executive priority
Treat as a targeted availability issue. Patch through normal kernel maintenance, escalating for fleets using the affected Wi-Fi driver or custom kernels. No source indicates active exploitation, so it is not an emergency absent driver exposure.
Technical view
CVE-2023-53281 is a locking flaw in _rtw_join_timeout_handler() in drivers/staging/rtl8723bs. A prior deadlock fix changed bottom-half locking to IRQ locking, allowing a later spin_unlock_bh() path to re-enable softirqs while IRQs were disabled, triggering a kernel oops. CVSS is 5.5 with local, low-complexity, low-privilege availability impact.
Likely exposure
Exposure appears limited to affected Linux kernel builds where the rtl8723bs/r8723bs staging driver is present and exercised. General servers without this driver loaded are less likely to be exposed, but embedded, laptop, or custom kernel environments should verify.
Exploitation context
The provided sources do not show public exploitation or KEV listing. The CVSS vector requires local access with low privileges and impacts availability only. Evidence supports a crash/oops condition, not confidentiality or integrity compromise.
Researcher notes
The root cause is inconsistent interrupt/bottom-half locking introduced by commit 041879b12ddb while addressing a different deadlock. The fix switches _rtw_join_timeout_handler() back to spin_lock_bh()/spin_unlock_bh() because users of the lock run from user context or softirqs.
Mitigation direction
Apply a vendor kernel update that includes the referenced stable kernel fixes.
Check distribution advisories for the exact fixed package for your kernel branch.
Prioritize assets that load or depend on the rtl8723bs/r8723bs driver.
For custom kernels, ensure the referenced locking correction is backported.
Track vendor guidance if no fixed package is currently available.
Validation and detection
Inventory running kernel versions against vendor and kernel.org fixed branches.
Confirm whether rtl8723bs/r8723bs is built, installed, or loaded on target systems.
Review kernel logs for oops or warnings involving _rtw_join_timeout_handler.
For source builds, verify _rtw_join_timeout_handler() uses bottom-half locking as fixed.
Regression-test wireless join behavior after applying kernel updates.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cwe · low confidence lookup
CWE-667: Exact CWE lookup
Use the exact CWE identifier as the starting point before reviewing related ATT&CK behavior. Open the exact CWE lookup page first, then review the ATT&CK searches from that MITRE weakness context. This is a Glexia lookup hint, not an official ATT&CK mapping.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.
CWE links open Glexia weakness intelligence pages with official CWE context, developer remediation guidance, and related CVE mappings.
CWE-667 · source CWE mapping
Improper Locking
Improper Locking represents a recurring weakness pattern that can create exploitable paths when design, validation, or implementation controls are missing.