CVE-2026-43267

What it actually does

This is a Linux kernel denial-of-service vulnerability in the rtw89 Wi-Fi driver’s beacon tracking logic. If the driver processes a wireless BSS configuration where the beacon interval value is zero, later calculations can divide by zero inside kernel context. A successful trigger can cause a kernel fault, driver failure, system instability, or a full system crash, impacting availability. The CVSS vector indicates local attack requirements with low complexity, low privileges, no user interaction, unchanged scope, and high availability impact; confidentiality and integrity are not directly affected.

Why it matters to the business

Systems using affected Linux kernels with Realtek rtw89-supported Wi-Fi hardware may be susceptible to local availability disruption. In practical terms, exploitation could cause laptops, workstations, embedded Linux devices, kiosks, or wireless-enabled appliances to crash or become unstable, potentially interrupting user productivity, field operations, or device uptime. The risk is lower than remotely exploitable kernel issues because exploitation is local and requires privileges, EPSS is very low, it is not in CISA KEV, and there is no known public exploit maturity reported; however, kernel crashes can still create operational disruption where affected Wi-Fi hardware is broadly deployed.

How an attack unfolds

An attacker who already has local access with low privileges targets a Linux system using the affected rtw89 Wi-Fi driver. The attacker attempts to influence or fuzz wireless configuration state so that the BSS beacon interval value seen by the driver is zero. When the rtw89 beacon tracking code later performs calculations using that value, the zero interval can lead to a division-by-zero condition in kernel space. Because the fault occurs inside the kernel or kernel driver path, the likely result is a kernel oops, driver crash, wireless subsystem failure, or system crash. There is no indication from the provided intelligence that this flaw is being exploited in the wild, used by ransomware campaigns, or associated with named threat actors.

How to fix it

Apply a Linux kernel update that includes the rtw89 fix for zero beacon interval handling. The corrected behavior sets a safe default beacon interval of 100 TU when the value is zero, preventing division by zero in subsequent calculations. Because no exact fixed package versions were provided, use the latest security kernel packages from the relevant Linux distribution or vendor and verify the vendor advisory explicitly includes the rtw89 beacon interval fix for this issue. Where immediate patching is not possible, reduce exposure by disabling unused Wi-Fi interfaces, unloading or blacklisting the rtw89 driver on systems that do not require it, restricting local shell access, and limiting the ability of untrusted users to manipulate wireless networking state. Reboot systems after kernel updates so the fixed kernel and driver are actually running.

How to confirm the fix worked

Confirm the running kernel version is updated to a vendor build containing the rtw89 beacon interval fix, not merely installed on disk. Check whether affected systems use Realtek rtw89 hardware or have the rtw89 driver loaded, for example by reviewing loaded kernel modules and wireless device inventory. Validate that systems have been rebooted into the fixed kernel after patching. For mitigation validation, confirm the rtw89 driver is not loaded or is successfully blacklisted where Wi-Fi is not required. Review kernel logs for absence of new divide-by-zero, kernel oops, or rtw89 crash messages during normal wireless operation after remediation.

Typical attack path

1. Obtain local access to a Linux system with an affected kernel and rtw89-supported Wi-Fi hardware or driver loaded.
2. Confirm the rtw89 driver is active and the wireless interface is managed by the vulnerable code path.
3. Manipulate, fuzz, or induce wireless BSS configuration state so the beacon interval value becomes zero.
4. Trigger beacon tracking calculations in the rtw89 driver.
5. Cause a division-by-zero fault in kernel context.
6. Crash the driver, destabilize the wireless subsystem, or trigger a broader system crash resulting in denial of service.

How to detect it

To assess possible prior exploitation, review kernel and system logs from affected Linux systems for evidence of rtw89 driver faults, divide-by-zero exceptions, kernel oops events, panics, unexpected reboots, or wireless subsystem crashes. Relevant sources include journald, syslog, kern.log, dmesg output, crash dump facilities such as kdump/vmcore, endpoint telemetry, and uptime/reboot history. Focus on systems with Realtek rtw89-supported Wi-Fi hardware or the rtw89 module loaded. Look for crash sequences involving rtw89 beacon tracking or division errors followed by loss of wireless connectivity, kernel oops, panic, watchdog reset, or unplanned reboot. Because the vulnerability causes denial of service rather than code execution, durable file, registry, or network IOCs are not expected; detection depends primarily on crash artifacts and temporal correlation with local user activity or wireless configuration changes.

• rtw89
• divide error
• division by zero
• kernel BUG
• Oops:
• Kernel panic
• BUG: unable to handle kernel
• Call Trace:
• Modules linked in: rtw89
• rtw89_core
• rtw89_pci
• beacon
• beacon_int
• wlan
• kdump
• vmcore
• watchdog: BUG: soft lockup
• systemd-journald: Journal stopped
• Linux version

What your security team should do

• Prioritize patching Linux endpoints and embedded systems that use Realtek rtw89 Wi-Fi hardware, especially systems where availability is operationally important.
• Inventory systems with the rtw89 driver loaded or Realtek Wi-Fi chipsets supported by rtw89 to determine actual exposure.
• Deploy the latest vendor-supported Linux kernel security updates and reboot affected systems into the fixed kernel.
• If patching must be delayed, disable unused wireless interfaces or blacklist the rtw89 driver on systems that do not need Wi-Fi.
• Restrict local interactive access and administrative control over wireless networking tools to trusted users only.
• Monitor kernel logs for divide-by-zero, kernel oops, panic, or rtw89-related crash events until patching is complete.
• Treat this as a moderate-priority availability issue: no KEV listing, no known ransomware use, very low EPSS, and no public exploit maturity were reported, but kernel DoS conditions can still disrupt operations.