** Sigh **
This is what happens when you develop an operating system that purports to work "the same" across multiple architectures: It doesn't.
By looking at the code for both the bug and the exploit, they each appear to be heavily x86-32/x86-64 dependent.
I would venture that there is a high degree of probability that this bug/exploit combination does not exist, for example, in versions of the Linux kernel developed and compiled for IBM's midrange (AS/400 / System i / System p) and mainframe (S/390 / System z) iron, in versions of the kernel developed to work on Cell-based parallel processing systems, or in versions compiled against SPARC machines.
This leads me to believe that it is perhaps the x86-32/x86-64 architecture that is at fault, at some lower level, for not properly securing access to 32-bit facilities provided by 64-bit processors. This kind of bug could **conceivably** be used to compromise Linux-based x86 hypervisors, by allowing an intruder to context-switch out of the virtual machine and into the host OS.
Granted, the fact that a regression of this magnitude was re-introduced into the Linux kernel is regrettable, but it isn't difficult to understand how such a mistake can be made, given the kernel's rather heterogeneous target audience. No one person, or group of persons, can be an expert on all of the different processor architectures supported by the Linux kernel.