The kernel's swap subsystem is charged with managing anonymous pages in secondary storage when those pages are (hopefully) not being used and the memory they occupy is needed elsewhere. This long-unloved subsystem has seen a resurgence of developer interest in recent times, so it is not surprising that it was the topic of three separate sessions in the memory-management track at the 2026 Linux Storage, Filesystem, Memory Management, and BPF Summit. Two of those sessions were concerned with improving the performance and maintainability of the swap code, while one (shared with the storage track) was about how swapping could be friendlier to solid-state storage devices.

Security updates have been issued by AlmaLinux (freerdp, gimp:2.8, jq, kernel, and rsync), Debian (chromium, ffmpeg, firewalld, kernel, nginx, openjpeg2, openssh, php7.4, and redis), Fedora (apptainer, chromium, coturn, dnsmasq, firefox, kernel, libgit2_1.8, libmetal, nginx, nginx-mod-brotli, nginx-mod-fancyindex, nginx-mod-headers-more, nginx-mod-js-challenge, nginx-mod-modsecurity, nginx-mod-naxsi, nginx-mod-vts, open-amp, perl-Net-CIDR-Lite, pgbouncer, pypy, python-jupytext, python-uv-build, rsync, rust-astral-tokio-tar, uriparser, uv, valkey, and yelp), Mageia (dpkg, firefox, thunderbird, golang, haproxy, and samba), Slackware (dnsmasq and kernel), and SUSE (apache-commons-configuration2, apache2, apptainer, chromedriver, cups-filters, curl, dnsmasq, expat, ffmpeg-4, ffmpeg-7, firebird, firewalld, flux2-cli, glibc, go1.25, go1.26, gosec, grub2, ImageMagick, java-11-openj9, java-17-openj9, java-1_8_0-openj9, java-1_8_0-openjdk, java-21-openj9, java-25-openj9, kdenlive, kernel, kernel-devel, keylime-config, krb5, libIex-3_4-33, mozjs115, mozjs78, nginx, openssh, openvswitch, ovmf, PackageKit, perl-Crypt-URandom, perl-CryptX, perl-libwww-perl, perl-Net-CIDR-Lite, perl-Text-CSV_XS, podman, postgresql17, postgresql18, python-pyOpenSSL, python310, rsync, sed, tekton-cli, valkey, xen, and zypper-docker).

The 7.1-rc4 kernel prepatch is out for testing.

Some of the documentation updates might be worth highlighting: the continued flood of AI reports has basically made the security list almost entirely unmanageable, with enormous duplication due to different people finding the same things with the same tools. People spend all their time just forwarding things to the right people or saying "that was already fixed a week/month ago" and pointing to the public discussion.

Which is all entirely pointless churn, and we're making it clear that AI detected bugs are pretty much by definition not secret, and treating them on some private list is a waste of time for everybody involved - and only makes that duplication worse because the reporters can't even see each other's reports.

(He is referring to this pull request with patches from Willy Tarreau defining what constitutes a security bug and responsible ways to use AI to find bugs).

We have received word that Peter G. Neumann, who, among many other things, ran the RISKS Digest for decades, has passed away. He will be much missed.

Update: the New York Times has published an obituary of Dr. Neumann.

The 7.0.9, 6.18.32, 6.12.90, and 6.6.140 stable kernels have been released. Each contains yet another set of important fixes.

Roman Gushchin began his session in the memory-management track of the 2026 Linux Storage, Filesystem, Memory Management, and BPF Summit by saying that the community has seen a lot of proposals adding BPF-based interfaces for memory management. None of them have made their way into the mainline, though. He wanted to explore the ways in which BPF might be helpful and the obstacles that have kept BPF-based solutions out so far. This session was followed by a discussion led by Shakeel Butt on what the requirements for a new, BPF-based interface for memory control groups might look like.

Recent times have seen a lot of effort put into the implementation of the kexec handover and live update orchestrator features in the Linux kernel. But that work is not yet complete. At the 2026 Linux Storage, Filesystem, Memory Management, and BPF Summit, Pratyush Yadav led a memory-management-track session on adding the ability to preserve hugetlbfs-provided memory during the live-update process.

The kernel's control-group subsystem works well for resource management, Chris Li said at the beginning of his memory-management-track session at the 2026 Linux Storage, Filesystem, Memory Management, and BPF Summit. Control groups work less well for other use cases, though. He was there to present his proposed enhancement, called "policy groups", that would address some of the shortcomings that he has encountered. A consensus on how this feature should look still seems distant, though.

