CVE-2026-43398 is a newly published Linux kernel vulnerability, disclosed by kernel.org and listed by NVD on May 8, 2026, involving the AMDGPU driver’s user queue wait ioctl path, where oversized user-supplied values could trigger out-of-memory conditions. The fix is not glamorous: it adds an upper bound check. That is precisely why the bug matters. Modern graphics drivers are no longer peripheral plumbing; they are privileged, memory-hungry subsystems sitting at the intersection of desktop responsiveness, GPU compute, virtualization, and cloud workloads.
The core of CVE-2026-43398 is almost banal. In
That is the kind of change security teams love and hate in equal measure. It is easy to explain after the fact, but it also raises the obvious question: why was untrusted input allowed to steer memory pressure so directly in the first place? In kernel space, “just an OOM” is rarely just an OOM. Availability is a security property when the target is a workstation, a build host, a GPU compute node, or a virtual desktop server.
For WindowsForum readers, the immediate caveat is important. This is a Linux kernel AMDGPU issue, not a Windows display driver bulletin. It does not mean Radeon users on Windows should panic, and it does not imply a Microsoft Windows kernel flaw. But its appearance in Microsoft’s Security Update Guide is still notable because Microsoft now ships and operates a broad Linux estate: Azure hosts Linux workloads, Microsoft maintains Linux distributions and container bases, and WSL has made Linux kernel behavior relevant to many Windows-first shops.
The old boundary between “Windows security” and “Linux security” has become porous. An enterprise that runs Windows endpoints, Azure Linux instances, container hosts, GPU-backed AI workloads, and developer WSL environments does not get to treat kernel.org advisories as somebody else’s weather.
An ioctl is a deliberately flexible mechanism. It lets user-space programs issue device-specific commands to kernel drivers, which is exactly what makes it powerful and exactly what makes it dangerous. A driver must assume that every integer, pointer, count, and length handed to it may be malicious, malformed, or simply absurd.
CVE-2026-43398 sits in that uncomfortable zone where a system call path is doing something legitimate until the input size stops being legitimate. Waiting on GPU user queue handles is not exotic behavior. The problem is that huge values can turn a normal operation into a memory exhaustion event.
That distinction matters for defenders because many vulnerability management tools still train people to think first in terms of code execution. Remote code execution gets the sirens. Privilege escalation gets the red banner. Denial-of-service bugs, especially local ones, get a shrug. But a local user or compromised workload that can reliably destabilize a GPU-backed system may be able to knock over shared compute, interrupt rendering sessions, break CI jobs, or cause cascading service disruption.
In 2026, GPU availability is business availability. The organizations buying racks of accelerator-backed infrastructure for AI, visualization, simulation, transcoding, and remote desktops already know this. The vulnerability database is simply catching up.
This is becoming a recurring operational problem. NVD has been changing how it prioritizes enrichment amid a sustained rise in CVE volume, and raw CVE records increasingly arrive before the familiar stack of CVSS, CWE, CPE matching, and product applicability data is complete. Vulnerability managers who wait for the score before making a decision are now waiting for a data pipeline, not necessarily for security truth.
The user-provided record reflects that ambiguity. CVSS 4.0, 3.x, and 2.0 are all listed without a NVD assessment. Weakness enumeration is not filled in. The change history shows the CVE was newly received from kernel.org on May 8, 2026, along with references to stable kernel commits.
That leaves administrators with a more manual question: do we run affected kernels with AMDGPU enabled in places where an untrusted or semi-trusted local user can hit this ioctl path? If the answer is yes, the lack of a CVSS score should not delay testing and scheduling the kernel update.
The industry spent years automating vulnerability triage around scores. CVE-2026-43398 is a reminder that the first public version of a modern CVE record may be more like a police blotter entry than a finished case file.
That distinction is easy to lose in patch-management dashboards. A CVE appears under an MSRC URL, the word “Microsoft” appears in the workflow, and suddenly a Linux kernel AMDGPU issue looks like a Windows Update concern. It is not. The affected code is in the Linux kernel’s AMDGPU driver, and the remediation path is through the relevant Linux kernel or vendor-maintained package stream.
But Microsoft’s ecosystem now includes too many Linux touchpoints to ignore the advisory. Azure images, Azure Kubernetes nodes, Azure Linux, Defender telemetry, container workloads, GPU-backed Linux VMs, and WSL-based developer environments all make Linux kernel exposure part of ordinary Microsoft customer operations. The security boundary is less about the logo on the desktop and more about where the vulnerable code actually runs.
For sysadmins, that means the right question is not “Is this a Windows CVE?” The right question is “Where do I run Linux kernels with AMDGPU support, and who can reach the vulnerable interface?”
That may include developer workstations booting Linux, dual-boot enthusiasts, lab machines, SteamOS-like gaming systems, GPU passthrough hosts, cloud VMs with AMD GPUs, or specialized media and compute boxes. In most home Windows environments, the answer will be “nowhere.” In mixed enterprise estates, the answer may be more interesting.
A limit that is too low would cause real applications to fail. A limit that is too high would blunt the protection. The art is not merely adding a check; it is choosing a value that distinguishes abusive input from real GPU synchronization behavior.
The patch also notes that a follow-up fix was squashed in and that the change was cherry-picked from an upstream commit. That is standard kernel-stable choreography, but it matters operationally because not every distribution kernel maps neatly to upstream version numbers. Enterprise Linux vendors, cloud kernels, and long-term support branches routinely backport fixes without rebasing wholesale.
That is why administrators should avoid the common trap of asking only, “What kernel version fixed this?” The better question is whether your vendor’s kernel package includes one of the relevant stable fixes or an equivalent backport. A system may report an older-looking kernel version and still contain the patch.
For enthusiasts compiling their own kernels, the path is more direct: check the stable branch or distribution patchset. For everyone else, the answer should come from the distro’s security advisory, package changelog, or cloud image release notes.
A local OOM condition can be a lever. On a multi-user GPU workstation, it can disrupt other sessions. On a research server, it can kill long-running jobs. On a remote desktop host, it can collapse user productivity. On a containerized or virtualized compute node, the blast radius depends on device exposure, cgroup limits, kernel configuration, and how GPU access is delegated.
The AMDGPU path is especially interesting because GPU device access is often granted to users or workloads that are not otherwise privileged. A rendering tool, compute job, game, browser acceleration process, machine-learning notebook, or media pipeline may have legitimate reason to talk to the graphics stack. That broad usability is why drivers need careful validation at the edge.
This is not an argument that CVE-2026-43398 is a catastrophic bug. The public description does not establish remote exploitability, privilege escalation, or data disclosure. It describes a memory-exhaustion condition caused by huge user inputs. But availability bugs in kernel drivers deserve a higher baseline of respect than they often receive.
If a vulnerable path can be exercised by a normal local user, the practical severity depends heavily on the environment. A single-user gaming desktop is one thing. A shared GPU host is another. A production node carrying customer workloads is another again.
That boundary is where many mature security bugs live. Counts must be checked. Arrays must be bounded. References must be dropped correctly on error paths. Output buffer sizes must be validated before the kernel writes to them. Synchronization objects must not leak. These are not glamorous classes of vulnerability, but they are the daily grind of securing a high-performance kernel subsystem.
CVE-2026-43398 also appears alongside a broader pattern of recent AMDGPU user queue fixes. Nearby public discussions and records have referenced issues in the same general ioctl area, including reference handling and warning-triggering behavior. That does not mean one bug proves the existence of a systemic disaster. It does suggest the code is active, evolving, and receiving scrutiny.
For Linux users, active scrutiny is good news. Kernel graphics drivers are complex enough that bugs are inevitable; the question is whether they are found, fixed, backported, and deployed. In this case, the fix has landed in stable commit references, and the CVE record is public.
For administrators, the risk is the gap between those facts and the machine in the rack. Upstream fixed does not mean locally patched.
WSL is the obvious example, although its exposure depends on configuration and kernel support. A typical WSL environment on a Windows laptop is not the same as a bare-metal Linux desktop running AMDGPU as its primary graphics driver. But WSL has trained Windows users to treat Linux as an app-like layer, and that can create sloppy assumptions about patching.
Azure is the more consequential example. Cloud administrators may manage GPU-backed Linux workloads through Microsoft portals, Microsoft billing, Microsoft identity, and Microsoft monitoring. Yet the guest kernel, driver stack, image lineage, and vendor patch cadence still matter. A CVE can be “in Microsoft’s guide” because it is relevant to Microsoft customers without being remediated by a familiar cumulative update.
This is the central lesson for mixed estates: branding does not define exposure. Code path does. If your vulnerable component is an upstream Linux kernel driver, your remediation process must follow the Linux distribution, kernel branch, cloud image, or appliance vendor that actually supplies that driver.
Security teams should use the MSRC entry as a routing clue, not as a substitute for asset intelligence. The inventory question comes first. Patch orchestration comes second. Dashboard closure comes last.
The highest-priority systems are not necessarily the ones with the most expensive GPUs. They are the ones where untrusted or semi-trusted users can access the vulnerable driver path and where availability matters. Shared Linux desktops in engineering labs, GPU compute nodes, render farms, university clusters, CI systems with graphics acceleration, and multi-tenant development hosts all deserve a closer look.
Consumer Linux desktops with AMD GPUs should patch too, but the practical urgency is different. If only the machine’s owner can trigger the issue, the risk is mostly self-inflicted disruption or post-compromise annoyance. Still, local denial-of-service bugs can be useful to malware, prank tools, or low-privilege footholds that want to degrade recovery and monitoring.
The subtler cases are virtualized environments. GPU passthrough, mediated devices, container GPU access, and accelerated desktop sessions all complicate the clean line between host and guest. Administrators should verify not just whether AMD hardware is present, but whether the vulnerable AMDGPU code is loaded and reachable from user-controlled workloads.
A good vulnerability scanner may eventually answer that. On day one of a sparse CVE record, it may not. That is where sysadmin knowledge still beats dashboard confidence.
The most concrete reading is simple: a kernel driver accepted user inputs that could be made unreasonably large, and the fix adds a maximum. The most useful reading is broader: GPU driver ioctls are privileged kernel interfaces, and any place that grants broad user or workload access to them should be treated as a meaningful attack surface.
The lack of NVD enrichment should be treated as a workflow condition, not a risk conclusion. In the current CVE ecosystem, raw records often appear before full metadata. Waiting for a score may be acceptable for low-exposure assets, but it is not a sound policy for shared GPU infrastructure.
The Microsoft wrinkle should also be handled carefully. MSRC visibility is a sign that Microsoft customers may need to care, not proof that Windows itself is affected. That nuance matters because misunderstanding it can waste effort in one direction and miss real Linux exposure in another.
Source: NVD / Linux Kernel Security Update Guide - Microsoft Security Response Center
A Small Bounds Check Exposes a Large Trust Problem
The core of CVE-2026-43398 is almost banal. In amdgpu_userq_wait_ioctl, user-controlled input could be large enough to force excessive allocation and potentially drive the system into an out-of-memory state. The kernel fix checks those values against AMDGPU_USERQ_MAX_HANDLES, a limit intended to be high enough for legitimate workloads while blocking pathological ones.That is the kind of change security teams love and hate in equal measure. It is easy to explain after the fact, but it also raises the obvious question: why was untrusted input allowed to steer memory pressure so directly in the first place? In kernel space, “just an OOM” is rarely just an OOM. Availability is a security property when the target is a workstation, a build host, a GPU compute node, or a virtual desktop server.
For WindowsForum readers, the immediate caveat is important. This is a Linux kernel AMDGPU issue, not a Windows display driver bulletin. It does not mean Radeon users on Windows should panic, and it does not imply a Microsoft Windows kernel flaw. But its appearance in Microsoft’s Security Update Guide is still notable because Microsoft now ships and operates a broad Linux estate: Azure hosts Linux workloads, Microsoft maintains Linux distributions and container bases, and WSL has made Linux kernel behavior relevant to many Windows-first shops.
The old boundary between “Windows security” and “Linux security” has become porous. An enterprise that runs Windows endpoints, Azure Linux instances, container hosts, GPU-backed AI workloads, and developer WSL environments does not get to treat kernel.org advisories as somebody else’s weather.
The GPU Driver Has Become Kernel Attack Surface, Not Display Furniture
Graphics drivers used to be discussed as the code that made your monitor light up and your games run faster. That mental model is badly out of date. The AMDGPU driver is part of Linux’s Direct Rendering Manager stack, and its ioctl interfaces are the front door through which user space asks the kernel to coordinate GPU resources, synchronization, queues, fences, buffers, and execution state.An ioctl is a deliberately flexible mechanism. It lets user-space programs issue device-specific commands to kernel drivers, which is exactly what makes it powerful and exactly what makes it dangerous. A driver must assume that every integer, pointer, count, and length handed to it may be malicious, malformed, or simply absurd.
CVE-2026-43398 sits in that uncomfortable zone where a system call path is doing something legitimate until the input size stops being legitimate. Waiting on GPU user queue handles is not exotic behavior. The problem is that huge values can turn a normal operation into a memory exhaustion event.
That distinction matters for defenders because many vulnerability management tools still train people to think first in terms of code execution. Remote code execution gets the sirens. Privilege escalation gets the red banner. Denial-of-service bugs, especially local ones, get a shrug. But a local user or compromised workload that can reliably destabilize a GPU-backed system may be able to knock over shared compute, interrupt rendering sessions, break CI jobs, or cause cascading service disruption.
In 2026, GPU availability is business availability. The organizations buying racks of accelerator-backed infrastructure for AI, visualization, simulation, transcoding, and remote desktops already know this. The vulnerability database is simply catching up.
The Absence of a Score Is Not the Absence of Risk
At publication, the NVD entry for CVE-2026-43398 had no NIST CVSS score. That should not be misread as a judgment that the bug is harmless. It means NVD had not yet completed enrichment for the record.This is becoming a recurring operational problem. NVD has been changing how it prioritizes enrichment amid a sustained rise in CVE volume, and raw CVE records increasingly arrive before the familiar stack of CVSS, CWE, CPE matching, and product applicability data is complete. Vulnerability managers who wait for the score before making a decision are now waiting for a data pipeline, not necessarily for security truth.
The user-provided record reflects that ambiguity. CVSS 4.0, 3.x, and 2.0 are all listed without a NVD assessment. Weakness enumeration is not filled in. The change history shows the CVE was newly received from kernel.org on May 8, 2026, along with references to stable kernel commits.
That leaves administrators with a more manual question: do we run affected kernels with AMDGPU enabled in places where an untrusted or semi-trusted local user can hit this ioctl path? If the answer is yes, the lack of a CVSS score should not delay testing and scheduling the kernel update.
The industry spent years automating vulnerability triage around scores. CVE-2026-43398 is a reminder that the first public version of a modern CVE record may be more like a police blotter entry than a finished case file.
Microsoft’s Presence Is a Signal About Linux in the Windows Estate
The MSRC link in the submitted material is the detail that makes this more than a narrow Linux graphics-driver note for a WindowsForum audience. Microsoft’s Security Update Guide has, for years, included CVEs assigned by industry partners when open-source components are bundled in Microsoft products or otherwise relevant to Microsoft customers. That does not transform every upstream Linux kernel CVE into a Windows flaw, but it does make it part of the Microsoft security conversation.That distinction is easy to lose in patch-management dashboards. A CVE appears under an MSRC URL, the word “Microsoft” appears in the workflow, and suddenly a Linux kernel AMDGPU issue looks like a Windows Update concern. It is not. The affected code is in the Linux kernel’s AMDGPU driver, and the remediation path is through the relevant Linux kernel or vendor-maintained package stream.
But Microsoft’s ecosystem now includes too many Linux touchpoints to ignore the advisory. Azure images, Azure Kubernetes nodes, Azure Linux, Defender telemetry, container workloads, GPU-backed Linux VMs, and WSL-based developer environments all make Linux kernel exposure part of ordinary Microsoft customer operations. The security boundary is less about the logo on the desktop and more about where the vulnerable code actually runs.
For sysadmins, that means the right question is not “Is this a Windows CVE?” The right question is “Where do I run Linux kernels with AMDGPU support, and who can reach the vulnerable interface?”
That may include developer workstations booting Linux, dual-boot enthusiasts, lab machines, SteamOS-like gaming systems, GPU passthrough hosts, cloud VMs with AMD GPUs, or specialized media and compute boxes. In most home Windows environments, the answer will be “nowhere.” In mixed enterprise estates, the answer may be more interesting.
The Patch Is Boring in the Best Possible Way
The fix described in the CVE is a classic kernel hardening move: set a sane maximum and reject input that exceeds it. In this case, the maximum isAMDGPU_USERQ_MAX_HANDLES, described as large enough for genuine use cases. That phrasing matters because security fixes in performance-sensitive driver paths always carry the risk of breaking unusual but legitimate workloads.A limit that is too low would cause real applications to fail. A limit that is too high would blunt the protection. The art is not merely adding a check; it is choosing a value that distinguishes abusive input from real GPU synchronization behavior.
The patch also notes that a follow-up fix was squashed in and that the change was cherry-picked from an upstream commit. That is standard kernel-stable choreography, but it matters operationally because not every distribution kernel maps neatly to upstream version numbers. Enterprise Linux vendors, cloud kernels, and long-term support branches routinely backport fixes without rebasing wholesale.
That is why administrators should avoid the common trap of asking only, “What kernel version fixed this?” The better question is whether your vendor’s kernel package includes one of the relevant stable fixes or an equivalent backport. A system may report an older-looking kernel version and still contain the patch.
For enthusiasts compiling their own kernels, the path is more direct: check the stable branch or distribution patchset. For everyone else, the answer should come from the distro’s security advisory, package changelog, or cloud image release notes.
Denial of Service Is Underrated Until the Box Is Shared
Security culture still undervalues denial-of-service bugs on local interfaces. That bias comes from an earlier computing model where a local attacker was already assumed to have “won enough,” and where rebooting a personal machine was an annoyance rather than an outage. Shared infrastructure has made that model stale.A local OOM condition can be a lever. On a multi-user GPU workstation, it can disrupt other sessions. On a research server, it can kill long-running jobs. On a remote desktop host, it can collapse user productivity. On a containerized or virtualized compute node, the blast radius depends on device exposure, cgroup limits, kernel configuration, and how GPU access is delegated.
The AMDGPU path is especially interesting because GPU device access is often granted to users or workloads that are not otherwise privileged. A rendering tool, compute job, game, browser acceleration process, machine-learning notebook, or media pipeline may have legitimate reason to talk to the graphics stack. That broad usability is why drivers need careful validation at the edge.
This is not an argument that CVE-2026-43398 is a catastrophic bug. The public description does not establish remote exploitability, privilege escalation, or data disclosure. It describes a memory-exhaustion condition caused by huge user inputs. But availability bugs in kernel drivers deserve a higher baseline of respect than they often receive.
If a vulnerable path can be exercised by a normal local user, the practical severity depends heavily on the environment. A single-user gaming desktop is one thing. A shared GPU host is another. A production node carrying customer workloads is another again.
AMDGPU’s User Queue Work Shows the Price of Modern Performance
The vulnerability lands in the context of AMDGPU user queue work, a part of the driver architecture meant to reduce overhead and improve how user space coordinates GPU execution. Like much of the modern graphics stack, it is built for performance, concurrency, and lower-latency control. Those goals push complexity toward the boundary between applications and the kernel.That boundary is where many mature security bugs live. Counts must be checked. Arrays must be bounded. References must be dropped correctly on error paths. Output buffer sizes must be validated before the kernel writes to them. Synchronization objects must not leak. These are not glamorous classes of vulnerability, but they are the daily grind of securing a high-performance kernel subsystem.
CVE-2026-43398 also appears alongside a broader pattern of recent AMDGPU user queue fixes. Nearby public discussions and records have referenced issues in the same general ioctl area, including reference handling and warning-triggering behavior. That does not mean one bug proves the existence of a systemic disaster. It does suggest the code is active, evolving, and receiving scrutiny.
For Linux users, active scrutiny is good news. Kernel graphics drivers are complex enough that bugs are inevitable; the question is whether they are found, fixed, backported, and deployed. In this case, the fix has landed in stable commit references, and the CVE record is public.
For administrators, the risk is the gap between those facts and the machine in the rack. Upstream fixed does not mean locally patched.
The Windows Angle Is WSL, Azure, and the End of Single-Platform Thinking
Most Windows users will never touchamdgpu_userq_wait_ioctl. Native Windows graphics drivers live in a different driver model, and Windows Update is not going to patch a Linux kernel module sitting in a distribution you installed outside Microsoft’s update path. That said, the Windows ecosystem increasingly contains Linux execution contexts that users forget are real operating systems.WSL is the obvious example, although its exposure depends on configuration and kernel support. A typical WSL environment on a Windows laptop is not the same as a bare-metal Linux desktop running AMDGPU as its primary graphics driver. But WSL has trained Windows users to treat Linux as an app-like layer, and that can create sloppy assumptions about patching.
Azure is the more consequential example. Cloud administrators may manage GPU-backed Linux workloads through Microsoft portals, Microsoft billing, Microsoft identity, and Microsoft monitoring. Yet the guest kernel, driver stack, image lineage, and vendor patch cadence still matter. A CVE can be “in Microsoft’s guide” because it is relevant to Microsoft customers without being remediated by a familiar cumulative update.
This is the central lesson for mixed estates: branding does not define exposure. Code path does. If your vulnerable component is an upstream Linux kernel driver, your remediation process must follow the Linux distribution, kernel branch, cloud image, or appliance vendor that actually supplies that driver.
Security teams should use the MSRC entry as a routing clue, not as a substitute for asset intelligence. The inventory question comes first. Patch orchestration comes second. Dashboard closure comes last.
The Hard Part Is Finding the Machines That Matter
For a vulnerability like this, the remediation advice “update your kernel” is both correct and insufficient. The real work is figuring out which systems are worth urgent attention.The highest-priority systems are not necessarily the ones with the most expensive GPUs. They are the ones where untrusted or semi-trusted users can access the vulnerable driver path and where availability matters. Shared Linux desktops in engineering labs, GPU compute nodes, render farms, university clusters, CI systems with graphics acceleration, and multi-tenant development hosts all deserve a closer look.
Consumer Linux desktops with AMD GPUs should patch too, but the practical urgency is different. If only the machine’s owner can trigger the issue, the risk is mostly self-inflicted disruption or post-compromise annoyance. Still, local denial-of-service bugs can be useful to malware, prank tools, or low-privilege footholds that want to degrade recovery and monitoring.
The subtler cases are virtualized environments. GPU passthrough, mediated devices, container GPU access, and accelerated desktop sessions all complicate the clean line between host and guest. Administrators should verify not just whether AMD hardware is present, but whether the vulnerable AMDGPU code is loaded and reachable from user-controlled workloads.
A good vulnerability scanner may eventually answer that. On day one of a sparse CVE record, it may not. That is where sysadmin knowledge still beats dashboard confidence.
This CVE Rewards the Shops That Patch by Exposure, Not by Panic
CVE-2026-43398 is not the kind of bug that should send every WindowsForum reader scrambling. It is, however, the kind of bug that separates mature patch operations from score-chasing ones. The public record says enough to justify action on exposed Linux AMDGPU systems, even while leaving enough unsaid to make blanket panic irresponsible.The most concrete reading is simple: a kernel driver accepted user inputs that could be made unreasonably large, and the fix adds a maximum. The most useful reading is broader: GPU driver ioctls are privileged kernel interfaces, and any place that grants broad user or workload access to them should be treated as a meaningful attack surface.
The lack of NVD enrichment should be treated as a workflow condition, not a risk conclusion. In the current CVE ecosystem, raw records often appear before full metadata. Waiting for a score may be acceptable for low-exposure assets, but it is not a sound policy for shared GPU infrastructure.
The Microsoft wrinkle should also be handled carefully. MSRC visibility is a sign that Microsoft customers may need to care, not proof that Windows itself is affected. That nuance matters because misunderstanding it can waste effort in one direction and miss real Linux exposure in another.
The Practical Reading for WindowsForum’s Mixed Estates
The useful response is not dramatic, but it is disciplined. Organizations should treat CVE-2026-43398 as a targeted Linux kernel maintenance item with special attention to AMDGPU-equipped systems that are shared, remote, or workload-bearing.- Identify Linux systems that load the AMDGPU driver, especially shared workstations, GPU compute hosts, render nodes, and cloud VMs with AMD graphics acceleration.
- Check distribution and cloud vendor advisories rather than relying only on upstream kernel version numbers, because stable fixes are often backported.
- Prioritize systems where non-admin users, containers, notebooks, or remote sessions can access GPU device interfaces.
- Do not assume the absence of an NVD CVSS score means the vulnerability is low risk or irrelevant.
- Do not treat the MSRC listing as a Windows driver issue; treat it as a signal to inspect Microsoft-adjacent Linux assets.
- Schedule kernel updates with reboot planning, because driver fixes of this class usually do not become effective until the patched kernel is running.
Source: NVD / Linux Kernel Security Update Guide - Microsoft Security Response Center
