Welcome to the LWN.net Weekly Edition for May 7, 2026

This edition contains the following feature content:

• LLM-driven security reports disrupt coordinated disclosure: well-orchestrated disclosure of security vulnerabilities may be a thing of the past.
• Restartable sequences, TCMalloc, and Hyrum's Law: Linus decrees regression rules apply, even when a program violates the documented ABI.
• Bug-monitoring expectations and Fedora GNOME packages: FESCo requires tweaks to an automatic response saying GNOME bug reports are not actively monitored.
• Version-controlled databases using Prolly trees: a look at a B-tree variant used to support efficient version control for databases.
• Hardware-assisted Arm VMs for s390: work to enable Arm VMs on s390 may lead to better testing, debugging, and documentation of both architectures.

This week's edition also includes these inner pages:

• Brief items: Brief news items from throughout the community.
• Announcements: Newsletters, conferences, security updates, patches, and more.

Please enjoy this week's edition, and, as always, thank you for supporting LWN.net.

Comments (none posted)

LLM-driven security reports disrupt coordinated disclosure

Predictions that LLM tools would cause a surge in reports of security vulnerabilities have, unquestionably, borne out. As expected, maintainers are having to wade through more security reports than ever before; in addition, LLM tools are disrupting traditional-coordinated disclosure practices as well. The method of Copy Fail's disclosure, in particular, left vendors, projects, and users scrambling. In addition, maintainers are seeing parallel discovery of the same security flaws within the embargo window. Both of these developments mean that coordinated security disclosures may become a thing of the past.

"Mining security gold"

Jeremy Stanley, a member of the vulnerability management team for the OpenStack cloud-computing project, brought this topic to the OSS Security mailing list on April 28. He said that projects he worked on "are under a seemingly unending deluge of reports from researchers using LLMs to mine for security gold in our software". That had led to him thinking about the risks that public LLM services might pose to traditional vulnerability-handling workflows, embargoes, and coordinated disclosure of security flaws. He wondered if it would be helpful to keep embargoes short to mitigate the risks of parallel discovery or disclosure to other LLM users.

I'm sorely tempted, both due to the increased volume and the risk of premature disclosure, to just assume that any vulnerability reported as a result of research using an LLM is trivially discoverable by others, and give up trying to pretend there's any point to working it under embargo. Similarly, it makes sense to me that patch development and descriptive prose shouldn't be produced with LLM assistance for any vulnerability that is being worked under an embargo.

He said that he could not be the only one thinking about this topic, and asked what others thought. Jacob Bachmeyer replied that parallel discovery was a big risk: "If an LLM can find a bug for a whitehat, it can do the same for a blackhat. [...] LLM-discovered vulnerabilities should be considered already publicly known".

Effect on embargoes

If the vulnerabilities are (arguably) known to multiple people, the question arises of whether standard practices around security embargoes still make sense. Lucas Holt said that he saw "the logic and temptation" of shortening embargoes, but dropping a zero-day exploit on a small project would not help anyone. He suggested that large projects may have multiple people looking for and discovering the same flaws, but smaller projects were unlikely to have multiple people probing them for vulnerabilities at the same time.

Stanley clarified that he was approaching the problem from the perspective of "an upstream maintainer and vulnerability coordinator of large/popular projects receiving these reports". He was seeing a flood of reports, and that trying to manage all of them in private was leading to "accidents breaking our embargoes before things are ready or distros/deployers have been given sufficient advance warning". If security reports were public immediately, he thought projects could crowdsource help from a larger portion of their community "rather than relying solely on overwhelmed vulnerability coordinators and security-focused maintainers".

Holt had suggested that people who used LLMs to find security bugs could also use their tools to create patches. Brian May warned people to be careful of that approach. "Simple patches that look good can in fact be hiding serious security issues. Thinking of the September 2006 Debian openssl issue here."

Greg Dahlman also thought that LLMs were unreliable when it comes to creating security fixes. He described the ability of current LLMs to produce correct and secure code as being within "the coin flip range"; in other words, he thought there was only a 50-50 chance that an LLM's suggested solution to fix a flaw would be adequate. Therefore, any embargo timeline needed to take into account the asymmetry between the time it takes to discover a flaw and the time needed to actually fix it.

Already happening

It turns out that Stanley's hypothesis about parallel discovery had already been proven in the wild. Clemens Lang, who works on the Red Hat Enterprise Linux (RHEL) crypto team, provided a data point to support the theory: "We're seeing duplicate reports of the same issue found by multiple independent groups that use LLMs, within the embargo period." Greg Kroah-Hartman also reported that kernel developers were "seeing duplicate reports of the same issue from different groups within the time period it takes to get a fix merged".

Willy Tarreau said that he had predicted the death of security embargoes months ago:

Embargoes now play against security, for all the time we don't act, users stay exposed to anyone having the luck to find the same problem. It's not a matter of the LLM's strength but a matter of determination by the researcher who could simply run a small model several times helping it dig further. Bigger models just find faster, but that only counts for those seeking protection, not for those trying to attack.

Copy Fail disclosure fail

The Copy Fail privilege-escalation vulnerability (CVE-2026-31431) was announced on April 29 by Xint. It is a "straight-line logic flaw", meaning that it does not require race conditions or other special circumstances, that allowed local users to trivially get root access on most Linux distributions unless they had the most up-to-date kernels.

Along with the announcement, there was a proof-of-concept (POC) Python script that allowed users to see if their systems were vulnerable. The fix had already been included with the 7.0, 6.19.12, and 6.18.22 kernels, but was not available as a backport to older stable kernels until April 30. Most Linux distributions were caught with their proverbial pants down. On April 30, with a POC showing how to exploit the vulnerability widely available, major distributions such as Debian, Red Hat Enterprise Linux, SUSE, and Ubuntu had no fix ready for their users.

It was described as "one of the worst make-me-root vulnerabilities in the kernel in recent times" by Eddie Chapman on the OSS Security list. He wondered what went wrong:

Has the embargo been broken early today? Not looking to point any fingers, those who make things happen in our communities work dam hard and deserve respect and support, especially with the extra burden of AI slop now.

Gentoo contributor Sam James said that it's up to security reporters to notify Linux distributions of kernel vulnerabilities: "unless the reporter chooses to bring it to the linux-distros [mailing list], there is no heads-up to distributions. It did not happen here."

The discussion turned to something of an ad-hoc postmortem, fingerpointing, and problem-solving session. Alexander Peslyak, who goes by "Solar Designer", said that distributions had little way of knowing about the importance of this vulnerability, as it did not stand out among all the others.

The vulnerability was reported to the kernel team on March 23, according to the timeline in Xint's announcement. A patch was committed to the mainline kernel on April 1. CVE-2026-31431 was added to the kernel's security repository on April 25, with a Common Vulnerability Scoring System (CVSS) score of 7.8 (out of a possible ten), four days before the Copy Fail announcement. Peslyak pointed out that there were 168 CVEs in the batch from that day, with scores between 7.1 and 9.8. "By the score alone, this one really does not stand out. To me, this is usual noise, with little signal in there." It did not hint at the severity or imminent threat of a POC being released. In fact, there are 21 CVEs added on April 25 that have a "9.8 CRITICAL" CVSS score.

Greg Kroah-Hartman replied that the kernel team's "constant message", for decades, has been that users must upgrade to the latest release to ensure that they have all of the fixes for currently known issues. He added that the kernel team had no knowledge of the Copy Fail announcement ahead of time "as no one is obligated to tell us that they are about to let loose a trivial exploit", and that the team was not allowed to notify others ahead of time, lest they have to tell everyone about everything. "That's the only policy by which all the legal/governmental agencies have agreed to allow us to operate in, so we are stuck with it."

On May 3, James shared a link to a comment from Brian Pak of Xint that said the company had provided a fully working exploit to the kernel security team when the vulnerability was reported. "We've since learned that such details don't automatically get forwarded downstream and that Linux kernel commit messages are typically kept minimal. That's simply how the process works." James said that the kernel team "were very much aware of the impact from the offset", and inquired if the kernel team was "honestly proud of how this went".

The CVE garbage patch

Kroah-Hartman asked exactly what James would suggest that the kernel team do better, and how it should do it. He added that the team receives bug reports of local-user privilege-escalation bugs all the time; it was not obvious that this one was special until after the fact because the submitter used it to show off their software. "That is something that normally does not happen and is outside of the control of all of us involved here." Emily Shepherd wanted to know if the POC or a description of the flaw's severity had been provided; Kroah-Hartman replied that he honestly did not remember because "that was months and hundreds, if not thousands, of reports ago". He also reminded the list how the kernel security team operates:

The job of the kernel security team is to triage a bug report, drag in the relevant maintainer/developer, get the issue fixed and merged into Linus's tree as soon as possible. Once it lands in Linus's tree, our role is over.

We do not do "announcements" of anything to anyone, so even if this was a "look how bad you can abuse the system" type of thing, we would not be telling anyone anything.

He added that he's documented this in detail, given many talks about it, and has been blogging about it as well.

On social media, Josh Bressers suggested that the blame lies with the company: "every AI vulnerability company wants to find something juicy, and have no idea how to coordinate the findings". Kroah-Hartman dismissed the idea that coordination of vulnerabilities was even possible now. Bressers agreed: "I do think you're right that the traditional disclosure model is gone forever". He did think it was "pretty obvious" that Copy Fail would be a big one; but he had no idea what to do to prevent important vulnerabilities from drowning in the "great CVE garbage patch".

Copy Fail is just one vulnerability out of thousands. At the rate that LLM tools seem to be speeding up discovery, it does seem that Kroah-Hartman has a point. Traditional disclosure notification is becoming increasingly difficult, if not outright impossible. The volume of reports, coupled with the fact that many AI-assisted reporters will be unfamiliar with how security disclosure usually works, means that relying on embargoes and coordinated fixes is going to be increasingly risky. We live in interesting times for open-source security, whether we want to or not.

Comments (28 posted)

Restartable sequences, TCMalloc, and Hyrum's Law

Hyrum's Law states that any observable behavior of a system will eventually be depended upon by somebody. The kernel community is currently contending with a clear demonstration of that principle. The recent work to address some restartable-sequences performance problems in the 6.19 release maintained the documented API in all respects, but that was not enough; Google's TCMalloc library, as it turns out, violates the documented API, prevents other code from using restartable features, and breaks with 6.19. But the kernel's no-regressions rule is forcing developers to find a way to accommodate TCMalloc's behavior.

As a quick reminder: the restartable sequences feature, accessed by way of the rseq() system call, provides a mechanism for the execution of brief critical sections in user space. A shared-memory segment is used to communicate to the kernel when a critical section is active, and the kernel can redirect execution if the running thread is preempted or migrated during that critical section. There are a number of associated features, including the ability to quickly determine which CPU a thread is running on; the time-slice-extension feature merged for the 7.0 release is also tied to restartable sequences.

TCMalloc trouble

On April 22, Mathias Stearn reported two problems with TCMalloc resulting from the 6.19 improvements to restartable sequences. One of them turned out to be a simple bug in the 64-bit Arm implementation, tied to the fact that the Arm architecture does not yet fully use the generic entry code. This bug is uncontroversial and will be fixed like any other. The second problem, though, has deeper origins.

The memory shared between the kernel and user space for restartable sequences includes an instance of struct rseq; that structure contains a number of fields, one of which, in particular, is of interest for this discussion. The 32-bit cpu_id_start field contains the number of the CPU on which the thread is running. This value, which is maintained by the kernel, is explicitly defined as a read-only value for user space, and is guaranteed to always contain a valid CPU number, even if restartable sequences are not in use.

