Kernel.org assigned CVE-2026-46136 on May 28, 2026, to a Linux kernel mt76 driver flaw in MediaTek’s MT7921 Wi-Fi path, where a country-location-control buffer length underflow can trigger a near-endless loop, bad transmit-power settings, or driver initialization failure. The bug is narrow, unglamorous, and not yet scored by NVD, but it is exactly the sort of kernel defect that matters to real users because it lives in the seam between firmware data, regional radio rules, and device bring-up. For WindowsForum readers, the lesson is not that a Linux Wi-Fi bug threatens Windows directly; it is that modern laptop radios are now tiny regulatory computers, and a three-line bounds check can decide whether a machine has wireless networking at boot.
CVE-2026-46136 is not the kind of vulnerability that arrives with a cinematic exploit chain. The public description says the
That phrasing sounds mundane until you remember where it sits. The affected code is in the MediaTek mt76 Linux wireless driver family, specifically the MT7921 path used by common Wi-Fi 6 and Wi-Fi 6E laptop adapters. This is not an obscure enterprise appliance driver; MT7921-class chips have shipped in plenty of consumer and enthusiast notebooks, including systems that dual-boot Windows and Linux.
The flaw also sits in the regulatory-control path, not in a user-facing network feature. Country Location Control, or CLC, is part of the machinery that helps a radio obey region-specific transmit-power and channel rules. A broken parse there does not merely risk a crash; it risks selecting the wrong power constraints or failing the device before the user ever sees a network list.
That is why the fix matters even before NVD has attached a CVSS score. The security industry has trained users to look for a number, but kernel maintainers often reveal the operational truth sooner than a database does. Here, the truth is simple: malformed or unexpected table length handling in a driver can strand a wireless adapter at initialization.
That is the classic shape of an unsigned-length bug. The code believes it is safely consuming a bounded buffer, but if the next claimed object is larger than what remains, subtracting the offset can wrap the length value rather than exhaust it. In C, especially in kernel code, arithmetic that looks harmless can become a control-flow trap when the type is unsigned and the input structure is trusted too much.
The interesting point is not that a developer forgot a bounds check. The interesting point is that Wi-Fi drivers increasingly parse complex data from firmware, EEPROM, regulatory tables, and vendor-specific control structures. That data changes as hardware revisions, regional requirements, and 6 GHz support evolve. A parser that was safe against yesterday’s table layout can become unsafe when today’s table grows a field, changes an entry length, or exposes a malformed segment.
The patch’s own history points to that dynamic. The change fixes behavior associated with an earlier adjustment for CLC country-count limitations, and it was sent to stable. That is a signal that maintainers view this not as a speculative cleanup for mainline kernels, but as a practical fix worth carrying back into supported trees.
That distinction matters because Linux kernel CVEs are often flattened into a single fear category. A kernel bug sounds severe by default, and a Wi-Fi bug sounds remotely reachable by default. But the known record for CVE-2026-46136 does not support the idea that an attacker can drive by with a crafted beacon frame and take over a machine.
The more grounded risk is boot-time or device-start instability on systems with affected MediaTek hardware and affected kernel builds. If the CLC table fed into the driver takes a shape the parser does not handle correctly, the adapter may fail to initialize or may get stuck in a path that looks like a hang. For a desktop wired into Ethernet, that is annoying. For a laptop, kiosk, field device, or classroom fleet that depends on Wi-Fi, it is an outage.
There is also a regulatory dimension. The mention of invalid power settings is easy to overlook, but it is important. Wi-Fi transmit power is not just a performance knob; it is constrained by country, band, channel, and device capabilities. A driver that misreads country power information can fail safe, fail noisy, or fail in ways that are hard to diagnose from user space.
In practical terms, many affected users will not know they have an MT7921 until something breaks. They will know the laptop as an ASUS, Acer, Lenovo, MSI, or mini-PC model; the Wi-Fi card’s vendor name only appears later, in
This is especially familiar to dual-boot users. Windows may ship a vendor driver stack for the same radio while Linux relies on mt76 plus firmware blobs from the Linux firmware ecosystem. The same chip can therefore feel “fine in Windows” and unreliable in Linux, not because the silicon changes, but because the operating systems exercise different driver code paths and power-management transitions.
CVE-2026-46136 should not be confused with every MT7921 complaint on the internet. Random disconnects, Bluetooth initialization failures, ASPM quirks, suspend/resume oddities, and firmware loading problems can have separate causes. But this CVE belongs to the same practical universe: small radio-driver assumptions that surface as user-visible instability.
The lack of a score should not be read as lack of impact. NVD scoring is a downstream classification process; it does not determine whether code is fixed, whether distributions should pick up the patch, or whether administrators should care. In the kernel world, the commit and stable backport trail often provide the earlier and more useful signal.
Still, the missing score does create a communication problem. Security dashboards prefer numeric severity, while operations teams need to know whether a defect can break machines. CVE-2026-46136 may ultimately land as a modest availability issue, but a modest availability issue in the Wi-Fi driver of a mobile fleet can have a larger practical blast radius than a scarier-looking bug in a rarely loaded subsystem.
This is where vulnerability management needs more texture. A headless server without MT7921 hardware is not meaningfully exposed. A Linux laptop image deployed to hundreds of students or field workers very much might be, even if no one is losing sleep over remote exploitation.
That is why this CVE belongs in the “reliability is security” file. A device that cannot join the network cannot receive policy, updates, remote assistance, or endpoint telemetry. In consumer terms, it cannot get online. In managed IT terms, it can fall out of compliance simply because the driver lost a length calculation.
The near-infinite-loop language also deserves attention. Kernel loops that spin too long can look like boot hangs, slow device enumeration, high CPU usage, or watchdog-triggered failures depending on timing and configuration. They are rarely pleasant to debug because the symptom is displaced from the cause. Users see “Wi-Fi vanished” or “boot got stuck,” not “CLC rule parser underflowed a remaining-length counter.”
For administrators, the diagnostic clue is hardware specificity. If the problem clusters around systems with MediaTek MT7921-class adapters and appears after a kernel update or firmware-table change, the CLC path becomes more plausible. If the same image works on Intel or Realtek wireless hardware, the case becomes stronger.
The practical question is therefore not “is there a patch?” but “has my kernel vendor shipped the patched build?” Rolling-release users may receive the fix quickly as part of a normal kernel update. Enterprise and long-term-support users may wait for a scheduled advisory unless the vendor classifies the regression risk as urgent.
There is a subtle tension here. Wi-Fi driver patches can fix one class of instability while introducing another if they interact badly with firmware, power management, or vendor-specific quirks. That does not argue against updating; it argues for testing updates on representative hardware before a broad fleet rollout. A three-line bounds check is low-risk as patches go, but wireless stacks have earned their reputation for surprising administrators.
The good news is that this fix is conceptually conservative. It does not redesign the CLC parser or change policy. It simply refuses to consume a rule whose computed size exceeds the remaining buffer. That is the kind of defensive programming kernel drivers should have by default.
But Windows users increasingly live in mixed environments. Enthusiasts dual-boot. Developers run Linux bare metal for containers, drivers, and AI workloads. IT pros maintain Linux appliances alongside Windows endpoints. Even Windows-first households now have SteamOS handhelds, Proxmox boxes, Raspberry Pi-class devices, and Linux-based routers in the same network.
The hardware overlap also matters. The same MediaTek radio that behaves one way under Windows may behave differently under Linux after a reboot, suspend cycle, or firmware reset. Dual-boot users already know this pattern from fast startup issues, Bluetooth state weirdness, and PCIe power-management quirks. CVE-2026-46136 is not necessarily caused by Windows leaving hardware in a bad state, but it belongs to the wider class of bugs where a shared device’s behavior depends heavily on driver assumptions.
There is also a procurement lesson. Wi-Fi adapters are often treated as commodity parts, swapped silently across laptop revisions. For buyers who care about Linux compatibility, the exact wireless chipset remains one of the most important hidden specifications. Intel radios are not perfect, Realtek radios are not all bad, and MediaTek radios are not doomed, but the support history of the driver stack should be part of the buying decision.
But the CVE label does useful work when it forces a reliability defect into patch-management systems. Without the identifier, this mt76 fix might disappear into a kernel changelog read only by wireless maintainers and distro packagers. With the identifier, asset owners can at least map it to affected kernels and hardware.
The risk is over-automation. A scanner may flag every Linux host as vulnerable because the kernel version falls into a broad range, even if the machine has no MediaTek Wi-Fi hardware and never loads
The right model is conditional exposure. The bug matters when three things line up: an affected kernel, an MT7921-family device using the mt76 path, and CLC data that can trigger the underflow. Remove the hardware and the practical risk collapses. Keep the hardware and deploy at scale, and the risk becomes operationally meaningful.
The fix pattern is also old. Before advancing a pointer, verify that the requested advance fits inside the remaining buffer. Before subtracting from a remaining length, verify that the subtraction cannot underflow. Before trusting a rule’s declared size, check it against the container that supposedly holds it.
What makes this bug modern is the radio-policy context. Wi-Fi 6E and 6 GHz operation made country, environment, and power rules more complicated. Devices increasingly need to distinguish bands, regulatory domains, indoor/outdoor assumptions, and access-point constraints. That complexity flows into driver tables, and driver tables become parser attack surfaces even when no attacker is in sight.
This is not an argument for freezing hardware features. It is an argument that every new regulatory feature should be treated like a new file format. If the driver parses it, the driver must survive malformed, unexpected, truncated, or future-shaped data.
If you manage a fleet, do not wait for NVD scoring to decide whether to test the fix. Pick representative systems with the affected wireless hardware, update them to the vendor kernel that includes the stable patch, and verify cold boot, warm reboot, suspend/resume, and roaming behavior. Wireless regressions often hide in transitions rather than in a clean boot.
For individual users, the practical symptom to watch is not a security alert but Wi-Fi initialization failure. If a laptop with a MediaTek MT7921 adapter suddenly stops presenting wireless interfaces after a kernel update, or logs mt76/mt7921 errors during boot, this CVE’s fix is one of the things worth checking. It may not be the cause, but it is close enough to the symptom to belong on the shortlist.
For Windows-only users, there is no need to patch Windows for this specific CVE. The useful takeaway is hardware literacy. If you dual-boot, run Linux live media, or rely on recovery environments, your wireless card’s Linux driver support can matter even when Windows is your daily operating system.
A Small Driver Bug Exposes a Large Trust Boundary
CVE-2026-46136 is not the kind of vulnerability that arrives with a cinematic exploit chain. The public description says the buf_len value used while retrieving country power settings may underflow under certain conditions after changes in the CLC power table. Once that happens, the driver can keep iterating for an almost absurd length of time or parse an invalid power setting, causing MT7921 initialization to fail.That phrasing sounds mundane until you remember where it sits. The affected code is in the MediaTek mt76 Linux wireless driver family, specifically the MT7921 path used by common Wi-Fi 6 and Wi-Fi 6E laptop adapters. This is not an obscure enterprise appliance driver; MT7921-class chips have shipped in plenty of consumer and enthusiast notebooks, including systems that dual-boot Windows and Linux.
The flaw also sits in the regulatory-control path, not in a user-facing network feature. Country Location Control, or CLC, is part of the machinery that helps a radio obey region-specific transmit-power and channel rules. A broken parse there does not merely risk a crash; it risks selecting the wrong power constraints or failing the device before the user ever sees a network list.
That is why the fix matters even before NVD has attached a CVSS score. The security industry has trained users to look for a number, but kernel maintainers often reveal the operational truth sooner than a database does. Here, the truth is simple: malformed or unexpected table length handling in a driver can strand a wireless adapter at initialization.
The Patch Is Three Lines Because the Mistake Is Older Than Wi-Fi 6E
The upstream patch is almost comically small. In the loop walking CLC rules, the driver calculates anoffset from the rule length plus the rule header size. The fix adds a check: if the remaining buffer length is smaller than that offset, stop walking the table.That is the classic shape of an unsigned-length bug. The code believes it is safely consuming a bounded buffer, but if the next claimed object is larger than what remains, subtracting the offset can wrap the length value rather than exhaust it. In C, especially in kernel code, arithmetic that looks harmless can become a control-flow trap when the type is unsigned and the input structure is trusted too much.
The interesting point is not that a developer forgot a bounds check. The interesting point is that Wi-Fi drivers increasingly parse complex data from firmware, EEPROM, regulatory tables, and vendor-specific control structures. That data changes as hardware revisions, regional requirements, and 6 GHz support evolve. A parser that was safe against yesterday’s table layout can become unsafe when today’s table grows a field, changes an entry length, or exposes a malformed segment.
The patch’s own history points to that dynamic. The change fixes behavior associated with an earlier adjustment for CLC country-count limitations, and it was sent to stable. That is a signal that maintainers view this not as a speculative cleanup for mainline kernels, but as a practical fix worth carrying back into supported trees.
This Is Availability First, Not a Remote-Code-Execution Panic
The public CVE wording does not describe remote code execution, privilege escalation, credential theft, or packet-triggered compromise. It describes an almost infinite loop, an invalid power setting, and driver initialization failure. In ordinary admin language, that means availability and reliability are the main concerns.That distinction matters because Linux kernel CVEs are often flattened into a single fear category. A kernel bug sounds severe by default, and a Wi-Fi bug sounds remotely reachable by default. But the known record for CVE-2026-46136 does not support the idea that an attacker can drive by with a crafted beacon frame and take over a machine.
The more grounded risk is boot-time or device-start instability on systems with affected MediaTek hardware and affected kernel builds. If the CLC table fed into the driver takes a shape the parser does not handle correctly, the adapter may fail to initialize or may get stuck in a path that looks like a hang. For a desktop wired into Ethernet, that is annoying. For a laptop, kiosk, field device, or classroom fleet that depends on Wi-Fi, it is an outage.
There is also a regulatory dimension. The mention of invalid power settings is easy to overlook, but it is important. Wi-Fi transmit power is not just a performance knob; it is constrained by country, band, channel, and device capabilities. A driver that misreads country power information can fail safe, fail noisy, or fail in ways that are hard to diagnose from user space.
MediaTek’s MT7921 Is Common Enough for This to Matter
The MT7921 family is supported by the Linux mt76 driver and covers PCIe, USB, and SDIO variants, with PCIe support present since the Linux 5.12 era and later support expanding across additional attachment types. The same driver family covers a wider set of MediaTek 802.11 chips, which is one reason mt76 changes are watched closely by laptop users, distro maintainers, and embedded vendors.In practical terms, many affected users will not know they have an MT7921 until something breaks. They will know the laptop as an ASUS, Acer, Lenovo, MSI, or mini-PC model; the Wi-Fi card’s vendor name only appears later, in
lspci, lsusb, Device Manager, or a support forum thread. That makes driver-level regressions feel random even when they map cleanly to hardware IDs.This is especially familiar to dual-boot users. Windows may ship a vendor driver stack for the same radio while Linux relies on mt76 plus firmware blobs from the Linux firmware ecosystem. The same chip can therefore feel “fine in Windows” and unreliable in Linux, not because the silicon changes, but because the operating systems exercise different driver code paths and power-management transitions.
CVE-2026-46136 should not be confused with every MT7921 complaint on the internet. Random disconnects, Bluetooth initialization failures, ASPM quirks, suspend/resume oddities, and firmware loading problems can have separate causes. But this CVE belongs to the same practical universe: small radio-driver assumptions that surface as user-visible instability.
NVD’s Empty Score Is a Data Lag, Not an All-Clear
As of the CVE publication record supplied for this story, NVD had not yet assigned CVSS 4.0, CVSS 3.x, or CVSS 2.0 scores. That “awaiting enrichment” status is normal for newly published kernel CVEs, particularly when the record originates from kernel.org and the vulnerability is described through a merged fix rather than a full advisory.The lack of a score should not be read as lack of impact. NVD scoring is a downstream classification process; it does not determine whether code is fixed, whether distributions should pick up the patch, or whether administrators should care. In the kernel world, the commit and stable backport trail often provide the earlier and more useful signal.
Still, the missing score does create a communication problem. Security dashboards prefer numeric severity, while operations teams need to know whether a defect can break machines. CVE-2026-46136 may ultimately land as a modest availability issue, but a modest availability issue in the Wi-Fi driver of a mobile fleet can have a larger practical blast radius than a scarier-looking bug in a rarely loaded subsystem.
This is where vulnerability management needs more texture. A headless server without MT7921 hardware is not meaningfully exposed. A Linux laptop image deployed to hundreds of students or field workers very much might be, even if no one is losing sleep over remote exploitation.
The Real Attack Surface Is the Boot Path
The driver initialization path is one of the least glamorous parts of a system, but it is also one of the most consequential. If a wireless adapter fails to come up, almost every higher-level control plane above it becomes irrelevant. NetworkManager can be perfect, WPA supplicant can be current, and the desktop shell can be polished; none of that matters if the kernel module cannot initialize the radio.That is why this CVE belongs in the “reliability is security” file. A device that cannot join the network cannot receive policy, updates, remote assistance, or endpoint telemetry. In consumer terms, it cannot get online. In managed IT terms, it can fall out of compliance simply because the driver lost a length calculation.
The near-infinite-loop language also deserves attention. Kernel loops that spin too long can look like boot hangs, slow device enumeration, high CPU usage, or watchdog-triggered failures depending on timing and configuration. They are rarely pleasant to debug because the symptom is displaced from the cause. Users see “Wi-Fi vanished” or “boot got stuck,” not “CLC rule parser underflowed a remaining-length counter.”
For administrators, the diagnostic clue is hardware specificity. If the problem clusters around systems with MediaTek MT7921-class adapters and appears after a kernel update or firmware-table change, the CLC path becomes more plausible. If the same image works on Intel or Realtek wireless hardware, the case becomes stronger.
Stable Backports Are the Story to Watch
The CVE record lists multiple stable kernel references, which means the fix is being carried across more than one maintained branch. That is exactly what Linux users want to see, because very few production systems run Linus Torvalds’ mainline tree directly. Most users consume kernels through Ubuntu, Fedora, Debian, Arch, openSUSE, Android-derived vendors, appliance builders, or enterprise distributions.The practical question is therefore not “is there a patch?” but “has my kernel vendor shipped the patched build?” Rolling-release users may receive the fix quickly as part of a normal kernel update. Enterprise and long-term-support users may wait for a scheduled advisory unless the vendor classifies the regression risk as urgent.
There is a subtle tension here. Wi-Fi driver patches can fix one class of instability while introducing another if they interact badly with firmware, power management, or vendor-specific quirks. That does not argue against updating; it argues for testing updates on representative hardware before a broad fleet rollout. A three-line bounds check is low-risk as patches go, but wireless stacks have earned their reputation for surprising administrators.
The good news is that this fix is conceptually conservative. It does not redesign the CLC parser or change policy. It simply refuses to consume a rule whose computed size exceeds the remaining buffer. That is the kind of defensive programming kernel drivers should have by default.
Windows Users Are Not the Target, but They Are Not Bystanders
For a WindowsForum audience, the obvious question is why a Linux kernel CVE deserves attention here. The immediate answer is that Windows itself is not affected by this specific mt76 Linux driver bug. Microsoft’s networking stack and MediaTek’s Windows driver are separate codebases.But Windows users increasingly live in mixed environments. Enthusiasts dual-boot. Developers run Linux bare metal for containers, drivers, and AI workloads. IT pros maintain Linux appliances alongside Windows endpoints. Even Windows-first households now have SteamOS handhelds, Proxmox boxes, Raspberry Pi-class devices, and Linux-based routers in the same network.
The hardware overlap also matters. The same MediaTek radio that behaves one way under Windows may behave differently under Linux after a reboot, suspend cycle, or firmware reset. Dual-boot users already know this pattern from fast startup issues, Bluetooth state weirdness, and PCIe power-management quirks. CVE-2026-46136 is not necessarily caused by Windows leaving hardware in a bad state, but it belongs to the wider class of bugs where a shared device’s behavior depends heavily on driver assumptions.
There is also a procurement lesson. Wi-Fi adapters are often treated as commodity parts, swapped silently across laptop revisions. For buyers who care about Linux compatibility, the exact wireless chipset remains one of the most important hidden specifications. Intel radios are not perfect, Realtek radios are not all bad, and MediaTek radios are not doomed, but the support history of the driver stack should be part of the buying decision.
The Security Label Does Useful Work Here
Some readers will object that this is “just a bug” dressed up as a CVE. That criticism is not entirely unfair. The Linux kernel CVE pipeline has broadened the number of driver defects receiving identifiers, and not every one of them deserves front-page panic.But the CVE label does useful work when it forces a reliability defect into patch-management systems. Without the identifier, this mt76 fix might disappear into a kernel changelog read only by wireless maintainers and distro packagers. With the identifier, asset owners can at least map it to affected kernels and hardware.
The risk is over-automation. A scanner may flag every Linux host as vulnerable because the kernel version falls into a broad range, even if the machine has no MediaTek Wi-Fi hardware and never loads
mt7921e. Conversely, a laptop fleet may look low priority because the CVSS field is blank. Both interpretations miss the point.The right model is conditional exposure. The bug matters when three things line up: an affected kernel, an MT7921-family device using the mt76 path, and CLC data that can trigger the underflow. Remove the hardware and the practical risk collapses. Keep the hardware and deploy at scale, and the risk becomes operationally meaningful.
This Is the Kind of Bug Defensive Parsing Is Supposed to Kill
The lesson for driver developers is old but still under-applied: every length field needs a skeptical reader. Hardware-adjacent code often receives structures from firmware or tables maintained outside the immediate source file. Those structures may be valid most of the time, but “most of the time” is not a kernel safety property.The fix pattern is also old. Before advancing a pointer, verify that the requested advance fits inside the remaining buffer. Before subtracting from a remaining length, verify that the subtraction cannot underflow. Before trusting a rule’s declared size, check it against the container that supposedly holds it.
What makes this bug modern is the radio-policy context. Wi-Fi 6E and 6 GHz operation made country, environment, and power rules more complicated. Devices increasingly need to distinguish bands, regulatory domains, indoor/outdoor assumptions, and access-point constraints. That complexity flows into driver tables, and driver tables become parser attack surfaces even when no attacker is in sight.
This is not an argument for freezing hardware features. It is an argument that every new regulatory feature should be treated like a new file format. If the driver parses it, the driver must survive malformed, unexpected, truncated, or future-shaped data.
What Administrators Should Do Before the Scanner Catches Up
The immediate action is straightforward: identify whether your Linux systems actually use the MediaTek MT7921 driver path, then track your distribution’s kernel updates. On a Linux machine, hardware inventory commands can show whether an MT7921-class PCIe or USB device is present, and loaded modules can confirm whethermt7921e, mt7921u, or related mt76 components are active.If you manage a fleet, do not wait for NVD scoring to decide whether to test the fix. Pick representative systems with the affected wireless hardware, update them to the vendor kernel that includes the stable patch, and verify cold boot, warm reboot, suspend/resume, and roaming behavior. Wireless regressions often hide in transitions rather than in a clean boot.
For individual users, the practical symptom to watch is not a security alert but Wi-Fi initialization failure. If a laptop with a MediaTek MT7921 adapter suddenly stops presenting wireless interfaces after a kernel update, or logs mt76/mt7921 errors during boot, this CVE’s fix is one of the things worth checking. It may not be the cause, but it is close enough to the symptom to belong on the shortlist.
For Windows-only users, there is no need to patch Windows for this specific CVE. The useful takeaway is hardware literacy. If you dual-boot, run Linux live media, or rely on recovery environments, your wireless card’s Linux driver support can matter even when Windows is your daily operating system.
The MT7921 Fix Is a Reminder to Inventory the Parts Nobody Puts on the Box
This CVE is unlikely to become a household name, but it is a good test of whether an organization’s vulnerability process can distinguish theoretical exposure from practical dependency. The affected code is specific, the known impact is availability-centered, and the fix is small; the operational consequences depend almost entirely on hardware, kernel branch, and update discipline.- CVE-2026-46136 affects the Linux kernel’s mt76 driver path for MediaTek MT7921-class Wi-Fi hardware, not the Windows driver stack.
- The known failure mode is a CLC buffer length underflow that can cause a near-infinite loop, invalid power-setting parsing, or Wi-Fi driver initialization failure.
- NVD had not assigned a CVSS score in the supplied record, so administrators should follow kernel and distribution patches rather than treating the blank score as reassurance.
- Systems without MT7921-family hardware are unlikely to face practical exposure, even if their kernel tree contains the affected source code.
- Laptop fleets, Linux workstations, dual-boot machines, and devices that depend on Wi-Fi at boot should prioritize testing kernels that include the stable fix.
- The patch is a defensive bounds check, which makes it the kind of low-drama update that should reduce risk without changing the driver’s intended behavior.
References
- Primary source: NVD / Linux Kernel
Published: 2026-05-29T01:06:14-07:00
NVD - CVE-2026-46136
nvd.nist.gov
- Security advisory: MSRC
Published: 2026-05-29T01:06:14-07:00
Original feed URL
Security Update Guide - Microsoft Security Response Center
msrc.microsoft.com
- Related coverage: wireless.docs.kernel.org
- Related coverage: kernel.googlesource.com
- Related coverage: lists.infradead.org
- Related coverage: codebrowser.dev
mcu.c source code [linux/drivers/net/wireless/mediatek/mt76/mt7921/mcu.c] - Codebrowser
Source code of linux/drivers/net/wireless/mediatek/mt76/mt7921/mcu.c linux v6.19-r on KDAB Codebrowser
codebrowser.dev
- Related coverage: spinics.net
[PATCH] wifi: mt76: mt7921: fix wrong power after multiple SAR set (Linux Wireless)
Linux Wireless: [PATCH] wifi: mt76: mt7921: fix wrong power after multiple SAR setwww.spinics.net - Related coverage: cocalc.com
- Related coverage: fcc.report
