Eviction Notice: Reviving and Advancing Page Cache Attacks
snee.la
Foreword This blog post is a summarized and introductory write up of our paper recently accepted at NDSS 2026, “Eviction Notice: Reviving and Advancing Page Cache Attacks”. Read the full paper here. Authors: Sudheendra Raghav Neela, Jonas Juffinger, Lukas Maar, Daniel Gruss Artifacts: Github Repository, Zenodo Record (Available, Functional, and Reproducible) CVE-2025-21691: Announcement, Red Hat, NVD NIST, Debian Tracker, Suse. Introduction An operating system deals with pages, the smallest region of memory in a system using virtual memory1.

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_fadvise syscall with the POSIX_FADV_DONTNEED can 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

    • cm0002@lemmy.cafeOPEnglish
      11·
      1 day ago

      Np, if you’re wondering why it was so quick:

      Why am I cross-posting .ml content?

      I cross-post from .ml to the nearest relevant non-.ml comm to reduce the influence of .ml comms and indirectly, the instance as a whole, to make it an easier decision for other instance admins to defederate because one key reason I identified that admins don’t want to defederate is because .ml still has some very large comms and some niche comms.

      Megathread on the issue

      Some highlights from the link:

      "Don’t worry guys, the Uyghur Genocide was REALLY just birth control! ~dessalines, .ml admin, dev https://lemmy.world/post/30580167

      “See! nobody died IN Tiananmen Square, just AROUND it, so it doesn’t count!!” ~ Davel, .ml admin https://lemmy.world/post/30673342

      .ml admin, Nutomics continued transphobia https://lemmy.world/post/29222558 The original transphobic Comment from Nutomic: https://lemmy.world/post/18236068

      “NK is actually good and anything counter to that is Western propaganda!” ~dessalines, .ml admin, dev https://lemmy.world/post/31595035

      General negative sentiment to other instances who haven’t “seen the way” yet ~davel, .ml admin https://lemmy.world/post/27426510

      “If you don’t support Russia then you just don’t understand geopolitics” ~dessalines, .ml admin, dev https://lemmy.world/post/27352415

      And so so much documentation on clear heavy handed censorship and bias also on the link. So much I can’t even put them all here because this comment would be really long.

      I believe the behavior of its admins (the main admins are Lemmy devs) does harm to the overall growth of the Lemmy-verse and maybe even the Thrediverse (since Lemmy kinda kicked off the Thrediverse) because of its association with the devs of Lemmy and their insistence to use .ml as their personal political platform to spread harmful propaganda

      On the outside, bringing up Lemmy frequently leads to comments like “Lemmy? Isn’t that the place with a bunch of tankies?” Or “Tried Lemmy, but found it full of pro Russia crap so I left”. The best way forward from that I see is to either widely defederate from .ml like the rest of the Triad, or pressure them to put a fair and unbiased as possible admin team.

    • kumi@feddit.onlineEnglish
      4·
      1 day ago

      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?

      • A Basil Plant@lemmy.world
        1·
        18 hours ago

        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), and cachestat (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