Native Client (NaCl), part 1

Bennet Yee, David Sehr, Gregory Dardyk, J. Bradley Chen, Robert Muth, Tavis Ormandy, Shiki Okasaka, Neha Narula, and Nicholas Fullagar. “Native Client: A sandbox for portable, untrusted x86 native code”. In IEEE Symposium on Security and Privacy “Oakland”, pages 79–93, Oakland, CA, USA, May 2009.
[IEEE]

David Sehr, Robert Muth, Cliff Biffle, Victor Khimenko, Egor Pasko, Karl Schimpf, Bennet Yee, and Brad Chen. “Adapting software fault isolation to contemporary CPU architectures”. In USENIX Security Symposium, pages 1–12, Washington, DC, USA, August 2010.
[USENIX]

Question: A modern CPU is a complex designed artifact just like a large program, and like software, hardware often has bugs (though they're more often called "errata"). In the first NaCl paper they mention that during testing they ran into combinations of instruction prefixes that seemed to cause the processor to hang; if such instructions were allowed by Native Client, users would be vulnerable to a denial-of-service attack. But that's not the worst possibility. Can you think of a plausible hardware bug (one that might occur by accident as a design mistake, not something inserted deliberately) that could allow malicious code running under Native Client to escape the (inner) sandbox?