Prior to the 6.19 release, the kernel would update cpu_id_start on every return from the kernel to user space, regardless of whether the CPU number had changed or not. Storing a single integer value does not seem like an expensive operation, but looks can be deceiving; many CPUs have features that prevent the kernel from randomly changing user-space memory. Turning off that protection (and re-enabling it after the store) is expensive. Removing the redundant stores improved performance by 15% for many workloads without changing the restartable-sequences ABI in any way — or so it seemed.

The TCMalloc library makes extensive use of restartable sequences to improve performance. Notably, while it does use this feature for critical sections, it also uses it to detect scheduling interruptions outside of critical sections. The trick (to avoid more pejorative terms) used is described in detail in this document. In short, TCMalloc's internal data structures are designed to overlay the shared struct rseq so that cpu_id_start becomes the upper four bytes of an internal cache pointer. When TCMalloc stores this pointer, the result is to write zeroes into cpu_id_start; the topmost bit is set, though, to distinguish the contents of cpu_id_start from any valid CPU number. When the kernel stores into cpu_id_start, it will end up clearing that top bit, enabling TCMalloc to quickly detect the change and regenerate that pointer.

The key point is that TCMalloc needs that signal for any sort of interruption, even if the running thread did not move to a new CPU. Pre-6.19 kernels would always overwrite cpu_id_start — an undocumented but observable behavior — providing TCMalloc with that signal; as of 6.19, that overwriting only happens if the thread migrates to a new CPU. As a result, TCMalloc, which has come to depend on that undocumented behavior, ends up leaving a smoking crater in the middle of any application that is trying to use it.

A regression?

The problematic nature of this behavior has been widely known for some years; the above-linked documentation advises that, since cpu_id_start can no longer be counted on to hold the current CPU number, "this makes __rseq_abi.cpu_id_start unusable for its original purpose". In other words, no other code running within a TCMalloc-using thread can use restartable sequences and expect it to work. That is somewhat awkward, given that one other user of the feature is the GNU C Library (glibc), as of version 2.35. Back in 2022, this problem was reported in the TCMalloc issue tracker and a change of behavior was requested but, despite a fair amount of discussion, no change was ever made. As a result, code using TCMalloc must be run with an environment variable set to prevent glibc from trying to use restartable sequences.

Kernel developers have had a dim view of this behavior for a while. Unsurprisingly, that view became rather dimmer yet when users started complaining that the 6.19 release broke TCMalloc entirely. The behavior described above violates the documented restartable-sequences ABI and makes the feature unusable for anybody else. It would have been detected by the kernel's debugging facilities, but those were clearly never used with TCMalloc, since they would have caused an immediate killing of the offending thread. In the issue discussion, kernel developers had offered an extension to restartable sequences to let TCMalloc stop overwriting cpu_id_start, but that offer was not accepted. The result, as Thomas Gleixner described it, is "everyone is in a hard place and up a creek without a paddle".

Gleixner made it clear that he thought TCMalloc's difficulties should not be considered to be a kernel regression, since the documented ABI guarantees are still being upheld by the kernel and the debugging feature would have caught the problem years ago. Linus Torvalds, though, was just as clear that the only thing that matters is that a once-working program stopped working as the result of a kernel change: "This is not some kind of gray area. It clearly violates our regression rules".

This response was clearly expected by Gleixner, though he still did not like it: "Feel free to enforce it, but be aware that you thereby set a precedence that a single abuser can then rightfully own a general shared interface of the kernel forever and force everybody else to give up". Glibc developer Florian Weimer was also unhappy, pointing out that TCMalloc's use breaks the modular design of the restartable-sequences ABI. Torvalds, though, was adamant that a fix had to be found.

Now what?

Various options for fixes were discussed; Stearn had been working on a simple, low-cost option that, seemingly, has not worked out. Another option, of course, is to simply go back to always updating cpu_id_start and accepting the associated performance penalty; there are not many supporters of this approach in the kernel community. The most likely fix, as of this writing, is something based on this patch from Gleixner, which works without requiring changes to either TCMalloc or glibc, albeit with the performance penalty in some environments.

As is the pattern with many recent system calls, rseq() requires the caller to pass in both the pointer to struct rseq and the size of that structure. In this way, future extensions can be made in compatible ways by increasing that size. Gleixner proposes increasing it from the current 32 bytes to 33 bytes, which would also have the effect of forcing a 64-byte alignment of the structure. Any caller presenting a 32-byte struct rseq or failing to align the structure properly would see the pre-6.19 behavior, with unconditional updating of cpu_id_start; more recent related features, such as time-slice extension, would also be unavailable. If, instead, the caller provides a 33-byte, 64-byte-aligned rseq structure, the kernel provides the 6.19 behavior, with full performance.

The result should be a fully compatible change. Existing TCMalloc installations will use the older structure size; the overlay trick used by the library also prevents a 64-byte alignment for the structure. So TCMalloc will be given the older behavior that it depends on. Newer glibc versions query the expected structure size (using getauxval()) and will be rewarded with higher performance and full functionality, with no glibc update needed.

Older glibc versions (those prior to 2.41), though, will be stuck with the performance penalty; Weimer indicated that updating those versions would not be an easy thing to do. Mathieu Desnoyers suggested adding a flag that could be passed to rseq() as an "I'm not TCMalloc" indicator, resulting in the faster behavior. Adding that flag would be a far easier backport to older glibc versions. Gleixner, though, dismissed that idea, saying that it would lead to unnecessary complexity in the code and, in any case, would be problematic in cases where there are multiple users of restartable sequences within a single application.

This solution appears to have survived initial testing, and has been put together into a proper patch series, along with some sharp words for the people who made it necessary:

As Linus decreed the onus is on the lack of ABI compliance enforcement in the original RSEQ kernel implementation and the clever abuse is fine. That's technically correct, but in the context of the larger ecosystem a fundamentally flawed decision. Though that's a completely different discussion to have as it affects the long term sustainability of the Open Source ecosystem in general and the ability to protect it against rogue actors, which are thereby officially entitled to hold a whole ecosystem hostage and force the people who provide them their operational base to go out on a limb to make progress.

Grumpiness aside, it seems that the form of the solution to this particular demonstration of Hyrum's law has been worked out. As long as there are no other users doing strange things, it should be possible to move forward, preserving all of the improvements that have been made, without breaking existing users. The absence of other surprises seems fairly likely to be the case, since there are few users of restartable sequences. In the end, things clearly could have been worse.

That said, this episode will surely not be reassuring to developers who fear exposing features that could end up creating similar compatibility problems in the future. Many discussions about adding new interfaces have run aground on that point; see, for example, this response by David Hildenbrand to the idea of allowing BPF programs to control more aspects of memory management. It is easy to see Hyrum lurking in the corner, just waiting to ossify some behavior inadvertently exposed by the kernel.

Comments (34 posted)

Bug-monitoring expectations and Fedora GNOME packages

For a number of years, users submitting bugs reports against GNOME packages in Fedora have received an auto-reply saying that the reports were not actively monitored; users were encouraged to file bugs with GNOME upstream instead. However, that practice seems to be in conflict with the Fedora Engineering Steering Committee (FESCo) policy that package maintainers "deal with reported bugs in a timely manner". On April 28, FESCo discussed the disconnect between practice and policy; so far, it has only opted to tweak the wording of the automatic response.

Many of the GNOME packages in Fedora are maintained by members of Red Hat's desktop team. Bugs filed against some of those packages, such as gnome-disk-utility, gnome-session, and nautilus, are automatically assigned to the "gnome-sig" alias in the Bugzilla bug tracker. There are 21 members in the group, but it is unclear if all users in that group are currently active.

Nearly 750 bugs are assigned to gnome-sig as of this writing. A few of those bugs, however, were opened more than a decade ago and were reassigned to the group at some point when package ownership changed—likely because a package was "orphaned" and no other packager stepped up to claim it. When a bug is assigned to gnome-sig, it receives an automatic response that reads in part:

Bug reports for this component on Red Hat Bugzilla are not actively monitored. Please consider reporting your issue directly to GNOME at https://gitlab.gnome.org/GNOME/ to improve the chances that your issue will be resolved.

In February, Carl George opened a ticket with FESCo about the automated reply. He said that it was "entirely reasonable to encourage collaboration with upstream projects", but the response suggested that the bugs were not being monitored at all, which would indicate that the package maintainers were not meeting their responsibilities under Fedora policy. "Can FESCo provide guidance on how this should be addressed?"

Too many bugs

FESCo member Kevin Fenzi replied with a link to a Fedora Workstation discussion in 2020 that led to the automatic reply. Michael Catanzaro had opened that conversation by saying he thought that most of Fedora's GNOME developers had given up on Bugzilla: "Currently, it's where bugs go to be ignored and receive no response, including serious bugs. This status quo is unfair to users." Fedora GNOME developers were only "passingly familiar" with the packages that they own: "I checked a couple other GNOME maintainers to see how many bugs are assigned to them and found: 260, 182, 420, 511, 372." He had fewer bugs, but also owned fewer packages than most of the GNOME maintainers who were maintaining "dozens of packages".

There were just too many bugs to practically deal with, Catanzaro said. Moving them upstream took too long as well: "we'd spend so much time moving bugs that we'd never get anything else done". If the bugs were filed upstream to begin with, "there's a decent chance the bug reports won't be ignored" because the bugs go "straight to the right developers". Allan Day wondered if GNOME was the only upstream with the problem of managing Fedora bugs. Neal Gompa responded that KDE also struggled, but he thought it made more sense to file bugs with both the upstream project and Fedora: "That way Fedora processes still work, and GNOME/KDE people can focus on upstream reports."

FESCo member Fabio Valentini pointed out that GNOME changes often caused problems in Fedora that did not qualify as bugs upstream. For example, GNOME may make changes to D-Bus interfaces that introduce crashes in the Pantheon desktop environment developed for elementary OS and packaged for Fedora. He had been told that GNOME's GitLab instance was the wrong place to report those problems, because "they're just 'features, not bugs'".

Owen Taylor admitted being one of the Fedora maintainers who ignored hundreds of bugs that had been assigned to him. Looking at bugs in the Fedora Bugzilla turned up "lots of interesting and intriguing stuff" that would sometimes lead to upstream bug fixes, "but getting bugzilla anywhere close to clean would have required me to be close to full-time bugzilla triager, and not get anything else done". He wanted to teach Fedora's Automatic Bug-Reporting Tool (ABRT) to report GNOME bugs upstream; that, though, could only apply to bugs being opened when application crashes were detected. He also wanted users to receive a suggestion to report bugs upstream unless their problem seemed to be related to packaging or otherwise unique to the distribution.

The discussion continued, and a solution of sorts was finally found; in June 2023, Tomas Popela said that a Bugzilla rule would be created to automatically add a comment after a bug was filed that the user should report bugs upstream unless it was related to packaging or to Fedora's release process (e.g., if a bug would block a Fedora release). The rule was implemented in November 2023.

ABRT did not learn how to report bugs upstream and is currently in the process of being decommissioned following years of neglect. Catanzaro said that Red Hat has stopped assigning developers to work on ABRT, and no one from the community has stepped up to maintain it. The graphical-user interface component for ABRT was removed in Fedora 44 and the plan is to remove it in its entirety before Fedora 45.

Community discussion

FESCo decided, during its meeting on February 17, to open a discussion on Fedora's forum to get community input about unmonitored bug reports. Valentini started the thread and then followed up with his own opinion on the topic. He agreed that a ridiculous number of bugs were being filed against some GNOME components, but the autoresponder was not helping. Once a bug was filed, he said, people feel like their part is done "and then they're asked to go do all that again somewhere else".

George replied that policy dictated maintainers deal with bugs in a timely manner; either the policy should be changed, or the response needed to change to be in alignment with Fedora policy. Gompa said that Fedora KDE maintainers also had "a very heavy bug reporting load", but had not requested special treatment. He acknowledged that the team was "quite bad at tagging bug reports to be closed", but felt that it was not a good idea to convey to users that bug reports were ignored by default:

