LWN.net front-page content, full text

[$] The tenth OpenPGP email summit

jzb — Wed, 20 May 2026 11:00:15 +0000

May 20, 2026

This article was contributed by Heiko Schäfer, Andrew Gallagher, and David Runge.

The OpenPGP Email Summit is an annual meeting for those who work on encrypted email and related topics. The tenth installment of this meeting took place in March 2026 and the minutes have now been published. As usual, a wide range of topics were discussed. Highlights included support for post-quantum cryptography (PQC) with multiple actors planning rollouts within this year, a promising new approach for making email signatures ubiquitous with the plan of making OpenPGP signed email a default, a new draft that brings reliable deletion (or "forward secrecy") features to OpenPGP, as well as a plan for transferring ownership of the OpenPGP.org domain.

The summit attendees represented many projects, providers, and other interested parties in the space including Delta Chat, FreePG, Hagrid, Hockeypuck, keys.openpgp.org (KOO), Proton, Ripasso, RNP, Sequoia-PGP, Signstar, Thunderbird, VOA, and others.

Governance and the openpgp.org Domain

Phil Zimmermann is the current owner of the OpenPGP.org domain. He was not at the summit, but he had communicated that he wants to hand off this digital asset to the community; the community would prefer to find a setup that doesn't require any individual to take on personal responsibility. The keys.openpgp.org (KOO) board is one existing governance body that could take over the domain. Its current mandate is narrowly focused on running the keys.openpgp.org keyserver.

It is exploring taking on responsibility for the domain, using the Wau Holland Foundation as a trustee. The foundation is loosely connected with the Chaos Computer Club (CCC) and has been the sponsor of the OpenPGP email summit over the past ten years. Its members are deeply invested in the proliferation of the OpenPGP ecosystem. As a next step, the KOO board has proposed a constitutional change to the voting body.

PQC in OpenPGP

PQC was one of the topics discussed at this summit. Throughout the industry, people are preparing for the eventuality that quantum computers might at some point be able to break the current crop of cryptographic algorithms. In such a scenario, an attacker could even collect today's encrypted messages to decrypt them later, once a sufficiently capable quantum computer is available. PQC algorithms are designed to be unbreakable even by potentially upcoming quantum computers. The IETF draft that specifies PQC support for OpenPGP has completed last call and is awaiting final approval by its authors. Formal ratification as an RFC is expected within the next few months. The format itself has been stable for about a year.

The draft specifies two composite algorithms for encryption, two composite algorithms for digital signatures and three PQC-only algorithms for digital signing. All seven algorithms are usable with the new OpenPGP key format, (specified in RFC 9580), commonly referred to as "v6". In addition, one of the composite encryption algorithms is designated for use with the currently common v4 keys (see below for more).

Proton, a company that provides OpenPGP encrypted mail services, already had a complete implementation of PQC support for its email service at the time of the summit. General availability has since been announced. The core parts of Proton's PQC implementation are available as free software in feature branches of the two OpenPGP libraries that Proton uses and maintains: GopenPGP and OpenPGP.js.

The Delta Chat secure-messaging project has all the building blocks for PQC support in place, and intends to roll it out in production later this year. Thunderbird has experimental support for sending and receiving v4 PQC-encrypted messages. Providing this feature in stable releases will still take some time, though. Thunderbird uses the RNP OpenPGP library; the library's maintainers are working on incorporating a sizeable PQC pull request that was developed as part of a project financed by Germany's Federal Office for Information Security (BSI). The Hockeypuck keyserver has also added support for composite PQC keys in its latest beta release.

PQC encryption for v4 keys

The v6 format supersedes the previous format (referred to as "v4", and specified in RFC 4880) The changes in the v6 key format itself are moderate. The main point of the new key version is that fingerprints for v6 keys use SHA2-256 hashes, while v4 keys use SHA1 hashes as fingerprints. Attacks on the SHA1 hash algorithm have become sufficiently serious that moving on from v4 keys seems to be the prudent long-term strategy.

However, transitioning the ecosystem to a new key version is a longer-term project. As the urgency of protecting communication against possible post-quantum attacks increases, allowing users to seamlessly upgrade their existing v4 keys to enable PQC encryption becomes more of a concern. To serve this need, the PQC draft explicitly designates ML-KEM-768+X25519 composites for use as v4 subkeys. Users can add a post-quantum encryption subkey with this algorithm to an existing v4 key, without requiring their correspondents to support the still nascent v6 key format.

Thunderbird plans to roll out PQC support for v4 keys with additional ML-KEM-768+X25519 encryption subkeys by the end of this year, presupposing an RNP release with support for the format. The availability of PQC in both v4 and v6 formats allows for a more flexible rollout of PQC support, depending on the needs and priorities of different projects. The two current OpenPGP modernization efforts—v6 key support and PQC support—can be tackled separately or in combination.

Since many libraries support the full range of formats, there should usually be a common denominator, even if projects upgrade their support on different timelines.

FreePG and PQC

FreePG is a patched version of GnuPG that is used partially or fully by many of the larger Linux distributions. Its main goal is adherence to the OpenPGP IETF standard to allow users of GnuPG to opt out of the upstream's increasing divergence from the OpenPGP standard. However, FreePG is designed as a temporary stopgap rather than a long-term fork.

Its maintainers clarified that adding support for the IETF PQC draft is non-trivial, and the available resources may be too limited to achieve support for it in FreePG in the short term. The group agreed that FreePG should at least be able to gracefully ignore v4 PQC encryption subkeys, even if it cannot use them. As long as GnuPG upstream doesn't support v6 keys, it's not feasible for FreePG to support any v6 formats, including v6 PQC keys.

Separate from FreePG, Hamming Quasi-Cyclic (HQC), a new post-quantum encryption algorithm, was discussed briefly. There is interest, but also consensus that it's too soon to start specifying use of the algorithm in OpenPGP.

Unobtrusive signatures

Unobtrusive signatures, as described in a new IETF draft, were also discussed this year. The idea was initially brainstormed during the previous (9th) email summit. Existing email signature schemes (which use a multipart/signed structure) are not handled gracefully by all email software. As a result, many users turn signature generation off, to avoid displaying harmless but confusing errors to the recipient.

The goal of unobtrusive signatures is to allow sending software to confidently enable signing by default, without risking complaints to its users from recipients with clients that do not support signatures. Unobtrusive signatures unblock this default because they are silently ignored by software that doesn't support them. Previously, OpenPGP signatures would confuse or even worry some email recipients, causing them to complain to senders. Thus, developers of email software were sometimes reluctant to enable signatures by default, since it could cause complaints from recipients who do not have support for signatures.

The new approach uses a multipart/mixed wrapper with an OpenPGP signature embedded as a header rather than an attachment. This construction allows unobtrusive signatures to fulfill their main goal, which is to never be displayed in a way that confuses recipients. Even legacy clients that do not understand the signature will render the rest of the email as normal, without displaying anything about the signature. On the other hand, clients that support unobtrusive signatures can verify the signature and signal success to the user.

At the time of the summit, an implementation of the scheme was available in development versions of Thunderbird, and has already seen some successful testing by users in the wild. Thunderbird Daily, a rolling release of the mail client that tracks development and includes bleeding-edge features, can already produce and consume unobtrusive signatures, though it currently requires users to enable a hidden preference. Kai Engert from Thunderbird estimates that production of unobtrusive signatures will start becoming the default later this year. Proton plans to implement support for incoming unobtrusive signatures soon as well.

Bart Butler from Proton observed that once both Thunderbird and Proton support unobtrusive signatures, it should be straightforward to bring other clients on board, making this effort one of the highest return-on-investment improvements for signed email.

Autocrypt v2 (AC2): Combining PQC and reliable deletion

Holger Krekel from Delta Chat presented Autocrypt v2 (AC2), a specification that was in part driven by Delta Chat project members (minutes of the discussion). AC2 deals with a separate concern than Autocrypt v1. While v1 handles exchange and update of OpenPGP keys between email peers, AC2 centrally introduces a scheme for clock-based rotation of key material. It doesn't concern itself with bindings between identities and key material.

The AC2 draft's introduction outlines the goals:

It offers defense against store-now-decrypt-later attacks from quantum computers through post-quantum hybrid cryptography. It also enables reliable deletion ("Forward Secrecy") of received messages even when adversaries capture encrypted messages in transit and later compromise the user's message archive and secret keys.

That is, if all participants in a chat don't retain decrypted message plaintext, and regularly destroy old private key material (as the scheme prescribes), then old plaintext becomes fundamentally unrecoverable over time by correspondents or attackers. Autocrypt v2 combines this clock-based key-rotation scheme with PQC encryption.

The key-rotation scheme combines a permanent fallback key with a short-lived encryption subkey (for example, valid for ten days). Communication usually relies only on the short-lived key, but can fall back to the long-lived encryption key in edge cases (for example when two peers have not communicated for a longer time). Senders regularly distribute new subkeys. Recipients merge their peers' encryption subkeys locally, while removing obsolete subkeys as they expire.

There was some discussion about the inherent tradeoffs of this scheme. Reliable deletion means that old messages are not readable anymore by anyone. This property is in tension with typical expectations of email, where messages are often stored indefinitely (e.g. on IMAP servers), and users expect to be able to decrypt and read them in the future. By contrast, if a client deletes its decryption subkey, but the ciphertext persists on a server, the user loses access to their old mail. Possible mitigations—re-encrypting messages to a long-term key, storing session keys separately—trade away some of the forward secrecy guarantee.

There was no conclusion, but it's clear that different use cases exist, and forward secrecy is not a good fit for all of them. The AC2 framework can be applied to realize different outcomes by choosing between the different tradeoffs.

Another question that was raised, but not resolved, was whether Autocrypt v2 certificates should be explicitly marked as such. This might be helpful as a hint, for example, to prompt keyservers to prune expired encryption subkeys rather than accumulating them indefinitely.

HKPv2: Modernized general key-server API

The OpenPGP ecosystem currently has three somewhat ad-hoc technologies for certificate distribution. The Hockeypuck servers implement the "Legacy HTTP Keyserver Protocol" (HKPv1). The Hagrid server at keys.openpgp.org uses the custom Verifying Key Server (VKS) API, but also implements a subset of HKPv1. A third scheme, named Web Key Directory (WKD) allows static serving of OpenPGP key material for lookup by email address.

HKPv2, which was discussed at this summit, is a proposal that aims to cover all use cases of these three key-distribution systems with one unified API. It is designed to cover both verifying and non-verifying key-server use cases, and also for serving certificates directly from a set of plain static files (akin to WKD, without requiring any specialized software on the server). This draft has arrived at a relatively stable state and is specifically designed to facilitate the ecosystem's shift from classic v4 keys to v6 and/or PQC keys.

The 2025 keys.openpgp.org board has discussed and worked on the HKPv2 draft, and arrived at the decision that keys.openpgp.org will implement support for the protocol (as soon as the limited development resources allow).

The Hockeypuck key-server software has since added preliminary support for the API. The 2025 keys.openpgp.org board also decided for the project to implement the API, but there is no clear timeline for this effort yet. The HKPv2 draft is currently waiting for adoption by the IETF OpenPGP working group.

Key migration and the key replacement draft

Upgrading from OpenPGP v4 keys to v6 keys, and/or PQC keys, was discussed briefly. In the near future, many OpenPGP users are going to consider upgrading from their current v4 keys to new v6 and/or PQC keys. Such key migrations have historically been a mostly manual process in OpenPGP: key holders created new keys, and issued various certifications between their certificates to mark them as linked. Their correspondents needed to manually determine if the new certificates were reliably linked to trusted previous certificates, and accept the new certificates in their OpenPGP software.

The key replacement draft defines a mechanism that formalizes key transitions, and enables software to handle them transparently, on behalf of users (both for key holders and for their correspondents).

Given good support in applications, this mechanism will make key transitions close to seamless—while at the same time being rigorously protected by cryptographic statements from the key holder. This draft was adopted by the OpenPGP working group, and has been textually mostly stable for a number of months, but is still waiting for implementations before entering "last call".

Looking Ahead

