Hi everyone! I'm happy to share that my first first-author paper has been accepted to a conference recently about side-channel attacks on the Linux page cache.
Side-channel attacks on the page cache (first shown in 2019 by my PhD advisor et al.) were thought to have been mitigated since 2019 or thought to be impractical for a long time. Work that I (+my co-authors) did over the past year showed that such attacks were very possible, but also way more severe than initially thought.
It started out with me randomly encountering the cachestat syscall, introduced in kernel 6.5 (2022) to query the state of OS pages in the page cache. After a bit of investigation, we found that it leaks whether pages are in the page cache, including of globally-readable files not owned by that user.
I have a few examples of what attacks are possible on the linked blog post, but the tl;dr is you can detect whether binaries are run (like pkexec, which is the GUI that pops up for password prompts), infer which websites a different local-user visits on Firefox (via the libxul shared library), infer user and system behavior across docker containers, and a few more.
We also found a few more interesting stuff, like the
posix_fadvisesyscall with thePOSIX_FADV_DONTNEEDcan deterministically remove pages from cache. The other fine grained details are available in the paper: https://snee.la/pdf/pubs/eviction-notice.pdf, but a general write up is in the blog post.The cachestat vulnerability was assigned CVE-2025-21691 and was fixed by Linus Torvalds himself (first time interacting with him!)
Since I know Lemmy loves Linux (as much as I do, or even more), I thought I'd share it here :D. Feel free to ask any questions if you have any!
There's also a Github repository of our code which has been peer-reviewed to be reproducible here: https://github.com/isec-tugraz/Eviction-Notice
Author @ABasilPlant@lemmy.world
Thanks for sharing your work!
Do you feel there is anything deeply problematic with the page cache that would make this kind of side channel likely to be around elsewhere too or is it more of a specific case?
Thanks for the question!
As long as caches have existed, very similar styles of side channels have been demonstrated since the late 90s. A lot of the terminology we use (flush+reload, flush+flush...) are attack techniques that have been already demonstrated on CPU caches, and these demonstrations are at least a decade old.
Flush+Reload: https://www.usenix.org/conference/usenixsecurity14/technical-sessions/presentation/yarom
Flush+Flush: https://gruss.cc/files/flushflush.pdf
Invalidate+Compare (GPU caches, 2024): https://www.usenix.org/conference/usenixsecurity24/presentation/zhang-zhenkai
My colleague, Hannes, found similar styles of attacks existed with the Linux DNS cache too: https://hannesweissteiner.com/pdfs/dmt.pdf (also published at NDSS 26!)
The one really big difference between the page-cache side channel and other side channels is the "monitor" primitive. There are methods that the OS provides which directly report the presence of a page in cache. These are syscalls like
mincore(mitigated in 2019),preadv2 + rwf_nowait(unmitigated), andcachestat(mitigated in 2025).With these syscalls, we don't even have to rely on timing information (is page access fast -> cached; is it slow -> not cached). These syscalls really set the page-cache side channel apart because you can nondestructively figure out whether a page is in cache.
The page-cache side channel was first explored in 2019. It was explored on Linux but also on Windows by my advisor et al.: https://gruss.cc/files/pagecacheattacks.pdf
Hope this answers your question :D