The kernel's reverse-mapping machinery is charged with locating the page-table entries that refer to a given page in memory. The reverse mapping of anonymous pages is handled differently than for file-backed pages. The kernel's implementation of reverse mapping for anonymous pages is, according to Lorenzo Stoakes in his proposal for a memory-management-track session at the 2026 Linux Storage, Filesystem, Memory Management, and BPF Summit, "a very broken abstraction", due to its complexity. It also has some performance problems. Stoakes was there to present, in raw form, a proposed replacement that he calls a "COW context".

Inside this week's LWN.net Weekly Edition:

• Front: Fedora AI; Forgejo "carrot" disclosure; memory-management maintainership; huge THPs; mshare; 64KB base pages; DAMON; direct map.
• Briefs: Dirty Frag; Fragnesia; Mythos and curl; killswitch; Debian reproducible builds; KDE investment; Quotes ...
• Announcements: Newsletters, conferences, security updates, patches, and more.

When Brendan Jackman proposed a session for the 2026 Linux Storage, Filesystem, Memory Management, and BPF Summit, his topic was "a pagetable library for the kernel". During the actual memory-management-track session, though, he stated that the idea had "fizzled" and he was going to cover related topics instead. What resulted was a session on ways to efficiently manage pages that are not present in the kernel's direct map.

Linux can share memory between processes, but each process (almost always) has its own set of page tables. In situations where vast numbers of processes are sharing a memory region, the combined size of the page tables can exceed that of the shared memory itself. There has, thus, long been an interest in enabling unrelated processes to share page tables referring to shared memory. Anthony Yznaga is the latest developer to try to push this idea (known as "mshare") forward; he described the status of that work in a memory-management-track discussion at the 2026 Linux Storage, Filesystem, Memory Management, and BPF Summit (LSFMM+BPF).

The KDE project has announced that it has been awarded over €1 million from the Sovereign Tech Fund to improve its desktop-environment software. "The investment will be used to strengthen the structural reliability and security of KDE's core infrastructure, including Plasma, KDE Linux, and the frameworks underlying its communication services."

The kernel's dma-buf subsystem provides a way for drivers to share memory buffers, usually in order to support efficient device-to-device I/O. At the 2026 Linux Storage, Filesystem, Memory Management, and BPF Summit, Pavel Begunkov, assisted by Kanchan Joshi, led a joint session of the storage and memory-management tracks to explore ways to make the use of dma-bufs more efficient yet, and to make them available for read and write operations initiated by user space.

As a general rule, when developers talk about huge pages, they are referring to PMD-level pages that are 1MB or 2MB in size, depending on the CPU architecture. Most CPUs can support other huge-page sizes, though. On x86 systems, PUD-level huge pages hold 1GB of data. Providing such large pages transparently to processes has generally not been considered as either feasible or desirable, but Usama Arif is trying to change that assessment. At the 2026 Linux Storage, Filesystem, Memory Management, and BPF Summit, he led a session in the memory-management track on how to make transparent huge pages (THPs) truly huge.

Some CPU architectures are able to run with a number of different base-page sizes; using a larger size can often result in better performance at the cost of increased memory use. Other architectures are more limited. At the 2026 Linux Storage, Filesystem, Memory Management, and BPF Summit, two sessions in the memory-management track explored options for letting processes run with 64KB page sizes when the underlying kernel does not. The first was focused on letting each process have its own page size, while the second concerned bringing 64KB pages to x86 systems.

Paul Gevers has slipped an interesting bit of news into a "bits from the release team" message:

Aided by the efforts of the Reproducible Builds project, we've decided it's time to say that Debian must ship reproducible packages. Since yesterday, we have enabled our migration software to block migration of new packages that can't be reproduced or existing packages (in testing) that regress in reproducibility.

As Gioele Barabucci pointed out, "reproducible" in this sense is limited to building within an instance of Debian's build environment, which is a tighter requirement than is normally used. It is still a big step forward for reproducible builds.

Linus has released 7.1-rc3 for testing. "I think this answers the 'is 7.1 continuing the larger size pattern that we saw with 7.0?' question, and the answer is yes: that wasn't a fluke brought on by a .0 release - it simply seems to be the new normal."

It seems that we are in for an extended period of the disclosure of vulnerabilities before fixes become available. One possible way of coping with this flood might be the killswitch proposal from Sasha Levin. In short, killswitch can immediately disable access to specific functionality in a running kernel, essentially blasting a vulnerable path (and its associated functionality) out of existence until a fix can be installed. "For most users, the cost of 'this socket family stops working for the day' is much smaller than the cost of running a known vulnerable kernel until the fix land."

The kernel's DAMON subsystem provides user-space monitoring and management of system memory. DAMON is developing rapidly, so an update on its progress has become a regular feature of the annual Linux Storage, Filesystem, Memory Management, and BPF Summit. This tradition continued at the 2026 gathering with an update from DAMON creator SeongJae Park covering a long list of new capabilities — tiering, data attributes monitoring, transparent huge pages, and more — being added to this subsystem.