A number of concrete next steps were announced at this summit. Thunderbird and Proton announced plans to ship unobtrusive signatures in upcoming releases of their respective software. Thunderbird is also planning to add complete v4 PQC support in an upcoming stable release. Proton confirmed its intention to roll out v6 PQC support to all of its users, after successful internal testing. Delta Chat is planning to roll out v6 PQC and "reliable deletion" via Autocrypt v2 to its users in 2026. The support for HKPv2 in the Hockeypuck keyserver software will be finalized and rolled out to the relevant keyservers this year, alongside support for PQC keys. It was also confirmed that keys.openpgp.org intends to add HKPv2 support to the Hagrid keyserver, but no clear roadmap for implementation has been put forth yet.

A number of longer-term efforts remain under active development. Many participants said that this year's summit was extremely productive. The OpenPGP ecosystem is looking diverse and vibrant; many long-term projects are currently coming to fruition. In particular, the finalization of PQC support in OpenPGP (which was kicked off in 2021 by Germany's BSI), and the multitude of imminent related rollouts, appear to be timely.

A followup interim meeting is scheduled for October 21, 2026; the next in-person summit tentatively for the end of April 2027. Anyone interested in participating can subscribe to the IETF Open Specification for Pretty Good Privacy group's mailing list. Participation is open to anyone.

Firefox 151.0 released

corbet — Tue, 19 May 2026 16:10:38 +0000

Version 151.0 of the Firefox browser has been released. Significant changes include the ability to clear and restart a private-browsing session, better fingerprinting protection, control over the apparent location when using the Firefox VPN, and more.

[$] openSUSE "terms of site" raise complaints about age restrictions

jzb — Tue, 19 May 2026 15:27:08 +0000

By Joe Brockmeier
May 19, 2026

Many people in the Linux community began using the operating system—and contributing to open source—at a tender age, often well before their 16th birthday. Thus, a recent change in openSUSE's terms of site (ToS) that required users of the project's web site to be "at least 16 years of age or the age of majority" in their jurisdiction has raised objections. The terms have since been modified, though users must still have parental approval to create accounts if they are younger than 16.

Must be 16 or older to enter

The age restriction seems to have been added on March 10, 2026, according to the site's history. The openSUSE site terms stated that using the site, at all, indicates acceptance of the ToS: "If at any time the Terms are no longer acceptable to You, You should immediately cease all use of this web site." Since the restrictions also forbade use by those under 16, the ToS meant that younger users were told not to even read openSUSE documentation, blog posts, etc.

Perhaps someone in SUSE's legal department believed that this language is necessary, and in some way enforceable. In reality, the vast majority of people simply browsing the openSUSE web sites are unlikely to ever see—much less agree to—the ToS unless specifically looking for it.

However, the ToS also covers contributions to openSUSE, use of the Open Build Service, and so forth. It may not affect casual users of openSUSE, but would (if observed) inhibit participating in the openSUSE project in any meaningful way. As written, the ToS did not even allow for users under the age of 16 to read the site with parental permission.

On May 8, Teckids founder and chairperson Dominik George complained on the openSUSE project mailing list about the restriction. He said that he had more than a decade of experience working with digital spaces for children: "That's why I can assure you: There is no legal reason to ban minors."

He also claimed that the new terms were also against openSUSE's code of conduct, which say that the project is "dedicated to providing a positive experience for everyone, regardless of such attributes, (including but not limited to)" a number of factors—including age. George called for the project to revert the change in terms, or at least to reword them so that they were only applicable for creating an account.

Some other Linux projects do have age requirements for creating accounts, though none that I've found attempt to impose age requirements for merely browsing their web sites. The new-account form on Fedora Accounts (which cannot be linked to directly) requires that users attest to being 16 or older; Canonical's terms of service requires that users be 13 or older to create an account, and to have parental permission between the ages of 13 and 18. Debian does not have a centralized account service, but none of its various services that I looked at had an age requirement for creating an account.

Discussion

On May 11, Luboš Kocman replied that he had shared George's feedback with SUSE's legal and data privacy teams. Jeff Mahoney, an openSUSE board member and SUSE employee, said that the age requirement was not requested by the project or openSUSE's board. "There are members of the board (or board-adjacent) who began using Linux at ages younger than 16 and the intention was not to prohibit participation of young people." There was a request, he said, to update the ToS to be "not be quite so US-centric" and that led to a review by SUSE's legal team.

Neal Gompa said that Fedora had needed to raise its minimum age requirement from 13 to 16 in order to comply with the European Union's General Data Protection Regulation (GDPR). There was some extended debate about when parental consent was necessary for users to create an account, or for an entity to collect personally-identifiable information; George said that there was no EU law that required a minimum age for using web sites and later replied that registering an account probably needed consent from a guardian due to contract law, "but not due to restrictions posed by privacy laws".

Patrick Fitzgerald said that he had "speed-read the relevant sections" of the GDPR, and did not think it applied. "I cannot see any legal requirement to discourage younger users. I started using a computer at age 14. Mind you, that was a little bit before the internet was widely available".

After a number of exchanges, George said he was "mostly fine with openSUSE copy-pasting all contract laws of the world into its ToS" as long as there was a way for minors to accept them, presumably with parental consent, though he did not say that explicitly. He would not take that approach, though, "because it's redundant and tedious, unnecessary work." He did acknowledge, though, that "that these considerations are not as trivial in reality".

Rollback

On May 13, Kocman replied to the list to say that the matter was with SUSE legal and that he was reminding them daily. On May 15, Jeff Mahoney provided an update to the list to say that SUSE's legal team had agreed to change the text to the following:

By creating an openSUSE account, you represent that you are at least 16 years of age or the age of digital consent in your jurisdiction. If you are under 16 years of age (or below the applicable age of digital consent in your jurisdiction), you may only create an account with the verifiable consent of your parent or legal guardian. No age requirement applies to general browsing or passive access to publicly available content on this site.

He added that the work was not done: "We don't want to ban contributors under the age of 16 either but we don't have a system in place to handle 'verifiable consent' yet." That, he said, was a legal requirement in the US and EU. He committed to bringing an update to the community when he had something to share.

It will be interesting to see how SUSE approaches "verifiable consent". To show that a parent or guardian has provided consent seems to imply that SUSE will also need to verify (at least some) users' ages. The topic of age attestation and verification has been a controversial topic lately for many reasons; any system that requires users to provide proof of age is likely to be unpopular.

Various governments around the world continue to put laws on the books that, in a variety of ways, push responsibilities onto service providers to put up ineffective safety bumpers to make the Internet "safe" for children. It is hard to see, however, how legal requirements that require age-gating participation in open-source communities makes anyone safer; it only increases the legal liability for open-source projects or their sponsors.

[$] In search of faster this_cpu operations

corbet — Tue, 19 May 2026 14:30:40 +0000

By Jonathan Corbet
May 19, 2026

LSFMM+BPF

The kernel's this_cpu operations are meant to speed access to per-CPU variables. They are more optimal on some CPUs than others, though. During a memory-management-track session at the 2026 Linux Storage, Filesystem, Memory Management, and BPF Summit, Yang Shi proposed a fundamental, and somewhat controversial, change to how these operations work in order to provide better performance on a wider range of architectures.

Per-CPU variables are organized as an array, indexed by CPU number, with each CPU's data being placed in a separate cache line; that allows CPUs to access their private data without locking overhead or contention from other CPUs. On the x86 architecture, a per-CPU access is implemented by prefixing the relevant instruction with a segment register, creating a single-instruction operation that executes atomically. Other architectures, including Arm, lack segment registers and, as a result, have a more complicated implementation. In particular, the calculation of the address and the access of the data behind that address must be done separately, turning a per-CPU access into a multi-instruction sequence.

That is a significant difference. If a multi-instruction sequence is preempted partway through, the newly running thread could access the same variable, leading to all sorts of unpleasant behavior. Migration of the thread could lead to cross-CPU access, which is also undesirable. To prevent these scenarios, the this_cpu operations must disable preemption on the affected architectures, which hurts performance.

Shi's proposal is to reimplement per-CPU variables so that any given variable has the same address on every CPU, using per-CPU page tables to make that work. That would eliminate the index calculation and preemption would no longer be a problem. The only problem with this scheme is that it would break the per_cpu_ptr() macro that is used to initialize data across all CPUs. To solve that problem, per-CPU variables would be mapped twice. The existing global mapping would be retained and used for initialization; a second mapping would be specific to each CPU.

Jason Gunthorpe pointed out that, in the past, Linus Torvalds has been strongly opposed to using per-CPU page tables in this way. If his concerns are not addressed, Gunthorpe said, this work will not go far. The objection seems to be based on the difficulty of correctly managing translation lookaside buffer (TLB) entries associated with those addresses; there was some discussion about whether that situation has improved with more recent architecture revisions. It was also pointed out that, while this scheme would eliminate the need to disable preemption in some situations, any sort of update involving more than one instruction would still need to be executed with preemption disabled.

Shi continued, saying that the new implementation does have a cost in the form of higher address-space usage; that cost appears to be small, though. The per-CPU page tables will need to occupy physical memory; he said that cost is about 2MB on a 160-core machine. Some extra page-table operations are needed for the allocation and freeing of per-CPU variables. There may also be a need to allocate a dedicated range of virtual address space, which could be a problem on 32-bit machines.

Performance benchmarks were run on a 160-core Arm system; the key kernel-build benchmark showed a 13-18% reduction in system time, and ran in 3-7% less wall-clock time. The stress-ng benchmarks showed significant improvements as well. Brendan Jackman expressed surprise at how large those numbers were; avoiding the need to disable preemption does not seem like enough to explain the difference. Some more investigation into the cause of the speedups is indicated, he said.

As time ran out, Ryan Roberts wondered if the in-kernel restartable-sequences work from Peter Zijlstra might be an alternative solution to this problem; Shi was not familiar enough with that work to say. Shi did say that the per-CPU page tables could, in the future, also be used for replication of the kernel text across NUMA nodes, providing local access across the system. Jackman said that they could make his proposed "mermap" (which was discussed earlier in the conference) work better as well.

[$] What's brewing in CXL

corbet — Tue, 19 May 2026 14:15:48 +0000

By Jonathan Corbet
May 19, 2026

LSFMM+BPF

Compute Express Link (CXL) is a technology intended to enable the provision of "memory nodes" in data centers that provide (possibly shared) memory to nearby CPUs. It has, Dan Williams said at the beginning of his memory-management-track session on the topic at the 2026 Linux Storage, Filesystem, Memory Management, and BPF Summit, "been making memory-management problems worse since 2021". He used the session to provide an overview of the ways in which CXL can be expected to extend that record into the future.

CXL, he began, is a way of providing memory over the PCIe bus; it generally offers latency that is worse than accessing memory on remote NUMA nodes. The strength and challenge of CXL is that it is highly configurable, allowing, for example, the setup of interleaved memory access that improves performance. One problem is that, while the kernel can control some access to CXL memory, the system firmware wants to play with things as well. Another challenge comes with the hot-plug nature of CXL memory; if it goes away, a portion of the system's RAM can disappear.

The CXL standard is evolving quickly, and manufacturers are putting out hardware with interesting deviations from the adopted standards. The kernel is following something like the ACPI "code-first" policy with regard to these changes and documenting them in the kernel tree. The hope is to send a message to manufacturers: "somebody broke it this way, please break yours the same way".

Error handling is an evolving area as well. CXL protocol errors are reported to the kernel as PCIe internal errors, but they are handled through a side channel so that the PCIe core code does not need to deal with them. The CXL code is introducing kernel panics in its error-handling paths; that is not something that is normally appreciated in kernel code but, Williams said, the firmware is going to panic the system anyway in such situations.

Accelerator support (memory-to-memory compression, for example) is close to landing in the kernel. It turns out that accelerators are relatively simple to support. Another development area is vfio-cxl, which is a mechanism to allow exporting CXL accelerators to virtual machines.

Dynamic capacity has long been a dream for system designers, Williams said. One buys a lot of DIMMs, puts them into a box, runs a cable, and a lot of hosts can then map that memory. But then the kernel has to somehow make that memory available to user space. The plan is to use device DAX as the interface, but there are questions about how to create private nodes for dedicated memory (a topic that would return the following day). There needs to be integration with guest_memfd as well.

