https://twitter.com/aionescu/status/1393955460517040129

> * AMD Zen "Summit Ridge" Stepping B1. That is Ryzen's 1xxx series.

> * AMD Zen2 "Matisse", "XT" series only. That is Ryzen's 3xxx series.

Other info at:

https://twitter.com/aionescu/status/1394039410300051456 https://twitter.com/aionescu/status/1394359314102427650 https://twitter.com/aionescu/status/1394359317038452738

Regardless, the vulnerability is in the driver, not the CPU / microcode. Also in the WHQL process that signed such a 'fake' driver. Until the signature is revoked, it might be possible for an attacker to manually install the signed driver on other system configurations too.

I tried to install the NtObjectManager module, but Bitdefender blocked it as Gen:Variant.Ursu.903319

> But even better, it has a security descriptor allowing Everyone + Low IL R/W Access, and an IOCTL interface with absolutely no Probes/SEH, which yes, dereferences wild pointers. They don't even bother checking for input size or output sizes.

If that's true of the driver, then it's a sec vuln regardless of what the MSR bit does or doesn't do, no?

Absolutely a security vulnerability, and while I havent reproduced on my own and am just going off what I read on the original Twitter thread (so it's possible I could be regurgitating bad info), my understanding is that it gives processes this access by listening to process creation and hashing the name. Meaning if I have a known hash from the list I can simply rename my program / malware and bam.