Linux Lands Fix For AMD Zen 1 Bug That Could Leak Data After A Division By Zero

[phoronix]

Phoronix: Linux Lands Fix For AMD Zen 1 Bug That Could Leak Data After A Division By Zero

After a rather busy Patch Tuesday with the AMD Inception vulnerability and Intel Downfall going public, the Linux kernel saw a new bug fix merged today for a different issue... It turns out original AMD Zen 1 processors could end up leaking data in certain conditions after a divide by zero occurs...

https://www.phoronix.com/news/AMD-Zen1-Divide-By-Zero-Bug

[andyprough]

Steve Jobs, revisited: "You're doing your maths wrong - stop dividing by zero. Divide by something sensible, like 2. Or 10."

[Vorpal]

I'm having a hard time imaging this is a practical leak... Programs generally don't divide by zero, as that causes a fault (segmentation or bus? forget which). So, in practice there wont be any programs to spy on that does this.

There also won't be any measurable performance impact from the fix, because again: well behaved programs don't do this.

Floating point division by zero is far more common, mainly because it doesn't cause an immediate fault, instead returning inf/-inf/nan (depending on the dividend). But this bug doesn't concern floats.

[Jumbotron]

So, I guess this would be the opposite of The Fixx's "Saved By Zero"?

[Michael]

I'm having a hard time imaging this is a practical leak... Programs generally don't divide by zero, as that causes a fault (segmentation or bus? forget which). So, in practice there wont be any programs to spy on that does this.

There also won't be any measurable performance impact from the fix, because again: well behaved programs don't do this.

Floating point division by zero is far more common, mainly because it doesn't cause an immediate fault, instead returning inf/-inf/nan (depending on the dividend). But this bug doesn't concern floats.

I'm guessing the actual attack vector is rogue software causing a divide by zero and hoping to get data before that point... Or from the sibling thread as the patch does note SMT disabling is needed for full coverage. But again not too clear based on the initial data. I haven't found any other mentions of this bug yet. At least though is significant enough to warrant this kernel patch all these years later for Zen 1.

[sophisticles]

This seems like another one of those "vulnerabilities" that "researchers" looking to earn a bounty reward for finding a "bug" dreamed up.

I would love to see a video of a proof-of-concept application of this attack vector.

[npwx]

This seems like another one of those "vulnerabilities" that "researchers" looking to earn a bounty reward for finding a "bug" dreamed up.

I would love to see a video of a proof-of-concept application of this attack vector.

Why so negative? It's obviously a bug in the CPU, so why not fix it.

[molletts]

I'm having a hard time imaging this is a practical leak... Programs generally don't divide by zero, as that causes a fault (segmentation or bus? forget which). So, in practice there wont be any programs to spy on that does this.

As I read it (and I may be wrong), it's not the "victim" that has to divide by zero, it's the attacker. The supposedly-undefined result of dividing by zero that the attacker gets back after the fault has been caught by the OS just happens to contain information left over from the last successful division, performed by the victim. The mitigation simply carries out a successful, valid division in the fault handler in order to overwrite this stale result.

[uxmkt]

Programs generally don't divide by zero, as that causes a fault (segmentation [SIGSEGV] or bus [SIGBUS]? forget which)

Obviously, arithmetic is neither related to segments nor the address bus. So SIGFPE (Arithmetic exception).

[Vorpal]

As I read it (and I may be wrong), it's not the "victim" that has to divide by zero, it's the attacker. The supposedly-undefined result of dividing by zero that the attacker gets back after the fault has been caught by the OS just happens to contain information left over from the last successful division, performed by the victim. The mitigation simply carries out a successful, valid division in the fault handler in order to overwrite this stale result.

That would make a lot more sense, and be a larger issue if true. Thankfully the workaround is simple enough, and not on a performance critical path at all. So regardless, let's just fix it and move on with our lives.