What is not brewing in CXL support? One non-development area is error isolation; if a CXL host bridge is lost, all associated devices will fail, and terabytes of system RAM may vanish. It is hard to envision a way in which the system can survive such an event, at least when memory is involved. Error isolation for accelerator users might be more feasible. There is also no work currently on supporting peer-to-peer operations on CXL devices, but "somebody will want it someday". Finally, CXL encryption, which he described as "another bucket of acronyms", is also not expected to be supported in the near future.

The session concluded there, with no real discussion among those present.

[$] Improving the per-CPU memory allocator

corbet — Tue, 19 May 2026 13:27:28 +0000

By Jonathan Corbet
May 19, 2026

LSFMM+BPF

There are many places in the kernel where performance can be improved by using per-CPU data. But, as it turns out, the kernel's allocator for per-CPU data has some performance problems of its own. Harry Yoo led a session in the memory-management track of the 2026 Linux Storage, Filesystem, Memory Management, and BPF Summit to explore ways to address those problems and accelerate the allocation and initialization of per-CPU data.

The dynamic per-CPU allocator was added by Tejun Heo for the 2.6.30 kernel release in 2009; it is built on a per-CPU-data infrastructure whose origin is lost in pre-Git antiquity. Documentation for users of this API is, presumably, in the works and will hopefully show up soon. Allocation of a per-CPU area results in an array of objects, indexed by CPU number, where each CPU's memory lives in a different cache line to avoid contention. A common use for this data is the creation of statistics counters. Each CPU can quickly increment its own counter as needed; when a total is required, it can be obtained by calculating a sum of all the per-CPU values.

This being a gathering of memory-management developers, there was particular interest in the per-CPU counters (rss_stat, stored in each process's mm_struct structure) used to keep track of each process's resident set size (RSS). Allocation and freeing of memory is a frequent operation, so managing a process-global RSS counter would be expensive for highly threaded processes. Splitting those counters into a per-CPU array can avoid contention on a global counter but, as was discussed in this session, can lead to other performance problems.

Yoo began by saying that there are two specific shortcomings with the current per-CPU allocator. One is that it was not designed for scalability; it uses a global lock for the allocation and freeing of memory. It is not uncommon to see multiple CPUs allocating per-CPU memory concurrently, leading to contention on that lock. The other problem is that initializing the per-CPU array can be expensive, especially in cases where there are a lot of CPUs and the data itself is short-lived. There have been a number of proposed solutions, he said, with the result that there are too many ideas floating around but not enough actual progress.

One of those ideas, he said, was dual-mode per-CPU counters, an idea that was proposed by Gabriel Krisman Bertazi as a solution to performance problems associated with the RSS counters. Under this proposal, when a set of counters is allocated for a new process, it will be created in a single-threaded mode, since the process itself only has one thread at that point. That greatly reduces the initialization cost. Should the process create a new thread sharing the same address space, the counters are upgraded into the full per-CPU mode. Since many processes never do create threads, this proposal eliminates the initialization cost entirely much of the time.

An alternative, shown in this series from Yoo, integrates the per-CPU allocator more closely with the slab allocator, and restores the slab destructor operation, which was removed many years ago. That would allow per-CPU objects to be retained in the slab cache and, in particular, would only require the constructor to be called on the initial allocation. This scheme would only work if users of per-CPU objects leave them in a reasonable state when freeing them. Some care would have to be taken with this approach, Yoo said, to limit lock acquisition in destructors to avoid deadlocks.

Finally, Mathieu Desnoyers (who attended the session via remote link) has proposed using the "per-MM concurrency IDs" (or "mm_cids") for this task. An mm_cid is a virtual CPU ID that is maintained as part of the restartable-sequences subsystem. Unlike a real CPU number, which can be as large as the number of CPUs the system might conceivably support, the mm_cid is bounded by both the number of threads the running process has and the number of CPUs that process is allowed to run on. As a result, it will generally be a much smaller number. A process with four threads on a 256-CPU system might see a CPU number as high as 255, but its maximum mm_cid will be three. See this article and the rseq() manual page for more details on this feature.

The core of Desnoyers's proposal, as he described it in the session, is that per-CPU data could be indexed using the mm_cid rather than the actual CPU ID. That would still isolate each CPU's access to the array, but the array itself could be much smaller. Individual entries would be initialized on first use, keeping the initialization cost down.

Kiryl Shutsemau pointed out that get_user_pages_remote() can allocate pages on a CPU other than the one it is running on, and Shakeel Butt wondered about remote access to another CPU's counters in general. Shutsemau also raised other cases of remote access, such as when a process is being manipulated with ptrace(). In those cases, the code in question is not part of the process it is manipulating, so the mm_cids will not match. Desnoyers said that would be an uncommon case that might be best addressed by adding a separate counter.

Yoo pushed for a conclusion, saying that some sort of solution was needed in the mainline. Davidlohr Bueso indicated support for the mm_cid idea, asking what problems would prevent it from being adopted. Shutsemau raised the get_user_pages_remote() problem again, but said that he would have to look more closely to determine if it is really a problem or not. Suren Baghdasaryan wondered how much extra overhead the mm_cid solution would add in general.

Another participant pointed out that the RSS counters are known to be imprecise, and that Desnoyers has been circulating a patch series to improve them. Some of the proposed solutions to the per-CPU problem are specific to the RSS counter format, he said, suggesting that the mm_cid solution is more general and would be preferable.

Yoo brought the session to a close by asking, again, what the conclusion should be; the room seemed to be heading toward a consensus to take the mm_cid approach. Butt suggested that Desnoyers should send patches implementing that solution; Desnoyers said that the idea only existed in his head for now, so it would take some time to put together a proper patch set.

Security updates for Tuesday

corbet — Tue, 19 May 2026 13:24:00 +0000

Dist.	ID	Release	Package	Date
AlmaLinux	ALSA-2026:18028	9	libpng	2026-05-18
AlmaLinux	ALSA-2026:18029	9	nginx	2026-05-18
Debian	DLA-4590-1	LTS	erlang	2026-05-18
Debian	DSA-6280-1	stable	netatalk	2026-05-18
Debian	DLA-4589-1	LTS	nginx	2026-05-18
Fedora	FEDORA-2026-8ac58f5cf3	F42	SDL2_image	2026-05-19
Fedora	FEDORA-2026-f1f87b465a	F43	SDL2_image	2026-05-19
Fedora	FEDORA-2026-707b7050da	F43	mod_md	2026-05-19
Fedora	FEDORA-2026-c9b72de46a	F44	mod_md	2026-05-19
Mageia	MGASA-2026-0149	9	perl-WWW-Mechanize-Cached, perl-File-XDG, perl-Path-Tiny	2026-05-18
Mageia	MGASA-2026-0148	9	perl-YAML-Syck	2026-05-18
Mageia	MGASA-2026-0150	9	perl-libwww-perl, perl-HTTP-Message	2026-05-19
Mageia	MGASA-2026-0151	9	postgresql15	2026-05-19
Mageia	MGASA-2026-0147	9	rclone	2026-05-18
SUSE	SUSE-SU-2026:1619-2	SLE15	PackageKit	2026-05-18
SUSE	openSUSE-SU-2026:20753-1	oS16.0	agama	2026-05-19
SUSE	openSUSE-SU-2026:20752-1	oS16.0	alloy	2026-05-19
SUSE	openSUSE-SU-2026:0169-1	osB15	cacti	2026-05-18
SUSE	SUSE-SU-2026:1980-1	MP4.3 SLE15 oS15.4 oS15.6	cloud-init	2026-05-18
SUSE	openSUSE-SU-2026:20748-1	oS16.0	dnsmasq	2026-05-19
SUSE	openSUSE-SU-2026:20759-1	oS16.0	emacs	2026-05-19
SUSE	openSUSE-SU-2026:20741-1	oS16.0	firefox	2026-05-19
SUSE	openSUSE-SU-2026:20764-1	oS16.0	glibc	2026-05-19
SUSE	openSUSE-SU-2026:20763-1	oS16.0	go1.25	2026-05-19
SUSE	openSUSE-SU-2026:20762-1	oS16.0	go1.26	2026-05-19
SUSE	SUSE-SU-2026:1938-1	MP4.3 SLE15	google-cloud-sap-agent	2026-05-18
SUSE	SUSE-SU-2026:1935-1	SLE12	google-cloud-sap-agent	2026-05-18
SUSE	openSUSE-SU-2026:20761-1	oS16.0	google-guest-agent	2026-05-19
SUSE	openSUSE-SU-2026:20750-1	oS16.0	ibus-rime, librime	2026-05-19
SUSE	openSUSE-SU-2026:20747-1	oS16.0	imagemagick	2026-05-19
SUSE	SUSE-SU-2026:1959-1	SLE15	kernel	2026-05-18
SUSE	SUSE-SU-2026:1978-1	SLE15	kernel	2026-05-18
SUSE	openSUSE-SU-2026:20743-1	SLE16.0 oS16.0	kernel	2026-05-19
SUSE	openSUSE-SU-2026:20758-1	SLE16.0 oS16.0	kernel	2026-05-19
SUSE	SUSE-SU-2026:1969-1	SLE12	libsndfile	2026-05-18
SUSE	SUSE-SU-2026:1968-1	SLE15	libsndfile	2026-05-18
SUSE	openSUSE-SU-2026:10796-1	TW	nginx	2026-05-18
SUSE	openSUSE-SU-2026:20742-1	oS16.0	ongres-scram, ongres-stringprep, plexus-testing,	2026-05-19
SUSE	openSUSE-SU-2026:20755-1	oS16.0	openexr	2026-05-19
SUSE	openSUSE-SU-2026:20757-1	oS16.0	openssh	2026-05-19
SUSE	SUSE-SU-2026:1936-1	SLE15	perl-Text-CSV_XS	2026-05-18
SUSE	SUSE-SU-2026:1970-1	SLE15 oS15.4	php-composer2	2026-05-18
SUSE	SUSE-SU-2026:1958-1	SLE15	php8	2026-05-18
SUSE	SUSE-SU-2026:1957-1	SLE15 oS15.6	php8	2026-05-18
SUSE	openSUSE-SU-2026:20745-1	oS16.0	php8	2026-05-19
SUSE	SUSE-SU-2026:1942-1	SLE15	postgresql16	2026-05-18
SUSE	SUSE-SU-2026:1946-1	SLE12	postgresql18	2026-05-18
SUSE	SUSE-SU-2026:1945-1	SLE15	postgresql18	2026-05-18
SUSE	openSUSE-SU-2026:20737-1	oS16.0	python-lxml	2026-05-19
SUSE	SUSE-SU-2026:1961-1	oS15.6	python-python-multipart	2026-05-18
SUSE	SUSE-SU-2026:1937-1	SLE12	python3	2026-05-18
SUSE	openSUSE-SU-2026:10798-1	TW	python311-urllib3	2026-05-18
SUSE	SUSE-SU-2026:1964-1	MP4.3 SLE15 oS15.4	rmt-server	2026-05-18
SUSE	openSUSE-SU-2026:20754-1	oS16.0	rsync	2026-05-19
SUSE	SUSE-SU-2026:1966-1	SLE12	tiff	2026-05-18
SUSE	SUSE-SU-2026:1965-1	SLE15 SLE5.3 SLE5.4 SLE5.5 SLE-m5.3 SLE-m5.4 SLE-m5.5	tiff	2026-05-18
SUSE	SUSE-SU-2026:1967-1	SLE15 oS15.6	tiff	2026-05-18
SUSE	openSUSE-SU-2026:20749-1	oS16.0	tree-sitter	2026-05-19
SUSE	SUSE-SU-2026:1962-1	SLE5.5 SLE-m5.5 oS15.5	util-linux	2026-05-18
SUSE	SUSE-SU-2026:1998-1	SLE15	xen	2026-05-19
SUSE	openSUSE-SU-2026:10800-1	TW	xen	2026-05-18
Ubuntu	USN-8273-1	18.04 20.04	linux, linux-aws, linux-aws-5.4, linux-aws-fips, linux-azure, linux-azure-5.4, linux-azure-fips, linux-bluefield, linux-fips, linux-gcp, linux-gcp-5.4, linux-gcp-fips, linux-hwe-5.4, linux-ibm, linux-ibm-5.4, linux-iot, linux-kvm, linux-oracle, linux-oracle-5.4, linux-xilinx-zynqmp	2026-05-19
Ubuntu	USN-8274-1	14.04 16.04	linux, linux-aws, linux-kvm, linux-lts-xenial	2026-05-19
Ubuntu	USN-8254-3	24.04	linux-nvidia-tegra	2026-05-19
Ubuntu	USN-8255-3	20.04 22.04	linux-nvidia-tegra-5.15, linux-raspi	2026-05-19
Ubuntu	USN-8275-1	22.04	linux-xilinx-zynqmp	2026-05-19

pgBackRest will continue

jzb — Tue, 19 May 2026 12:05:42 +0000

In April, David Steele, maintainer of the popular pgBackRest backup and restore project for PostgreSQL, announced that he had archived the project and it would no longer be maintained due to lack of sponsorship. On May 18, he announced that a number of sponsors have stepped forward to ensure its continued development:

Over the last few weeks, a coalition of sponsors has come together to fund ongoing development. Their support means the project is no longer reliant on a single sponsor, giving pgBackRest the stability it needs for the long term.

[...] I'm looking forward to getting back to work. There are features and optimizations in the pipeline that I'm excited to share in upcoming releases. Thank you to our sponsors for making this possible, and thank you to the community for your patience and support during this transition.

Thanks to Paul Wise for the tip.

[$] Swap tables, flash-friendly swap, swap_ops, and more

corbet — Mon, 18 May 2026 13:16:04 +0000

By Jonathan Corbet
May 18, 2026

LSFMM+BPF

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.

Status and roadmap

The first session was a breakneck-paced presentation from Kairui Song on recent changes in the swap subsystem and what is coming next. Song began by describing his work introducing the swap table and removing a lot of swap-subsystem complexity; see this article and its successor for details on this work. Before his changes were merged for 7.0, the swap subsystem incurred an overhead of between three and 11 bytes per page; that overhead is now reduced to between two and ten bytes. That news was greeted by applause in the room.

Song is not done, though; he intends to cut the static overhead to zero bytes, albeit still with a maximum of ten. His goal to cap that overhead at eight bytes will not be realized in the short term because refault tracking for the memory resource controller requires more data. In the long term, he still hopes to cut the maximum overhead to three bytes per page.

The need for some operations to bypass the swap cache has been removed, and most of the swap-oriented helpers are now folio based. Most operations only need the folio lock now; there are opportunities, he said, to optimize further by applying some lockless algorithms. Work to unify folio allocation with the swap cache is still in progress. Currently, anonymous and shared-memory folios come with their own allocation logic that may bypass readahead; he described this code as a long, complex, and racy fallback loop. He is working to replace it with a single allocation helper.

Other work is aimed at letting the system make better use of the swap cache; better readahead support is an important step in that direction. The zram subsystem can take advantage of it now but, he said, whether that is beneficial is not entirely clear. It may be that zram is fast enough already.

Swapping I/O is asynchronous and takes time; that means that there can be a long delay between the onset of memory pressure and the completion of the I/O that allows that pressure to be relieved. By the time that happens, it may turn out that the system has overshot and swapped out more pages than really needed. This could be helped by immediately dropping pages from the swap cache once writeout has completed. He is not sure why that is not always done now; more research is needed there.

There are a number of other problems yet to be solved. Swapping of PMD-level huge pages is not as efficient as it could be. Readahead can end up bringing in pages used for hibernation, which is wasteful but not a huge problem, though the workaround is ugly. He is contemplating adding a special bit to mark pages reserved for hibernation. There are users who would like to be able to resize swap areas on the fly; that should be practical to implement now.

Another problem arises when both anonymous and shared-memory (shmfs) folios are swapped to the same device. If shmfs-backed transparent huge pages (THPs) are being swapped, they can end up overlapping an anonymous page's slot; when that happens now, the offending folio is simply dropped. The problem will worsen, though, if readahead gains support for THPs. He is contemplating creating a new swap-table type to address this problem. Matthew Wilcox said the problem may come down to a confusion of logical (within the owning process's address space) and physical readahead; we are doing something wrong somewhere, he suggested.

