CVE-2026-97516: wifi: rtw88: Add NULL check for chip->edcca_th in rtw_fw_adaptivity_result()
In the Linux kernel, the following vulnerability has been resolved:
wifi: rtw88: Add NULL check for chip->edccath in rtwfwadaptivityresult()
It was recently reported that rtwfwadaptivityresult() in fw.c dereferences rtwdev->chip->edccath without a NULL check. The issue is that devices with the 8821CE chip don't define edccath in their chip info. As a result, when rtwfwadaptivityresult() tries to dereference it, the kernel triggers an oops.
Add a NULL check for edccath before dereferencing it in rtwfwadaptivityresult() in fw.c. Placing the check at the function entry avoids logging any garbage values.
This change does not address the root cause for this behavior, but it prevents the NULL dereference and the resulting oops while a more permanent solution is developed.
Tested on a 8822CE chip which defines edccath, so this issue is not present on it, but it still uses this driver and I can verify there are no regressions.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Compensating control
Add a NULL check for rtwdev->chip->edcca_th before dereferencing it in rtw_fw_adaptivity_result() in fw.c.
Event History
Frequently Asked Questions
Which systems are affected by this issue?
Systems using the Linux kernel rtw88 Wi-Fi driver with an 8821CE chip are affected because that chip's information does not define edcca_th. The issue was not present on a tested 8822CE device, which defines edcca_th.
What happens when the vulnerable code is reached?
rtw_fw_adaptivity_result() can dereference a NULL edcca_th pointer, triggering a kernel oops. The fix adds an entry-point NULL check to prevent that dereference and avoid logging garbage values.
Does the fix resolve the underlying cause?
No. The change prevents the NULL dereference and resulting kernel oops, but the underlying cause is not addressed and a more permanent solution is still needed.