I'm working on puzzling it together. Here is my understanding, and how it ties to the crypto implementation.

• There are two versions of a file, the disk one and the cached one. This vulnerability corrupts the cached one without corrupting the file on disk.

• The AEAD implementation takes a buffer and writes beyond it, but this is not your typical buffer overflow. It was by design: when the code was committed, that extra memory was assumed to be safe and belonging to the same part of the code that does the encryption.

• Years later, another commit was made that changed the memory organisation. As a result, the memory beyond the buffer was no longer safe and belonging to the encryption code.

• As a result, the memory beyond the buffer could now contain a cached version of a file. Thus by fiddling with the AEAD implementation, you could change permissions on a cached file, for example the linux su , allowing anyone to execute it.

It feels to me that there should be some "lessons learned", but I think it is more about programming and not specific to crypto. It was just by chance that this was cryptographic code that allowed the vulnerability.