Song is looking into compaction of the swap table. The system manages swap space in clusters, which are organized into a least-recently-used list. It might be possible to drop full clusters from the list; that would increase performance, but might increase memory pressure.

All of the above was compressed into a half-hour slot, but Song was not done yet. The time is coming, he said, where swap files should be renamed to "swap mappings". Swapping now looks a lot like the mapping used for file-backed memory, though with different writeback policies and locking schemes. Much of this could be abstracted out by adding a new virtual swap layer, which could address a number of other problems (such as defragmentation and migration) as well. He put up a slide showing the overall design of this layer:

An RFC patch set has been posted with an initial implementation of this idea. It reuses the existing swap infrastructure, but adds an extra layer of mapping. Among other things, this design allows for faster removal of a swap device (since there is no longer a need to adjust the page-table entries for all of the processes that have pages on the to-be-removed device) and easy defragmentation of swap devices.

Johannes Weiner pointed out that this design could make it easier to swap out huge pages without requiring large chunks of contiguous space on the swap device. David Hildenbrand asked how large the virtual table would be, and whether it might suffer from fragmentation; Song answered that the table can be made large enough to avoid that problem.

Flash-friendly swapping

Swapping can generate a lot of I/O that, if not managed properly, can significantly shorten the lifetime of solid-state storage devices. Youngjun Park is working with embedded devices that make aggressive use of swap, and he would like those devices to not burn out their swap storage prematurely. This session was held jointly between the memory-management and storage tracks.

Flash storage, he said, will wear out over time. Rewriting of data will cause erase cycles, so copying data to the device will cause extra writes and extra wear. The built-in flash translation layer (FTL) has some support for wear leveling, but it is not enough, with the result that swapping is hard on flash devices. It creates a steady stream of random 4KB operations that challenge the wear-leveling algorithms, but flash-friendly write patterns do exist and can be made use of.

The embedded device in question swaps to RAM using a custom mechanism, similar to zram, that compresses pages in memory. These pages are flushed to persistent storage by a kernel thread that is registered as a shrinker; it performs sequential writes that are aligned to erase blocks. There is a deduplication layer that reduces write operations; in particular, there are a lot of matches with pages that were saved in previous hibernation rounds and do not need to be rewritten. The result, he said, is a big increase in the lifetime of the storage device.

Christoph Hellwig asked Park to share his code, "even if it's ugly"; that would help others to understand what is going on. Park answered that it is a implemented as a block device and hard to upstream; Hellwig said that the point was not to merge the code, but to push the discussion forward. There are some good ideas there, he said; the code would likely need a major restructuring, but it helps to have a working starting point.

Weiner asked if Park had looked at using zswap with some sort of writeback added on. The answer was that this option had been considered but (for unspecified reasons) not used. Wilcox said that he found the described approach surprising, that overwriting full erase blocks tends to work better. Chris Li commented that it is hard to discover the parameters that describe the optimal I/O patterns for a given device, and that he would like to encourage vendors to be more free with that information.

The final part of the session was focused on the fact that Park's system depends heavily on hibernation, which is the source of much of the swap traffic. Perhaps, it was suggested, it might be better to decouple swap and hibernation and make it possible to create a separate hibernation target that would still use the swap device, but would avoid the swap code and its I/O patterns.

Abstracting the swap backend

The swap subsystem was designed to interface directly with a block device, and it creates its block-I/O operations internally. There is interest, though, in the ability to put other types of devices at the storage layer of the swap subsystem. This concept, which goes by the name "swap_ops", was proposed for discussion by Baoquan He, but, as Li explained in the session, He had fallen victim to Red Hat's closure of its entire China-based development operation, so Li would be running the discussion instead.

The core idea behind swap_ops, he began, is that it would be a subsystem to enable modular swap backends and allow the customization of some swap behavior. It would be a virtual filesystem (VFS) layer for swap, he said. The idea was first proposed at the 2023 LSFMM+BPF gathering, and further discussed in 2024 and 2025. There are a number of similarities with the VFS; where the VFS has a superblock at the beginning of a filesystem, for example, the swap layer has its swap header. A file in the VFS is much like a folio in the swap subsystem, an inode is similar to a swap entry, and so on. But the swap_ops layer would have a much lower overhead, and would not support an equivalent to directories.

There is, Li said, a patch series implementing this concept; He updated the series on May 12. As an example of its value, Li pointed out that the zram subsystem is currently emulating a block device; it would be possible to remove a lot of code if zram were implemented as a swap_ops backend. Other possible backends could be a flash-friendly layer as Park had described, or even one that works with raw flash, though the room was not receptive to that idea. Eventually support for compressed page I/O could be added as well.

At the end, Li said that it might make sense to allow the backend to handle the allocation of swap slots. There is also work to be done to figure out the best way to move pages between backends. Li concluded there, and there were no questions from the group.

Security updates for Monday

corbet — Mon, 18 May 2026 12:59:35 +0000