To me, actions like this make it feel like Fedora is not providing value to the user or the upstream. Because if maintainers aren't doing that funnel work or leveraging shared infrastructure to help improve the quality of the components they maintain, I don't know what they are doing.

Fedora is currently working on adopting Forgejo as its collaborative-development platform, which will (at some point) include using Fedora Forge instead of Bugzilla for tracking bug reports. Catanzaro said that, when that happens, users would see a report template that would direct them upstream before they open a bug with the Fedora project. He suggested that Fedora needed to focus on fixing its bug tracker and bug-report tooling to ensure that bugs were reported in the right place. "I really don't think it's realistic to expect packagers to read the downstream bug reports."

Gompa argued that telling users to go upstream was a bad idea for several reasons; there is no one-to-one mapping of components between Fedora and GNOME, and users would be interacting with developers who may or may not have influence on how quickly a fix could be delivered. George replied that, whether it was realistic or not, Fedora's current policy required packagers to read and respond to bug reports.

Change the message

After the public discussion had time to wind down, FESCo revisited the topic during its meeting on April 28 (log). FESCo decided that the first sentence in the automatic response ("Bug reports for this component on Red Hat Bugzilla are not actively monitored") would be dropped. That was implemented on April 29.

Note that this does not mean that bug reports are being any more actively monitored than before; the message has changed, but FESCo has not yet given any guidance on what should be done next. It has concluded further discussion (and, perhaps, action) would be needed because, as Valentini wrote in the meeting summary, "intentionally not monitoring bugs on bugzilla is in tension (if not conflict) with guidelines around package maintainer responsibilities."

FESCo member Stephen Gallagher said that he had followed up with Catanzaro and Matthias Clasen, and they intended to join the next FESCo meeting. If the Workstation working group adopted an issue template that directed users upstream before filing a bug report, he thought, "it will be accepted as a reasonable compromise between policy and reality".

Whatever the outcome of the meeting, it seems unlikely that it will address the core problem that Fedora's GNOME package maintainers seem to have more work than they can comfortably manage. It matters little where bugs are filed if there aren't enough hands to do the work.

Comments (23 posted)

Version-controlled databases using Prolly trees

Modern database and filesystems make pervasive use of B-trees, which are tree structures optimized for storing sorted lists of keys and values on block devices. Dolt is an Apache 2.0-licensed project that makes clever use of a variant of a B-tree to support efficient version control for an entire database. The data structure it uses could well be of interest to other projects.

The company behind Dolt, DoltHub, makes its money selling hosted versions of three Apache-licensed open-source projects: Dolt, Doltgres, and DoltLite. The projects are intended to be drop-in replacements for MySQL, PostgreSQL, and SQLite, respectively. They have separate frontends for the different SQL dialects, but the projects share a common storage backend that supports version-control operations.

In practice, that allows the projects to expose Git-like operations as custom SQL functions:

    -- Modify the database
    INSERT INTO users VALUES (...);
    -- Add the changes to a table to staging
    SELECT dolt_add('users');
    -- Commit them
    SELECT dolt_commit('-m', 'Add Joe to users');
    -- See the resulting diff
    SELECT * from dolt_diff_users('HEAD~1', 'HEAD');

At any given time, the database has a current HEAD commit, some number of changes in the staging area, and some number of changes in the working area, just like Git. That deliberate similarity is a major selling point of the projects — the company's home page says: "You already know how to use Dolt." That may be an exaggeration, but it is true that having basic knowledge of Git and SQL seems sufficient to start making use of Dolt.

What might be less clear is what one would use a version-controlled database for. Simply making commits on its own does not really add much power over the existing concept of a database transaction. The real utility of Dolt comes from the ability to restore old commits, fork historical states of the database, and merge in changes after review. For example, a programmer might want to run an analysis against an old state of the database to determine what would have been reported as of a particular date. They could make a new branch pointing at a historical commit, cherry pick a schema change that the analysis needs, and then run it.

Another potential use is to give automated tools a "real" database that they can work against, without giving them the ability to completely break the production database; any changes can be investigated separately and merged in only once it is clear that they won't break anything. Dolt is fully compatible with normal MySQL clients; the only difference is in the connection string, so the tools have no reason to think that they're not talking to the real production database.

    -- Connect to the normal db
    mysql://db-server:3306/mydb
    -- Connect to a named branch
    mysql://db-server:3306/mydb/branch-name
    -- Connect to a read-only historical commit
    mysql://db-server:3306/mydb/ia1ibijq8hq1llr7u85uivsi5lh3310p

Of the three projects, Dolt is the most mature. Doltgres recently entered beta, and DoltLite is somewhere in-between — the components adapted from SQLite have had plenty of testing in their original context, but the project is still on version 0.8.1. The company's performance testing of Dolt suggests that its speed is comparable to MySQL's, although the normal caveats about the difficulty of precise benchmarking apply.

That competitive performance is possible because Dolt only changes the storage layer of the database. The query planner, index maintenance, and so on all reuse MySQL, PostgreSQL, or SQLite's existing implementations. All of these databases use B-trees; Dolt uses a slight variation on a B-tree that allows efficient diffing and shares storage between mostly identical versions.

B-trees

B-trees have a lot in common with their simpler cousins, binary trees. In a binary tree, each node has a key, a value, and two (possibly empty) sub-trees. Keys with a lower value are stored in the left sub-tree, and keys with a higher value are stored in the right sub-tree. As long as some scheme is employed to keep the tree balanced (such as the use of red-black trees in the kernel), this results in reasonably efficient comparison-based searching: each comparison cuts out roughly half of the remaining candidates. Keys are looked up in time proportional to the base-two logarithm of the number of nodes in the tree.

B-trees take this core concept, and remove a bunch of pointer indirections. Each node in a B-tree has an array of keys, values, and pointers to sub-trees. Typically, the size of the array is chosen such that one node fits on one sector or page of the underlying storage. To find an item in a B-tree, the computer scans over the array and either finds the key directly, or finds two keys that the target key should be between, and goes on to check the corresponding sub-tree. This structure greatly reduces the number of levels of the tree and the number of pointer indirections, thus making the whole structure faster to access in practice. In a B-tree with sixteen keys per node, for example, searching for a key only involves one quarter of the number of nodes compared to a binary tree.

This makes B-trees an excellent fit for databases, which have to maintain a balance between efficient searches for particular items, in-order scans over the items in a range, and access to the underlying storage. There are a handful of variations of B-trees used by different databases that provide small speedups. For example, moving all of the values to leaf nodes and storing only keys in the interior nodes of the tree allows for more keys per interior node, making the tree wider and shorter. An extension to that idea adds a "next" pointer to each leaf node so that in-order traversals can proceed along the leaves without needing to load any interior nodes. Dolt's core data structure, described below, incorporates both of those optimizations.

The problem with plain B-trees, and the reason that Dolt is interesting, is that comparing entire B-trees is expensive. The order in which items are inserted and deleted can affect how the internal nodes of the B-tree are structured, which means that the only way to compare two B-trees is by iterating through both trees in their entirety. That downside doesn't matter much to traditional databases, but it poses real problems for version-control systems.

Snapshot-based version-control systems, such as Git, can be thought of as storing many snapshots of some source tree. Each commit is logically independent, and could in theory just be stored as-is. In practice, most Git repositories do not completely change between commits, and it's more efficient to store the differences between subsequent snapshots, rather than the snapshots themselves.

Git, which works with entire directory trees, relies on being able to quickly check whether a particular sub-tree has changed in order to produce compact diffs that include only the actual changes. B-trees aren't compatible with that kind of algorithm, since the same logical list of keys and values could be represented by two different B-trees. Naively applying a diff algorithm to a B-tree could produce a lot of inefficient churn between representations of internal nodes.

The problem comes from the way that B-trees split and merge nodes as items are added and removed. When a B-tree node is full, it is split into two smaller nodes that are each half-full. When a B-tree node is not full enough (a threshold that varies between implementations, but which is typically just under half-full), its children are merged together to produce a more full node. When correctly implemented, this keeps the B-tree balanced and prevents the nodes from wasting storage space. But it also means that splitting and merging decisions depend on the order of insertion into the tree.

Prolly trees

Probabilistic B-trees (Prolly trees, for short) are Dolt's answer to this problem. They are almost identical to B-trees, except that the logic for inserting and removing items is updated such that any two trees that contain the same items are completely identical regardless of how items were inserted. The same property holds for individual sub-trees, so comparing two Prolly trees is much simplified: if a sub-tree hasn't changed between two versions, it will have the same hash, even if an item was inserted and then removed.

To accomplish this, Prolly trees need to be able to determine what size each node "should" be, based only on its contents and not on any internal state of the tree. At first, it might seem tempting to say that every node should be as full as possible, to maximize use of storage space. But that would require sometimes shuffling nodes at the same level of the tree back and forth between parents, which would destroy some of the nice properties of the B-tree and cause additional churn between versions. To keep insertion and deletion efficient, the average node should not be so full or so empty that the insertion or deletion of a single item will need to trigger a split or a merge.

The solution to this problem is to use a hash function to make the decision in a way that depends only on the data and not on how full a particular node happens to be. A hash is effectively a deterministic pseudorandom number that can be compared to a threshold to make a randomized decision, which is where the "probabilistic" part of Prolly trees comes in. To insert a new value into a node, the implementation puts it in the correct position in the array (based on the key), and then recalculates where the boundary between this node and its sibling should fall based on the hashes of the items. Each hash is compared to a chosen cutoff value (the threshold) to decide whether the node should end at that item. Since the values of the hashes are independent, so are the decisions about where to put the boundaries between nodes. Most of the time, therefore, adding an item won't result in a new boundary: its hash value will be above the threshold, and the node will still end at the same place (a preexisting item with a low hash value). Occasionally, an inserted item will have a low hash value, causing the node to split in two and keeping the overall sizes of the nodes balanced.

That picture is slightly complicated by performance considerations; in order to keep the nodes optimally sized, the threshold used is actually dynamic, based on the number of items before a given key in a node. That still means that the actual decisions about where to place the boundaries between nodes are made independently of the pre-existing structure of the tree. The locations of the boundaries depend only on the hashes of the items stored in the tree, which are the same regardless of what order items were inserted in.

This insertion logic is a little complicated, especially if the implementation is optimized for performance, but it's still reasonably compact:

    # Unoptimized Python example code
    # This function is called by some internal node to update one of its child
    # nodes; the return value is used to update the internal node.
    def insert_into_node(node, new_items):
        sibling = node.next_sibling
        new_items = sorted(new_items + node.items)
        collected = []
        nodes = []
        
        while new_items:
            next = new_items.pop(0)
            collected.append(next)
            if hash(next.key) < threshold(len(collected)) \
               or len(collected) >= max_node_length:
                nodes.append(Node(items=collected))
                collected = []

        if collected:
            # The while loop didn't end on a natural barrier
            if node.next_sibling is not None:
                new_nodes, sibling = insert_into_node(node.next_sibling, collected)
                nodes += new_nodes
            else:
                nodes.append(Node(items=collected))
            
        for i in range(1, len(nodes)):
            nodes[i - 1].next_sibling = nodes[i]
        nodes[-1].next_sibling = sibling
        
        return nodes, nodes[0]

With a suitably chosen threshold, the average insertion won't create a new node, and so only one node needs to be updated at each level of the tree. Theoretically, adding a single item could cause all of the nodes after it to be split up differently, but the chances of that are infinitesimal, because the hash values of the items are statistically independent. The hash values of all of the existing items would have to just barely miss the threshold in order to cause that kind of realignment, so it's not a practical performance problem. Since the decision of how to place items into nodes only depends on the data, the same nodes will be created every time.

