Having grokked the abstract, I feel like can speculate a bit as to what is going on. Take this with a grain of salt; I have no clue what has actually been disco

Having grokked the abstract, I feel like can speculate a bit as to what is going on. Take this with a grain of salt; I have no clue what has actually been discovered. I believe that the researchers have found a way to remove PAC as a barrier to exploitation by disclosing PAC verification results via speculative execution. This is only useful to attackers going after a target that uses PAC, and those attackers will need to have another vulnerability that enables them to hijack control-flow through modifying pointers to code that are located in memory. The attackers can use this new Pacman vulnerability as a crash-free oracle that says whether their forged pointer worked, and once they find a working one, they can use that to hijack control flow. PAC (or Pointer Authentication) is a security feature found in recent iPhones, the Apple Silicon Macs, and the Graviton3. It is intended as a defense against control-flow hijacks. It works by signing pointers found in memory with one of five keys that are known only to the processor. Before the pointer is used, the processor should be instructed to "authenticate" the pointer by checking the pointer's signature using its private keys. To prevent simple reuse of one authenticated pointer used in one place to a pointer used in another place in the program, code can provide a "context" value to be used during the authentication. A great resource for learning about PAC and its usage in the Apple platforms is at [1] (it links to other resources) and if you want to play with a PAC enabled binary, check out [2] [1]: https://googleprojectzero.blogspot.com/2019/02/examining-pointer-authentication-on.html?m=1 https://googleprojectzero.blogspot.com/2019/02/examining-poi... [2]: https://blog.ret2.io/2021/06/16/intro-to-pac-arm64/ https://blog.ret2.io/2021/06/16/intro-to-pac-arm64/ EDIT: The attack works by: 1) Place your guess such that it is used as the pointer input to an authentication instruction 2) Causing a branch misprediction. On the not-taken side of the branch, code needs to perform a pointer authentication and usage of the pointer. On the taken side of the branch, code should not crash. 3) CPU speculatively executes down the not-taken side of the branch (misprediction) and speculatively executes the authentication instruction. 4) If your guess is correct, the authentication instruction will return a valid pointer. If your guess is incorrect, the authentication instruction returns a pointer that, if dereferenced, will cause an exception. 5) CPU speculatively executes a load (in the case of a data pointer) or an instruction fetch (in the case of a code pointer) on the pointer value. 6) If the pointer is valid, the address translation for that pointer will appear in the TLB. If the pointer is not valid, it will not (because of the exception). 7) All of the effects from this mispredicted branch get squashed when the CPU realizes that the branch is not taken. No exception is actually thrown! 8) Measure the TLB entries to determine whether the speculative address translation made it in. If it is present, you know that the guess is correct. 9) Repeat, up to 2^16 times.