Dist.	ID	Release	Package	Date
AlmaLinux	ALSA-2026:16482	9	freerdp	2026-05-16
AlmaLinux	ALSA-2026:17533	8	gimp:2.8	2026-05-16
AlmaLinux	ALSA-2026:16692	10	jq	2026-05-16
AlmaLinux	ALSA-2026:A010	10	kernel	2026-05-16
AlmaLinux	ALSA-2026:16195	8	kernel	2026-05-16
AlmaLinux	ALSA-2026:A008	8	kernel	2026-05-16
AlmaLinux	ALSA-2026:A009	9	kernel	2026-05-16
AlmaLinux	ALSA-2026:17481	8	rsync	2026-05-16
Debian	DSA-6273-1	stable	chromium	2026-05-15
Debian	DSA-6276-1	stable	ffmpeg	2026-05-15
Debian	DLA-4585-1	LTS	firewalld	2026-05-15
Debian	DLA-4587-1	LTS	kernel	2026-05-16
Debian	DSA-6274-1	stable	kernel	2026-05-15
Debian	DSA-6275-1	stable	kernel	2026-05-15
Debian	DSA-6278-1	stable	nginx	2026-05-16
Debian	DSA-6277-1	stable	openjpeg2	2026-05-15
Debian	DLA-4584-1	LTS	openssh	2026-05-15
Debian	DLA-4586-1	LTS	php7.4	2026-05-16
Debian	DSA-6279-1	stable	redis	2026-05-17
Fedora	FEDORA-2026-db5621b65e	F42	apptainer	2026-05-18
Fedora	FEDORA-2026-6c547e9f64	F43	apptainer	2026-05-18
Fedora	FEDORA-2026-d516d12934	F44	apptainer	2026-05-18
Fedora	FEDORA-2026-67a2a7275d	F42	chromium	2026-05-15
Fedora	FEDORA-2026-885a3f8c70	F44	chromium	2026-05-18
Fedora	FEDORA-2026-dfa8ea5809	F42	coturn	2026-05-18
Fedora	FEDORA-2026-f0fbd93125	F43	coturn	2026-05-18
Fedora	FEDORA-2026-3b3139882c	F44	coturn	2026-05-18
Fedora	FEDORA-2026-ac5cceec13	F44	dnsmasq	2026-05-15
Fedora	FEDORA-2026-c62259888c	F42	firefox	2026-05-15
Fedora	FEDORA-2026-8b4a8d18d2	F42	kernel	2026-05-15
Fedora	FEDORA-2026-03be3dc34b	F43	kernel	2026-05-15
Fedora	FEDORA-2026-2aeb7d033a	F44	kernel	2026-05-15
Fedora	FEDORA-2026-bb6bb5d1e4	F42	libgit2_1.8	2026-05-17
Fedora	FEDORA-2026-7b1d032de7	F43	libgit2_1.8	2026-05-17
Fedora	FEDORA-2026-a4d5162b52	F44	libgit2_1.8	2026-05-17
Fedora	FEDORA-2026-c618807faa	F44	libmetal	2026-05-18
Fedora	FEDORA-2026-38623b4fed	F42	nginx	2026-05-15
Fedora	FEDORA-2026-fb53cb4d67	F43	nginx	2026-05-15
Fedora	FEDORA-2026-094eb13bb1	F44	nginx	2026-05-15
Fedora	FEDORA-2026-38623b4fed	F42	nginx-mod-brotli	2026-05-15
Fedora	FEDORA-2026-fb53cb4d67	F43	nginx-mod-brotli	2026-05-15
Fedora	FEDORA-2026-094eb13bb1	F44	nginx-mod-brotli	2026-05-15
Fedora	FEDORA-2026-38623b4fed	F42	nginx-mod-fancyindex	2026-05-15
Fedora	FEDORA-2026-fb53cb4d67	F43	nginx-mod-fancyindex	2026-05-15
Fedora	FEDORA-2026-094eb13bb1	F44	nginx-mod-fancyindex	2026-05-15
Fedora	FEDORA-2026-38623b4fed	F42	nginx-mod-headers-more	2026-05-15
Fedora	FEDORA-2026-fb53cb4d67	F43	nginx-mod-headers-more	2026-05-15
Fedora	FEDORA-2026-094eb13bb1	F44	nginx-mod-headers-more	2026-05-15
Fedora	FEDORA-2026-094eb13bb1	F44	nginx-mod-js-challenge	2026-05-15
Fedora	FEDORA-2026-38623b4fed	F42	nginx-mod-modsecurity	2026-05-15
Fedora	FEDORA-2026-fb53cb4d67	F43	nginx-mod-modsecurity	2026-05-15
Fedora	FEDORA-2026-094eb13bb1	F44	nginx-mod-modsecurity	2026-05-15
Fedora	FEDORA-2026-38623b4fed	F42	nginx-mod-naxsi	2026-05-15
Fedora	FEDORA-2026-fb53cb4d67	F43	nginx-mod-naxsi	2026-05-15
Fedora	FEDORA-2026-094eb13bb1	F44	nginx-mod-naxsi	2026-05-15
Fedora	FEDORA-2026-38623b4fed	F42	nginx-mod-vts	2026-05-15
Fedora	FEDORA-2026-fb53cb4d67	F43	nginx-mod-vts	2026-05-15
Fedora	FEDORA-2026-094eb13bb1	F44	nginx-mod-vts	2026-05-15
Fedora	FEDORA-2026-c618807faa	F44	open-amp	2026-05-18
Fedora	FEDORA-2026-6f3d2d0d82	F44	perl-Net-CIDR-Lite	2026-05-15
Fedora	FEDORA-2026-cf2ba5b766	F42	pgbouncer	2026-05-18
Fedora	FEDORA-2026-fad57ac86d	F43	pgbouncer	2026-05-18
Fedora	FEDORA-2026-d3d959a176	F44	pgbouncer	2026-05-18
Fedora	FEDORA-2026-3505a95524	F43	pypy	2026-05-17
Fedora	FEDORA-2026-130f7539d3	F44	pypy	2026-05-17
Fedora	FEDORA-2026-793b55138d	F42	python-jupytext	2026-05-17
Fedora	FEDORA-2026-85b819b928	F43	python-jupytext	2026-05-17
Fedora	FEDORA-2026-301cbbe347	F44	python-jupytext	2026-05-17
Fedora	FEDORA-2026-8d8aee6aaf	F42	python-uv-build	2026-05-18
Fedora	FEDORA-2026-a8100094df	F43	python-uv-build	2026-05-18
Fedora	FEDORA-2026-7aacc8ea7d	F44	python-uv-build	2026-05-18
Fedora	FEDORA-2026-75599531db	F44	rsync	2026-05-15
Fedora	FEDORA-2026-8d8aee6aaf	F42	rust-astral-tokio-tar	2026-05-18
Fedora	FEDORA-2026-a8100094df	F43	rust-astral-tokio-tar	2026-05-18
Fedora	FEDORA-2026-7aacc8ea7d	F44	rust-astral-tokio-tar	2026-05-18
Fedora	FEDORA-2026-593d463bbf	F42	uriparser	2026-05-15
Fedora	FEDORA-2026-8d8aee6aaf	F42	uv	2026-05-18
Fedora	FEDORA-2026-a8100094df	F43	uv	2026-05-18
Fedora	FEDORA-2026-7aacc8ea7d	F44	uv	2026-05-18
Fedora	FEDORA-2026-114b1e5d3a	F42	valkey	2026-05-18
Fedora	FEDORA-2026-76cf27ea56	F43	valkey	2026-05-18
Fedora	FEDORA-2026-3e31dafe5c	F44	valkey	2026-05-18
Fedora	FEDORA-2026-7c3b91a2bc	F43	yelp	2026-05-17
Fedora	FEDORA-2026-ed4f450fa9	F44	yelp	2026-05-17
Mageia	MGASA-2026-0144	9	dpkg	2026-05-16
Mageia	MGASA-2026-0145	9	firefox, thunderbird	2026-05-16
Mageia	MGASA-2026-0143	9	golang	2026-05-16
Mageia	MGASA-2026-0146	9	haproxy	2026-05-17
Mageia	MGASA-2026-0142	9	samba	2026-05-16
Slackware	SSA:2026-135-01		dnsmasq	2026-05-15
Slackware	SSA:2026-135-02		kernel	2026-05-15
SUSE	openSUSE-SU-2026:10777-1	TW	ImageMagick	2026-05-15
SUSE	SUSE-SU-2026:1939-1	SLE15 oS15.6	PackageKit	2026-05-18
SUSE	openSUSE-SU-2026:10784-1	TW	apache-commons-configuration2	2026-05-17
SUSE	openSUSE-SU-2026:10785-1	TW	apache2	2026-05-17
SUSE	openSUSE-SU-2026:20730-1	oS16.0	apptainer	2026-05-15
SUSE	openSUSE-SU-2026:10786-1	TW	chromedriver	2026-05-17
SUSE	SUSE-SU-2026:1948-1	SLE15 oS15.6	cups-filters	2026-05-18
SUSE	SUSE-SU-2026:1940-1	SLE15 oS15.6	curl	2026-05-18
SUSE	SUSE-SU-2026:1934-1	SLE15 SLE5.3 SLE5.4 SLE5.5 SLE-m5.3 SLE-m5.4 SLE-m5.5 oS15.4	dnsmasq	2026-05-18
SUSE	openSUSE-SU-2026:10787-1	TW	expat	2026-05-17
SUSE	openSUSE-SU-2026:20726-1	oS16.0	ffmpeg-4	2026-05-15
SUSE	openSUSE-SU-2026:10768-1	TW	ffmpeg-7	2026-05-15
SUSE	SUSE-SU-2026:1868-1	SLE15	firebird	2026-05-15
SUSE	SUSE-SU-2026:1872-1	SLE15 oS15.6	firewalld	2026-05-15
SUSE	openSUSE-SU-2026:10769-1	TW	flux2-cli	2026-05-15
SUSE	openSUSE-SU-2026:10770-1	TW	glibc	2026-05-15
SUSE	SUSE-SU-2026:1862-1	SLE15	go1.25	2026-05-15
SUSE	SUSE-SU-2026:1861-1	SLE15	go1.26	2026-05-15
SUSE	openSUSE-SU-2026:0167-1	osB15	gosec	2026-05-16
SUSE	SUSE-SU-2026:21621-1	SLE-m6.0	grub2	2026-05-15
SUSE	openSUSE-SU-2026:10788-1	TW	java-11-openj9	2026-05-17
SUSE	openSUSE-SU-2026:10789-1	TW	java-17-openj9	2026-05-17
SUSE	openSUSE-SU-2026:10790-1	TW	java-1_8_0-openj9	2026-05-17
SUSE	SUSE-SU-2026:1955-1	SLE15	java-1_8_0-openjdk	2026-05-18
SUSE	openSUSE-SU-2026:10791-1	TW	java-21-openj9	2026-05-17
SUSE	openSUSE-SU-2026:10792-1	TW	java-25-openj9	2026-05-17
SUSE	openSUSE-SU-2026:20723-1	oS16.0	kdenlive	2026-05-15
SUSE	SUSE-SU-2026:1909-1	MP4.3 SLE15 SLE5.3 SLE5.4 SLE-m5.3 SLE-m5.4 oS15.4	kernel	2026-05-18
SUSE	SUSE-SU-2026:1904-1	SLE12	kernel	2026-05-18
SUSE	SUSE-SU-2026:1900-1	SLE15 SLE5.3 SLE5.4 SLE-m5.3 SLE-m5.4	kernel	2026-05-18
SUSE	SUSE-SU-2026:1907-1	SLE15 SLE5.5 SLE-m5.5 oS15.5	kernel	2026-05-18
SUSE	SUSE-SU-2026:1899-1	SLE15 SLE5.5 SLE-m5.5 oS15.5	kernel	2026-05-18
SUSE	SUSE-SU-2026:1908-1	SLE15 oS15.6	kernel	2026-05-18
SUSE	SUSE-SU-2026:21616-1	SLE16.0	kernel	2026-05-15
SUSE	SUSE-SU-2026:21622-1	SLE6.0 SLE-m6.0	kernel	2026-05-15
SUSE	openSUSE-SU-2026:10793-1	TW	kernel-devel	2026-05-17
SUSE	openSUSE-SU-2026:10779-1	TW	keylime-config	2026-05-16
SUSE	SUSE-SU-2026:21618-1	SLE-m6.0	krb5	2026-05-15
SUSE	openSUSE-SU-2026:10772-1	TW	libIex-3_4-33	2026-05-15
SUSE	SUSE-SU-2026:1870-1	SLE15 oS15.6	mozjs115	2026-05-15
SUSE	SUSE-SU-2026:1956-1	SLE15 oS15.4	mozjs78	2026-05-18
SUSE	SUSE-SU-2026:1953-1	SLE15 oS15.4	nginx	2026-05-18
SUSE	SUSE-SU-2026:1876-1	SLE15 oS15.6	openssh	2026-05-18
SUSE	SUSE-SU-2026:1871-1	oS15.4	openvswitch	2026-05-15
SUSE	SUSE-SU-2026:1952-1	SLE15	ovmf	2026-05-18
SUSE	SUSE-SU-2026:1954-1	SLE15	perl-Crypt-URandom	2026-05-18
SUSE	openSUSE-SU-2026:10773-1	TW	perl-CryptX	2026-05-15
SUSE	openSUSE-SU-2026:10780-1	TW	perl-Net-CIDR-Lite	2026-05-16
SUSE	openSUSE-SU-2026:10774-1	TW	perl-Text-CSV_XS	2026-05-15
SUSE	openSUSE-SU-2026:10781-1	TW	perl-libwww-perl	2026-05-16
SUSE	SUSE-SU-2026:1931-1	SLE15 SES7.1 oS15.3	podman	2026-05-18
SUSE	SUSE-SU-2026:1943-1	SLE15 oS15.6	postgresql17	2026-05-18
SUSE	SUSE-SU-2026:1944-1	SLE15 oS15.6	postgresql18	2026-05-18
SUSE	SUSE-SU-2026:21619-1	SLE-m6.0	python-pyOpenSSL	2026-05-15
SUSE	SUSE-SU-2026:21617-1	SLE-m6.0 SLE-m6.1	python-pyOpenSSL	2026-05-15
SUSE	SUSE-SU-2026:1947-1	SLE15 oS15.4	python310	2026-05-18
SUSE	openSUSE-SU-2026:10775-1	TW	rsync	2026-05-15
SUSE	SUSE-SU-2026:1941-1	SLE15 oS15.6	sed	2026-05-18
SUSE	openSUSE-SU-2026:10776-1	TW	tekton-cli	2026-05-15
SUSE	SUSE-SU-2026:1949-1	SLE15	valkey	2026-05-18
SUSE	SUSE-SU-2026:1950-1	SLE15 oS15.6	valkey	2026-05-18
SUSE	SUSE-SU-2026:1933-1	SLE5.5 SLE-m5.5 oS15.5	xen	2026-05-18
SUSE	SUSE-SU-2026:1951-1	SLE15	zypper-docker	2026-05-18

Kernel prepatch 7.1-rc4

corbet — Sun, 17 May 2026 21:39:26 +0000

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).