There are some downsides to using a Prolly tree over a B-tree. For example, nodes need to store the hashes of sub-trees, which requires either more storage space or an additional indirection through a content-addressed block store to turn a hash into an address. Content-addressed storage is a scheme that many version-control systems use to deduplicate data: a particular diff or other object is stored in a location based on the hash of its contents. This ensures that duplicate items will reuse the same storage space. A Prolly tree implemented as part of a version-control system can reuse that existing content-addressed object storage for blocks, and refer to blocks by hash, leading to more compact internal nodes. Other systems will need their own solutions.

Another problem is that the performance of the tree is highly sensitive to how the probabilities of splitting are tuned. Using a constant probability results in the mean node being half-full, but the median node containing only one or two entries. To cope with that, Prolly trees use a dynamic threshold that increases as the node fills up, so that the size of nodes ends up following a normal distribution. Of course, some applications really do have requirements for worst-case performance rather than average-case performance, which is incompatible with the randomized layout of a Prolly tree.

Despite these deficits, Prolly trees could be a useful data structure for applications that depend on being able to compare snapshots of trees, or on being able to store trees in a content-addressable way.

History and future

Prolly trees were invented by Aaron Boodman for the now-defunct Noms database. Afterward, they were picked up by the InterPlanetary Linked Data project and by DoltHub. The storage backend used in Dolt is a forked version of Noms, although the project has seen a fair number of changes and optimizations since then. Some other implementations of Prolly trees exist as libraries, but none apply them to databases.

Dolt provides an appealing evolution on the traditional design of a database. Personally, however, I am excited to see how the ideas could apply in other programs that use B-trees, such as filesystems. Prolly trees are certainly not appropriate for all uses of B-trees, but filesystems share many of the same tradeoffs between in-order traversal, random access, and ease of snapshotting that databases do. Perhaps Prolly trees could help with space-efficient snapshots of large, frequently modified files.

Comments (20 posted)

Hardware-assisted Arm VMs for s390

A recent patch set from Steffen Eiden and others has set the groundwork for allowing hardware-assisted emulation of Arm CPUs on s390 CPUs. Version two of the posting fixes a handful of smaller problems, but does not differ much. The patches were welcomed by the Arm maintainers, pending some discussion of how the collaboration between the architectures could be structured to prevent maintainability problems on the Arm side. When those details are resolved, the patches could pave the way for transparently running Arm-based virtual machines (VMs) on s390 hosts at native or near-native speeds.

The core of the feature is a patch that adds support for a new s390 instruction called "Start Arm Execution" (SAE). It performs a similar function to the existing "Start Interpretive Execution" instruction on s390 that is used to enter a hardware-assisted virtual machine while keeping the virtual CPU state separate from the host CPU. Both instructions take a pointer to a "control block" that describes how the virtual CPU should be set up and entered. The difference is that a SAE instruction's control block sets the instruction pointer to a block of memory containing Arm instructions and interprets them as such, rather than s390 instructions.

In theory, this allows someone with a s390 CPU new enough to support the feature to run an Arm virtual machine directly. There clearly has to be a translation from Arm machine code to s390 machine code at some point, but the CPU handles that internally. How exactly it does that is not clear from the patch set.

On the kernel side, while the idea is simple, the implementation is a bit more complex. When virtual machines make calls to their hypervisor, they do so using an architecture-specific interface. If Arm virtual machines are to run on s390 unmodified, the KVM code in an s390 kernel needs to be able to interpret Arm hypercalls. To support that, Eiden's patch set moves the interface definition and related header files to include/uapi/arch/arm64/, allowing other architectures to reference them. Amusingly, this allowed some duplicated code to be cleaned up; the patches ended up removing more lines of code than they added.

There is additional work to be done once these patches are merged, however. The s390 architecture is also gaining instructions for manipulating Arm registers, handling interrupts, and so on. Eiden hopes to add support for those over the coming months in conjunction with the rest of the s390 developers.

There was relatively little feedback on the patch set, but Marc Zyngier had a lengthy response written in consultation with Will Deacon. They were supportive of the effort, but worried that moving some of the Arm-specific code to a shared directory was messy and could interfere with the code's maintainability. They suggested that using symbolic links, relative paths, or code generation could allow the existing Arm code to remain it its accustomed location without unduly restricting s390 code.

Eiden's reply explained that they had tried using symbolic links for header files originally, but feared the approach wouldn't gain support since it was somewhat messy. Some of the code is also automatically generated, reusing the Makefile rules from the Arm code. But he agreed to prototype an alternative that makes use of symbolic links and post that for comparison. That patch set was sent on the April 28 and has not received any review as of the time of writing.

A more serious concern was how s390 would keep up with changes to the Arm virtual-machine-guest API, which is still evolving, Zyngier said. For example, there are some CPU-vulnerability mitigations that require cooperation from guests. When a new one is discovered, Arm assigns a hypercall function number for the new interface needed, and KVM implements it. The s390 code will presumably need something similar, both adding stubs for new Arm-specific mitigations and working with Arm to add any s390-specific interfaces needed. Those should be limited to mitigations, however, since the Arm KVM code "makes a point of forbidding any use of implementation specific instruction or system registers," and Zyngier expects the s390 code to do the same.

Eiden was not overly worried about this, saying that a primary goal of the project was to be able to run unmodified Arm guests, and so he and his fellow s390 developers would be treating the Arm code as the source of truth. As such, they had no plans to introduce s390-specific features or abrogate the usual process.

Zyngier and the other Arm maintainers are, understandably, not familiar with the details of s390. So, Zyngier and Deacon also asked for help with documentation, testing, and debugging, to ensure that changes to the Arm code do not have adverse effects on s390.

Finally, we feel it would be beneficial for both projects to swap prisoners and have cross-reviewers in MAINTAINERS, so that there is an s390 reviewer added to KVM/arm64, and an arm64 reviewer added to KVM/s390.

Eiden readily agreed, and suggested that cross-compilation of the kernel for s390 was a good starting point for testing. He offered access to s390 virtual machines hosted by IBM for doing native builds, as well. Eiden plans to add Arm's continuous-integration-testing branches to s390's build infrastructure, to catch any breakage early. He also thought an exchange of maintainers made sense, and added himself as an Arm KVM reviewer in the second revision of the patch series.

Eiden and Zyngier made plans to meet up with the other s390 and Arm kernel developers at the Linux Plumbers Conference Linux Storage, Filesystem, Memory Management, and BPF Summit. Hopefully an in-person meeting will suffice to figure out any remaining details, but since everyone seems happy enough with the change that is quite likely.

[ Thanks to Andi Holmes for bringing this topic to our attention. ]

Comments (31 posted)

Eden: NHS goes to war against open source

Terence Eden reports that the UK's National Health Service (NHS) is preparing to close almost all of its open-source repositories as a response to LLM tools, such as Anthropic's Mythos, becoming more sophisticated at finding security vulnerabilities. He does not, to put it mildly, agree with the decision:

The majority of code repos published by the NHS are not meaningfully affected by any advance in security scanning. They're mostly data sets, internal tools, guidance, research tools, front-end design and the like. There is nothing in them which could realistically lead to a security incident.

When I was working at NHSX during the pandemic, we were so confident of the safety and necessity of open source, we made sure the Covid Contact Tracing app was open sourced the minute it was available to the public. That was a nationally mandated app, installed on millions of phones, subject to intense scrutiny from hostile powers - and yet, despite publishing the code, architecture and documentation, the open source code caused zero security incidents.

Furthermore, this new guidance is in direct contradiction to the UK's Tech Code of Practice point 3 "Be open and use open source" which insists on code being open.

Comments (15 posted)

Kernel release status

The current development kernel is 7.1-rc2, released on May 3. Linus said: "It's not small, and while it's a bit early to say for sure, I do suspect we're seeing the same continued pattern of more patches than usual - probably due to AI tooling - that we saw in 7.0."

As of -rc2, the 7.1 development cycle has brought in 13,417 non-merge commits from 2,066 developers, 355 of whom are first-time kernel contributors. The release history looks like:

RC	Date	Commits
v7.1-rc1	2026-04-26	13963	13963
v7.1-rc2	2026-05-03	475	475

See the KSDB 7.1 page for lots of details.

Stable updates: 7.0.3, 6.18.26, 6.12.85, 6.6.137, 6.1.170, 5.15.204, and 5.10.254 were released on April 30. The 7.0.3 and 6.18.26 kernels only contain fixes needed for Xen users; the others, though, have backported fixes for the recently disclosed AEAD socket vulnerability.

Comments (none posted)

Quotes of the week

I love it how people think that "coordination of vulnerabilities" is actually something that can be done these days. Think of just who uses the software in question, and who should, and should not, be on such a list to get a "early disclosure notification".

As I have said for quite some time now, all early-disclosure lists are leaks, otherwise why would your government allow them to be in existence?

Software, and specifically open source software, runs the world. So should the whole world be on that notification list? :)

— Greg Kroah-Hartman

We do remove algorithms from AF_ALG occasionally, but we've been unable to remove ones like MD4 (yes, that MD4) that are still used by iwd: https://lore.kernel.org/linux-crypto/946591db-36aa-23db-a5c4-808546eab762@gmail.com/ Likewise with removing support for SHA-1 from KEYCTL_PKEY_* (https://lore.kernel.org/linux-crypto/f0492c92-1015-48e3-bfce-598c7a4843d1@quicinc.com/). People even post the Linus quote "we simply do not break user space".

Unfortunately, the developers and users of this small set of userspace programs are disconnected from the extraordinary amount of time and effort that the rest of the Linux community is putting in to maintain these UAPIs and respond to the continuous stream of vulnerabilities.

To them these are simply APIs available that work.

— Eric Biggers

Comments (none posted)

Alpine Linux systems currently offline

The Alpine Linux account on fosstodon.org reports that all systems hosted at Linode, including its GitLab instance, "are suspended at the moment due to some billing issue". They are working to get it resolved, but in the meantime all of their services appear to be down.

Update: Alpine Linux's servers are back online.

Comments (none posted)

Distributions quote of the week

2,442 days is a fair amount of time, and that's how long I had been on the openSUSE Board as its chair when I started this note.

That journey began on August 19th, 2019, and it ends today as I am stepping down as chair of the openSUSE Board.

It's been an intense time for most of it — just a bit calm the last year and a half. A time of joy and frustration, anger occasionally and rewarding more often than that.

During those years we have seen SUSE and openSUSE carve out from Micro Focus (escalations on the IT side included); a global pandemic; SUSE go public and return to private; the arrival of Rancher, NeuVector, and Losant; four CIOs and four (and de facto more) General Managers for Linux at SUSE; repeated discussions on the logo and name of our project; the creation of Geeko Foundation; people move on and others step up; seven board elections; board meetings become public; passionate debates and growing pains; web site refreshes; the number of distros and tooling around them grow and evolve; and quite a bit more.

If I can leave one piece of advice, it is to embrace open, non-violent communication and trust — both given and received.

I encourage more lateral sharing (of accomplishments, changes, challenges, calls for collaboration) between the cells and bodies that make up openSUSE, and above all applying the PRINCIPLE OF CHARITY. That is, giving others the benefit of the doubt, assuming good intentions, and looking for real value in their perspectives.

Does that always come easy? Absolutely not.
Does it make a difference? A lot.

— Gerald Pfeifer

Comments (none posted)

GCC 16.1 released

Version 16.1 of the GNU Compiler Collection (GCC) has been released.

The C++ frontend now defaults to the GNU C++20 dialect and the corresponding parts of the standard library are no longer experimental. Several C++26 features receive experimental support, including Reflection (-freflection), Contracts, expansion statements and std::simd.

