MrBruh argues that AMD cannot disclaim responsibility for a vulnerability in a driver that AMD itself owns, signs, and distributes through its first-party Ryzen Master utility. He documents that PSIRT acknowledged the report but declined to fix, framing AMD's scope/exploitability rationale as an evasion rather than a legitimate technical disagreement.
The editorial situates the AMD driver alongside Capcom, MSI Afterburner, Intel diagnostic, and OEM 'PC health' drivers as a decade-long pattern of thinly-validated hardware-tuning shims accumulating on Microsoft's blocklist. The argument is that the bug class is mundane — what's notable is that a top-tier silicon vendor is now openly refusing to patch one.
The editorial credits the Windows Vulnerable Driver Blocklist as effective but structurally reactive: it only catches drivers after a researcher publishes and Microsoft ingests the hash. Because BYOVD has been industrialized by ransomware crews and EDR-evasion tooling, the disclosure-to-blocklist gap is precisely the window attackers exploit, making vendor non-fixes materially dangerous rather than academic.
Security researcher MrBruh published a second post in his AMD series — bluntly titled "The RCE that AMD wouldn't fix" — documenting a remote code execution chain rooted in a kernel driver that ships with AMD's Ryzen Master tuning utility. He reported it through AMD's PSIRT. AMD acknowledged the report, sat on it, and ultimately declined to ship a fix, citing the usual vendor framings around scope and exploitability. The researcher disclosed.
The bug is not theoretical: it is a signed, AMD-branded kernel driver with a writable interface that lets unprivileged code escalate and, chained with a browser or installer foothold, achieve remote code execution at ring 0. The driver is the same kind of thinly-validated hardware-tuning shim that the Windows ecosystem has been quietly drowning in for a decade — the family that produced the Capcom driver, the MSI Afterburner driver, the Intel diagnostic driver, and dozens of OEM "PC health" abominations now sitting on Microsoft's vulnerable-driver blocklist.
What makes this one notable is not the bug class. It's the response. AMD owns the driver, AMD signs the driver, AMD ships the driver in a first-party utility recommended on its own product pages — and AMD's position is that this is not their problem to fix.
The BYOVD (Bring Your Own Vulnerable Driver) attack pattern is no longer fringe. Ransomware crews, state actors, and EDR-evasion toolkits have spent the last three years industrializing the technique: drop a signed-but-broken driver, load it, use it to disable Defender or CrowdStrike, then own the box. Microsoft's response — the Vulnerable Driver Blocklist, shipped by default in Windows 11 and Server 2022 — is essentially a giant deny-list maintained from public disclosures like this one. The blocklist works. But it only works after a researcher publishes, Microsoft ingests, and the hash propagates. The gap between disclosure and blocklist update is exactly the window attackers want.
AMD's stance here is the part worth chewing on. The polite reading is that the vendor evaluated severity, decided local privilege escalation chained from a separate RCE primitive didn't clear their bar, and moved on. The less polite reading is that fixing kernel drivers is expensive, regression-testing them across the Ryzen Master matrix is more expensive, and the calculus of "researcher discloses, Microsoft blocklists, problem solved for us" is genuinely cheaper than engineering work. Either way the externality lands on you, the operator.
Compare this to how the industry's mature security organizations handle the same situation. Intel ships microcode advisories with CVEs and patched drivers on a quarterly cadence; NVIDIA's PSIRT publishes a bulletin and a new signed driver within weeks; even Realtek, mocked for years, now patches kernel drivers when researchers report them. AMD's silicon security team has done credible work on SEV-SNP and platform attestation. The Ryzen Master driver does not appear to live anywhere near that team's standards.
Community reaction on Hacker News (246 points) has been unusually pointed. The top comments are not the usual "researcher should have given more time" hand-wringing — they're operators noting that this is the second AMD utility-driver RCE the same researcher has published, and the first one followed the same arc. Pattern, not incident.
If you manage Windows endpoints, the playbook is short and unambiguous.
First: audit for the Ryzen Master driver (`AMDRyzenMasterDriver.sys`) across your fleet and uninstall it. Don't wait for the Microsoft blocklist update. Ryzen Master is a tuning tool — almost no production workload needs it installed, and the gaming-rig minority can re-install when they actually want to overclock. Sysinternals' `sigcheck` or a one-line PowerShell `Get-ChildItem -Recurse -Filter AMDRyzenMaster*.sys` will find it.
Second: turn on HVCI (Memory Integrity) and the Microsoft Vulnerable Driver Blocklist if you haven't already. Both are off-by-default on a lot of existing Win10 deployments and on-by-default for Win11 22H2+. HVCI breaks BYOVD by enforcing kernel code integrity; the blocklist is the belt to HVCI's suspenders. If you run WDAC, push a policy that explicitly denies the driver hash — your endpoint vendor's threat-intel feed almost certainly has it within the week.
Third, and this is the boring infrastructure point: treat OEM and silicon-vendor utilities as untrusted by default in your golden image. Dell SupportAssist, HP Support Assistant, Lenovo Vantage, Intel DSA, AMD Ryzen Master, NVIDIA GeForce Experience — every one of them has shipped a kernel-mode RCE in the last five years. None of them belong on a server, a developer laptop running prod credentials, or a CI runner. The convenience of "auto-update my GPU driver" is not worth ring-0 attack surface that the vendor may decline to maintain.
For security teams running EDR: confirm your product's BYOVD detection is actually enabled. Most EDRs ship the capability disabled because it generates false positives on legitimate hardware utilities. Now is a good time to flip the switch and accept the noise.
The broader story is that the signed-driver supply chain is structurally broken and nobody is incentivized to fix it. Microsoft signs based on attestation, not code review. Vendors ship drivers as a cost center, patch them as a cost center, and rationally underinvest in both. Researchers absorb the externality by disclosing for free. The blocklist accumulates like sediment. The honest fix is that Microsoft should require vendors to maintain a current security contact and a published patch SLA as a condition of WHQL signing — and revoke signatures from vendors who refuse. Until that happens, the operating procedure for every Windows shop is the same one MrBruh's post implies: assume the silicon vendor will not save you, and harden accordingly.
AMD will probably ship a quiet fix in the next Ryzen Master release once the embarrassment compounds. The driver will get blocklisted either way. The next AMD utility driver bug, when it lands, will follow the same script. Plan for it.
It's ridiculous to consider MITM attacks out of scope for taking over your computer. Also, there are probably ways to exploit this without a true MITM like DNS cache poisoning. But it's best to just assume the whole internet is MITMed.
This is a pretty common behavior that I've seen from bug bounty programs:> a blog post discussing this issue has already been published, which does not appear to be in accordance with the program’s terms.Companies reject bugs as out of scope and/or sit on them forever, then use the bug
AMD's inability to make good software has been a recurring problem for decades. Many years ago I had some success with their optimising compiler, but everything else I've touched was bad. A real pity.
The "signature verification" in the fix being CRC32 is pretty hilariously clueless.
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.
> Final update: A couple of days before the embargo ended (and after I wrote the majority of this blog post), AMD told me what their patch for this vulnerability is [...] Although it is true that they now fully use HTTPS, the claim about signature verification is untrue; they only perform a CRC-3