RIP Peter G. Neumann

corbet — Sun, 17 May 2026 19:36:06 +0000

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.

Some weekend stable kernel updates

corbet — Sun, 17 May 2026 17:43:12 +0000

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.

[$] Controlling memory management with BPF

corbet — Fri, 15 May 2026 14:54:56 +0000

By Jonathan Corbet
May 15, 2026

LSFMM+BPF

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.

Obstacles to BPF integration

Existing efforts have tried to capture a number of different memory-management heuristics, he began. There have been proposals to use BPF to control out-of-memory handling, NUMA balancing, memory control groups, page-cache eviction, and more. There are more interesting ideas that have not yet been pursued, including readahead control, madvise(), kernel samepage merging, and guest-memory control. Readahead, in particular, is a messy set of heuristics, but it is important for performance.

There are a number of obstacles to the addition of BPF interfaces for the memory-management subsystem, he said; he would cover them from the least important to the most. The first was concerns about out-of-tree BPF programs. Kernel developers want to see production-quality code land in the mainline, but that is not how BPF is working now. There are production-quality sched_ext schedulers, for example, but they are all stubbornly out of tree. BPF maintainer Alexei Starovoitov said that "sched_ext was a mistake", in that it did not bring any production schedulers with it into the mainline. That is a hard situation to fix now, he said. It would be good to have a good, in-tree out-of-memory handler; if nothing else, it would help developers to judge the proposed interfaces.

Including BPF programs in the kernel tree does not seem to be controversial, Gushchin said, so the real question is how far developers should go. A first step would be to just include the source for people to examine and play with. Automatic loading of included BPF programs could be a good second step, Starovoitov said; it would let people use the included BPF programs easily. Gushchin suggested that a BPF implementation of systemd-oomd would provide a good example of how that subsystem works.

Another obstacle is the current inability to attach struct ops programs to control groups. BPF programs can be attached, but not those using the struct ops interface. He has an implementation for the out-of-memory handler, but sched_ext uses a different solution.

Then, there is the issue of safety and fallback; a broken BPF memory-management program could easily make the system unusable. This is the hardest issue to solve, at least from Gushchin's perspective; it is hard even to define what "safety" means in this context. Time-based fallbacks are hard to implement and ugly, he said. Memory-management actions can be wrapped into monitored kfuncs, but that leads to non-generic solutions that can hurt performance. The acceptable level of service needs to be defined; a traffic-control program that drops all packets is OK, but a sched_ext scheduler that starves half of the tasks in the system is less so. What should happen if a faulty BPF program is loaded and the system can no longer reclaim memory?

There will always be concerns about performance in hot paths, which will make it hard to justify adding BPF programs in the hottest of them. The memory-management subsystem depends heavily on batching for performance, raising the question of whether BPF programs should run before or after batching is done. He suggested that batching should happen first, but that makes it impossible to control the batching itself with a BPF program.

Finally, the most important obstacle, he said, is ABI stability; this concern had been most recently raised by David Hildenbrand on the mailing list. In person, Hildenbrand said that there was some confusion about what providing hooks for BPF programs means; are they a permanent memory-management feature? The community may not want to commit to keeping those hooks around indefinitely. That concern has led to a decision not to provide hooks for the management of transparent huge pages; nobody knows what the picture will look like in five years, he said, so it will not be possible to get the interface right.

What will happen, he said, is that memory-management developers will wake up someday and realize that some aspect of the interface should be done differently. If they act on that realization, programs will break and people will get angry. Perhaps the solution is to only commit to supporting BPF programs that are maintained in the kernel tree itself. Hildenbrand concluded by saying that he sees the value of using BPF, but worries that adding interfaces may commit the subsystem to maintaining features that it regrets in the future.

The session was out of time at this point. At the conclusion, Gushchin said that it would be important to add only the most generic sorts of BPF hooks. So, for example, a hook to assign out-of-memory scores would be a bad idea, since a future out-of-memory killer might not use them. But a hook to free some memory under pressure, perhaps by killing some processes, could be useful.

Reimagining memory control groups

Butt followed immediately after with a discussion of how he might like to see the kernel's memory controller evolve, and how BPF might fit into that. He started by saying that the memory controller distributes memory resources hierarchically, implementing both hard and soft limits. Any given group will be allowed to use up to its hard limit when memory is plentiful, but will be squeezed back to the soft limit when memory is tight.

The memory controller has a number of challenges, he said. The enforcement of limits is inflexible and disruptive; since it happens synchronously, it can cause unexpected stalls in latency-sensitive threads. Its interfaces have proved hard to evolve, since significant changes will break the existing ABI, which kernel developers are not allowed to do. It would be nice, he said, to have a mechanism that would make it possible to experiment with alternatives.

The goal of a new interface would be to provide capabilities to support a wide variety of use cases. One example use case was provided in his session proposal and repeated during the session itself:

Policy: "keep system-level memory utilization below 95 percent; avoid priority inversions by not throttling allocators holding locks; trim each workload's usage to its working set without regressing its relevant performance metrics; collaborate with workloads on load shedding and memory trimming decisions; and under extreme memory pressure, collaborate with the OOM killer and the central job scheduler to kill and clean up a workload."

A new memory controller, he said, would need to provide memory-use notifications that applications can act on. It needs to support background reclaim, so that memory limits can be enforced without stalling running threads. Memory-use throttling should be aware of threads that hold locks to avoid priority-inversion problems. User space needs to be able to influence throttling in other ways, with the ability to, for example, identify specific threads that should be exempt to an extent. The controller should also support memory tiering, providing control over how pages are moved between tiers.

There was not much time to go into how this new interface would work; this effort, in general, appears to be in an early stage. Butt said that a new BPF callback, bpf_memcg_charge_succeed(), could be added to inform a BPF program about an increase in memory usage; that program might then respond by initiating background reclaim. Other callbacks could inform the program when a control group has reached a usage watermark (or hit a usage limit), relying on the program to provide hints on how to respond. That program might initiate some sort of reclaim, but it could also inform the application of the situation with the expectation that said application would respond by reducing its memory usage.

At the end, a member of the audience said that a useful feature would be the ability to introspect what types of memory an application is using; Butt answered that this feature was already being worked on.

Seven new stable kernels with patches for CVE-2026-46333

jzb — Fri, 15 May 2026 13:34:24 +0000

Greg Kroah-Hartman has announced the 7.0.8, 6.18.31, 6.12.89, 6.6.139, 6.1.173, 5.15.207, and 5.10.256 stable kernels. These kernels contain a patch for CVE-2026-46333 a vulnerability reported by the Qualys Security Advisory team, though Jann Horn proposed a patch in 2020. The vulnerability has a proof-of-concept exploit published already. Some of the kernels have additional patches for other bugs; as always, users are advised to upgrade.

[$] HugeTLB preservation over live update

corbet — Fri, 15 May 2026 13:27:42 +0000

By Jonathan Corbet
May 15, 2026

LSFMM+BPF

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 use case for live updates, Yadav began, is to replace the host kernel on a running system without disturbing the virtual machines running under that kernel. The kexec handover machinery marks regions of memory to be preserved during the kernel change; it is an in-kernel interface with no user-space API. Once memory has been marked, the kexec_load() system call is invoked to boot the new kernel, after which the preserved memory is restored to its owning process. The live update orchestrator provides the user-space interface to this feature, letting users mark resources to preserve and restore them on the new kernel.

Kexec handover and the live update orchestrator were merged during the 6.19 development cycle, with limited support for the preservation of files in memory-based filesystems. It can handle memfds (anonymous files created with memfd_create()) backed by shared memory, but not much else. That feature can be used to preserve the contents of a virtual machine, but running virtual machines in memfds is relatively inefficient. A virtual machine placed in a small number of huge pages (perhaps of the 1GB variety) from the hugetlbfs subsystem will run more efficiently, but that memory will not, yet, survive a live update.

Yadav's goals are to make it possible to carry those virtual machines (and their associated memory) through the live-update process. Preferably, it would be possible to obtain hugetlbfs pages by way of a special memfd, so that mounting hugetlbfs itself would not be necessary. The intent is to minimize the amount of preserved state; everything that is preserved becomes a part of the kernel's ABI, so less of it is better. He is also working to minimize the number of changes to hugetlbfs itself.

The feature works by first freezing the contents of the huge pages to be preserved, so that changes are not lost during the update process. There are two ways of doing that; the first would be to add a flag to the associated hugetlbfs inodes, then check that flag when changes are about to be made. The shared-memory filesystem works this way. In addition, the relevant memory would be pinned to prevent migration or compaction during the update. This option can work, but it is seen as a bit of a hack by some developers. The alternative is to make the filemap code aware of freezing by way of a new address-space flag; once again, the flag would be checked before allowing modifications. There are various details that have to be managed to make this option work correctly, meaning that the virtual filesystem layer has to be aware of the freezing process.

After the pages are frozen, some metadata about each — its size and position — is recorded. Both the frozen pages and the metadata are marked for preservation. Then the update can proceed.

Once the new kernel is running, a new hugetlbfs-backed memfd is created, and each of its component huge pages is placed back into use, with the hugetlbfs state being updated accordingly. Control-group charging for the allocated memory is done, and the new pages are added to the page cache. At that point, from the point of view of memory preservation, the update process is complete.

There is a bit of a complication regarding huge-page allocation, Yadav said. Hugetlbfs works by preallocating a set number of huge pages during the boot process. The restoration of a hugetlbfs-backed virtual machine will also allocate the necessary huge pages. In the original kernel, those pages were allocated from hugetlbfs; in the new kernel, instead, they are allocated separately. That can lead to over-allocation of huge pages in general. The solution is to count the number of preserved huge pages when the new kernel is booting, then to reduce the number preallocated by hugetlbfs accordingly.

An as-yet unsolved problem is the interaction of this feature with the contiguous memory allocator (CMA). If the original huge pages were obtained from CMA, the new pages need to be inserted back into CMA after the update, but CMA does not offer any way of extending its memory zone. So the current patches just disable the use of hugetlbfs with CMA if live update is enabled. Someday it will be possible to preserve the state of CMA as well, but that does not happen with the current version of this work.

Yadav closed with a status summary, saying that an RFC patch set had been posted in December 2025. As part of that work, he had found a number of problems with kexec handover that required some significant infrastructure work to fix. He will soon be posting an updated patch set, once he has responded to the feedback he has received.

The only question came from Mike Rapoport, who wondered if making CMA pages movable would help in its integration with kexec handover. Yadav said that such a change had a high chance of breaking things and probably would not help much.

Security updates for Friday

jzb — Fri, 15 May 2026 13:16:03 +0000