Other changes include the introduction of an experimental compiler frontend for the Algol68 language, ability to output GCC diagnostics in HTML form, and more.

Comments (9 posted)

Incus 7.0 LTS released

Version 7.0 of the Incus container and virtual-machine management system has been released. Notable changes in this release include the inclusion of a low-level backup API, the addition of basic S3 operations directly in Incus to replace the now-unmaintained MinIO project, as well as the removal of support for cgroups v1 and xtables (iptables/ip6tables/ebtables). This is a long-term-support (LTS) release, with support through June 2031.

The first 2 years will feature bug and security fixes as well as minor usability improvements, delivered through occasional point releases (7.0.x). After that initial two years, Incus 7.0 LTS will move to security only maintenance for the remaining of its 5 years of support.

A total of 204 individuals contributed to Incus between the 6.0 LTS and 7.0 LTS releases with 45 contributing between the 6.23 and 7.0 LTS releases.

Comments (none posted)

NetHack 5.0.0 released

Version 5.0.0 of the NetHack dungeon-exploration game, a distant relative of Rogue and Hack, has been released. NetHack's code is now compliant with the C99 standard, and the release includes more than 3,100 bug fixes and changes, detailed in doc/fixes5-0-0.txt (may contain game spoilers). Saved games from previous versions will not work with NetHack 5.0.0.

Comments (4 posted)

The retirement of the PHP license

The PHP project has long shipped under its own license — except for the parts under the Zend Engine License. The PHP project has now announced that the PHP license has been retired, and the PHP code has been relicensed under the three-clause BSD license. See this blog entry for more details.

Getting here required more than writing an RFC. The PHP License gives the PHP Group the authority to change it, which meant tracking down each of the original PHP Group members and getting their written consent. Each approved the proposal. Perforce Software, the successor to Zend Technologies, needed to sign off on the Zend Engine side, as well. They provided a formal letter confirming their full authority and support for the change. I hired an attorney to review the proposal and provide advice on any legal questions that might surface during the discussion period. Speaking of which, I allowed for a six-month community discussion period preceding the vote, which passed unanimously.

LWN covered the license-change process back in March.

Comments (4 posted)

Development quote of the week

At the time, the prevalence of goblins did not look especially alarming. A few months later, the goblins came back to haunt us in a much more specific and reproducible form.

— OpenAI research

Comments (none posted)

CFP Deadlines: May 7, 2026 to July 6, 2026

The following listing of CFP deadlines is taken from the LWN.net CFP Calendar.

Deadline	Event Dates	Event	Location
May 25	July 20 July 25	DebConf 26	Santa Fe, Argentina
May 31	October 1	Open Tech Day | Software-defined Storage	Nuremberg, Germany
June 1	July 13 July 16	Netdev	Rome, Italy
June 1	October 20 October 23	PostgreSQL Conference Europe	Valencia, Spain
June 5	July 18	AlmaLinux Day: Los Angeles	Los Angeles, CA, US
June 14	October 20 October 23	The Matrix Conference	Malmö, Sweden
June 14	June 14	Neocypherpunk Summit	Berlin, Germany
June 14	September 30 October 1	All Systems Go! 2026	Berlin, Germany
June 24	October 7 October 9	Embedded Linux Conference Europe	Prague, Czech Republic
June 24	October 7 October 9	Open Source Summit Europe	Prague, Czech Republic
June 28	October 8	Linux Security Summit Europe	Prague, Czechia
June 30	November 17 November 19	Open Source Monitoring Conference	Nuremberg, Germany
July 3	September 28 September 30	X.Org Developers Conference	Toronto, Canada

If the CFP deadline for your event does not appear here, please tell us about it.

Events: May 7, 2026 to July 6, 2026

The following event listing is taken from the LWN.net Calendar.

Date(s)	Event	Location
May 4 May 11	MiniDebConf Hamburg 2026	Hamburg, Germany
May 15 May 17	PyCon US	Long Beach, California, US
May 16 May 17	Lomiri Tech Meeting	Tilburg, The Netherlands
May 18 May 23	RustWeek 2026	Utrecht, Netherlands
May 18 May 20	Open Source Summit North America	Minneapolis, Minnesota, US
May 21 May 22	Linux Security Summit North America	Minneapolis, Minnesota, US
May 23 May 24	Curl up	Prague, Czechia
May 26	Media Summit	Nice, France
May 27 May 28	Embedded Recipes	Nice, France
May 29	libcamera workshop	Nice, France
May 29	Yocto Project Developer Day	Nice, France
May 30 May 31	Journées du Logiciel Libre 2026	Lyon, France
June 6	Hong Kong Open Source Conference	Hong Kong
June 6 June 7	Technical Dutch Open Source Event	Geldrop (near Eindhoven), Netherlands
June 8 June 12	RISC-V Summit Europe 2026	Bologna, Italy
June 12 June 14	Southeast Linuxfest	Charlotte, NC, US
June 14	Neocypherpunk Summit	Berlin, Germany
June 14 June 16	Flock to Fedora	Prague, Czechia
June 16 June 17	Open Source Summit India	Mumbai, India
June 18 June 20	Linux Audio Conference	Maynooth, Ireland

If your event does not appear here, please tell us about it.

Alert summary April 30, 2026 to May 6, 2026

