this POC was designed on an extremely out of date LTS kernel (6.1.45), on a custom kernel config, and on a custom build toolchain.

The longer a thread holds a lock, the greater the risk that the thread will be interrupted by the OS scheduler while holding the lock. If this happens, other threads will be left "spinning" (repeatedly trying to acquire the lock), while the thread holding the lock is not making progress towards releasing it.
The result is an indefinite postponement until the thread holding the lock can finish and release it. This is especially true on a single-processor system, where each waiting thread of the same priority is likely to waste its quantum (allocated time where a thread can run) spinning until the thread that holds the lock is finally finished.

Implementing spinlocks correctly is challenging because programmers must take into account the possibility of simultaneous access to the lock, which could cause race conditions. Generally, such an implementation is possible only with special assembly language instructions, such as atomic (i.e. un-interruptible) test-and-set operations and cannot be easily implemented in programming languages not supporting truly atomic operations.

Pixnapping is a new class of attacks that allows a malicious Android app to stealthily leak information displayed by other Android apps or arbitrary websites. Pixnapping exploits Android APIs and a hardware side channel that affects nearly all modern Android devices. We have demonstrated Pixnapping attacks on Google and Samsung phones and end-to-end recovery of sensitive data from websites including Gmail and Google Accounts and apps including Signal, Google Authenticator, Venmo, and Google Maps. Notably, our attack against Google Authenticator allows any malicious app to steal 2FA codes in under 30 seconds while hiding the attack from the user.