Dist.	ID	Release	Package	Date
Debian	DSA-6268-1	stable	ffmpeg	2026-05-14
Debian	DSA-6271-1	stable	gsasl	2026-05-14
Debian	DSA-6272-1	stable	nodejs	2026-05-14
Debian	DSA-6269-1	stable	postgresql-15	2026-05-14
Debian	DSA-6270-1	stable	postgresql-17	2026-05-14
Debian	DLA-4583-1	LTS	python3.9	2026-05-15
Debian	DLA-4582-1	LTS	thunderbird	2026-05-14
Fedora	FEDORA-2026-ee7b1c75b6	F43	GitPython	2026-05-15
Fedora	FEDORA-2026-b4653c757d	F44	GitPython	2026-05-15
Fedora	FEDORA-2026-4ef690dc30	F44	expat	2026-05-15
Fedora	FEDORA-2026-4542b2d7aa	F43	firefox	2026-05-15
Fedora	FEDORA-2026-dfde5fc92a	F43	freerdp	2026-05-15
Fedora	FEDORA-2026-5e5a0f9621	F43	kernel	2026-05-15
Fedora	FEDORA-2026-6b173ffc2a	F44	kernel	2026-05-15
Fedora	FEDORA-2026-c4d1ca4f16	F43	php	2026-05-15
Fedora	FEDORA-2026-5619c60e85	F44	rust-podman-sequoia	2026-05-15
Fedora	FEDORA-2026-5619c60e85	F44	rust-rpm-sequoia	2026-05-15
Fedora	FEDORA-2026-5619c60e85	F44	rust-sequoia-chameleon-gnupg	2026-05-15
Fedora	FEDORA-2026-5619c60e85	F44	rust-sequoia-git	2026-05-15
Fedora	FEDORA-2026-5619c60e85	F44	rust-sequoia-keystore-server	2026-05-15
Fedora	FEDORA-2026-5619c60e85	F44	rust-sequoia-octopus-librnp	2026-05-15
Fedora	FEDORA-2026-5619c60e85	F44	rust-sequoia-openpgp	2026-05-15
Fedora	FEDORA-2026-5619c60e85	F44	rust-sequoia-sop	2026-05-15
Fedora	FEDORA-2026-5619c60e85	F44	rust-sequoia-sq	2026-05-15
Fedora	FEDORA-2026-5619c60e85	F44	rust-sequoia-sqv	2026-05-15
Mageia	MGASA-2026-0138	9	awstats	2026-05-15
Mageia	MGASA-2026-0141	9	libreoffice	2026-05-15
Mageia	MGASA-2026-0140	9	perl-HTTP-Tiny	2026-05-15
Mageia	MGASA-2026-0139	9	tomcat	2026-05-15
Oracle	ELSA-2026-13644	OL10	corosync	2026-05-14
Oracle	ELSA-2026-13657	OL8	corosync	2026-05-14
Oracle	ELSA-2026-16014	OL10	freerdp	2026-05-14
Oracle	ELSA-2026-16019	OL8	freerdp	2026-05-14
Oracle	ELSA-2026-16482	OL9	freerdp	2026-05-14
Oracle	ELSA-2026-16484	OL9	gimp	2026-05-14
Oracle	ELSA-2026-16875	OL8	git-lfs	2026-05-14
Oracle	ELSA-2026-15969	OL10	glib2	2026-05-14
Oracle	ELSA-2026-15953	OL8	glib2	2026-05-14
Oracle	ELSA-2026-15971	OL9	glib2	2026-05-14
Oracle	ELSA-2026-16692	OL10	jq	2026-05-14
Oracle	ELSA-2026-16252	OL8	jq	2026-05-14
Oracle	ELSA-2026-16693	OL9	jq	2026-05-14
Oracle	ELSA-2026-16062	OL10	kernel	2026-05-14
Oracle	ELSA-2026-50262	OL7	kernel	2026-05-14
Oracle	ELSA-2026-50262	OL8	kernel	2026-05-14
Oracle	ELSA-2026-50261	OL8	kernel	2026-05-14
Oracle	ELSA-2026-50271	OL8	kernel	2026-05-14
Oracle	ELSA-2026-50262	OL8	kernel	2026-05-14
Oracle	ELSA-2026-50261	OL9	kernel	2026-05-14
Oracle	ELSA-2026-50271	OL9	kernel	2026-05-14
Oracle	ELSA-2026-16206	OL9	kernel	2026-05-14
Oracle	ELSA-2026-50271	OL9	kernel	2026-05-14
Oracle	ELSA-2026-50260	OL9	kernel	2026-05-14
Oracle	ELSA-2026-50270	OL9	kernel	2026-05-14
Oracle	ELSA-2026-50261	OL9	kernel	2026-05-14
Oracle	ELSA-2026-16799	OL8	krb5	2026-05-14
Oracle	ELSA-2026-15968	OL10	libsoup3	2026-05-14
Oracle	ELSA-2026-16055	OL8	libtiff	2026-05-14
Oracle	ELSA-2026-15888	OL10	openexr	2026-05-14
Oracle	ELSA-2026-15887	OL9	openexr	2026-05-14
Oracle	ELSA-2026-15892	OL9	thunderbird	2026-05-14
Oracle	ELSA-2026-50270		uek-kernel	2026-05-14
Oracle	ELSA-2026-50260		uek-kernel	2026-05-14
Oracle	ELSA-2026-17075	OL10	yggdrasil	2026-05-14
Red Hat	RHSA-2026:17040-01	EL10.0	podman	2026-05-15
Red Hat	RHSA-2026:17287-01	EL9.6	podman	2026-05-15
Red Hat	RHSA-2026:16696-01	EL10.0	skopeo	2026-05-15
SUSE	SUSE-SU-2026:21615-1	SLE16.0	ImageMagick	2026-05-15
SUSE	openSUSE-SU-2026:10765-1	TW	amazon-ssm-agent	2026-05-14
SUSE	SUSE-SU-2026:21631-1	SLE-m6.1	avahi	2026-05-15
SUSE	SUSE-SU-2026:21584-1	SLE-m6.2	c-ares	2026-05-15
SUSE	SUSE-SU-2026:21583-1	SLE-m6.2	cairo	2026-05-15
SUSE	SUSE-SU-2026:21630-1	SLE-m6.1	containerd	2026-05-15
SUSE	SUSE-SU-2026:21599-1	SLE16.0	cpp-httplib	2026-05-15
SUSE	SUSE-SU-2026:21626-1	SLE-m6.0	dnsmasq	2026-05-15
SUSE	SUSE-SU-2026:21633-1	SLE-m6.1	dnsmasq	2026-05-15
SUSE	SUSE-SU-2026:21640-1	SLE-m6.2	dnsmasq	2026-05-15
SUSE	openSUSE-SU-2026:10766-1	TW	dovecot24	2026-05-14
SUSE	openSUSE-SU-2026:10767-1	TW	ffmpeg-4	2026-05-14
SUSE	SUSE-SU-2026:21607-1	SLE16.0	firefox	2026-05-15
SUSE	SUSE-SU-2026:21628-1	SLE-m6.0	helm	2026-05-15
SUSE	SUSE-SU-2026:21635-1	SLE-m6.1	helm	2026-05-15
SUSE	SUSE-SU-2026:21582-1	SLE-m6.2	iproute2	2026-05-15
SUSE	SUSE-SU-2026:1857-1	MP4.3 SLE15 SLE5.3 SLE5.4 SLE-m5.3 SLE-m5.4 oS15.4	kernel	2026-05-14
SUSE	SUSE-SU-2026:21610-1	SLE16.0	kernel	2026-05-15
SUSE	SUSE-SU-2026:21594-1	SLE16.0 SLE-m6.2	kernel	2026-05-15
SUSE	SUSE-SU-2026:21590-1	SLE16.0 SLE-m6.2	kernel	2026-05-15
SUSE	SUSE-SU-2026:21643-1	SLE6.0 SLE-m6.0	kernel	2026-05-15
SUSE	SUSE-SU-2026:21642-1	SLE6.0 SLE-m6.0	kernel	2026-05-15
SUSE	SUSE-SU-2026:21625-1	SLE6.0 SLE-m6.0	kernel	2026-05-15
SUSE	SUSE-SU-2026:21644-1	SLE6.0 SLE-m6.0 SLE-m6.1	kernel	2026-05-15
SUSE	SUSE-SU-2026:21636-1	SLE6.0 SLE-m6.0 SLE-m6.1	kernel	2026-05-15
SUSE	SUSE-SU-2026:21632-1	SLE6.0 SLE-m6.0 SLE-m6.1	kernel	2026-05-15
SUSE	SUSE-SU-2026:21641-1	SLE-m6.0	krb5	2026-05-15
SUSE	SUSE-SU-2026:21629-1	SLE-m6.1	krb5	2026-05-15
SUSE	SUSE-SU-2026:21581-1	SLE-m6.2	libtpms	2026-05-15
SUSE	SUSE-SU-2026:21608-1	SLE16.0	ongres-scram, ongres-stringprep, plexus-testing, maven, maven-doxia, mojo-parent, sisu	2026-05-15
SUSE	SUSE-SU-2026:21637-1	SLE-m6.1	openCryptoki	2026-05-15
SUSE	SUSE-SU-2026:21593-1	SLE-m6.2	openCryptoki	2026-05-15
SUSE	SUSE-SU-2026:21627-1	SLE-m6.0	openssh	2026-05-15
SUSE	SUSE-SU-2026:21634-1	SLE-m6.1	openssh	2026-05-15
SUSE	SUSE-SU-2026:21596-1	SLE16.0	perl-Text-CSV_XS	2026-05-15
SUSE	SUSE-SU-2026:21612-1	SLE16.0	php8	2026-05-15
SUSE	openSUSE-SU-2026:10759-1	TW	python-Twisted-doc	2026-05-14
SUSE	SUSE-SU-2026:21587-1	SLE-m6.2	python-lxml	2026-05-15
SUSE	SUSE-SU-2026:21603-1	SLE16.0	python-lxml	2026-05-15
SUSE	openSUSE-SU-2026:10758-1	TW	python311-GitPython	2026-05-14
SUSE	openSUSE-SU-2026:10760-1	TW	python311-click	2026-05-14
SUSE	openSUSE-SU-2026:10762-1	TW	rclone	2026-05-14
SUSE	openSUSE-SU-2026:10763-1	TW	regclient	2026-05-14
SUSE	openSUSE-SU-2026:10764-1	TW	syncthing	2026-05-14
Ubuntu	USN-8269-1	14.04 16.04 18.04 20.04 22.04 24.04 25.10 26.04	avahi	2026-05-14

[$] Policy groups for memory management

corbet — Thu, 14 May 2026 19:02:35 +0000

By Jonathan Corbet
May 14, 2026

LSFMM+BPF

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.

Resource management is designed deeply into control groups; this focus drives a core assumption that the resources granted to a parent group must be greater than or equal to the resources given to any of its child groups. Control groups are also organized into a unified hierarchy; that was a key requirement of the control-group redesign effort over a decade ago. But this design has limitations; it does not fit cases that do not conform to its resource-management model, the unified hierarchy does not work for all use cases, and control groups are not an effective tool for policies that are not tied to processes.

As an example of a policy that doesn't fit the resource model, he said, consider service-level objectives. A child group might be given a service level that is either faster or slower than its parent. An area of particular interest to Li is regulating access to swap devices of different speeds; the difficulty in adapting control groups to this model is impeding the upstreaming of the swap-tiers work. A case that doesn't fit the unified hierarchy would be the Android distinction between foreground and background tasks; applications can perform some of that organization internally, but what they come up with may not fit the system's view of the process hierarchy. Non-process cases include control over filesystem allocation and network-control policies.

The proposed policy groups, which would be attached to control groups in an unspecified way, would address these limitations. Policy groups would be focused on managing policies rather than resources and would not be forced into the same hierarchical model. There have been other attempts at this sort of control, he said, including network namespaces, NUMA memory policies, and the use of prctl() to control behaviors like kernel samepage merging. Policy groups would bring a more formalized structure to this kind of feature.

Liam Howlett said that policy-related features typically use prctl(), and asked whether that is really a good fit for this task. There are, he suggested, a lot of features stuffed into prctl() that should perhaps be implemented differently. Suren Baghdasaryan asked why policy groups would be associated with control groups if the policies to be enforced are not hierarchical in nature; Li answered that there is still a need to attach policies to the process hierarchy.

Lennart Poettering said that the control-group redesign moved that subsystem away from independent hierarchies, which was a good thing; it would be better to avoid bringing that concept back. In more recent kernels, it is possible to attach extended attributes to control groups; these, he suggested, could be used to attach policies. The BPF Linux security module uses extended attributes attached to control groups in this way. Extended attributes, he said, might well be a good fit for policy groups as well. Li answered that this approach might work for some cases, but not for those that are not inherently tied to processes.

Roman Gushchin said that policy groups probably should not be attached to control groups at all. Another participant said that grouping all these policies under a single framework might be a mistake. It could be better, he said, to attach some policies to a filesystem, and others to a control group, for example. While an overall policy framework might be useful, nobody has ever figured out a generally applicable solution.

Li asked whether the right approach might be to create a new policy-group virtual filesystem; it might present a flat view rather than implementing a hierarchy. Poettering answered that he is not looking forward to dealing with yet another control interface from the kernel. Li asked how Poettering would suggest setting a process's service level for swap; Poettering repeated the extended-attributes idea.

The discussion lost focus as time ran out; a suggestion to add a new namespace type did not get a lot of support. It was seemingly agreed that it would be better to not add a new control structure if possible. Using BPF was suggested, but there are systems (especially in the embedded area) that do not support BPF, so Li said he would prefer to avoid that approach. The session closed with Li saying that he would look more closely at ways of attaching policies directly to processes.