Dist.	ID	Release	Package	Date
AlmaLinux	ALSA-2026:13284	8	LibRaw	2026-05-05
AlmaLinux	ALSA-2026:11360	9	LibRaw	2026-04-29
AlmaLinux	ALSA-2026:8863	8	OpenEXR	2026-04-30
AlmaLinux	ALSA-2026:11635	8	PackageKit	2026-04-29
AlmaLinux	ALSA-2026:11504	9	PackageKit	2026-04-30
AlmaLinux	ALSA-2026:10135	9	buildah	2026-04-30
AlmaLinux	ALSA-2026:13657	8	corosync	2026-05-06
AlmaLinux	ALSA-2026:13830	8	dovecot	2026-05-05
AlmaLinux	ALSA-2026:12176	8	fence-agents	2026-04-30
AlmaLinux	ALSA-2026:10767	10	firefox	2026-04-29
AlmaLinux	ALSA-2026:10757	9	firefox	2026-04-29
AlmaLinux	ALSA-2026:10707	10	gdk-pixbuf2	2026-04-29
AlmaLinux	ALSA-2026:10708	9	gdk-pixbuf2	2026-04-30
AlmaLinux	ALSA-2026:8861	8	giflib	2026-04-30
AlmaLinux	ALSA-2026:8859	9	giflib	2026-04-30
AlmaLinux	ALSA-2026:10223	10	grafana	2026-04-29
AlmaLinux	ALSA-2026:10226	9	grafana	2026-04-30
AlmaLinux	ALSA-2026:1838	10	image-builder	2026-05-06
AlmaLinux	ALSA-2026:3840	10	image-builder	2026-05-06
AlmaLinux	ALSA-2026:3839	9	image-builder	2026-05-05
AlmaLinux	ALSA-2026:13671	9	image-builder	2026-05-05
AlmaLinux	ALSA-2026:9683	8	java-1.8.0-openjdk	2026-04-30
AlmaLinux	ALSA-2026:9683	9	java-1.8.0-openjdk	2026-04-30
AlmaLinux	ALSA-2026:9689	10	java-21-openjdk	2026-04-30
AlmaLinux	ALSA-2026:9689	8	java-21-openjdk	2026-04-30
AlmaLinux	ALSA-2026:9689	9	java-21-openjdk	2026-04-30
AlmaLinux	ALSA-2026:A003	10	kernel	2026-05-01
AlmaLinux	ALSA-2026:13577	8	kernel	2026-05-05
AlmaLinux	ALSA-2026:A001	8	kernel	2026-05-01
AlmaLinux	ALSA-2026:A002	9	kernel	2026-05-01
AlmaLinux	ALSA-2026:13578	8	kernel-rt	2026-05-05
AlmaLinux	ALSA-2026:12423	10	libcap	2026-05-01
AlmaLinux	ALSA-2026:13285	8	libcap	2026-05-04
AlmaLinux	ALSA-2026:12441	9	libcap	2026-05-01
AlmaLinux	ALSA-2026:12265	10	libtiff	2026-05-01
AlmaLinux	ALSA-2026:12271	9	libtiff	2026-05-01
AlmaLinux	ALSA-2026:13380	10	openssh	2026-05-04
AlmaLinux	ALSA-2026:13383	8	openssh	2026-05-04
AlmaLinux	ALSA-2026:13381	9	openssh	2026-05-05
AlmaLinux	ALSA-2026:10713	10	pcs	2026-04-29
AlmaLinux	ALSA-2026:10710	9	pcs	2026-04-29
AlmaLinux	ALSA-2026:13670	9	python-tornado	2026-05-06
AlmaLinux	ALSA-2026:10774	9	python3.11	2026-04-29
AlmaLinux	ALSA-2026:10711	10	python3.12	2026-04-30
AlmaLinux	ALSA-2026:10745	9	python3.12	2026-04-29
AlmaLinux	ALSA-2026:10949	9	python3.9	2026-04-29
AlmaLinux	ALSA-2026:13902	8	resource-agents	2026-05-06
AlmaLinux	ALSA-2026:10758	10	sudo	2026-04-29
AlmaLinux	ALSA-2026:12310	9	sudo	2026-05-01
AlmaLinux	ALSA-2026:13651	10	systemd	2026-05-06
AlmaLinux	ALSA-2026:13677	9	systemd	2026-05-05
AlmaLinux	ALSA-2026:12285	10	thunderbird	2026-05-03
AlmaLinux	ALSA-2026:13537	8	thunderbird	2026-05-05
AlmaLinux	ALSA-2026:13414	8	tigervnc	2026-05-05
AlmaLinux	ALSA-2026:10739	9	tigervnc	2026-04-29
AlmaLinux	ALSA-2026:11389	10	vim	2026-04-29
AlmaLinux	ALSA-2026:11509	8	vim	2026-04-30
AlmaLinux	ALSA-2026:11510	9	vim	2026-04-29
AlmaLinux	ALSA-2026:11692	8	xorg-x11-server	2026-04-30
AlmaLinux	ALSA-2026:11388	9	xorg-x11-server	2026-04-29
AlmaLinux	ALSA-2026:11352	10	xorg-x11-server-Xwayland	2026-04-29
AlmaLinux	ALSA-2026:11656	8	xorg-x11-server-Xwayland	2026-04-30
AlmaLinux	ALSA-2026:11369	9	xorg-x11-server-Xwayland	2026-04-29
AlmaLinux	ALSA-2026:11413	10	yggdrasil	2026-04-29
AlmaLinux	ALSA-2026:11412	10	yggdrasil-worker-package-manager	2026-04-29
Debian	DLA-4554-1	LTS	calibre	2026-04-30
Debian	DSA-6239-1	stable	chromium	2026-05-01
Debian	DLA-4556-1	LTS	dovecot	2026-05-01
Debian	DSA-6197-3	stable	dovecot	2026-05-01
Debian	DLA-4555-1	LTS	firefox-esr	2026-04-30
Debian	DSA-6236-1	stable	firefox-esr	2026-04-29
Debian	DLA-4559-1	LTS	imagemagick	2026-05-01
Debian	DSA-6245-1	stable	imagemagick	2026-05-03
Debian	DSA-6240-1	stable	imagemagick	2026-05-01
Debian	DSA-6244-1	stable	incus	2026-05-02
Debian	DLA-4560-1	LTS	kernel	2026-05-02
Debian	DSA-6238-1	stable	kernel	2026-04-30
Debian	DSA-6243-1	stable	kernel	2026-05-01
Debian	DLA-4563-1	LTS	libarchive	2026-05-05
Debian	DLA-4558-1	LTS	libexif	2026-05-01
Debian	DLA-4561-1	LTS	linux-6.1	2026-05-02
Debian	DSA-6247-1	stable	lxd	2026-05-04
Debian	DLA-4566-1	LTS	openjdk-11	2026-05-06
Debian	DLA-4565-1	LTS	openjdk-17	2026-05-06
Debian	DSA-6237-1	stable	openjdk-17	2026-04-29
Debian	DSA-6246-1	stable	openjdk-25	2026-05-03
Debian	DLA-4557-1	LTS	pyasn1	2026-05-01
Debian	DLA-4564-1	LTS	pyjwt	2026-05-05
Debian	DSA-6241-1	stable	python-aiohttp	2026-05-01
Debian	DLA-4562-1	LTS	thunderbird	2026-05-04
Debian	DSA-6242-1	stable	thunderbird	2026-05-01
Fedora	FEDORA-2026-fdbf3705cc	F43	GitPython	2026-05-02
Fedora	FEDORA-2026-9342da13e0	F44	GitPython	2026-05-02
Fedora	FEDORA-2026-98decbde87	F42	asterisk	2026-04-30
Fedora	FEDORA-2026-80b21debe7	F43	asterisk	2026-04-30
Fedora	FEDORA-2026-38d71393c1	F44	asterisk	2026-04-30
Fedora	FEDORA-2026-3831e11232	F42	binaryen	2026-04-30
Fedora	FEDORA-2026-fb3e461878	F43	binaryen	2026-04-30
Fedora	FEDORA-2026-156e6bfb27	F42	buildah	2026-04-30
Fedora	FEDORA-2026-36fb406407	F42	chromium	2026-05-04
Fedora	FEDORA-2026-2a5d3e5194	F42	chromium	2026-05-01
Fedora	FEDORA-2026-af3f470d38	F43	chromium	2026-05-05
Fedora	FEDORA-2026-f5ed344d5c	F44	chromium	2026-05-03
Fedora	FEDORA-2026-511c8bd939	F43	dokuwiki	2026-04-30
Fedora	FEDORA-2026-e1f1cff72a	F44	dokuwiki	2026-04-30
Fedora	FEDORA-2026-ad17a2db6c	F42	dotnet10.0	2026-05-01
Fedora	FEDORA-2026-eadd724963	F43	dotnet10.0	2026-05-01
Fedora	FEDORA-2026-fc2112cdd4	F44	dotnet10.0	2026-05-01
Fedora	FEDORA-2026-02b2a30c02	F42	dotnet8.0	2026-05-01
Fedora	FEDORA-2026-a1302c450c	F43	dotnet8.0	2026-05-01
Fedora	FEDORA-2026-edca75e401	F44	dotnet8.0	2026-05-01
Fedora	FEDORA-2026-ac43e01af9	F42	dotnet9.0	2026-05-01
Fedora	FEDORA-2026-97fbaaef10	F43	dotnet9.0	2026-05-01
Fedora	FEDORA-2026-e1d2833798	F44	dotnet9.0	2026-05-01
Fedora	FEDORA-2026-52dad6273a	F42	emacs	2026-05-01
Fedora	FEDORA-2026-290753da75	F43	emacs	2026-05-01
Fedora	FEDORA-2026-49b8ca7981	F44	emacs	2026-05-01
Fedora	FEDORA-2026-c0a4f03150	F43	firefox	2026-05-03
Fedora	FEDORA-2026-4b7780802c	F43	glibc	2026-05-03
Fedora	FEDORA-2026-ced72ab158	F44	glibc	2026-05-02
Fedora	FEDORA-2026-9d0e7df23a	F42	glow	2026-05-01
Fedora	FEDORA-2026-6d67b00ef1	F43	glow	2026-05-01
Fedora	FEDORA-2026-423a143483	F44	glow	2026-05-01
Fedora	FEDORA-2026-ce402e1f82	F42	insight	2026-05-03
Fedora	FEDORA-2026-e0f5e87dd6	F43	insight	2026-05-03
Fedora	FEDORA-2026-f72d44d09e	F44	insight	2026-05-05
Fedora	FEDORA-2026-6b87863841	F44	jfrog-cli	2026-05-01
Fedora	FEDORA-2026-8b43ea2f82	F44	krb5	2026-05-02
Fedora	FEDORA-2026-69743812a7	F42	lemonldap-ng	2026-04-30
Fedora	FEDORA-2026-38914f4e04	F43	lemonldap-ng	2026-04-30
Fedora	FEDORA-2026-6c8dcaf023	F44	lemonldap-ng	2026-04-30
Fedora	FEDORA-2026-b01307dc4d	F42	libexif	2026-04-30
Fedora	FEDORA-2026-8409145c11	F43	libgcrypt	2026-04-30
Fedora	FEDORA-2026-9a79c58afd	F44	libgcrypt	2026-04-30
Fedora	FEDORA-2026-2e8a8fd35b	F42	miniupnpd	2026-04-30
Fedora	FEDORA-2026-5f908cb040	F43	miniupnpd	2026-04-30
Fedora	FEDORA-2026-f933979509	F44	miniupnpd	2026-04-30
Fedora	FEDORA-2026-3111ffa11a	F44	nano	2026-05-03
Fedora	FEDORA-2026-9dc3a61ad8	F43	nodejs20	2026-05-05
Fedora	FEDORA-2026-c99f9dc3b1	F44	nodejs20	2026-05-05
Fedora	FEDORA-2026-c0a4f03150	F43	nss	2026-05-03
Fedora	FEDORA-2026-c008e6a5da	F42	openbao	2026-05-01
Fedora	FEDORA-2026-41918b2b57	F43	openbao	2026-05-01
Fedora	FEDORA-2026-c7450bfed6	F44	openbao	2026-05-01
Fedora	FEDORA-2026-d08c298940	F42	openssh	2026-05-02
Fedora	FEDORA-2026-ddc5696c20	F42	openvpn	2026-05-02
Fedora	FEDORA-2026-086acf3001	F44	openvpn	2026-04-30
Fedora	FEDORA-2026-f416c4ba87	F44	pdns	2026-05-06
Fedora	FEDORA-2026-bc5090f99b	F42	perl-CryptX	2026-05-02
Fedora	FEDORA-2026-3e1f671a17	F43	perl-CryptX	2026-05-02
Fedora	FEDORA-2026-f533fcc0b6	F44	perl-CryptX	2026-05-02
Fedora	FEDORA-2026-156e6bfb27	F42	podman	2026-04-30
Fedora	FEDORA-2026-05d463c932	F44	pyOpenSSL	2026-05-06
Fedora	FEDORA-2026-91671b8061	F42	pyp2spec	2026-05-01
Fedora	FEDORA-2026-1f68c09a18	F43	pyp2spec	2026-05-01
Fedora	FEDORA-2026-4a8ed954a6	F44	pyp2spec	2026-05-01
Fedora	FEDORA-2026-97a8eb204a	F43	python3.14	2026-05-04
Fedora	FEDORA-2026-c1ca370c1a	F42	python3.6	2026-05-01
Fedora	FEDORA-2026-f08d5a8191	F43	python3.6	2026-05-01
Fedora	FEDORA-2026-a335d04675	F44	python3.6	2026-05-01
Fedora	FEDORA-2026-60a694a385	F42	python3.9	2026-04-30
Fedora	FEDORA-2026-7986d7f994	F43	python3.9	2026-04-30
Fedora	FEDORA-2026-85cf3694d8	F44	python3.9	2026-04-30
Fedora	FEDORA-2026-76f57efeef	F42	rust-openssl	2026-05-02
Fedora	FEDORA-2026-16a3cea414	F43	rust-openssl	2026-05-02
Fedora	FEDORA-2026-fc9d4b5520	F44	rust-openssl	2026-05-02
Fedora	FEDORA-2026-76f57efeef	F42	rust-openssl-sys	2026-05-02
Fedora	FEDORA-2026-16a3cea414	F43	rust-openssl-sys	2026-05-02
Fedora	FEDORA-2026-fc9d4b5520	F44	rust-openssl-sys	2026-05-02
Fedora	FEDORA-2026-a80c26d6f3	F43	rust-rpm-sequoia	2026-04-30
Fedora	FEDORA-2026-a15009ab19	F44	rust-rpm-sequoia	2026-04-30
Fedora	FEDORA-2026-204499102d	F42	rust-rustls-webpki	2026-05-01
Fedora	FEDORA-2026-bea616fc84	F43	rust-rustls-webpki	2026-05-01
Fedora	FEDORA-2026-8f36b2341e	F44	rust-rustls-webpki	2026-05-01
Fedora	FEDORA-2026-6f64d2e143	F42	rust-sequoia-git	2026-05-03
Fedora	FEDORA-2026-95ac9001e8	F43	rust-sequoia-git	2026-05-03
Fedora	FEDORA-2026-0a72408e1b	F44	rust-sequoia-git	2026-05-05
Fedora	FEDORA-2026-156e6bfb27	F42	skopeo	2026-04-30
Fedora	FEDORA-2026-c0590bd498	F44	squid	2026-05-06
Fedora	FEDORA-2026-57515ed8b1	F44	uriparser	2026-05-05
Fedora	FEDORA-2026-795b0d0367	F42	vhs	2026-05-01
Fedora	FEDORA-2026-7646f2a691	F43	vhs	2026-05-01
Fedora	FEDORA-2026-94fbf80bec	F44	vhs	2026-05-01
Fedora	FEDORA-2026-adc66b374a	F42	xdg-dbus-proxy	2026-04-30
Fedora	FEDORA-2026-78cd69d9ae	F43	xen	2026-05-01
Fedora	FEDORA-2026-883e88db68	F44	xen	2026-05-02
Mageia	MGASA-2026-0108	9	kernel, kmod-virtualbox	2026-05-04
Oracle	ELSA-2026-11635	OL8	PackageKit	2026-04-30
Oracle	ELSA-2026-11504	OL9	PackageKit	2026-04-30
Oracle	ELSA-2026-50249		dtrace	2026-05-01
Oracle	ELSA-2026-50251	OL8	dtrace	2026-05-01
Oracle	ELSA-2026-50250	OL8	dtrace	2026-05-01
Oracle	ELSA-2026-50251	OL8	dtrace	2026-05-01
Oracle	ELSA-2026-50250	OL9	dtrace	2026-05-01
Oracle	ELSA-2026-50250	OL9	dtrace	2026-05-01
Oracle	ELSA-2026-50249	OL9	dtrace	2026-05-01
Oracle	ELSA-2026-12176	OL8	fence-agents	2026-05-01
Oracle	ELSA-2026-11712	OL10	grafana	2026-04-30
Oracle	ELSA-2026-11507	OL8	grafana	2026-04-30
Oracle	ELSA-2026-11711	OL9	grafana	2026-04-30
Oracle	ELSA-2026-11881	OL10	grafana-pcp	2026-05-01
Oracle	ELSA-2026-11514	OL8	grafana-pcp	2026-04-30
Oracle	ELSA-2026-11704	OL9	grafana-pcp	2026-04-30
Oracle	ELSA-2026-50255	OL7	kernel	2026-05-04
Oracle	ELSA-2026-50255	OL8	kernel	2026-05-04
Oracle	ELSA-2026-50255	OL8	kernel	2026-05-04
Oracle	ELSA-2026-50253	OL8	kernel	2026-05-04
Oracle	ELSA-2026-50254	OL9	kernel	2026-05-04
Oracle	ELSA-2026-50253	OL9	kernel	2026-05-04
Oracle	ELSA-2026-50253	OL9	kernel	2026-05-04
Oracle	ELSA-2026-12423	OL10	libcap	2026-05-04
Oracle	ELSA-2026-12441	OL9	libcap	2026-05-01
Oracle	ELSA-2026-12265	OL10	libtiff	2026-05-01
Oracle	ELSA-2026-12271	OL9	libtiff	2026-05-01
Oracle	ELSA-2026-11521	OL8	sudo	2026-04-30
Oracle	ELSA-2026-12310	OL9	sudo	2026-05-01
Oracle	ELSA-2026-12285	OL10	thunderbird	2026-05-04
Oracle	ELSA-2026-50254		uek-kernel	2026-05-04
Oracle	ELSA-2026-11509	OL8	vim	2026-04-30
Oracle	ELSA-2026-11510	OL9	vim	2026-04-30
Oracle	ELSA-2026-11692	OL8	xorg-x11-server	2026-04-30
Oracle	ELSA-2026-11656	OL8	xorg-x11-server-Xwayland	2026-05-01
Red Hat	RHSA-2026:8467-01	EL10	.NET 10.0	2026-05-05
Red Hat	RHSA-2026:8473-01	EL8	.NET 10.0	2026-05-05
Red Hat	RHSA-2026:8471-01	EL9	.NET 10.0	2026-05-05
Red Hat	RHSA-2026:8470-01	EL10	.NET 8.0	2026-05-05
Red Hat	RHSA-2026:13281-01	EL10.0	.NET 8.0	2026-05-05
Red Hat	RHSA-2026:8468-01	EL8	.NET 8.0	2026-05-05
Red Hat	RHSA-2026:8469-01	EL9	.NET 8.0	2026-05-05
Red Hat	RHSA-2026:13693-01	EL9.4	.NET 8.0	2026-05-05
Red Hat	RHSA-2026:13283-01	EL9.6	.NET 8.0	2026-05-05
Red Hat	RHSA-2026:8472-01	EL10	.NET 9.0	2026-05-05
Red Hat	RHSA-2026:13280-01	EL10.0	.NET 9.0	2026-05-05
Red Hat	RHSA-2026:8475-01	EL8	.NET 9.0	2026-05-05
Red Hat	RHSA-2026:8474-01	EL9	.NET 9.0	2026-05-05
Red Hat	RHSA-2026:13282-01	EL9.6	.NET 9.0	2026-05-05
Red Hat	RHSA-2026:13284-01	EL8	LibRaw	2026-05-04
Red Hat	RHSA-2026:10135-01	EL9	buildah	2026-04-30
Red Hat	RHSA-2026:12030-01	EL9.4	buildah	2026-05-04
Red Hat	RHSA-2026:11749-01	EL9.6	buildah	2026-05-04
Red Hat	RHSA-2026:1905-01	EL10	fence-agents	2026-05-04
Red Hat	RHSA-2026:2309-01	EL10.0	fence-agents	2026-05-04
Red Hat	RHSA-2026:1906-01	EL8	fence-agents	2026-05-04
Red Hat	RHSA-2026:12176-01	EL8	fence-agents	2026-05-05
Red Hat	RHSA-2026:2483-01	EL8.4	fence-agents	2026-05-04
Red Hat	RHSA-2026:2486-01	EL8.6	fence-agents	2026-05-04
Red Hat	RHSA-2026:2221-01	EL8.8	fence-agents	2026-05-04
Red Hat	RHSA-2026:1903-01	EL9	fence-agents	2026-05-04
Red Hat	RHSA-2026:13672-01	EL9	fence-agents	2026-05-05
Red Hat	RHSA-2026:2303-01	EL9.0	fence-agents	2026-05-04
Red Hat	RHSA-2026:2300-01	EL9.2	fence-agents	2026-05-04
Red Hat	RHSA-2026:2302-01	EL9.4	fence-agents	2026-05-04
Red Hat	RHSA-2026:2299-01	EL9.6	fence-agents	2026-05-04
Red Hat	RHSA-2026:11805-01	EL8.2	firefox	2026-05-04
Red Hat	RHSA-2026:10707-01	EL10	gdk-pixbuf2	2026-04-30
Red Hat	RHSA-2026:11325-01	EL10.0	gdk-pixbuf2	2026-04-30
Red Hat	RHSA-2026:12114-01	EL7	gdk-pixbuf2	2026-04-30
Red Hat	RHSA-2026:10741-01	EL8	gdk-pixbuf2	2026-04-30
Red Hat	RHSA-2026:11806-01	EL8.2	gdk-pixbuf2	2026-04-30
Red Hat	RHSA-2026:12115-01	EL8.6	gdk-pixbuf2	2026-04-30
Red Hat	RHSA-2026:12060-01	EL8.8	gdk-pixbuf2	2026-04-30
Red Hat	RHSA-2026:10708-01	EL9	gdk-pixbuf2	2026-04-30
Red Hat	RHSA-2026:12061-01	EL9.0	gdk-pixbuf2	2026-04-30
Red Hat	RHSA-2026:11326-01	EL9.2	gdk-pixbuf2	2026-04-30
Red Hat	RHSA-2026:11328-01	EL9.4	gdk-pixbuf2	2026-04-30
Red Hat	RHSA-2026:11327-01	EL9.6	gdk-pixbuf2	2026-04-30
Red Hat	RHSA-2026:9254-01	EL7	java-11-openjdk with Extended Lifecycle Support	2026-05-04
Red Hat	RHSA-2026:7675-01	EL10	nodejs24	2026-05-04
Red Hat	RHSA-2026:9711-01	EL9.4	nodejs:20	2026-04-30
Red Hat	RHSA-2026:9874-01	EL9.6	nodejs:20	2026-04-30
Red Hat	RHSA-2026:7670-01	EL8	nodejs:24	2026-05-04
Red Hat	RHSA-2026:7350-01	EL9	nodejs:24	2026-05-04
Red Hat	RHSA-2026:13380-01	EL10	openssh	2026-05-04
Red Hat	RHSA-2026:12389-01	EL10.0	openssh	2026-05-04
Red Hat	RHSA-2026:13383-01	EL8	openssh	2026-05-04
Red Hat	RHSA-2026:3354-01	EL10	python-pyasn1	2026-05-04
Red Hat	RHSA-2026:4138-01	EL10.0	python-pyasn1	2026-05-04
Red Hat	RHSA-2026:4148-01	EL7	python-pyasn1	2026-05-04
Red Hat	RHSA-2026:4146-01	EL8	python-pyasn1	2026-05-04
Red Hat	RHSA-2026:4145-01	EL8.2	python-pyasn1	2026-05-04
Red Hat	RHSA-2026:4147-01	EL8.4	python-pyasn1	2026-05-04
Red Hat	RHSA-2026:4144-01	EL8.6	python-pyasn1	2026-05-04
Red Hat	RHSA-2026:4139-01	EL8.8	python-pyasn1	2026-05-04
Red Hat	RHSA-2026:3359-01	EL9	python-pyasn1	2026-05-04
Red Hat	RHSA-2026:4140-01	EL9.0	python-pyasn1	2026-05-04
Red Hat	RHSA-2026:4142-01	EL9.2	python-pyasn1	2026-05-04
Red Hat	RHSA-2026:4143-01	EL9.4	python-pyasn1	2026-05-04
Red Hat	RHSA-2026:4141-01	EL9.6	python-pyasn1	2026-05-04
Red Hat	RHSA-2026:2758-01	EL7	resource-agents	2026-05-04
Red Hat	RHSA-2026:2712-01	EL8.4	resource-agents	2026-05-04
Red Hat	RHSA-2026:2453-01	EL8.6	resource-agents	2026-05-04
Red Hat	RHSA-2026:2460-01	EL8.8	resource-agents	2026-05-04
Red Hat	RHSA-2026:10107-01	EL8	rhc	2026-05-01
Red Hat	RHSA-2026:10706-01	EL9	rhc	2026-05-01
Red Hat	RHSA-2026:10705-01	EL9.6	rhc	2026-05-01
Red Hat	RHSA-2026:10758-01	EL10	sudo	2026-05-05
Red Hat	RHSA-2026:11521-01	EL8	sudo	2026-05-05
Red Hat	RHSA-2026:12310-01	EL9	sudo	2026-05-05
Red Hat	RHSA-2026:13731-01	EL9.0	sudo	2026-05-05
Red Hat	RHSA-2026:13651-01	EL10	systemd	2026-05-05
Red Hat	RHSA-2026:13677-01	EL9	systemd	2026-05-05
Red Hat	RHSA-2026:9638-01	EL10	thunderbird	2026-05-04
Red Hat	RHSA-2026:11813-01	EL10.0	thunderbird	2026-05-04
Red Hat	RHSA-2026:9345-01	EL8	thunderbird	2026-05-04
Red Hat	RHSA-2026:8459-01	EL9	thunderbird	2026-05-04
Red Hat	RHSA-2026:12264-01	EL9.0	thunderbird	2026-05-04
Red Hat	RHSA-2026:13412-01	EL9.2	thunderbird	2026-05-04
Red Hat	RHSA-2026:13342-01	EL9.6	thunderbird	2026-05-04
Red Hat	RHSA-2026:13414-01	EL8	tigervnc	2026-05-04
Red Hat	RHSA-2026:11692-01	EL8	xorg-x11-server	2026-05-04
Red Hat	RHSA-2026:11388-01	EL9	xorg-x11-server	2026-05-04
Red Hat	RHSA-2026:11656-01	EL8	xorg-x11-server-Xwayland	2026-05-04
Red Hat	RHSA-2026:11369-01	EL9	xorg-x11-server-Xwayland	2026-05-04
Slackware	SSA:2026-124-01		httpd	2026-05-04
Slackware	SSA:2026-125-01		hunspell	2026-05-05
Slackware	SSA:2026-121-01		mozilla	2026-05-01
SUSE	SUSE-SU-2026:21412-1	SLE-m6.0	Mesa	2026-04-30
SUSE	SUSE-SU-2026:1701-1	SLE12	PackageKit	2026-05-06
SUSE	SUSE-SU-2026:1700-1	SLE15 oS15.4	PackageKit	2026-05-06
SUSE	SUSE-SU-2026:21427-1	SLE16.0	PackageKit	2026-05-04
SUSE	openSUSE-SU-2026:10669-1	TW	alloy	2026-05-05
SUSE	SUSE-SU-2026:21417-1	SLE-m6.0	avahi	2026-04-30
SUSE	SUSE-SU-2026:21445-1	SLE-m6.1	avahi	2026-05-04
SUSE	openSUSE-SU-2026:10670-1	TW	avahi	2026-05-05
SUSE	SUSE-SU-2026:21404-1	SLE16	bouncycastle	2026-04-30
SUSE	openSUSE-SU-2026:10671-1	TW	bubblewrap	2026-05-05
SUSE	openSUSE-SU-2026:0161-1	osB15	chromium	2026-05-01
SUSE	openSUSE-SU-2026:10672-1	TW	cmctl	2026-05-05
SUSE	SUSE-SU-2026:21405-1	SLE16	container-suseconnect	2026-04-30
SUSE	openSUSE-SU-2026:10673-1	TW	coredns	2026-05-05
SUSE	SUSE-SU-2026:21452-1	SLE-m6.1	curl	2026-05-04
SUSE	openSUSE-SU-2026:10674-1	TW	curl	2026-05-05
SUSE	openSUSE-SU-2026:10632-1	TW	dnsdist	2026-04-29
SUSE	openSUSE-SU-2026:10675-1	TW	dpkg	2026-05-05
SUSE	openSUSE-SU-2026:10668-1	TW	firefox	2026-05-05
SUSE	SUSE-SU-2026:21418-1	SLE-m6.0	firewalld	2026-04-30
SUSE	SUSE-SU-2026:21446-1	SLE-m6.1	freeipmi	2026-05-04
SUSE	SUSE-SU-2026:21436-1	SLE16.0	freerdp	2026-05-04
SUSE	openSUSE-SU-2026:20657-1	oS16.0	freerdp	2026-05-04
SUSE	SUSE-SU-2026:21411-1	SLE-m6.0	gdk-pixbuf	2026-04-30
SUSE	openSUSE-SU-2026:10676-1	TW	golang-github-prometheus-prometheus	2026-05-05
SUSE	openSUSE-SU-2026:10654-1	TW	google-guest-agent	2026-05-01
SUSE	openSUSE-SU-2026:10655-1	TW	google-osconfig-agent	2026-05-01
SUSE	openSUSE-SU-2026:10677-1	TW	grafana	2026-05-05
SUSE	openSUSE-SU-2026:20654-1	oS16.0	grafana	2026-04-30
SUSE	openSUSE-SU-2026:10652-1	TW	gvim	2026-05-01
SUSE	openSUSE-SU-2026:20662-1	oS16.0	hauler	2026-05-04
SUSE	SUSE-SU-2026:21461-1	SLE-m6.2	helm	2026-05-04
SUSE	SUSE-SU-2026:21434-1	SLE16.0	helm	2026-05-04
SUSE	openSUSE-SU-2026:20655-1	oS16.0	helm	2026-05-04
SUSE	SUSE-SU-2026:21437-1	SLE16.0	himmelblau	2026-05-04
SUSE	openSUSE-SU-2026:20658-1	oS16.0	himmelblau	2026-05-04
SUSE	openSUSE-SU-2026:10656-1	TW	java-1_8_0-openjdk	2026-05-01
SUSE	openSUSE-SU-2026:10639-1	TW	java-25-openjdk	2026-04-30
SUSE	SUSE-SU-2026:1672-1	MP4.3 SLE15 SLE5.3 SLE5.4 SLE-m5.3 SLE-m5.4 oS15.4	kernel	2026-05-04
SUSE	SUSE-SU-2026:21443-1	SLE-m6.0	kernel	2026-05-04
SUSE	SUSE-SU-2026:21459-1	SLE-m6.0	kernel	2026-05-04
SUSE	SUSE-SU-2026:21454-1	SLE-m6.0 SLE-m6.1	kernel	2026-05-04
SUSE	SUSE-SU-2026:1668-1	SLE12	kernel	2026-05-01
SUSE	SUSE-SU-2026:1669-1	SLE12 SLE15	kernel	2026-05-04
SUSE	SUSE-SU-2026:1661-1	SLE15	kernel	2026-04-30
SUSE	SUSE-SU-2026:1678-1	SLE15	kernel	2026-05-04
SUSE	SUSE-SU-2026:1674-1	SLE15 SLE5.2 SLE-m5.2	kernel	2026-05-04
SUSE	SUSE-SU-2026:1677-1	SLE15 SLE5.2 SLE-m5.2 oS15.3	kernel	2026-05-04
SUSE	SUSE-SU-2026:1675-1	SLE15 SLE5.3 SLE5.4 SLE-m5.3 SLE-m5.4	kernel	2026-05-04
SUSE	SUSE-SU-2026:1670-1	SLE15 SLE5.5 SLE-m5.5 oS15.5	kernel	2026-05-04
SUSE	SUSE-SU-2026:1676-1	SLE15 SLE5.5 SLE-m5.5 oS15.5	kernel	2026-05-04
SUSE	SUSE-SU-2026:1671-1	SLE15 oS15.6	kernel	2026-05-04
SUSE	SUSE-SU-2026:1671-2	SLE15 oS15.6	kernel	2026-05-04
SUSE	SUSE-SU-2026:21421-1	SLE16.0	kernel	2026-05-04
SUSE	SUSE-SU-2026:21439-1	SLE16.0	kernel	2026-05-04
SUSE	SUSE-SU-2026:21463-1	SLE16.0 SLE-m6.2	kernel	2026-05-04
SUSE	SUSE-SU-2026:21460-1	SLE16.0 SLE-m6.2	kernel	2026-05-04
SUSE	SUSE-SU-2026:21442-1	SLE6.0 SLE-m6.0	kernel	2026-05-04
SUSE	SUSE-SU-2026:21458-1	SLE6.0 SLE-m6.0	kernel	2026-05-04
SUSE	SUSE-SU-2026:21453-1	SLE6.0 SLE-m6.0 SLE-m6.1	kernel	2026-05-04
SUSE	SUSE-SU-2026:21465-1	SLE6.0 SLE-m6.0 SLE-m6.1	kernel	2026-05-04
SUSE	openSUSE-SU-2026:10657-1	TW	krb5-appl-clients	2026-05-01
SUSE	SUSE-SU-2026:1660-1	SLE15	libheif	2026-04-29
SUSE	openSUSE-SU-2026:10641-1	TW	libixml11	2026-04-30
SUSE	openSUSE-SU-2026:10642-1	TW	libmozjs-140-0	2026-04-30
SUSE	openSUSE-SU-2026:10640-1	TW	libpng12-0	2026-04-30
SUSE	SUSE-SU-2026:1702-1	SLE12	libpng12	2026-05-06
SUSE	SUSE-SU-2026:21393-1	SLE-m6.2	libsodium	2026-04-30
SUSE	SUSE-SU-2026:21422-1	SLE16.0	libsodium	2026-05-04
SUSE	openSUSE-SU-2026:20642-1	oS16.0	libsodium	2026-04-30
SUSE	openSUSE-SU-2026:20659-1	oS16.0	libspectre	2026-05-04
SUSE	SUSE-SU-2026:21396-1	SLE-m6.2	libssh	2026-04-30
SUSE	SUSE-SU-2026:21428-1	SLE16.0	libssh	2026-05-04
SUSE	openSUSE-SU-2026:20647-1	oS16.0	libssh	2026-04-30
SUSE	openSUSE-SU-2026:10650-1	TW	libtiff-devel-32bit	2026-05-01
SUSE	SUSE-SU-2026:21407-1	SLE16	mariadb	2026-04-30
SUSE	SUSE-SU-2026:21432-1	SLE16.0	ntfs-3g_ntfsprogs	2026-05-04
SUSE	openSUSE-SU-2026:20651-1	oS16.0	ntfs-3g_ntfsprogs	2026-04-30
SUSE	SUSE-SU-2026:1658-1	SLE-m5.5 oS15.5	openCryptoki	2026-04-29
SUSE	SUSE-SU-2026:21419-1	SLE-m6.0	openCryptoki	2026-04-30
SUSE	SUSE-SU-2026:21455-1	SLE-m6.1	openCryptoki	2026-05-04
SUSE	SUSE-SU-2026:21433-1	SLE16.0	openexr	2026-05-04
SUSE	openSUSE-SU-2026:20652-1	oS16.0	openexr	2026-04-30
SUSE	SUSE-SU-2026:21440-1	SLE-m6.0 SLE-m6.1	ovmf	2026-05-04
SUSE	openSUSE-SU-2026:20646-1	oS16.0	packagekit	2026-04-30
SUSE	SUSE-SU-2026:1655-1	SLE-m5.2 SLE-m5.3 SLE-m5.4	polkit	2026-04-29
SUSE	openSUSE-SU-2026:10644-1	TW	prometheus-postgres_exporter	2026-04-30
SUSE	SUSE-SU-2026:21426-1	SLE16.0	python-Mako	2026-05-04
SUSE	SUSE-SU-2026:21431-1	SLE16.0	python-PyNaCl	2026-05-04
SUSE	SUSE-SU-2026:1666-1	MP4.3 SLE15 oS15.4 oS15.6	python-Pygments	2026-05-01
SUSE	SUSE-SU-2026:1667-1	SLE15 oS15.3	python-Pygments	2026-05-01
SUSE	SUSE-SU-2026:21425-1	SLE16.0	python-jwcrypto	2026-05-04
SUSE	openSUSE-SU-2026:20644-1	oS16.0	python-jwcrypto	2026-04-30
SUSE	openSUSE-SU-2026:20645-1	oS16.0	python-mako	2026-04-30
SUSE	openSUSE-SU-2026:20650-1	oS16.0	python-pynacl	2026-04-30
SUSE	SUSE-SU-2026:21415-1	SLE-m6.0	python311	2026-04-30
SUSE	SUSE-SU-2026:21447-1	SLE-m6.1	python311	2026-05-04
SUSE	openSUSE-SU-2026:10646-1	TW	python311-pyOpenSSL	2026-04-30
SUSE	openSUSE-SU-2026:10658-1	TW	python311-pypdf	2026-05-01
SUSE	openSUSE-SU-2026:10648-1	TW	python315	2026-04-30
SUSE	openSUSE-SU-2026:20653-1	oS16.0	radare2	2026-04-30
SUSE	SUSE-SU-2026:1659-1	SLE-m5.2 SLE-m5.3 SLE-m5.4 SLE-m5.5 oS15.3	sed	2026-04-29
SUSE	SUSE-SU-2026:21413-1	SLE-m6.0	sed	2026-04-30
SUSE	SUSE-SU-2026:21448-1	SLE-m6.1	sed	2026-05-04
SUSE	SUSE-SU-2026:1699-1	SLE12	sed	2026-05-06
SUSE	openSUSE-SU-2026:10649-1	TW	sed	2026-05-01
SUSE	openSUSE-SU-2026:20664-1	oS16.0	thunderbird	2026-05-04
SUSE	openSUSE-SU-2026:10651-1	TW	trivy	2026-05-01
SUSE	openSUSE-SU-2026:0163-1	osB15	trivy	2026-05-04
SUSE	SUSE-SU-2026:21414-1	SLE-m6.0	vim	2026-04-30
SUSE	SUSE-SU-2026:21398-1	SLE-m6.0	vim	2026-04-30
SUSE	SUSE-SU-2026:21450-1	SLE-m6.1	vim	2026-05-04
SUSE	SUSE-SU-2026:21464-1	SLE-m6.1	vim	2026-05-04
SUSE	SUSE-SU-2026:1657-1	SLE15 SLE-m5.5 oS15.5	xen	2026-04-29
SUSE	SUSE-SU-2026:1692-1	SLE5.3 SLE5.4 SLE-m5.3 SLE-m5.4 oS15.4	xen	2026-05-05
SUSE	openSUSE-SU-2026:10660-1	TW	xen	2026-05-04
Ubuntu	USN-8227-1	22.04 24.04 25.10 26.04	curl	2026-05-04
Ubuntu	USN-8230-1	20.04 22.04 24.04 26.04	docker.io-app	2026-05-06
Ubuntu	USN-8228-1	22.04 24.04 25.10 26.04	exim4	2026-05-04
Ubuntu	USN-8226-2	14.04 16.04 18.04 20.04	kmod	2026-04-30
Ubuntu	USN-8226-1	22.04 24.04 25.10	kmod	2026-04-30
Ubuntu	USN-8224-1	20.04	linux-bluefield	2026-04-29
Ubuntu	USN-8233-1	16.04 18.04 20.04 22.04 24.04 25.10	nghttp2	2026-05-05
Ubuntu	USN-8232-1	22.04 24.04 25.10 26.04	python-django	2026-05-05
Ubuntu	USN-8234-1	16.04 18.04 20.04 22.04 24.04 25.10 26.04	python-mako	2026-05-05
Ubuntu	USN-8225-1	18.04 20.04 22.04 24.04 26.04	python-marshmallow	2026-04-30
Ubuntu	USN-8223-1	16.04 18.04 20.04 22.04 24.04	roundcube	2026-04-29
Ubuntu	USN-8229-1	22.04 24.04 25.10 26.04	sed	2026-05-04
Ubuntu	USN-8218-1	18.04 20.04 22.04 24.04	zulucrypt	2026-04-30

Full Story (comments: none)