Look up another CVE · open CVE-2026-90403 in the interactive tracker
CVE-2026-90403
wifi: rtlwifi: pci: fix error path in rtl_pci_probe()
Published 2026-09-17 (31 days ago) by the Linux kernel CNA. Subsystem drivers/net. Debian urgency: not yet assigned.
What to do, per Debian release
Debian's own status for CVE-2026-90403 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source
| Release | Status | Version | What this means |
|---|---|---|---|
| Debian 12bookworm | fixedDLA-4841-1 · 2026-10-17 · text | 6.1.190-1 | Update the kernel and reboot. DLA-4841-1 shipped the fix on 2026-10-17, in 6.1.190-1. A running kernel keeps the old code until the machine restarts. |
| Debian 13trixie | fixedDSA-6528-1 · 2026-09-29 · text | 6.12.111-1 | Update the kernel and reboot. DSA-6528-1 shipped the fix on 2026-09-29, in 6.12.111-1. A running kernel keeps the old code until the machine restarts. |
| Debian 14forky | fixed | 7.2.6-1 | Update the kernel and reboot. Fixed in 7.2.6-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.2.6-1 | Update the kernel and reboot. Fixed in 7.2.6-1. A running kernel keeps the old code until the machine restarts. |
| Debian 12bookworm · linux-6.12 | fixedDLA-4817-1 · 2026-10-04 · text | 6.12.111-1~deb12u1 | Update the kernel and reboot. DLA-4817-1 shipped the fix on 2026-10-04, in 6.12.111-1~deb12u1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
In the last error path in rtl_pci_probe(), the cleanup functions are skipped due to a wrong goto label. Moreover, the successful call to rtl_init_rfkill(), ieee80211_register_hw(), rtl_debug_add_one() have to be reverted. Fix this issue by updating the labels and adding the relevant cleanup functions to the last error path.
Where it lives
The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.
drivers/net/wireless/realtek/rtlwifi/pci.c
- What this is
- REALTEK WIRELESS DRIVER (rtlwifi family)MAINTAINERS section matched on drivers/net/wireless/realtek/rtlwifi/ · linux-wireless@vger.kernel.org · Maintained
- Kernel module
- rtl_pci
Check it on the machine
grep -wE 'CONFIG_RTLWIFI|CONFIG_RTLWIFI_PCI|CONFIG_WLAN|CONFIG_WLAN_VENDOR_REALTEK' /boot/config-$(uname -r)Reads the booted kernel's own configuration, on the machine and nowhere else. =y is built in, =m is a module, and an is not set line means the code is not there.
lsmod | grep -w rtl_pciPrints a line if that module is loaded right now, and nothing if it is not. One that is not loaded can still be loaded later by anything that needs it.
Show whether Debian builds this, per release
Debian builds this, but not on every flavour. At least one release below builds the code on some of its kernel flavours and not on others, so the answer depends on the architecture and flavour installed.
- bookwormMnot built on amd64/cloud-amd64, arm64/cloud-arm64
- trixieMnot built on amd64/cloud-amd64, arm64/cloud-arm64, armel/rpi, s390x/s390x
- forky, sidMnot built on amd64/cloud-amd64, arm64/cloud-arm64, s390x/s390x
- bookworm · linux-6.12Mnot built on amd64/cloud-amd64, arm64/cloud-arm64
- M
- a module where it is built at all; some flavours do not build it
- Build switches
- CONFIG_RTLWIFI, CONFIG_RTLWIFI_PCI, CONFIG_WLAN, CONFIG_WLAN_VENDOR_REALTEK
- Reads as
- all on means the file is compiled; any one off means it is not.
From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS kbuild Makefiles Debian linux-config packages
Signals
- Published
- 2026-09-17 (31 days ago)source
- CVSS
- 7.0 high
CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:Hsource recompute it - Attack vector
- local (AV:L)source
- EPSS
- 0.14%, higher than 3.4% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- not yet assignedsource
- Subsystem
- drivers/net
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 2.6.38 | 5.10.270 | 2634998247d2 |
| 2.6.38 | 5.15.221 | cfd6824dd1d1 |
| 2.6.38 | 6.1.188 | 86e6187f8525 |
| 2.6.38 | 6.6.157 | aef178ffae54 |
| 2.6.38 | 6.12.110 | b42fcfb097da |
| 2.6.38 | 6.18.52 | a89818977338 |
| 2.6.38 | 7.2.6 | 1b68b6e529ce |
| 2.6.38 | 7.3 | 3c2999d13eeb |
Debian advisories
| Advisory | Date | Shipped to | Debian |
|---|---|---|---|
| DLA-4841-1 | 2026-10-17 | bookworm 6.1.190-1 | tracker |
| DLA-4817-1 | 2026-10-04 | bookworm 6.12.111-1~deb12u1 | tracker |
| DSA-6528-1 | 2026-09-29 | trixie 6.12.111-1 | tracker |
Why the CNA scored it this way
Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source
- AV:LAttack vector, local
- The UAF is only on rtl_pci_probe()'s last error path, when rtl_pci_intr_mode_decide() fails and the old code jumped to fail3. That path is reached from local_pci_probe() as the .probe of rtl8192ce/rtl8188ee/rtl8192ee/rtl8723be and related pci_driver tables (e.g. Realtek 0x8191/0x8178). 802.11 frames never enter rtl_pci_probe.
- AC:HAttack complexity, high
- The only trigger is pci_enable_msi() or request_irq(pdev->irq, _rtl_pci_interrupt, IRQF_SHARED) failing after ieee80211_register_hw() has already succeeded. pdev->irq is assigned by the host PCI/ACPI code, and the subsequent irqaction kzalloc is tiny compared with earlier ring and wiphy allocations, so an attacker cannot reliably force that failure.
- PR:LPrivileges required, low
- Once fail3 has run ieee80211_free_hw() on the still-registered hw, the leftover default wlan vif from ieee80211_if_add(), cfg80211 wiphy, inetaddr notifiers, and rfkill poll are reachable via nl80211 or any netns address change without init-namespace root or PCI sysfs bind.
- UI:NUser interaction, none
- No victim must mount media or associate to a network; after the failed probe unwind, the attacker’s own nl80211 use of the leftover wlan vif, an inetaddr change, or cfg80211_rfkill_poll touches the still-registered ieee80211_local.
- S:UScope, unchanged
- ieee80211_free_hw() frees the still-registered ieee80211_local/wiphy while mac80211 still holds it; impact is host-kernel heap corruption, not a VM, IOMMU, or sandbox escape.
- C:HConfidentiality impact, high
- fail3 calls ieee80211_free_hw() without ieee80211_unregister_hw(), so cfg80211_rfkill_poll → ieee80211_rfkill_poll and nl80211 still dereference the kfree'd ieee80211_local, wiphy bands, and default STA vif, a UAF read primitive.
- I:HIntegrity impact, high
- The leftover objects are written by ieee80211_ifa_changed (inetaddr notifier), mac80211 workqueues never torn down by ieee80211_unregister_hw(), and rtl_op_rfkill_poll via wiphy_rfkill_start_polling, enabling UAF writes and control-flow hijack.
- A:HAvailability impact, high
- ieee80211_free_hw() without ieee80211_unregister_hw() leaves mac80211 workqueues, inetaddr notifiers, the default wlan vif, and rfkill polling running against freed ieee80211_local, which oopses or panics on the next access.