[$] Buffered atomic writes, writethrough, and more

jake — Thu, 14 May 2026 14:54:26 +0000

By Jake Edge
May 14, 2026

LSFMM+BPF

In back-to-back sessions at the start of the 2026 Linux Storage, Filesystem, Memory Management, and BPF Summit (which spilled over into a third slot), the atomic-buffered-writes feature was discussed. In the first session, Pankaj Raghav and Andres Freund set the stage with an introduction to the problem, along with a use case for its solution: the PostgreSQL database system. In the second, Ojaswin Mujoo described a potential way forward for the feature using an approach based on writethrough, which effectively means that the kernel immediately writes the data to disk instead of waiting for writeback from the page cache to occur. As might be expected, there was quite a bit of discussion among the assembled filesystems and storage developers during the combined sessions for those tracks.

Freund began by describing what PostgreSQL currently does to prevent torn (partial) writes of its 8KB default pages; without atomic guarantees from the block layer, it uses its full-page-writes feature to write to the write-ahead log (WAL) in order to ensure that the pages are fully written. There are a number of benefits that would come with atomic 8KB writes: for example, turning off full page writes results in around 1.7x more transactions per second (TPS) with a 14x reduction in the variability of the TPS as well. It would also reduce the write amplification factor (WAF) because the pages would not need to be written twice to ensure their integrity on disk. Meanwhile, continuous archiving with point-in-time recovery requires storing the WAL in the archive logs, which can add up to a significant amount of storage quickly, he said. A simple benchmark showed a 14x increase in accumulated WAL size when full page writes is used.

An attendee asked what atomic page size PostgreSQL needed. Freund said that PostgreSQL would like to be able to write in larger chunks than 8KB, but that it only needed assurance that 8KB chunks would not be torn. Randy Jennings asked if the storage needed to be able to support these atomic writes; Freund said that it was required for the atomic-write feature.

Ted Ts'o pointed out that the "whole atomic-writes saga" has been going on for years; it has featured in multiple prior summits, for example. It started, he said, because the software-defined storage used by the cloud vendors could provide the atomic guarantees needed by databases that were using direct I/O; performance improvements of 2x were common using that feature. Now, databases that use buffered writes, like PostgreSQL, would like to get those same performance boosts, which is why the buffered-atomic-writes feature has arisen. That is especially true now that NVMe devices can provide the same atomic-write granularity as has been available for cloud storage, he said.

Raghav explained why writeback, which is used for buffered I/O, is fundamentally incompatible with atomic writes. Leaving pages in the page cache until writeback occurs provides a large window in time where the pages could be modified. Also, if there is memory pressure, page faults or reclaim could potentially result in a torn write.

So a new flag, RWF_WRITETHROUGH, has been proposed for pwritev2(), which will copy the data to the page cache and immediately issue a direct I/O to write the data from the provided buffer to the block device. Matthew Wilcox asked how the new flag differs from RWF_DSYNC; Jan Kara said that RWF_DSYNC provides a much stronger guarantee that the write operation has completed successfully all the way down to the disk. RWF_WRITETHROUGH simply indicates that the write has been issued. The RWF_WRITETHROUGH flag does not implement the atomic behavior; that would have to be added as a separate feature using the flag, Raghav said.

Christoph Hellwig said that he is not a fan of PosgreSQL's use of buffered I/O, which drives the need for buffered atomic writes, but did not have a problem with RWF_WRITETHROUGH. "I think he said 'no objection'", Amir Goldstein said to laughter.

John Garry wondered how the pwritev2() call could know for sure that the hardware can support an atomic write and determine what alignment is required to perform it. Raghav said that the plan was to use the same mechanism that is used for direct I/O (O_DIRECT) atomic writes. Ts'o said that the problem had already been solved for O_DIRECT; the alignment requirements come from the block device and using pwritev2() with the RWF_ATOMIC flag says that all of the buffers are properly aligned.

Wilcox suggested starting out small, perhaps by implementing RWF_DSYNC using the direct I/O that RWF_WRITETHROUGH does after copying the data to the page cache. But Hellwig did not think that literally using the direct-I/O path from the write made sense; simply implementing it with a regular block write might be better. The direct-I/O path handles a lot of corner cases that may not need to be considered, but he said that it was only a "gut feeling" so it was worth trying it to see. He noted that some developers have complained about the complexity of the direct-I/O code path, so maybe this effort could be a starting point for a simpler interface.

Writethrough

Next up was Mujoo, who began with a timeline of support for atomic writes in the kernel. For direct I/O, Linux 6.13 in January 2025 could write a single filesystem block atomically. In June 2025, the 6.16 kernel added the ability to handle multiple filesystem blocks atomically. On the buffered-I/O side, there have been three designs, culminating in the writethrough approach in April 2026. The first two designs suffered from the problem that there is no easy way for a given write operation to communicate with the writeback path to ensure that it is treated atomically.

As noted in the previous session, the writethrough approach avoids that problem by immediately initiating the I/O to the device from the pwritev2() call. That avoids the need to track atomic ranges for page-cache pages. Tracking those ranges made the first two designs more complex, so combining the write path with the I/O-submission path looks to simplify things. There may be other uses beyond atomic writes that can use the same technique, he said.

He stepped through a flow chart that described the writethrough mechanism. From the write, the data is copied into the page cache, a bio_vec is created from the folio range, and an I/O operation is initiated. If it is not an asynchronous write, the initial write awaits the completion of the block I/O and then returns to the caller. For an asynchronous I/O, the I/O completion is handled by a workqueue in the background, similar to the way it is done for direct I/O.

There are several use cases, he said. Buffered atomic writes can be based on writethrough without needing extra code to track atomic ranges. Writes with RWF_DSYNC can use writethrough to support asynchronous buffered writes by moving the call to generic_write_sync() from the submission to the completion phase; writethrough provides the shared context between the two phases. Likewise, other use cases that need tracking between the write and the writeback, such as RWF_DSYNC with forced unit access (FUA) and RWF_DONTCACHE writes, may be able to use writethrough.

He put up some performance graphs that showed 35-60% improvements in write speed when doing random writes to separate files from multiple threads. But they also showed up to a 65% performance decrease when all of the threads are writing to the same file. He believes that is due to contention on the inode lock, which is held within the I/O-submission path.

Ts'o wondered if that performance degradation would be a problem in practice for PostgreSQL. Freund said that there are multiple threads writing, but it is not clear to him whether there would be a lot of concurrent writing to the same file with real workloads.

Hellwig thought that the critical section holding the inode lock could be reduced, as there is no real reason to hold it throughout the I/O-submission process. Mujoo said that he could look at splitting out some of the code that currently runs with the inode lock held, which Hellwig thought should be doable and might help simplify some other code paths.

There was some discussion of the need to prevent writeback occurring on the pages in the page cache while the writethrough operation is being performed. There is a need to prevent modification of the in-flight buffer, which could interfere with checksums and the like, Hellwig said; that can be accomplished by taking the writeback lock. The default mode for the iomap layer is to submit its I/O without holding the page lock, just the writeback lock, he said.

The discussion turned to reducing contention on the xa_lock and possibly using a shared lock for aligned, buffered I/O, as is used for direct I/O. Kara seemed to think it was a reasonable idea and Hellwig suggested that the right time to introduce such a lock was when a new flag (e.g. RWF_WRITETHROUGH) was being added. The proposed writethrough feature is much the same as RWF_DSYNC, Hellwig said, except that it does not guarantee that the block device actually flushes its cache to disk. If a shared lock is added later, a new flag will need to be added at that time to govern its use, so it makes sense to just include that with the writethrough feature in his mind.

io_uring

Josef Bacik said that he hated having this kind of conversation and wanted to step back and look toward avoiding all of the various special cases in the I/O path that are handled by adding new flags. "What we should be doing here is just rethinking how we do this"; he suggested looking at io_uring as a potential solution. Each of the low-level operations needed for I/O (update the page cache, submit the I/O operation, etc.) would be a separate io_uring operation that can be built up into whatever style of I/O user space wants.

Doing so would allow user space to "mix and match all of these different features" and avoid needing the kernel developers to figure out how new pwritev2() flags interact for all of the different special cases. Christian Brauner was concerned that the same problems would eventually arise for an io_uring-based solution; in a few years, there would need to be discussions about how the different operations interact. Hellwig did not see why moving the problem into io_uring would make the situation any better, though he found Bacik's description to be fairly abstract.

Goldstein worried that it would be difficult for users to understand how to use the io_uring interface; meanwhile, the flags are a way to limit the number of different ways the operations can be combined, so moving to io_uring would substantially increase the testing matrix required. Bacik said that every new use case brings a slight wrinkle to how the write operation interacts with the page cache, writeback, iomap, and so on; of the full matrix that might be exposed, the flags limit the choices, but that ends up leading to more flags.

I/O testing already "sucks" and moving to io_uring would potentially make that worse, he said. But "it pushes the complexity of what user space wants down to user space", which is better than cementing various heuristics and policy decisions into the kernel code. That results in user-space developers being unhappy because their specific use case is not one of the ones supported—followed by another flag proposal and long discussions on the mailing list and at the summit.

Ts'o said that they would need to see the code before being able to determine whether the approach was viable, but his concern was that locks would need to be taken multiple times for the various sub-operations. There might be a way to analyze the series of operations in order to optimize the locking, but without that, performance may suffer compared to what there is today. Analyzing the operations and combining the lock acquisition would also increase the test matrix because it would make things dependent on the order of operations "and this scares me".

Hellwig wondered what concrete io_uring operations were being talked about, as he still found the discussion to be too abstract. Brauner asked: "Why is Jens [Axboe] so silent?". That was met with laughter and, eventually, a response from Axboe, who is the io_uring maintainer, but it was clear that he did not have strong feelings about the idea. Bacik said that it simply did not make sense to "add a new flag every two years" to do some "new, special thing".

The complexity of the new io_uring commands led to worries that most developers would not be able to use them; there is a reason that the kernel developers are defining how the different kinds of I/O should be done. Bacik said that the synchronous-I/O options could continue being handled with flags of various sorts, but that newer, fancier asynchronous use cases could be pointed at the io_uring-based approach.

Hellwig was somewhat skeptical that the various operations could be fully defined with their semantics clearly specified, but even then the testing becomes burdensome. Others were not so sure that it would change the testing picture all that much in comparison to all of the existing flags and combinations of them. Brauner worried that changes to the semantics of writes would continue and that in five years, say, the same kinds of discussions would have to happen for an io_uring-based solution; it may just be kicking the can down the road.

After Axboe pointed out that system calls could be added instead, Bacik wondered, perhaps not entirely seriously, if instead of io_uring he should have proposed "17 new syscalls"; he simply thought that io_uring "sounded better". He is concerned that trying to shoehorn all of a feature under a single all-encompassing flag leads to problems; finding a way to split up the pieces that are composed to perform the I/O would make more sense.

There was some discussion of the overall design of the I/O API that currently exists versus what might be done differently if the kernel developers were to start over. For example, Ts'o noted that O_DIRECT was designed by Oracle several decades ago and filesystems implement it differently because it was not clearly specified. But any overhaul of the API will not be used widely for multiple years and, meanwhile, the current API will have to be maintained.

Goldstein summarized that part of the discussion as the session concluded by saying that adding a new flag is probably the easier approach because user-space developers are used to the system-call API and understand it. But the flag should be well-documented first, so that reviewers can try to ensure that it makes sense and fits with everything else. If it cannot be clearly specified, that is a pretty clear indication that the feature is not on the right track.

[I would like to apologize for any errors here. The acoustics in the room were problematic for both hearing and recording. Misunderstanding and misidentification may have resulted.]

Three stable kernels for Thursday

jzb — Thu, 14 May 2026 14:44:32 +0000

Greg Kroah-Hartman has announced the release of the 7.0.7, 6.18.30, and 6.12.88 stable kernels. These kernels do not include a patch for the Fragnesia local-privilege-escalation exploit that came to light on May 13, but do include many other important fixes throughout the tree. Users are, as always, advised to upgrade.