CVE-2026-46092 is a newly published Linux kernel vulnerability, disclosed by kernel.org and added to NVD on May 27, 2026, that fixes a crash in the Realtek rtw88 Wi-Fi PCI driver when an RTL8821CE device sits directly on a PCI root bus. The bug is not a glamorous remote-code-execution headline, and it does not currently carry an NVD severity score. But it is exactly the kind of small kernel assumption that matters to people who run Linux on odd hardware, repurpose laptop-class wireless cards, or maintain fleets where “rare topology” eventually becomes “Tuesday.” The patch is only a two-line logic change, yet the story behind it is larger: modern driver security increasingly depends on proving that the boring hardware paths are safe, not merely that the common laptop path works.
At the center of CVE-2026-46092 is a familiar kernel programming sin: a function can return
That distinction sounds like trivia until the probe path dereferences the missing bridge and the kernel crashes. A Wi-Fi card that should merely initialize now becomes a system-stability problem. The vulnerability description is blunt about the likely reason this survived: RTL8821CE hardware is mostly supplied in laptops, and those laptops commonly have a bridge upstream of the wireless device.
That is the kind of assumption driver code accumulates over time. Hardware enablement often begins with the machines developers can buy, the schematics OEMs ship, and the bug reports users actually file. If every observed 8821CE system has a bridge in front of the card, the bridge stops feeling like a variable and starts feeling like part of the chipset’s natural habitat. CVE-2026-46092 is what happens when the habitat changes.
The fix is not conceptually complicated. The patched condition checks that the bridge exists before looking at its vendor ID. In human terms: only apply the Intel-bridge-specific workaround when there is, in fact, a bridge to examine. That is the whole difference between a probe-time crash and a driver that can continue through an unusual PCI layout.
The rtw88 driver family supports a range of Realtek 802.11ac-era devices, including variants that have appeared across consumer laptops and low-cost systems. The specific device called out here, 8821CE, is a PCIe Wi-Fi adapter class that has been common enough to generate years of Linux troubleshooting chatter. That matters because common hardware can still live in uncommon configurations.
The vulnerability is not saying that every 8821CE user is exposed to an active attack. It is saying the kernel had a reachable crash path under a particular PCI topology. That topology is apparently uncommon in the laptop designs where the chip usually ships, but the Linux kernel cannot rely on laptop conventionality. Users move cards. Vendors design compact boards differently. Industrial and embedded systems reuse consumer components in places their original driver assumptions never anticipated.
This is where the CVE label can feel both useful and misleading. Useful, because it gives distribution maintainers, vulnerability scanners, and enterprise tracking systems a shared handle for the fix. Misleading, because a crash during device probing does not carry the same operational risk profile as a remote network compromise. The right response is not panic; it is targeted patch management.
The upstream patch points to a previous workaround: disabling PCIe ASPM L1 while doing NAPI polling for 8821CE. ASPM, or Active State Power Management, is one of those power-saving mechanisms that makes laptops last longer and driver authors age faster. The workaround was conditional on the device being an 8821C-family chip and the upstream bridge being Intel. The bug was not the workaround itself; it was assuming that
This is why the diff is almost comically small. A vulnerable condition becomes a safe condition by adding
There is also a security taxonomy issue here. Kernel CVEs increasingly include defects that are best understood as reliability and denial-of-service fixes. A local crash path in driver probe code may not map cleanly to the exploit narratives security teams are trained to prioritize. Still, in kernel space, a crash is not harmless. Availability is part of security, and the kernel is the one process nobody gets to restart casually.
That is exactly what static analysis is good at when deployed well. It is not a replacement for maintainers who understand hardware, timing, and regression risk. It is a pressure test against assumptions that have become invisible. In this case, the tool seems to have found a defect that real-world laptop deployments may not have triggered often enough to force a bug report.
The kernel community has spent years improving sanitizers, fuzzers, static analysis, and automated testing infrastructure, but hardware drivers remain one of the hardest areas to cover thoroughly. You can fuzz syscalls at scale. You can run filesystem tests across virtual disks. But reproducing every PCI topology, every bridge vendor, every power-management state, and every repurposed Wi-Fi card configuration is another matter entirely.
That makes CVE-2026-46092 a small win for a larger model of kernel assurance. The bug was found before it became a widely reported failure pattern. The fix is easy to audit. The stable tree received the patch. The process worked, but the underlying lesson is uncomfortable: the kernel still contains plenty of code paths whose safety depends on assumptions inherited from the hardware that happened to be most common when the code was written.
But “narrow” is not the same as “unimportant.” A kernel crash during probe can be devastating in exactly the systems that are least pleasant to debug: headless boxes, appliances, lab machines, older desktops with repurposed laptop Wi-Fi cards, or remote systems where network access is needed to fix the network problem. A Wi-Fi driver that crashes during initialization can also complicate live media, installers, and recovery environments.
The likely impact is denial of service rather than confidentiality or integrity compromise. There is no indication from the published description that an attacker can remotely trigger the condition over Wi-Fi traffic. The described failure depends on hardware topology and driver probing. That makes it a local, configuration-dependent reliability issue more than a classic network-facing vulnerability.
Still, the kernel’s privilege boundary changes how we talk about crashes. A user-space application crash is an inconvenience. A kernel crash is system failure. If a vulnerable driver path can be triggered by installing or presenting a device in a certain topology, that matters for machines where physical access, device passthrough, hot-plug arrangements, or unusual PCI configurations are part of the operating environment.
If the answer is yes, the right move is a kernel update from the distribution vendor, not a hand-rolled driver patch unless the environment already supports that workflow. The fix is small, but kernel patching is still kernel patching. Enterprises should prefer vendor-shipped kernels because those packages include backport decisions, module signing, regression testing, and support accountability.
This is especially true for long-term-support kernels. The patch has appeared in stable review contexts, including older maintained branches, which suggests maintainers considered it appropriate for backporting. But downstream timing will vary. Ubuntu, Debian, Fedora, Arch, SUSE, Red Hat derivatives, appliance vendors, and embedded Linux suppliers all move kernel fixes through different pipelines.
Administrators should resist the temptation to overfit their response to the absence of an NVD score. “No score yet” does not mean “not real.” It means the enrichment process has not attached a vector and base score. In the meantime, the kernel patch and the affected code path provide enough information for a sane operational decision.
But Windows users increasingly live adjacent to Linux even when they do not think of themselves as Linux users. Dual-boot machines, WSL-adjacent development workflows, Linux live USBs, home labs, Proxmox hosts, NAS appliances, SteamOS-like gaming systems, and container hosts have blurred the old boundary. A Realtek Wi-Fi card that behaves normally in Windows can still expose a Linux-specific driver defect when the same hardware boots another OS.
That matters for enthusiasts in particular. The kind of person who swaps a Wi-Fi card, installs Linux on an older laptop, or builds a compact router from spare parts is exactly the kind of person who can wander into rare hardware topology. These are not hypothetical users. They are the people who keep forum search indexes alive.
The lesson for Windows-centric readers is not that Linux is uniquely fragile. Windows has its own driver stack, its own OEM-specific quirks, and its own long tail of power-management bugs. The broader lesson is that commodity PC hardware is not as standardized in practice as it appears on a spec sheet. Operating systems survive by encoding thousands of small expectations about how devices are wired, and every so often one of those expectations meets a machine that disagrees.
But the alternative is worse. If kernel defects are only assigned CVEs after someone proves a polished exploit chain, defenders lose the ability to track classes of risky fixes systematically. A crash bug in a driver may be a nuisance on a laptop, a denial-of-service vector in a kiosk, or a serious availability problem in an appliance. Context turns “minor” into “material.”
The friction comes from trying to make one identifier serve several audiences. Kernel developers want fixes landed and backported. Distribution security teams want traceability. Enterprise scanners want severity. Users want to know whether they should reboot. A CVE entry with no score and a terse kernel commit message satisfies none of those audiences perfectly, but it does create a common reference point.
The better posture is to treat these entries as prompts for triage rather than verdicts. CVE-2026-46092 is not a five-alarm fire. It is a signpost: if you have this driver, this chip, this topology, and an unpatched kernel, you can hit a crash. That is enough to justify patching on the normal kernel maintenance cycle and fast-tracking only where the affected configuration is known to exist.
Linux has always been strongest where its hardware diversity is treated as a first-class requirement. It runs on servers, phones, routers, dev boards, laptops, workstations, storage arrays, and strange industrial boxes whose owners may never file upstream bug reports. Supporting that breadth means the kernel must be suspicious of every assumption that begins with “usually.”
PCI topology is one of those areas where “usually” can betray you. A device may sit behind a bridge, or it may not. A workaround may apply to Intel upstream bridges, or the upstream bridge may not exist. The correct code must handle both cases without drama because the kernel does not get to choose the motherboard.
That is why this patch is more than defensive programming boilerplate. It is a reminder that hardware enablement is not complete when the mainstream laptop boots. It is complete when the driver behaves correctly across the legal configurations the bus allows, including the ones that almost nobody tests.
That does not mean every user should immediately compile a custom kernel at midnight. Kernel maintenance is still a balancing act. If a machine is stable, not using rtw88, or not using RTL8821CE, the fix can arrive with the next normal distribution update. If a machine is known to crash during rtw88 probe on unusual hardware, the patched kernel becomes much more urgent.
For troubleshooting, the signs will be hardware- and boot-path-specific. Affected users may see a kernel oops or panic involving rtw88 PCI probing, especially on systems where the adapter is not arranged like the common laptop designs. The absence of a crash does not prove the vulnerable code is absent; it may simply mean the topology never triggers it.
The safest operational guidance is therefore conservative. Keep kernels current. Prefer distribution kernels over out-of-tree driver experiments unless there is a clear reason to do otherwise. Record Realtek Wi-Fi hardware in asset inventories when Linux depends on it for connectivity. And if a system’s network access is mission-critical, do not let a single consumer Wi-Fi adapter be the only path to recovery.
A Tiny Null Check Exposes a Bigger Hardware Assumption
At the center of CVE-2026-46092 is a familiar kernel programming sin: a function can return NULL, and a caller acted as if it would not. In this case, the Realtek rtw88 PCI probing path used pci_upstream_bridge() while applying a workaround for the 8821CE Wi-Fi chipset. If the device is behind a PCI-to-PCI bridge, the code can inspect that upstream bridge and decide whether to disable a particular ASPM behavior. If the device is on a root bus, however, there may be no upstream bridge to inspect.That distinction sounds like trivia until the probe path dereferences the missing bridge and the kernel crashes. A Wi-Fi card that should merely initialize now becomes a system-stability problem. The vulnerability description is blunt about the likely reason this survived: RTL8821CE hardware is mostly supplied in laptops, and those laptops commonly have a bridge upstream of the wireless device.
That is the kind of assumption driver code accumulates over time. Hardware enablement often begins with the machines developers can buy, the schematics OEMs ship, and the bug reports users actually file. If every observed 8821CE system has a bridge in front of the card, the bridge stops feeling like a variable and starts feeling like part of the chipset’s natural habitat. CVE-2026-46092 is what happens when the habitat changes.
The fix is not conceptually complicated. The patched condition checks that the bridge exists before looking at its vendor ID. In human terms: only apply the Intel-bridge-specific workaround when there is, in fact, a bridge to examine. That is the whole difference between a probe-time crash and a driver that can continue through an unusual PCI layout.
The Realtek Driver Path Has Always Been Where Linux Meets Messy PCs
Realtek Wi-Fi on Linux has long occupied an awkward place in the ecosystem. The hardware is ubiquitous, inexpensive, and found in laptops and small-form-factor systems that many users never think of as “exotic.” The software reality is less tidy: multiple Realtek driver families, firmware dependencies, power-management quirks, suspend failures, and distribution-specific patch timing have made these adapters a recurring source of forum threads and support tickets.The rtw88 driver family supports a range of Realtek 802.11ac-era devices, including variants that have appeared across consumer laptops and low-cost systems. The specific device called out here, 8821CE, is a PCIe Wi-Fi adapter class that has been common enough to generate years of Linux troubleshooting chatter. That matters because common hardware can still live in uncommon configurations.
The vulnerability is not saying that every 8821CE user is exposed to an active attack. It is saying the kernel had a reachable crash path under a particular PCI topology. That topology is apparently uncommon in the laptop designs where the chip usually ships, but the Linux kernel cannot rely on laptop conventionality. Users move cards. Vendors design compact boards differently. Industrial and embedded systems reuse consumer components in places their original driver assumptions never anticipated.
This is where the CVE label can feel both useful and misleading. Useful, because it gives distribution maintainers, vulnerability scanners, and enterprise tracking systems a shared handle for the fix. Misleading, because a crash during device probing does not carry the same operational risk profile as a remote network compromise. The right response is not panic; it is targeted patch management.
The Patch Says More Than the Scoreboard Does
NVD currently lists CVE-2026-46092 as awaiting enrichment, with no NIST CVSS score assigned. That absence will frustrate dashboards that want everything reduced to a red, yellow, or green number. But for kernel defects, especially hardware-specific crash bugs, the score often lags behind the practical question administrators actually need answered: do we have affected hardware, and do we boot kernels with the vulnerable driver path?The upstream patch points to a previous workaround: disabling PCIe ASPM L1 while doing NAPI polling for 8821CE. ASPM, or Active State Power Management, is one of those power-saving mechanisms that makes laptops last longer and driver authors age faster. The workaround was conditional on the device being an 8821C-family chip and the upstream bridge being Intel. The bug was not the workaround itself; it was assuming that
bridge->vendor could be read without first confirming bridge was valid.This is why the diff is almost comically small. A vulnerable condition becomes a safe condition by adding
bridge && before checking the bridge vendor. But tiny patches in kernel drivers can have outsized consequences because they sit on hot paths: boot, probe, suspend, resume, interrupt handling, and network packet processing. If one of those paths crashes early, the user may experience “Linux won’t boot with this card installed” rather than “a Wi-Fi driver has a null-pointer dereference.”There is also a security taxonomy issue here. Kernel CVEs increasingly include defects that are best understood as reliability and denial-of-service fixes. A local crash path in driver probe code may not map cleanly to the exploit narratives security teams are trained to prioritize. Still, in kernel space, a crash is not harmless. Availability is part of security, and the kernel is the one process nobody gets to restart casually.
Static Analysis Found the Bug Humans Had Normalized
The disclosure credits the Linux Verification Center and its Svace static analysis tool. That detail deserves more attention than it will probably get. A human reviewer can easily scan a driver workaround and mentally fill in the usual hardware topology. A static analyzer has no such loyalty to the common case. It sees a nullable return and a later dereference, then asks the embarrassing question.That is exactly what static analysis is good at when deployed well. It is not a replacement for maintainers who understand hardware, timing, and regression risk. It is a pressure test against assumptions that have become invisible. In this case, the tool seems to have found a defect that real-world laptop deployments may not have triggered often enough to force a bug report.
The kernel community has spent years improving sanitizers, fuzzers, static analysis, and automated testing infrastructure, but hardware drivers remain one of the hardest areas to cover thoroughly. You can fuzz syscalls at scale. You can run filesystem tests across virtual disks. But reproducing every PCI topology, every bridge vendor, every power-management state, and every repurposed Wi-Fi card configuration is another matter entirely.
That makes CVE-2026-46092 a small win for a larger model of kernel assurance. The bug was found before it became a widely reported failure pattern. The fix is easy to audit. The stable tree received the patch. The process worked, but the underlying lesson is uncomfortable: the kernel still contains plenty of code paths whose safety depends on assumptions inherited from the hardware that happened to be most common when the code was written.
The Risk Is Narrow, but the Blast Radius Is the Kernel
For most desktop Linux users, CVE-2026-46092 will not be a dramatic event. If your system does not use the Realtek rtw88 PCI driver, this specific flaw is irrelevant. If your RTL8821CE adapter sits behind the expected PCI-to-PCI bridge, you may never have encountered the crash. If your distribution has already picked up the stable patch, the issue may be gone before you read the CVE entry.But “narrow” is not the same as “unimportant.” A kernel crash during probe can be devastating in exactly the systems that are least pleasant to debug: headless boxes, appliances, lab machines, older desktops with repurposed laptop Wi-Fi cards, or remote systems where network access is needed to fix the network problem. A Wi-Fi driver that crashes during initialization can also complicate live media, installers, and recovery environments.
The likely impact is denial of service rather than confidentiality or integrity compromise. There is no indication from the published description that an attacker can remotely trigger the condition over Wi-Fi traffic. The described failure depends on hardware topology and driver probing. That makes it a local, configuration-dependent reliability issue more than a classic network-facing vulnerability.
Still, the kernel’s privilege boundary changes how we talk about crashes. A user-space application crash is an inconvenience. A kernel crash is system failure. If a vulnerable driver path can be triggered by installing or presenting a device in a certain topology, that matters for machines where physical access, device passthrough, hot-plug arrangements, or unusual PCI configurations are part of the operating environment.
Enterprise Linux Will Treat This as Inventory Work, Not Incident Response
The practical enterprise response should start with boring questions. Are any managed Linux systems using Realtek rtw88 PCI hardware? Are any of those systems running kernels that predate the stable fix? Are there non-laptop systems where an 8821CE card might sit directly on a root bus? If the answer is no, the CVE can be documented and moved down the queue.If the answer is yes, the right move is a kernel update from the distribution vendor, not a hand-rolled driver patch unless the environment already supports that workflow. The fix is small, but kernel patching is still kernel patching. Enterprises should prefer vendor-shipped kernels because those packages include backport decisions, module signing, regression testing, and support accountability.
This is especially true for long-term-support kernels. The patch has appeared in stable review contexts, including older maintained branches, which suggests maintainers considered it appropriate for backporting. But downstream timing will vary. Ubuntu, Debian, Fedora, Arch, SUSE, Red Hat derivatives, appliance vendors, and embedded Linux suppliers all move kernel fixes through different pipelines.
Administrators should resist the temptation to overfit their response to the absence of an NVD score. “No score yet” does not mean “not real.” It means the enrichment process has not attached a vector and base score. In the meantime, the kernel patch and the affected code path provide enough information for a sane operational decision.
Windows Users Should Still Care, Just Not for the Obvious Reason
This is WindowsForum, so the obvious caveat is worth stating: CVE-2026-46092 is a Linux kernel vulnerability, not a Windows driver vulnerability. It does not describe a flaw in Microsoft’s networking stack, Windows Update, or the Windows Realtek driver package. A Windows-only laptop with an RTL8821CE adapter is not affected by this Linux kernel bug.But Windows users increasingly live adjacent to Linux even when they do not think of themselves as Linux users. Dual-boot machines, WSL-adjacent development workflows, Linux live USBs, home labs, Proxmox hosts, NAS appliances, SteamOS-like gaming systems, and container hosts have blurred the old boundary. A Realtek Wi-Fi card that behaves normally in Windows can still expose a Linux-specific driver defect when the same hardware boots another OS.
That matters for enthusiasts in particular. The kind of person who swaps a Wi-Fi card, installs Linux on an older laptop, or builds a compact router from spare parts is exactly the kind of person who can wander into rare hardware topology. These are not hypothetical users. They are the people who keep forum search indexes alive.
The lesson for Windows-centric readers is not that Linux is uniquely fragile. Windows has its own driver stack, its own OEM-specific quirks, and its own long tail of power-management bugs. The broader lesson is that commodity PC hardware is not as standardized in practice as it appears on a spec sheet. Operating systems survive by encoding thousands of small expectations about how devices are wired, and every so often one of those expectations meets a machine that disagrees.
The CVE System Is Becoming a Changelog for Kernel Correctness
CVE-2026-46092 also illustrates a continuing shift in how Linux kernel vulnerabilities are cataloged. Many kernel CVEs now read less like traditional adversarial security advisories and more like annotated bug fixes: a null check here, a reference leak there, a bounds check somewhere else. Critics argue that this floods vulnerability management systems with low-drama entries. They are not entirely wrong.But the alternative is worse. If kernel defects are only assigned CVEs after someone proves a polished exploit chain, defenders lose the ability to track classes of risky fixes systematically. A crash bug in a driver may be a nuisance on a laptop, a denial-of-service vector in a kiosk, or a serious availability problem in an appliance. Context turns “minor” into “material.”
The friction comes from trying to make one identifier serve several audiences. Kernel developers want fixes landed and backported. Distribution security teams want traceability. Enterprise scanners want severity. Users want to know whether they should reboot. A CVE entry with no score and a terse kernel commit message satisfies none of those audiences perfectly, but it does create a common reference point.
The better posture is to treat these entries as prompts for triage rather than verdicts. CVE-2026-46092 is not a five-alarm fire. It is a signpost: if you have this driver, this chip, this topology, and an unpatched kernel, you can hit a crash. That is enough to justify patching on the normal kernel maintenance cycle and fast-tracking only where the affected configuration is known to exist.
The 8821CE Fix Is Really About the Unusual Machine
The most interesting phrase in the disclosure is not “crash” or “vulnerability.” It is the observation that the issue “probably” went unnoticed because 8821CE is mostly supplied in laptops. That single word carries a lot of engineering humility. The maintainers are acknowledging that the bug hid in the gap between typical hardware and valid hardware.Linux has always been strongest where its hardware diversity is treated as a first-class requirement. It runs on servers, phones, routers, dev boards, laptops, workstations, storage arrays, and strange industrial boxes whose owners may never file upstream bug reports. Supporting that breadth means the kernel must be suspicious of every assumption that begins with “usually.”
PCI topology is one of those areas where “usually” can betray you. A device may sit behind a bridge, or it may not. A workaround may apply to Intel upstream bridges, or the upstream bridge may not exist. The correct code must handle both cases without drama because the kernel does not get to choose the motherboard.
That is why this patch is more than defensive programming boilerplate. It is a reminder that hardware enablement is not complete when the mainstream laptop boots. It is complete when the driver behaves correctly across the legal configurations the bus allows, including the ones that almost nobody tests.
The Fix Is Small Enough to Trust, but Updates Still Need Discipline
From a regression-risk perspective, this is the kind of kernel patch administrators like to see. It does not redesign rtw88. It does not alter firmware loading. It does not change the broader Wi-Fi stack. It simply prevents a vendor check from running when there is no bridge object to check.That does not mean every user should immediately compile a custom kernel at midnight. Kernel maintenance is still a balancing act. If a machine is stable, not using rtw88, or not using RTL8821CE, the fix can arrive with the next normal distribution update. If a machine is known to crash during rtw88 probe on unusual hardware, the patched kernel becomes much more urgent.
For troubleshooting, the signs will be hardware- and boot-path-specific. Affected users may see a kernel oops or panic involving rtw88 PCI probing, especially on systems where the adapter is not arranged like the common laptop designs. The absence of a crash does not prove the vulnerable code is absent; it may simply mean the topology never triggers it.
The safest operational guidance is therefore conservative. Keep kernels current. Prefer distribution kernels over out-of-tree driver experiments unless there is a clear reason to do otherwise. Record Realtek Wi-Fi hardware in asset inventories when Linux depends on it for connectivity. And if a system’s network access is mission-critical, do not let a single consumer Wi-Fi adapter be the only path to recovery.
The Small Patch That Should Change the Triage Conversation
CVE-2026-46092 is easy to dismiss because it lacks the theatrical elements of modern security news. There is no botnet angle, no ransomware branding, no cloud breach, and no emergency logo. But the concrete takeaways are useful precisely because the bug is small and bounded.- CVE-2026-46092 affects the Linux kernel’s Realtek rtw88 PCI driver path for RTL8821CE-class hardware under a PCI topology where no upstream bridge exists.
- The failure mode described publicly is a probing routine crash caused by assuming
pci_upstream_bridge()returned a valid bridge object. - NVD published the entry on May 27, 2026, but had not yet assigned a CVSS score at the time of publication.
- The upstream fix adds an existence check before applying an Intel-bridge-specific ASPM workaround.
- Most ordinary laptop users are unlikely to see dramatic impact, but unusual desktops, embedded systems, repurposed cards, and lab hardware deserve closer attention.
- The appropriate response is normal kernel patching through trusted distribution channels, with faster action for systems known to use the affected Realtek hardware in uncommon PCI layouts.
References
- Primary source: NVD / Linux Kernel
Published: 2026-05-28T01:08:56-07:00
NVD - CVE-2026-46092
nvd.nist.gov
- Security advisory: MSRC
Published: 2026-05-28T01:08:56-07:00
Original feed URL
Security Update Guide - Microsoft Security Response Center
msrc.microsoft.com
- Related coverage: spinics.net
[PATCH rtw-next] wifi: rtw88: check for PCI upstream bridge existence — Linux Kernel
Linux Kernel: [PATCH rtw-next] wifi: rtw88: check for PCI upstream bridge existence
www.spinics.net
- Related coverage: cve.imfht.com
CVE-2025-71273: Linux kernel 安全漏洞
## 概述 Linux 内核 Wi-Fi 驱动 `rtw88` 中存在内存泄漏问题。通过重构 `rtw_set_supported_band()` 函数，使用设备管理内存分配函数 `devm_kmemdup()` 替代手动内存管理，从而修复了在 `rtw_register_hw()` 错误处理路径中支持的频段数据未释放的问题。 ## 影响版本(如有) Linux 内核中的 `rtw88` Wi-
cve.imfht.com
- Related coverage: rapid7.com
Rapid7
Rapid7's VulnDB is curated repository of vetted computer software exploits and exploitable vulnerabilities.www.rapid7.com