LWN.net Weekly Edition for September 4, 2025
Welcome to the LWN.net Weekly Edition for September 4, 2025
This edition contains the following feature content:
- The challenge of maintaining curl: a brief Open Source Summit Europe keynote on how maintaining a project with over one-billion installations is not easy.
- Changing GNOME technical governance?: the GNOME project considers a more formal governance model for technical decisions.
- Removing Guix from Debian: why Guix is faced with a rare mid-release-cycle removal.
- Tracking trust with Rust in the kernel: using the Rust type system to ensure that user-space data is properly sanitized.
- The future of 32-bit support in the kernel: 32-bit systems may be obsolete, but the kernel will continue to support them for a long time.
- Highlights from systemd v258: part one: what to expect from the next systemd release.
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.
The challenge of maintaining curl
Keynote sessions at Open Source Summit events tend not to allow much time for detailed talks, and the 2025 Open Source Summit Europe did not diverge from that pattern. Even so, Daniel Stenberg, the maintainer of the curl project, managed to cram a lot into the 15 minutes given to him. Like the maintainers of many other projects, Stenberg is feeling some stress, and the problems appear to be getting worse over time.
![[Daniel Stenberg]](https://static.lwn.net/images/conf/2025/osseu/DanielStenberg-sm.png "Daniel Stenberg")
Curl, he began, is "a small project with a big impact
". It began in
1996 with all of 100 lines of code; it has since grown to 180,000
lines that have been contributed by 1,400 authors. In any given month,
there are 20-25 developers who are actively contributing to curl. The
project has exactly one full-time employee — that being Stenberg himself.
The program is widely used, having been deployed in at least one-billion devices. Just about anything that occasionally connects to the net, he said, uses curl to do it. But using curl is different from supporting its development. As an example, he put up a slide listing the 47 car brands that use curl in their products; he followed it with a slide listing the brands that contribute to curl. The second slide, needless to say, was empty. (A version of both slides can be seen on this page).
Companies tend to assume that somebody else is paying for the development of open-source software, so they do not have to contribute. He emphasized that he has released curl under a free license, so there is no legal problem with what these companies are doing. But, he suggested, these companies might want to think a bit more about the future of the software they depend on.
Open-source software is the best choice, he said, but maintaining it is a tough job. Most projects out there have a single maintainer, and that person is often doing the work in their spare time, without funding. Maintenance involves a lot of tasks, including taking care of security, reviewing patches, writing documentation, keeping the web site going, administering the mailing list, and a long list of other tasks. Occasionally, if a little time is left over, it might also be possible to do a bit of feature development. That is a lot for one person to keep up with.
Companies have a certain tendency to make things worse. He put up an excerpt of a message from Apple support, referring a customer to the curl project for help with their (Apple) device. He has received demands from companies for information on the project's development and security practices, often with tight deadlines for a response. He typically replies by sending back a support contract; that usually results in never hearing from the company again, he said. More recently, he has been getting demands from European companies seeking information on the curl project's Cyber Resilience Act compliance practices.
Some communications are rather less humorous than that; one email
came with a subject reading "I will slaughter you
". He gets emails
from people who found his address in the license notices shipped with their
automobiles asking for support. But he also gets nice thank-you emails at
times.
Problematic email takes other forms as well. There is an increasing crowd
of people who ask a large language model to "find a problem in curl,
make it sound terrible
", then send the result, which is never correct,
to the project, thinking that they are somehow helping. Dealing with these
useless problem reports takes an increasing amount of time.
Recently, the curl project, like many operators of web sites, has been contending with distributed denial-of-service attacks by scrapers run by AI companies. He put up a link to LWN's article on this problem for those who are unfamiliar with it. The curl site consumes a massive amount of bandwidth every month, but only 0.01% of that is source downloads. Most of the rest is bot traffic. That, too, adds to the difficulty of maintaining the project.
He concluded the brief talk with one last email; it was from an 11-year-old child who had found curl useful in some project they were working on. It included an expression of gratitude that, Stenberg said, was truly heartwarming.
[Thanks to the Linux Foundation, LWN's travel sponsor, for supporting our travel to this event.]
Changing GNOME technical governance?
The GNOME project, which recently celebrated its 28th birthday, has never had a formal technical governance; progress has been driven by individuals and groups that advocated for—and worked toward—a particular goal in an ad hoc fashion. Longtime GNOME contributor Emmanuele Bassi would like to see that change by adding cross-project teams and a steering committee for the project; to that end, he gave a talk (YouTube video) at GUADEC 2025 in late July on his idea to establish some technical governance for the project. He also put together a blog post with his notes from the talk. The audience reaction was favorable, so he has followed up on the GNOME discussion forum with an RFC on governance to try to move the effort along.
In the RFC, Bassi described the motivation for the change. He laid out the
current situation, which has changed little "from the 'rag tag band of
misfits' of the halcyon days of the project's youth
". Governance is
highly informal, which leads to difficulties with the project's overall
direction. "Decision-making is an exercise of sisyphean patience, where
people must push the boulder of the community uphill only to watch it roll
back down with every cycle.
"
He quoted from the GNOME Project Handbook; the governance section describes how decisions are made:
Most decisions in GNOME are made informally, by individuals working in collaboration with one another. This informal way of making decisions applies to who works on what, which features are supported, and which technical and user experience designs are implemented.
His goal is to switch away from the "informal" and "individual" parts of
that and instead to "create formal, shared structures to increase
accountability while diffusing personal responsibility
". GNOME has
a set of existing
teams, but they are not aligned to the components and applications that
make up the project. GNOME is, effectively, a collective of individual
projects, each of which is maintained by a single person or, more rarely, a
small group, with no mechanism for those projects to collaborate:
There is no formal venue for discussing changes across multiple projects. There is no formal process to propose changes across multiple projects. Each project is its own special, unique snowflake when it comes to interaction with other projects, both as dependencies and reverse dependency.
One potentially troubling problem is that there is no documented way to
change the technical-governance situation. The GNOME Foundation board is not
part of the technical governance of the project; it is focused on the
foundation itself, overall strategic goals, financial oversight, and the
like.
Bassi is proposing to form four
new teams (platform, OS, core apps, and tooling) that would join with
four existing teams (design, release, translation, and infrastructure) to
form a steering
committee with a single representative from each team. The committee
would be responsible for setting the "overall direction and vision
"
of the project, its priorities, and generally being the ultimate
decision-making authority for GNOME, as well as for the teams and sub-projects.
Though it is not specified, some kind of project-wide referendum would
presumably be needed to enact this, or some other, governance structure.
The teams would be responsible for deciding on whether to accept features and other changes within the projects in their domain. They would communicate in public forums, so that others in the project can have a view into their plans. The teams would form the basis for more collaborative, cross-project planning and development, while the steering committee would oversee all of the teams and the GNOME project as a whole.
The RFC has more detail about the makeup and responsibilities of each team, the structure and duties of the steering committee, term limits, and more. But, at the core of his vision, and, seemingly, his unhappiness with the way that GNOME works currently, is the maintainer model for GNOME projects. The RFC does not go into as much detail, though it clearly looks toward replacing project maintainers with cross-project teams, but the blog post says more:
Individual maintainers should not exist in a complex project—for both the project's and the contributors' sake. They are inefficiency made manifest, a bottleneck, a point of contention in a distributed environment like GNOME. Luckily for us, we almost made them entirely redundant already! Thanks to the release service and CI pipelines, we don't need a person spinning up a release archive and uploading it into a file server. We just need somebody to tag the source code repository, and anybody with the right permissions could do that.We need people to review contributions; we need people to write release notes; we need people to triage the issue tracker; we need people to contribute features and bug fixes. None of those tasks require the "maintainer" role.
There have only been a few replies to the RFC post, all generally favorable, but there are questions about getting rid of the maintainer role. Adrian Vovk thought that there may not really be enough people in GNOME to fill the roles that are being described. He wondered if the end result would be to continue the maintainer role, though perhaps without the name:
Overall, my concern is that we don't have enough people for this bureaucratic process to shift us away from the status quo. It seems to me like we'll still have de-facto "maintainers" who have the institutional knowledge over their corner of the stack. Not even necessarily because folks want to hoard institutional knowledge, but simply because we don't have enough people interested in involving themselves. Someone needs to keep triaging issues/reviewing MRs/fixing bugs/etc, and it's going to be the people who know most about a specific codebase. I fear the end result will be teams that have members working on unrelated projects, or grouped into subteams that consist essentially of individuals.[...] I suppose a valid course of action is just to accept that this is what it is, and that the people with de-facto power today (by being a maintainer of a project) will have formal power when we put these structures into place (by being the sole interested party for a project on the relevant team). But I'm not certain that this is all you intend to achieve.
Bassi pointed out
that the "Drawbacks"
section of the RFC mentioned the lack-of-people problem, but that the aim
is to "bring in new contributors that have so far resisted the role of
'maintainer'
". But Michael Catanzaro suggested
that removing maintainers was "unrealistic
":
GNOME is a big collection of small projects, and teams with a large scope and perspective are just not a better way of working on small projects. I see only two possible ways that ends: (a) we'll continue to have de facto maintainers and everything operates same as before, except without any way to formally indicate who the maintainer is, which is not an improvement; or (b) we take "no maintainers" seriously until chaos ensues and eventually we change our minds and bring back maintainers.
He noted that the RFC did not directly call for removing maintainers and he
saw no problem with forming teams as an experiment. Creating a steering
committee to relieve the current release and design teams from serving in
that role is "a clear improvement
", he said. Bassi seemed to
bristle a bit about the concerns expressed by Vovk and Catanzaro with
regard to the need for maintainers. Bassi wondered if it was because they
were too strongly focused on the recognition aspects of being the
maintainer of a project. The attention on the maintainers question seemed to
irritate him some, as seen in his reply to
another generally
favorable response from Allan Day:
Ideally, instead of people hyperfocusing on whether or not I'm trying to remove the role of maintainers like I'm proposing the installation of guillotines in the middle of Place de la Revolution, we'd see people proposing additional teams and sub-teams.
Bassi, Catanzaro, and Vovk appeared to be talking past each other to a
certain extent.
Both Catanzaro and Vovk were largely in favor of the ideas, but expressed concern that there
were simply not enough people to fill the teams,
which would inevitably mean that some interested developers would be acting
as maintainers anyway. Catanzaro explicitly
rejected the notion that he was focused on recognition and agreed with
Bassi that the maintainer model is flawed: "The fact that maintainers
have final say on everything is a defect in our current development model,
and I appreciate that you're trying to fix that.
" But there is a need
for some person or entity to have responsibility for ensuring that the
critical work of maintaining a project is actually done:
So my question is: how will high level teams decide who will read the issue tracker, respond to merge requests, flag security issues for GNOME Security, etc? Components cannot be overlooked. If you join the Platform team, then will you dutifully help with triaging libxslt issue reports? I rather doubt it, but the team will need to ensure that somebody does so. Maintainership seems like the best way to define this responsibility, but as long as each high level team truly has a plan to take responsibility for each of the dozens of components within its extremely broad purview, I suppose that's sufficient.
That is as far as the conversation has gotten at the time of this writing; we will have to wait and see where it goes. The goals of the proposal seem popular, while some of the details will still need to be worked out—all par for the course in a free-software-governance discussion. What is unclear, however, is how to actually enact the change, since there is no steering committee or other overarching technical-governance decision-making body. One suspects that if the proposal (or some, yet-to-be-revealed alternative) gains steam, GNOME will figure that out in due course.
We have seen other projects undertake this kind of change before, notably Python; Bassi has clearly looked into governance, and changes to it, in other free-software communities as part of coming up with his proposal. Someday, other projects may also look to GNOME for guidance, when they reach a point where change is needed. It is yet another benefit of building our communities in the open.
Removing Guix from Debian
As a rule, if a package is shipped with a Debian release, users can count on it being available, and updated, for the entire life of the release. If package foo is included in the stable release—currently Debian 13 ("trixie")—a user can reasonably expect that it will continue to be available with security backports as long as that release is supported, though it may not be included in Debian 14 ("forky"). However, it is likely that the Guix package manager will soon be removed from the repositories for Debian 13 and Debian 12 ("bookworm", also called oldstable).
Debian has the Advanced Package Tool (APT) for package management, of course, but Guix offers a different approach and can be used in conjunction with other distribution package managers. Guix is inspired by Nix's functional package management; it offers transactional upgrades and rollbacks, package management for unprivileged users, and more. Unlike Nix, its packages are defined using the Guile implementation of the Scheme programming language. There is also a GNU Guix distribution as well; LWN covered both NixOS and Guix in February 2024, and looked at Nix alternative Lix in July 2024.
On June 24, the Guix project disclosed several security vulnerabilities that affected the guix-daemon, which is a program that is used to build software and access the store where successful builds are kept. Two of the vulnerabilities, CVE-2025-46415 and CVE-2025-46416, would allow a local user to gain the privileges of any build users, manipulate build output, as well as gain the privileges of the daemon user. The vulnerabilities also impacted Nix and Lix package managers.
The disclosure blog post gave instructions on how to mitigate the vulnerabilities by updating guix-daemon using the "guix pull" command, but the project did not make a new Guix release. The last actual release from the project was version 1.4.0, which was announced in December 2022. The Guix project has a rolling-release model, with sporadic releases, and does not maintain stable branches with security updates. This may not pose a problem for users getting Guix directly from the project, but it poses some obstacles for inclusion in other Linux distributions.
Debian package
Salvatore Bonaccorso filed a bug
against Debian's
guix package
on June 25 to report the vulnerabilities. Vagrant
Cascadian, the maintainer of the package, replied
on July 15, and said that the fixes for the security
vulnerabilities had been "commingled with a lot of other upstream
changes
", and it would be "trickier than in the past
" to try
to backport the fixes without the other changes in Guix. He said he
had just managed to "get something to compile
" with the
security fixes applied, using a backport
repository maintained by Denis 'GNUtoo' Carikli.
Carikli had brought up the difficulty of backporting Guix fixes on the guix-devel mailing list on July 8. Various distributions had Guix versions 1.2.0, 1.3.0, and 1.4.0, with Debian shipping 1.2.0 and 1.4.0 and used as the upstream for other distributions' packages:
But the Debian package maintainer has the almost impossible task to backport all the security fixes without a community nor help behind [maintaining it] and as things are going, this will probably lead to the Debian guix package being removed with cascading effect for the other distributions.
He said he had applied about 50 patches that involve guix-daemon between the 1.4.0 release and the last-known security fix. He also noted that his effort would probably not be suitable for Linux distributions that ship a Guix package. He wondered what the best way would be to collaborate on a branch that distributions could pull from for updates.
Liam Hupfer said
that "we gave up and shipped the last commit on master mentioned in
the recent CVE disclosure
" for Nix. He said he would also like to
see Guix figure out backporting patches, but could Cascadian consider
the Nix approach until then?
No, that approach would not make sense, Cascadian said. If
Guix was "truly a rolling release
", then it may just not make
sense to maintain distribution packages:
Up till recently, it has always been possible to backport changes with relative ease, but that was perhaps just lack of development... the recent unprivileged daemon stuff really made backporting patches harder. [...]
In the Debian release model, ideally we would avoid bringing in unrelated patchsets (e.g. the unprivileged daemon code bringing in an entire network stack?) but that might be too hard to pull off. Not sure if the security team would accept a patchset that includes more than the minimum necessary to fix the security issues.
Without a branch that contained backported patches, they would be
inclined "to recommend dropping the Guix package in Debian
".
On August 27, they did just that. Cascadian filed a bug to remove guix from Debian 11 ("bullseye"), bookworm, and trixie. They also filed a bug to remove the package from the upcoming forky release. Adam D. Barratt replied and said that it would not be possible to remove guix from bullseye, which is now an LTS release; only updates from the security archive were now allowed.
There are no dependencies on guix, so the removal of the package should not affect any other Debian packages in the trixie and bookworm releases.
What's next?
I emailed Cascadian to find out what the next steps would be for
the package in those releases. They said that the package is likely to
be removed from the upcoming point
releases for trixie and bookworm. Users who have it installed
already will be stuck at the old version, unless they take manual
steps to update. Cascadian said this was not a great outcome "but
better than keeping it available for people to install the vulnerable
version
".
The guix package should not have landed in trixie at all,
Cascadian said, "my understanding was that [the bug report] should
have blocked it from being released
". However, it seems there was
enough activity on the bug that prevented Debian's autoremoval
mechanisms from triggering and pulling the package from the final
release. "There apparently is not manual review of all blockers in
the current Debian release process
". Even if the timing had been
better for the trixie release, though, the same fixes would need to
have been applied to bookworm and older releases.
Cascadian said that it has been a fair amount of work to keep Guix
working on Debian. For example, he has had to maintain various Guile
dependencies, and deal with the fact that Guix uses "fairly
old
" GCC versions whereas Debian usually ships the latest GCC
version available for a given release. At some point, they said,
"you have to evaluate whether that work is worth it
" when the
upstream provides a binary that people can install.
Guix is better for having been packaged for Debian and run through
Debian's Lintian
tool. Cascadian said that they have probably fixed more typos in Guix
than anyone else, and have found other problems while checking that
the builds of Guix are reproducible. "Any time you run a piece of
software through processes outside of the primary development
workflow, you find surprises worth fixing.
"
Regular releases
There is an effort in the Guix project to create yearly releases. In May, Steve George proposed that the project adopt a Guix Consensus Document for "Regular and efficient releases", and it was accepted by the project in July. It calls for a release every year in June, with a one-time exception for a November 2025 release, and a short development cycle for the June 2026 release. Even so, that will not provide stable branches for Debian and other distributions to pull from; it will just shorten the interval and feature differences between major releases.
Debian users will, of course, still be able to use Guix by installing it using binaries provided by the Guix project. That will, at least potentially, leave some users out in the cold—Debian currently provides a guix package for x86-64, Arm64, PowerPC, RISC-V, 32-bit Arm, and 32-bit x86. The Guix project itself does does not have RISC-V binaries, though it does cover the other architectures.
It is fairly unusual for a package to be removed from a stable or oldstable release. For example, the bookworm release has been out for more than two years, but a search of the Debian bug database only shows one package—guix—that has the "RM" tag in the subject to flag a package for removal.
According to Debian's popularity contest (popcon) statistics, there are not quite 230 systems with Guix installed. Popcon statistics only hint at the actual number of package installs, but assuming they are approximately accurate, then removing Guix will not inconvenience a significant number of Debian users. It will, however, mean that fewer people are poking at Guix with an intent to making it work on distributions like Debian, while finding distribution-specific bugs.
Tracking trust with Rust in the kernel
The Linux kernel has to handle many different sources of data that should not be trusted: user space, network connections, and removable storage, to name a few. The kernel has to remain secure even if one of these sends garbled (or malicious) data. Benno Lossin has been working on an API for kernel Rust code that makes it harder to accidentally make decisions based on data from user space. That work is now on its fourth revision, and Lossin has asked kernel developers to experiment with it and see where problems remain, making this a good time to look at the proposed API.
The core approach, as with so many things in Rust, centers on the type system. Lossin's patch set introduces a new type, Untrusted, that marks data as originating from an untrusted source, and therefore requiring special caution. Trying to access a value wrapped by Untrusted is forbidden by Rust. The type is a "transparent" structure, meaning that it will be laid out in memory exactly like the type that it wraps. An Untrusted<u8> is a single byte, for example. The type therefore has no run-time overhead, so it can be used as a kind of marker in the type system for data that has come from user space without being validated. That makes it impossible to pass into functions that expect normal kernel data by accident.
The bulk of Lossin's patch set is documentation for Untrusted, and some utility functions to manipulate untrusted values. There is also special support for common data structures, specifically slices (arrays with a run-time-known length) and vectors (growable arrays on the heap) of untrusted values. When dealing with an existing buffer that should be filled with untrusted data, the documentation recommends writing the interface like this:
pub fn read_from_userspace(buf: &mut [Untrusted<u8>])
That function takes a mutable reference to a slice of untrusted bytes, and will fill it with user-space data. That data can later be copied back to user space without having to unwrap it. Trying to actually use the value of an untrusted object within the kernel, however, will cause a compiler error. Lossin recommends that form of API because converting an &mut Untrusted<[u8]> (a mutable reference to an untrusted slice of bytes) into an &mut [Untrusted<u8>] (a mutable reference to a slice of individually untrusted bytes) can be done automatically — conversions are inserted where needed by the compiler due to the DerefMut implementation for Untrusted — but converting things the other way around requires an explicit function call. If Rust developers get in the habit of writing APIs involving Untrusted in this way, they'll be less of a hassle to use.
Sometimes, the kernel does need to read user-space data, not merely copy it around. The third patch of the set contains functions to help with that. It introduces a new trait called Validate that encapsulates the logic for validating user-space data before use. For a custom type T, an implementation of Validate<S> contains the logic needed to turn an Untrusted<S> into a plain T. Lossin isn't totally happy with that API, though, and wants to find time to improve it.
Greg Kroah-Hartman, who has been enthusiastic about the idea of marking input from user space in the past, asked for Lossin to add an example of a driver using Untrusted.
ioctl() is the callback that is taking untrusted data from userspace. That's one place we have had more kernel buffer overflows then I can count and ALWAYS needs to be properly verified before anything can be done with the data there.
Lossin hasn't written a complete example driver, but did share a rough sketch of what using the new API to implement a driver ioctl() function might look like. ioctl() is a tricky interface because it takes two parameters: cmd, which specifies which command to run, and arg, the meaning of which depends on cmd. How arg should be validated depends, therefore, on which command user space has sent. Lossin suggested representing this in Rust with an enumeration:
enum MyIoctlArgs {
WriteFoo(UserPtr<Foo>),
VerifyBar(UserPtr<Bar>),
// ...
}
With some suitable tweaks to the Rust driver API, the generic MiscDevice::ioctl() function could take a structure that bundles cmd and arg together:
pub struct IoctlArgs {
pub cmd: u32,
pub arg: usize,
}
fn ioctl(
_device: <Self::Ptr as ForeignOwnable>::Borrowed<'_>,
_file: &File,
_args: Untrusted<IoctlArgs>,
) -> Result<isize>
The Untrusted<IoctlArgs> could then be validated into a normal MyIoctlArgs value. This would not prevent the programmer from botching the validation logic, of course, but it would force the conversion to happen in one specific place, and enforce that it is called. Hopefully, that makes it easier to spot missing checks.
Kroah-Hartman raised the problem of bugs where the kernel "validates" a particular piece of data while it is still accessible to user space, and only then copies it with copy_from_user(). He wondered how this interface could protect against that. The UserPtr types in MyIoctlArgs in his example help there, Lossin explained. These represent pointers to user-space memory; when combined with a length, they can become a UserSlice. The UserSlice::read_all() method being the Rust equivalent of copy_from_user(). Right now, read_all() just reads bytes directly, but if his patch set is accepted, he would want to change it to mark the read bytes as untrusted:
pub fn read_all<A: Allocator>(
self,
buf: &mut Untrusted<Vec<u8, A>>,
flags: Flags
) -> Result
With the types Lossin sketched out, the type system would theoretically enforce the progression from Untrusted<IoctlArgs>, to MyIoctlArgs, to UserPtr, to Untrusted<Vec<u8>>, to whatever user-defined type is appropriate for the argument of ioctl(). Since he did not provide a full, working example, there are still some questions his response leaves unanswered, but Kroah-Hartman was happy with it. At the time of writing no other comments on the patch set have been made. If the API is adopted in its current form, it will necessitate pervasive changes to the interfaces for Rust drivers, so the patch set seems likely to be a topic of discussion at the upcoming Kangrejos conference about the Rust for Linux project in September.
The future of 32-bit support in the kernel
Arnd Bergmann started his Open Source Summit Europe 2025 talk with a clear statement of position: 32-bit systems are obsolete when it comes to use in any sort of new products. The only reason to work with them at this point is when there is existing hardware and software to support. Since Bergmann is the overall maintainer for architecture support in the kernel, he is frequently asked whether 32-bit support can be removed. So, he concluded, the time has come to talk more about that possibility.People naturally think about desktop machines first, he continued. If you were running Linux in the 1990s, you had a 32-bit, desktop system. Unix systems, though, moved to 64-bit platforms around 30 years ago, and the Linux desktop made that move about 20 years ago. Even phones and related devices have been 64-bit for the last decade. If those systems were all that Linux had to support, 32-bit support would have long since been removed from the kernel. He summarized the situation with this slide, showing how the non-embedded architectures have transitioned to either 64-bit or nonexistence over time:
![[History of
non-embedded 32-bit platforms]](https://static.lwn.net/images/conf/2025/osseu/arnd-non-embedded-sm.png)
The world is not all desktops — or servers — though; embedded Linux exists as well. About 90% of those systems are running on Arm processors. The kernel has accumulated a lot of devicetree files describing those systems over the years; only in this last year has the number of devicetrees for armv8 (64-bit) systems exceeded the number for armv7 (32-bit) systems.
For Arm processors with pre-armv7 architectures, there are only three for which it is still possible to buy hardware, but a number are still supported by the kernel community:
![[History of
pre-armv7 platforms]](https://static.lwn.net/images/conf/2025/osseu/arnd-pre-v7-sm.png)
Many other pre-armv7 CPUs are out of production, but the kernel still has support for them. Of those, he said, there are about ten that could be removed now. It would be nice to be able to say that support for the others will be removed after a fixed period, ten years perhaps, but hardware support does not work that way. Instead, one has to think in terms of half lives; every so often, it becomes possible to remove support for half of the platforms. It all depends on whether there are users for the processors in question.
The kernel is still adding support for some 32-bit boards, he said, but at least ten new 64-bit boards gain support for each 32-bit one.
There are a number of non-Arm 32-bit architectures that still have support in the kernel; these include arc, microblaze, nios2, openrisc, rv32, sparc/leon, and xtensa. All of them are being replaced by RISC-V processors in new products. RISC-V is what you use if you don't care about Arm compatibility, he said.
Then, there is the dusty corner where nommu (processors without a
memory-management unit) live; these include armv7-m, m68k, superh, and
xtensa. Nobody is building anything with this kind of hardware now, and
the only people who are working on them in any way are those who have to
support existing systems. "Or to prove that it can be done
."
There are still some people who need to run 32-bit applications that cannot be updated; the solution he has been pushing people toward is to run a 32-bit user space on a 64-bit kernel. This is a good solution for memory-constrained systems; switching to 32-bit halves the memory usage of the system. Since, on most systems, almost all memory is used by user space, running a 64-bit kernel has a relatively small cost. Please, he asked, do not run 32-bit kernels on 64-bit processors.
![[Arnd Bergmann]](https://static.lwn.net/images/conf/2025/osseu/ArndBergmann-sm.png "Arnd Bergmann")
There are some definite pain points that come with maintaining 32-bit
support; most of the complaints, he said, come from developers in the
memory-management subsystem. The biggest problem there is the need to
support high memory; it is complex, and requires support throughout the
kernel. High memory is needed when the kernel lacks the address space to
map all of the installed physical memory; that tends to be at about 800MB
on 32-bit systems. (See this article for
more information about high memory).
Currently the kernel is able to support 32-bit systems with up to 16GB of
installed memory. Such systems are exceedingly rare, though, and support
for them will be going away soon. There are a few 4GB systems out there,
including some Chromebooks. Systems with 2GB are a bit more common. Even
these systems, he said, are "a bit silly
" since the memory costs
more than the CPU does. There are some use cases for such systems, though.
Most 32-bit systems now have less than 1GB of installed memory. The
kernel, soon, will not try to support systems with more than 4GB.
There are some ideas out there for how to support the larger-memory 32-bit systems without needing the high-memory abstraction. Linus Walleij is working on entirely separating the kernel and user-space address spaces, giving each 4GB to work with; this is a variant on the "4G/4G" approach that has occasionally been tried for many years. It is difficult to make such a system work efficiently, so this effort may never succeed, Bergmann said.
Another approach is the proposed "densemem" memory model, which does some fancy remapping to close holes in the physical address space. Densemem can support up to 2GB and is needed to replace the SPARSEMEM memory model, the removal of which which will eventually be necessary in any case. This work has to be completed before high memory can be removed; Bergmann said that he would be interested in hearing from potential users of the densemem approach.
One other possibility is to drop high memory, but allow the extra physical memory to be used as a zram swap device. That would not be as efficient as accessing the memory directly, but it is relatively simple and would make it possible to drop the complexity of high memory.
Then, there is the year-2038 problem, which he spent several years working on. The kernel-side work was finished in 2020; the musl C library was updated that same year, and the GNU C Library followed the year after. Some distributors have been faster than others to incorporate this work; Debian and Ubuntu have only become year-2038-safe this year.
The year-2038 problem is not yet completely solved, though; there are a lot of packages that have unfixed bugs in this area. Anything using futex(), he said, has about a 50% chance of getting time handling right. The legacy 32-bit system calls, which are not year-2038 safe, are still enabled in the kernel, but they will go away at some point, exposing more bugs. There are languages, including Python and Rust, that have a lot of broken language bindings. Overall, he said, he does not expect any 32-bit desktop system to survive the year-2038 apocalypse.
A related problem is big-endian support, which is also 32-bit only, and also obsolete. Its removal is blocked because IBM is still supporting big-endian mainframe and PowerPC systems; as long as that support continues, big-endian support will stay in the kernel.
A number of other types of support are under discussion. There were once
32-bit systems with more than eight CPUs, but nobody is using those
machines anymore, so support could be removed. Support for armv4
processors, such as the DEC StrongARM CPU,
should be removed. Support for early armv6 CPUs, including the omap2 and
i.mx31, "complicates everything
"; he would like to remove it, even
though there are still some Nokia
770 systems in the wild. The time is coming for the removal of all
non-devicetree board files. Removal of support for Cortex M CPUs,
which are nommu systems, is coming in a couple of years. Developers are
eyeing i486 CPU support, but that will not come out yet. Bergmann has sent
patches to remove support for KVM on 32-bit CPUs, but there is still
"one PowerPC user
", so that support will be kept for now.
To summarize, he said, the kernel will have to retain support for armv7 systems for at least another ten years. Boards are still being produced with these CPUs, so even ten years may be optimistic for removal. Everything else, he said, will probably fade away sooner than that. The removal of high-memory support has been penciled in for sometime around 2027, and nommu support around 2028. There will, naturally, need to be more discussion before these removals can happen.
An audience member asked how developers know whether a processor is still in use or not; Bergmann acknowledged that it can be a hard question. For x86 support, he looked at a lot of old web pages to make a list of which systems existed, then showed that each of those systems was already broken in current kernels for other reasons; the lack of complaints showed that there were no users. For others, it is necessary to dig through the Git history, see what kinds of changes are being made, and ask the developers who have worked on the code; they are the ones who will know who is using that support.
Another person asked about whether the kernel would support big-endian
RISC-V systems. Bergmann answered that those systems are not supported
now, and he hoped that it would stay that way. "With RISC-V, anybody
can do anything, so they do, but it is not always a good idea
". The
final question was about support for nommu esp32 CPUs; he answered that
patches for those CPUs exist, but have not been sent upstream. Those
processors are "a cool toy
", but he does not see any practical
application for them.
The slides for this talk are available. The curious may also want to look at Bergmann's 2020 take on this topic.
[Thanks to the Linux Foundation, LWN's travel sponsor, for supporting my travel to this event.]
Highlights from systemd v258: part one
The next release of systemd has been percolating for an unusually long time. Systemd releases are usually about six months apart, but v257 came out in December 2024, and v258 just now seems to be nearing the finish line; the third release candidate for v258 was published on August 20 (release notes). Now is a good time to dig in and take a look at some of the new features, enhancements, and removals coming soon to systemd. These include new workload-management features, a concept for multiple home-directory environments, and the final, once-and-for-all removal of support for control groups version 1.
Lennart Poettering has been doing his now-traditional parade of systemd feature highlights on Mastodon for v258 by posting about one feature daily (with some gaps for weekends, etc.); he started on May 21, and is now up to the 46th installment as of August 26. This installment will focus on some of the new features, with a follow-up article after the v258 release to cover others.
Gone or going
The systemd folks have been banging the drum to warn users that
control groups v1 support was going away at least since the v253 release in
February 2023. Support was disabled in v257, but it could be
re-enabled by setting the
SYSTEMD_CGROUP_ENABLE_LEGACY_FORCE=1 option on the kernel
command line. Now v1 support is gone for good, and systemd only
supports control
groups v2. Poettering said
that this has allowed the project "to remove a lot of code and
simplify the logic of cgroup handling quite substantially
".
The minimum kernel version for v258 has been bumped to 5.4, which was released in 2019. The minimum recommended kernel version is 5.7, which was released in 2020. (LWN subscribers can view the release history of all Git-era kernels via our kernel source database.) The support for System V service scripts is deprecated and will be removed in v259. The release notes suggest that developers update software to include a standard systemd unit file to ensure future compatibility. Additionally, systemd v258 sheds support for System V run levels and no longer provides initctl, runlevel, and telinit commands. (These were actually just symbolic links to systemctl, which would emulate the behavior of those legacy commands.)
The project has made OpenSSL the only supported cryptography backend for the systemd-resolved and systemd-importd services; support for GnuTLS and libgcrypt has been removed in v258 in an effort to use just one cryptography provider. Poettering polled the systemd-devel mailing list in April to ask if anyone was using these backends before they were removed, but there were no replies.
Workload management
Systemd uses the concept of slices to allow managing the resources of a group of processes; it uses unit-configuration files with the ".slice" suffix that specify resource limits to be applied using control groups. With v258, systemd is extending this to provide some basic workload management functionality by adding two new controls for .slice units: ConcurrencySoftMax= and ConcurrencyHardMax=.
These control knobs add limits to the maximum number of units, what most folks would call jobs, that may be active for a slice at the same time. The soft concurrency limit dictates how many jobs can be active at the same time; if there are more units to be run than slots available, then the others will be queued up to run after the active units finish. If the hard concurrency limit is set, then any additional jobs above that limit will simply fail. For example, if one sets ConcurrencyHardMax=5 and there are six units, then the sixth will fail.
This is a fairly coarse-grained knob for workload control; Poettering said that the project may eventually extend workload control to address CPU, I/O, memory limits, and so on, to give greater control over defining when workloads should run.
Home areas
Each regular user on a Linux system gets a single home directory, usually /home/user, where their configuration information and data are stored. This is typically sufficient, but in some cases it might be useful to be able to have more than one home directory. For example, one might want separate home environments for specific development projects or one home directory for work and another for personal projects.
In v258, systemd has introduced limited support for separate login environments called "home areas". Each home area is maintained in a subdirectory, under /home/user/Areas, of the user's regular home directory. For example, a person who does freelance work could have a separate home area for each work project, such as /home/user/Areas/proj1 that would have configuration files and data used for a specific project.
To log into that home area, they would add "%" and a "proj1" suffix to their username ("user%proj1") and use their regular password. That would set /home/user/Areas/proj1 as $HOME, and provide a cleaner separation between data and configuration files used for that project and their regular home environment. Poettering explained on Mastodon how he uses this feature:
My personal usecase for this goes something like this: I regularly build disk images for VMs of different distributions on my host, for building and testing systemd and other stuff. And I want access to my host user's home dir in each when booting them up, but not necessarily log directly into my host's home directory, but keep a separate area for each such image, so that the build trees in it can be distinct, do not leak context into each other, and can be created anew and flushed out easily. I also want full access to all my data from each such VM to simplify my work. And the area concept allows me to do all that.
All files still have the user's regular user ID (UID) and group ID (GID): there is no privilege separation between areas, and there are no plans to add it, so a user can still access files in their home directory or other home areas while logged in with "user%proj1".
The addition of the areas feature comes with a new "defaultArea" user record field, which (as the name suggests) can be used to specify a default home area. The standard /home/user is the default if no area is specified. This can be specified with the "homectl --default-area=" command.
Currently, the areas feature does not allow logging into a full
graphical session using this feature because systemd does not start a
per-area service manager for the user. However, the release notes
indicate that this is planned for "one of the next
releases
". Poettering has
said that the areas feature is only implemented for users managed
with systemd-homed;
it is unlikely that it will ever support "classic" Linux users
defined in /etc/passwd. It is
also not possible to use the "%area" syntax with
SSH, at least at this time. The project has added an option
(--area=) to the run0
command to allow a user to directly enter a specific home area when
using run0 to elevate or acquire different user
privileges.
Quotas for tmpfs
With systemd v258, users are automatically assigned a quota for /dev/shm and /tmp if /tmp is backed by a tmpfs. The default is 80% of the size assigned to the tmpfs. The goal for this feature is to prevent any user from effectively performing a denial-of-service attack by filling up /tmp or /dev/shm.
This goes hand-in-hand with another change in systemd v258: new user-record fields to specify quotas for /tmp and /dev/shm, as well as support for managing those fields with the homectl command. The fields are tmpLimit, tmpLimitScale, devShmLimit, and devShmLimitScale; they can be set or modified using the homectl command. For example, to set a user's /tmp quota to max out at 20% of the available tmpfs filesystem, one would use "homectl --tmp-limit=20%".
System reset
Systemd added systemd-repart to automatically manage disk partitions in v245, which was released in 2020. One of its features is a "factory reset" mode, invoked with the --factory-reset=yes option, that erases existing partitions to reset an installation to vendor defaults. With v258, systemd has added the systemd-factory-reset tool to provide a framework for a more complete reset that includes TPM keys and other bits.
In describing
this tool on Mastodon, Poettering said that he believed "a
fundamental aspect of OS security must be a secure way to return the
OS into a well-defined, secure state
" if the system had been
compromised. It was not sufficient to reinstall an operating system,
he said,
because that would not take care of resetting the TPM key. If the old
key is not invalidated, then all secrets associated with a compromised
install would remain valid.
The current implementation only addresses resetting storage partitions and the TPM key, but the documentation notes that other services can be defined and plugged into the factory-reset target as well.
Miscellaneous changes
The "systemctl start" command now has a verbose (-v) option, which will display the service's logs as it is started until its startup is completed. This should make it somewhat easier to debug problems with service startup. Previously, if a service failed to start for some reason, it would be necessary to use a command like "journalctl -u" command to view the log. A feature request was created for a verbose option in 2015; Poettering said that it has been a much-requested feature since, but it was difficult to implement due to the number of sources that contribute to the log stream.
Systemd v258 has added support for generating hostnames with a dynamic part; one can request a hostname with a static string and a string that is assigned dynamically. This is done by including question mark characters ("?") in /etc/hostname. Each "?" is replaced with a nibble that is hashed from the system's machine-id.
This might be useful, for example, when managing a fleet of systems; it might be desirable to assign a static hostname part to designate (say) what the system is used for, or some other common detail for a subset of the fleet. For example, if the hostname is specified as "web-????????" in /etc/hostname for web servers then the hostname might be set to "web-98b0e71d". If there are multiple database servers they might be "db-????????", and so forth. There is not a preset limit on how many question marks can be used when setting the dynamic portion of the hostname, but Poettering notes that the kernel has a limit of 63 characters for a hostname.
It is possible to require certain conditions before a systemd unit is executed by specifying them in a systemd unit file. For example, one might want to ensure that a unit is only executed on the arm64 hardware architecture, which can be expressed with ConditionArchitecture=arm64. These are evaluated by systemd-analyze.
The ConditionKernelVersion= check was introduced in systemd v244, which allowed a test for the kernel version as returned by uname -r. For instance, one might use ConditionKernelVersion=6.12.*deb* to check whether a system is running a version of the 6.12 Linux kernel on a Debian system. With v258, ConditionKernelVersion= has been replaced with ConditionVersion=, which currently also supports a check for the version of glibc or systemd in use.
This release also adds ConditionKernelModuleLoaded=, which is used to check if a specified kernel module is already loaded. That logic can be used to skip or enable a service, which may be useful to speed up the boot process by suppressing unneeded modprobe activity when it is not needed.
Systemd supports the use of extension images, which are discoverable disk images (DDIs) that are overlay filesystems that can be applied to a system to extend directory hierarchies. System extensions (sysext) are used to extend /usr or /opt, while configuration extensions (confext) are used for /etc. This can be useful to add software to an immutable system, for example. This blog post from the Flatcar Container Linux project about system extension images is a good overview of how they might be used.
With systemd v258, it is now possible to automatically reload confext images associated with a service when that service is reloaded via "systemctl reload" or similar. See the systemd-sysext man page for more on the commands and unit files associated with system extensions.
Testing systemd
There is quite a bit to chew on in systemd v258. Those wanting to test systemd v258 immediately can find up-to-date packages via openSUSE's Open Build Service (OBS) for Arch Linux, Debian, Fedora, openSUSE, and Ubuntu. Developers who want to contribute to systemd—or just tinker with development versions of systemd—can follow the "hacking on systemd" documentation to use mkosi to build images with the systemd source. It takes 20-30 minutes to set up using mkosi, compile systemd, and build an image—though some of that is dependent on the speed of one's computer.
In the next installment we'll take a look at new features related to disk quotas, service-manager improvements, systemd-resolved changes, and more.
Brief items
Security
The hidden vulnerabilities of open source (FastCode)
The FastCode site has a lengthy article on how large language models make open-source projects far more vulnerable to XZ-style attacks.
Open source maintainers, already overwhelmed by legitimate contributions, have no realistic way to counter this threat. How do you verify that a helpful contributor with months of solid commits isn't an LLM generated persona? How do you distinguish between genuine community feedback and AI created pressure campaigns? The same tools that make these attacks possible are largely inaccessible to volunteer maintainers. They lack the resources, skills, or time to deploy defensive processes and systems.The detection problem becomes exponentially harder when LLMs can generate code that passes all existing security reviews, contribution histories that look perfectly normal, and social interactions that feel authentically human. Traditional code analysis tools will struggle against LLM generated backdoors designed specifically to evade detection. Meanwhile, the human intuition that spot social engineering attacks becomes useless when the "humans" are actually sophisticated language models.
Security quote of the week
— Josh Bressers (Thanks to Paul Wise.)If you want to make a big deal about something, maybe it shouldn't be what country a sole maintainer is from. Let's face it, the Russians aren't dumb enough to backdoor a package owned by a guy living in Russia. They're going to do something like pretend to be from another country with a name like Jia Tan, not Boris D. Badguy. This isn't a Rocky and Bullwinkle episode. [...]
Open source, the thing that drives the world, the thing Harvard says has an economic value of 8.8 trillion dollars (also a big number). Most of it is one person. And I can promise you not one of those single person projects have the proper amount of resources they need. If you want to talk about possible risks to your supply chain, a single maintainer that's grossly underpaid and overworked. That's the risk. The country they are from is irrelevant.
Kernel development
Kernel release status
The current development kernel is 6.17-rc4, released on August 31. "So it all looks fairly good. Please do keep testing, and we'll get 6.17 out in a timely manner and in good shape."
Stable updates: 6.16.4, 6.12.44, 6.6.103, 6.1.149, 5.15.190, 5.10.241, and 5.4.297 were released on August 28.
The 6.16.5, 6.12.45, 6.6.104, 6.1.150, 5.15.191, 5.10.242, and 5.4.298 updates are all in the review process; they are due on September 4.
Bcachefs goes to "externally maintained"
Linus Torvalds has quietly changed the maintainer status of bcachefs to "externally maintained", indicating that further changes are unlikely to enter the mainline anytime soon. This change also suggests, though, that the immediate removal of bcachefs from the mainline kernel is not in the cards.
Distributions
Linux From Scratch 12.4 released
Version 12.4 of Linux From Scratch (LFS) and Beyond Linux From Scratch (BLFS) have been released. LFS provides step-by-step instructions on building a customized Linux system entirely from source, and BLFS helps to extend an LFS installation into a more usable system. Notable changes in this release include updates to GNU Binutils 2.45, GCC 15.2, GNU C Library (glibc) 2.42, and Linux 6.15.1. See the Changelog for all updates since 12.3.
Development
New ELF specification for public review
Cary Coutant has announced a draft for version 4.3 of the Executable and Linking Format (ELF) object file format. The specification was formerly part of the Unix System V Release 4 (SVR4) gABI document:
The last published gABI documents were the Fourth Edition and a draft of Edition 4.1, both published in March 1997. The ELF portions of the document were updated several times between 1998 and 2015, published online [...]
I've published the last draft from 2015 as Version 4.2, and collected the several changes since then, along with new e_machine values, as Version 4.3.
The source for the draft is on GitHub in reStructuredText format, and Coutant has collected the mailing list discussions for changes in 4.3 as GitHub issues. Thanks to Jose E. Marchesi for the tip.
Home Assistant 2025.9 released
Version 2025.9 of the Home Assistant home automation system has been released. Changes include a new experimental dashboard that is eventually meant to become the default, a number of tile-card improvements, a reworked automation editor, several new integrations, and more.Niri 25.08 released
Version 25.08 of the niri scrollable-tiling Wayland compositor has been released. Notable changes include xwayland-satellite integration, modal exit confirmation, and the introduction of basic support for screen readers:
A series of posts by fireborn earlier this year on the screen reader situation in Linux got me curious: how does one support screen readers in a Wayland compositor? The documentation is unfortunately scarce and difficult to find. Thankfully, @DataTriny from the AccessKit project came across my issue, pointed me at the right protocols, and answered a lot of my questions.
So, as of this release, niri has basic support for screen readers! We implement the org.freedesktop.a11y.KeyboardMonitor D-Bus interface for Orca to listen and grab keyboard keys, and we expose the main niri UI elements via AccessKit. [...]
The current screen reader support and further considerations are documented on the new Accessibility wiki page.
LWN covered niri in July.
Python: The Documentary
Attendees at EuroPython had the chance to preview part of Python: The Documentary during a keynote panel. The full film, created by CultRepo, is now available on YouTube:
This is the story of the world's most beloved programming language: Python. What began as a side project in Amsterdam during the 1990s became the software powering artificial intelligence, data science and some of the world's biggest companies. But Python's future wasn't certain; at one point it almost disappeared.
This 90-minute documentary features Guido van Rossum, Travis Oliphant, Barry Warsaw, and many more, and they tell the story of Python's rise, its community-driven evolution, the conflicts that almost tore it apart, and the language's impact on... well... everything.
The video of the keynote is also available.
Announcing the Rust Innovation Lab
During the opening of RustConf 2025 in Seattle, Washington, the Rust Foundation announced a new initiative to provide financial and administrative support to open-source Rust projects. The first project to benefit from the new Rust Innovation Lab is Rustls, an implementation of TLS in Rust. The foundation welcomes inquiries from other projects. Dr. Rebecca Rumbul, Executive Director of the Rust Foundation said:
Rustls is hopefully the first of many really good [...] projects that will find a home in the foundation.
Development quotes of the week
— Wesley MooreI'm sure you'll be pleased to know that the News tab in Nautilus from GNOME 1.4 (released in 2001) still shows current LWN headlines/still supports whatever API/feed it's using.
— Leon Henrik PlickatI was about to ask why the file manager displays news, then I remembered that I use emacs, so I think I get it.
These claims wouldn't matter if the topic weren't so deadly serious. Tech leaders everywhere are buying into the FOMO, convinced their competitors are getting massive gains they're missing out on. This drives them to rebrand as AI-First companies, justify layoffs with newfound productivity narratives, and lowball developer salaries under the assumption that AI has fundamentally changed the value equation.— Mike JudgeAnd yet, despite the most widespread adoption one could imagine, these tools don’t work.
My argument: If so many developers are so extraordinarily productive using these tools, where is the flood of shovelware? We should be seeing apps of all shapes and sizes, video games, new websites, mobile apps, software-as-a-service apps — we should be drowning in choice. We should be in the middle of an indie software revolution. We should be seeing 10,000 Tetris clones on Steam.
Miscellaneous
GNOME loses another executive director
The GNOME Foundation has announced that Steven Deobald will be leaving the position of Executive Director after just four months.
We are extremely grateful to Steven for all this and more. Despite these many positive achievements, Steven and the board have come to the conclusion that Steven is not the right fit for the Executive Director role at this time. We are therefore bidding Steven a fond farewell.
Page editor: Daroc Alden
Announcements
Newsletters
Distributions and system administration
Development
Meeting minutes
Miscellaneous
Calls for Presentations
CFP Deadlines: September 4, 2025 to November 3, 2025
The following listing of CFP deadlines is taken from the LWN.net CFP Calendar.
| Deadline | Event Dates | Event | Location |
|---|---|---|---|
| September 10 | December 11 December 13 |
Linux Plumbers Conference | Tokyo, Japan |
| September 10 | December 13 December 15 |
GNOME Asia Summit 2025 | Tokyo, Japan |
| September 11 | November 20 | NLUUG Autumn Conference 2025 | Utrecht, The Netherlands |
| September 16 | December 13 December 14 |
LibreOffice Asia Conference 2025 | Tokyo, Japan |
| September 19 | December 6 December 7 |
EmacsConf | online |
| September 29 | September 29 October 2 |
Alpine Linux Persistence and Storage Summit 2025 | Wattenberg, Austria |
| October 12 | March 23 March 26 |
KubeCon + CloudNativeCon Europe | Amsterdam, Netherlands |
| October 27 | March 16 March 17 |
FOSS Backstage | Berlin, Germany |
If the CFP deadline for your event does not appear here, please tell us about it.
Upcoming Events
Events: September 4, 2025 to November 3, 2025
The following event listing is taken from the LWN.net Calendar.
| Date(s) | Event | Location |
|---|---|---|
| September 8 | Workshop on eBPF and kernel extensions (colocated with ACM SIGCOMM) | Coimbra, Portugal |
| September 17 September 18 |
Kangrejos | Oviedo, Spain |
| September 19 September 21 |
Datenspuren 2025 | Dresden, Germany |
| September 20 | Software Freedom Day - NJ | Montclair, NJ, US |
| September 22 September 24 |
Kernel Recipes | Paris, France |
| September 23 | Open Tech Day 25: Grafana Edition | Nuremberg, Germany |
| September 26 September 28 |
Qubes OS Summit | Berlin, Germany |
| September 26 September 28 |
GNU Tools Cauldron | Porto, Portugal |
| September 27 September 28 |
Nextcloud Community Conference 2025 | Berlin, Germany |
| September 29 October 1 |
X.Org Developers Conference | Vienna, Austria |
| September 29 October 2 |
Alpine Linux Persistence and Storage Summit 2025 | Wattenberg, Austria |
| September 30 October 1 |
All Systems Go! 2025 | Berlin, Germany |
| October 3 October 4 |
Texas Linux Festival | Austin, US |
| October 12 October 14 |
All Things Open | Raleigh, NC, US |
| October 17 October 19 |
OpenInfra Summit Europe 2025 | Paris-Saclay, France |
| October 18 October 19 |
OpenFest 2025 | Sofia, Bulgaria |
| October 21 October 24 |
PostgreSQL Conference Europe | Riga, Latvia |
| October 28 October 29 |
Cephalocon | Vancouver, Canada |
If your event does not appear here, please tell us about it.
Security updates
Alert summary August 28, 2025 to September 3, 2025
| Dist. | ID | Release | Package | Date |
|---|---|---|---|---|
| AlmaLinux | ALSA-2025:14592 | 10 | aide | 2025-08-27 |
| AlmaLinux | ALSA-2025:14573 | 8 | aide | 2025-08-28 |
| AlmaLinux | ALSA-2025:14493 | 9 | aide | 2025-08-27 |
| AlmaLinux | ALSA-2025:14750 | 8 | fence-agents | 2025-08-28 |
| AlmaLinux | ALSA-2025:14417 | 10 | firefox | 2025-08-27 |
| AlmaLinux | ALSA-2025:14442 | 8 | firefox | 2025-08-28 |
| AlmaLinux | ALSA-2025:14416 | 9 | firefox | 2025-08-27 |
| AlmaLinux | ALSA-2025:15095 | 10 | httpd | 2025-09-03 |
| AlmaLinux | ALSA-2025:14510 | 10 | kernel | 2025-09-01 |
| AlmaLinux | ALSA-2025:14438 | 8 | kernel | 2025-09-02 |
| AlmaLinux | ALSA-2025:14420 | 9 | kernel | 2025-08-27 |
| AlmaLinux | ALSA-2025:14439 | 8 | kernel-rt | 2025-08-28 |
| AlmaLinux | ALSA-2025:15009 | 8 | kernel-rt | 2025-09-02 |
| AlmaLinux | ALSA-2025:14625 | 10 | mod_http2 | 2025-08-27 |
| AlmaLinux | ALSA-2025:14983 | 9 | mod_http2 | 2025-09-02 |
| AlmaLinux | ALSA-2025:14878 | 9 | postgresql | 2025-08-29 |
| AlmaLinux | ALSA-2025:14826 | 10 | postgresql16 | 2025-08-29 |
| AlmaLinux | ALSA-2025:14862 | 9 | postgresql:15 | 2025-09-02 |
| AlmaLinux | ALSA-2025:14899 | 8 | postgresql:16 | 2025-08-29 |
| AlmaLinux | ALSA-2025:14827 | 9 | postgresql:16 | 2025-08-29 |
| AlmaLinux | ALSA-2025:14553 | 8 | python-cryptography | 2025-08-28 |
| AlmaLinux | ALSA-2025:14841 | 8 | python3.11 | 2025-08-29 |
| AlmaLinux | ALSA-2025:14900 | 8 | python39:3.9 | 2025-09-01 |
| AlmaLinux | ALSA-2025:14844 | 10 | thunderbird | 2025-08-29 |
| AlmaLinux | ALSA-2025:14743 | 8 | thunderbird | 2025-08-28 |
| AlmaLinux | ALSA-2025:14640 | 9 | thunderbird | 2025-08-29 |
| Debian | DSA-5988-1 | stable | chromium | 2025-08-28 |
| Debian | DSA-5992-1 | stable | firebird4.0 | 2025-08-30 |
| Debian | DLA-4285-1 | LTS | golang-github-gin-contrib-cors | 2025-08-28 |
| Debian | DLA-4286-1 | LTS | libcommons-lang3-java | 2025-08-31 |
| Debian | DLA-DLA-4287-1 | LTS | libsndfile | 2025-09-01 |
| Debian | DSA-5990-1 | stable | libxml2 | 2025-08-29 |
| Debian | DLA-4274-2 | LTS | mbedtls | 2025-08-30 |
| Debian | DSA-5991-1 | stable | nodejs | 2025-08-29 |
| Debian | DLA-4079-2 | LTS | openvpn | 2025-08-31 |
| Debian | DLA-4289-1 | LTS | python-eventlet | 2025-09-02 |
| Debian | DLA-4290-1 | LTS | python-h2 | 2025-09-03 |
| Debian | DLA-4288-1 | LTS | ruby-saml | 2025-09-01 |
| Debian | DLA-4284-1 | LTS | udisks2 | 2025-08-28 |
| Debian | DSA-5989-1 | stable | udisks2 | 2025-08-28 |
| Debian | DSA-5987-1 | stable | unbound | 2025-08-27 |
| Fedora | FEDORA-2025-b7cb89ddd3 | F42 | cef | 2025-08-31 |
| Fedora | FEDORA-2025-2392144625 | F41 | chromium | 2025-08-29 |
| Fedora | FEDORA-2025-dc1c32b029 | F41 | chromium | 2025-08-31 |
| Fedora | FEDORA-2025-ad180e88ee | F42 | chromium | 2025-09-01 |
| Fedora | FEDORA-2025-4e0d9fb468 | F41 | docker-buildx | 2025-09-01 |
| Fedora | FEDORA-2025-aeb4a7b52f | F42 | docker-buildx | 2025-08-31 |
| Fedora | FEDORA-2025-387e64c9fd | F42 | exiv2 | 2025-09-01 |
| Fedora | FEDORA-2025-9c12e64470 | F41 | firefox | 2025-08-30 |
| Fedora | FEDORA-2025-be0c6f25ce | F41 | mod_auth_openidc | 2025-08-28 |
| Fedora | FEDORA-2025-ca3edc5c88 | F42 | rocm-rpp | 2025-08-31 |
| Fedora | FEDORA-2025-c866472f43 | F42 | udisks2 | 2025-08-31 |
| Mageia | MGASA-2025-0224 | 9 | aide | 2025-09-02 |
| Mageia | MGASA-2025-0222 | 9 | ceph | 2025-09-01 |
| Mageia | MGASA-2025-0220 | 9 | glibc | 2025-09-01 |
| Mageia | MGASA-2025-0225 | 9 | gnutls | 2025-09-02 |
| Mageia | MGASA-2025-0221 | 9 | golang | 2025-09-01 |
| Mageia | MGASA-2025-0223 | 9 | tomcat | 2025-09-02 |
| Mageia | MGASA-2025-0226 | 9 | vim | 2025-09-02 |
| Oracle | ELSA-2025-14750 | OL8 | fence-agents | 2025-08-27 |
| Oracle | ELSA-2025-15023 | OL9 | httpd | 2025-09-02 |
| Oracle | ELSA-2025-14510 | OL10 | kernel | 2025-08-27 |
| Oracle | ELSA-2025-14438 | OL8 | kernel | 2025-08-27 |
| Oracle | ELSA-2025-14983 | OL9 | mod_http2 | 2025-09-02 |
| Oracle | ELSA-2025-14878 | OL9 | postgresql | 2025-09-01 |
| Oracle | ELSA-2025-14826 | OL10 | postgresql16 | 2025-08-28 |
| Oracle | ELSA-2025-14862 | OL9 | postgresql:15 | 2025-09-02 |
| Oracle | ELSA-2025-14899 | OL8 | postgresql:16 | 2025-08-29 |
| Oracle | ELSA-2025-14827 | OL9 | postgresql:16 | 2025-08-28 |
| Oracle | ELSA-2025-14841 | OL8 | python3.11 | 2025-08-28 |
| Oracle | ELSA-2025-15010 | OL9 | python3.11 | 2025-09-02 |
| Oracle | ELSA-2025-14984 | OL10 | python3.12 | 2025-09-02 |
| Oracle | ELSA-2025-15007 | OL9 | python3.12 | 2025-09-02 |
| Oracle | ELSA-2025-15019 | OL9 | python3.9 | 2025-09-02 |
| Oracle | ELSA-2025-14900 | OL8 | python39:3.9 | 2025-09-01 |
| Oracle | ELSA-2025-14844 | OL10 | thunderbird | 2025-08-29 |
| Oracle | ELSA-2025-14743 | OL8 | thunderbird | 2025-08-28 |
| Oracle | ELSA-2025-15017 | OL8 | udisks2 | 2025-09-02 |
| Oracle | ELSA-2025-15018 | OL9 | udisks2 | 2025-09-02 |
| Red Hat | RHSA-2025:14592-01 | EL10 | aide | 2025-09-02 |
| Red Hat | RHSA-2025:14573-01 | EL8 | aide | 2025-09-02 |
| Red Hat | RHSA-2025:14980-01 | EL8.2 | aide | 2025-09-02 |
| Red Hat | RHSA-2025:14981-01 | EL8.4 | aide | 2025-09-02 |
| Red Hat | RHSA-2025:15058-01 | EL8.6 | aide | 2025-09-02 |
| Red Hat | RHSA-2025:14982-01 | EL8.8 | aide | 2025-09-02 |
| Red Hat | RHSA-2025:15038-01 | EL9.2 | aide | 2025-09-02 |
| Red Hat | RHSA-2025:15039-01 | EL9.4 | aide | 2025-09-02 |
| Red Hat | RHSA-2025:14750-01 | EL8 | fence-agents | 2025-08-31 |
| Red Hat | RHSA-2025:14442-01 | EL8 | firefox | 2025-09-01 |
| Red Hat | RHSA-2025:14683-01 | EL7 | gdk-pixbuf2 | 2025-08-31 |
| Red Hat | RHSA-2025:14647-01 | EL8.4 | gdk-pixbuf2 | 2025-08-31 |
| Red Hat | RHSA-2025:14646-01 | EL8.6 | gdk-pixbuf2 | 2025-08-31 |
| Red Hat | RHSA-2025:14901-01 | EL9.0 | httpd | 2025-08-31 |
| Red Hat | RHSA-2025:14902-01 | EL9.2 | httpd | 2025-08-31 |
| Red Hat | RHSA-2025:14903-01 | EL9.4 | httpd | 2025-08-31 |
| Red Hat | RHSA-2025:15005-01 | EL10 | kernel | 2025-09-03 |
| Red Hat | RHSA-2025:14748-01 | EL7 | kernel | 2025-08-31 |
| Red Hat | RHSA-2025:14742-01 | EL8.2 | kernel | 2025-08-31 |
| Red Hat | RHSA-2025:15035-01 | EL8.4 | kernel | 2025-09-03 |
| Red Hat | RHSA-2025:14692-01 | EL8.6 | kernel | 2025-08-31 |
| Red Hat | RHSA-2025:15011-01 | EL9 | kernel | 2025-09-03 |
| Red Hat | RHSA-2025:14744-01 | EL9.0 | kernel | 2025-08-31 |
| Red Hat | RHSA-2025:14696-01 | EL9.2 | kernel | 2025-08-31 |
| Red Hat | RHSA-2025:14746-01 | EL7 | kernel-rt | 2025-08-31 |
| Red Hat | RHSA-2025:14749-01 | EL9.0 | kernel-rt | 2025-08-31 |
| Red Hat | RHSA-2025:14691-01 | EL9.2 | kernel-rt | 2025-08-31 |
| Red Hat | RHSA-2025:14828-01 | EL7 | libarchive | 2025-08-31 |
| Red Hat | RHSA-2025:14810-01 | EL8.4 | libarchive | 2025-08-31 |
| Red Hat | RHSA-2025:14808-01 | EL8.6 | libarchive | 2025-08-31 |
| Red Hat | RHSA-2025:10630-01 | EL10 | libxml2 | 2025-08-31 |
| Red Hat | RHSA-2025:10698-01 | EL8 | libxml2 | 2025-08-31 |
| Red Hat | RHSA-2025:10699-01 | EL9 | libxml2 | 2025-08-31 |
| Red Hat | RHSA-2025:12099-01 | EL9.0 | libxml2 | 2025-08-31 |
| Red Hat | RHSA-2025:12199-01 | EL9.2 | libxml2 | 2025-08-31 |
| Red Hat | RHSA-2025:11580-01 | EL9.4 | libxml2 | 2025-08-31 |
| Red Hat | RHSA-2025:11035-01 | EL8 | lz4 | 2025-08-29 |
| Red Hat | RHSA-2025:9332-01 | EL7 | mpfr | 2025-08-28 |
| Red Hat | RHSA-2025:14811-01 | EL9.4 | multiple packages | 2025-08-31 |
| Red Hat | RHSA-2025:14878-01 | EL9 | postgresql | 2025-08-31 |
| Red Hat | RHSA-2025:14870-01 | EL9.0 | postgresql | 2025-08-31 |
| Red Hat | RHSA-2025:14869-01 | EL9.2 | postgresql | 2025-08-31 |
| Red Hat | RHSA-2025:15114-01 | EL9.4 | postgresql | 2025-09-03 |
| Red Hat | RHSA-2025:14826-01 | EL10 | postgresql16 | 2025-08-31 |
| Red Hat | RHSA-2025:15115-01 | EL8 | postgresql:12 | 2025-09-03 |
| Red Hat | RHSA-2025:15034-01 | EL8.4 | postgresql:12 | 2025-09-02 |
| Red Hat | RHSA-2025:15006-01 | EL8.6 | postgresql:12 | 2025-09-02 |
| Red Hat | RHSA-2025:15012-01 | EL8.8 | postgresql:12 | 2025-09-02 |
| Red Hat | RHSA-2025:15021-01 | EL8 | postgresql:13 | 2025-09-02 |
| Red Hat | RHSA-2025:15057-01 | EL8.4 | postgresql:13 | 2025-09-02 |
| Red Hat | RHSA-2025:15013-01 | EL8.8 | postgresql:13 | 2025-09-02 |
| Red Hat | RHSA-2025:15022-01 | EL8 | postgresql:15 | 2025-09-02 |
| Red Hat | RHSA-2025:15031-01 | EL8.8 | postgresql:15 | 2025-09-02 |
| Red Hat | RHSA-2025:14862-01 | EL9 | postgresql:15 | 2025-08-31 |
| Red Hat | RHSA-2025:15062-01 | EL9.2 | postgresql:15 | 2025-09-03 |
| Red Hat | RHSA-2025:15014-01 | EL9.4 | postgresql:15 | 2025-09-02 |
| Red Hat | RHSA-2025:14899-01 | EL8 | postgresql:16 | 2025-08-31 |
| Red Hat | RHSA-2025:14827-01 | EL9 | postgresql:16 | 2025-08-31 |
| Red Hat | RHSA-2025:15015-01 | EL9.4 | postgresql:16 | 2025-09-02 |
| Red Hat | RHSA-2025:14841-01 | EL8 | python3.11 | 2025-08-31 |
| Red Hat | RHSA-2025:3634-01 | EL9 | python3.11 | 2025-09-01 |
| Red Hat | RHSA-2025:3631-01 | EL9 | python3.12 | 2025-09-01 |
| Red Hat | RHSA-2025:14900-01 | EL8 | python39:3.9 | 2025-08-31 |
| Red Hat | RHSA-2025:14844-01 | EL10 | thunderbird | 2025-09-01 |
| Red Hat | RHSA-2025:14743-01 | EL8 | thunderbird | 2025-09-01 |
| Red Hat | RHSA-2025:14640-01 | EL9 | thunderbird | 2025-09-01 |
| Slackware | SSA:2025-242-01 | udisks2 | 2025-08-30 | |
| SUSE | openSUSE-SU-2025:15498-1 | TW | ImageMagick | 2025-08-29 |
| SUSE | openSUSE-SU-2025:0327-1 | osB15 | chromium | 2025-08-28 |
| SUSE | openSUSE-SU-2025:0326-1 | osB15 | chromium | 2025-08-28 |
| SUSE | openSUSE-SU-2025:15504-1 | TW | dcmtk | 2025-09-02 |
| SUSE | SUSE-SU-2025:20565-1 | SLE-m6.0 | docker | 2025-08-28 |
| SUSE | SUSE-SU-2025:20562-1 | SLE-m6.0 | dpkg | 2025-08-28 |
| SUSE | SUSE-SU-2025:03009-1 | SLE12 | firefox | 2025-08-28 |
| SUSE | SUSE-SU-2025:03008-1 | SLE15 SES7.1 oS15.6 | firefox | 2025-08-28 |
| SUSE | SUSE-SU-2025:03010-1 | SLE12 | gdk-pixbuf | 2025-08-28 |
| SUSE | SUSE-SU-2025:03012-1 | SLE15 oS15.6 | git, git-lfs, obs-scm-bridge, python-PyYAML | 2025-08-29 |
| SUSE | SUSE-SU-2025:03037-1 | MP4.3 SLE15 SLE-m5.5 SES7.1 oS15.3 | git | 2025-09-01 |
| SUSE | SUSE-SU-2025:03022-1 | SLE12 | git | 2025-08-29 |
| SUSE | SUSE-SU-2025:20563-1 | SLE-m6.0 | gnutls | 2025-08-28 |
| SUSE | openSUSE-SU-2025:0332-1 | osB15 | go-sendxmpp | 2025-08-30 |
| SUSE | SUSE-SU-2025:03046-1 | SLE15 oS15.6 | govulncheck-vulndb | 2025-09-02 |
| SUSE | SUSE-SU-2025:20595-1 | SLE-m6.1 | helm | 2025-08-29 |
| SUSE | SUSE-SU-2025:02998-1 | SLE-m5.1 | ignition | 2025-08-27 |
| SUSE | SUSE-SU-2025:03000-1 | SLE-m5.2 | ignition | 2025-08-27 |
| SUSE | SUSE-SU-2025:02999-1 | SLE-m5.3 | ignition | 2025-08-27 |
| SUSE | SUSE-SU-2025:03001-1 | SLE15 oS15.4 oS15.6 | ignition | 2025-08-27 |
| SUSE | SUSE-SU-2025:03025-1 | SLE15 oS15.6 | javamail | 2025-08-29 |
| SUSE | SUSE-SU-2025:02993-1 | SLE15 SES7.1 oS15.6 | jetty-minimal | 2025-08-27 |
| SUSE | SUSE-SU-2025:02993-2 | oS15.6 | jetty-minimal | 2025-09-01 |
| SUSE | SUSE-SU-2025:20591-1 | SLE-m6.1 | jq | 2025-08-29 |
| SUSE | openSUSE-SU-2025:15506-1 | TW | jupyter-bqplot-jupyterlab | 2025-09-02 |
| SUSE | openSUSE-SU-2025:15499-1 | TW | kea | 2025-08-29 |
| SUSE | SUSE-SU-2025:20586-1 | SLE-m6.0 | kernel | 2025-08-28 |
| SUSE | SUSE-SU-2025:20577-1 | SLE-m6.0 | kernel | 2025-08-28 |
| SUSE | SUSE-SU-2025:20602-1 | SLE-m6.0 SLE-m6.1 | kernel | 2025-08-29 |
| SUSE | SUSE-SU-2025:20601-1 | SLE-m6.0 SLE-m6.1 | kernel | 2025-08-29 |
| SUSE | SUSE-SU-2025:02997-1 | SLE15 | kernel | 2025-08-27 |
| SUSE | SUSE-SU-2025:03011-1 | SLE15 | kernel | 2025-08-28 |
| SUSE | SUSE-SU-2025:02996-1 | SLE15 oS15.6 | kernel | 2025-08-27 |
| SUSE | SUSE-SU-2025:03023-1 | SLE15 oS15.6 | kernel | 2025-08-29 |
| SUSE | openSUSE-SU-2025:15505-1 | TW | kured | 2025-09-02 |
| SUSE | SUSE-SU-2025:20560-1 | SLE-m6.0 | libarchive | 2025-08-28 |
| SUSE | SUSE-SU-2025:20594-1 | SLE-m6.1 | libarchive | 2025-08-29 |
| SUSE | SUSE-SU-2025:02522-2 | SLE12 | libarchive | 2025-09-01 |
| SUSE | openSUSE-SU-2025:15494-1 | TW | libmozjs-128-0 | 2025-08-27 |
| SUSE | SUSE-SU-2025:20598-1 | SLE-m6.1 | libsoup | 2025-08-29 |
| SUSE | SUSE-SU-2025:03026-1 | SLE12 | libsoup | 2025-08-29 |
| SUSE | SUSE-SU-2025:20596-1 | SLE-m6.1 | libssh | 2025-08-29 |
| SUSE | openSUSE-SU-2025:15511-1 | TW | libudisks2-0 | 2025-09-02 |
| SUSE | SUSE-SU-2025:20564-1 | SLE-m6.0 | libxml2 | 2025-08-28 |
| SUSE | SUSE-SU-2025:20607-1 | SLE-m6.1 | libxml2 | 2025-08-29 |
| SUSE | openSUSE-SU-2025:15493-1 | TW | matrix-synapse | 2025-08-27 |
| SUSE | SUSE-SU-2025:03056-1 | SLE15 | munge | 2025-09-03 |
| SUSE | SUSE-SU-2025:20566-1 | SLE-m6.0 | net-tools | 2025-08-28 |
| SUSE | SUSE-SU-2025:03021-1 | netty | 2025-08-29 | |
| SUSE | SUSE-SU-2025:03039-1 | SLE15 oS15.6 | nginx | 2025-09-01 |
| SUSE | SUSE-SU-2025:20593-1 | SLE-m6.1 | openssl-3 | 2025-08-29 |
| SUSE | openSUSE-SU-2025:15495-1 | TW | perl-Crypt-CBC | 2025-08-28 |
| SUSE | SUSE-SU-2025:20559-1 | SLE-m6.0 | polkit | 2025-08-28 |
| SUSE | SUSE-SU-2025:03003-1 | SLE12 | postgresql13 | 2025-08-27 |
| SUSE | SUSE-SU-2025:02994-1 | SLE15 SES7.1 | postgresql13 | 2025-08-27 |
| SUSE | SUSE-SU-2025:03031-1 | MP4.2 MP4.3 SLE15 SLE-m5.1 SLE-m5.2 SLE-m5.3 SLE-m5.4 SLE-m5.5 SES7.1 | postgresql14 | 2025-08-29 |
| SUSE | SUSE-SU-2025:03020-1 | SLE12 | postgresql14 | 2025-08-29 |
| SUSE | SUSE-SU-2025:03019-1 | SLE15 oS15.6 | postgresql14 | 2025-08-29 |
| SUSE | SUSE-SU-2025:03030-1 | MP4.2 MP4.3 SLE15 SLE-m5.1 SLE-m5.2 SLE-m5.3 SLE-m5.4 SES7.1 | postgresql15 | 2025-08-29 |
| SUSE | SUSE-SU-2025:03004-1 | SLE12 | postgresql15 | 2025-08-27 |
| SUSE | SUSE-SU-2025:03018-1 | SLE15 oS15.6 | postgresql15 | 2025-08-29 |
| SUSE | SUSE-SU-2025:03005-1 | SLE15 oS15.6 | postgresql16 | 2025-08-27 |
| SUSE | SUSE-SU-2025:02995-1 | MP4.3 SLE15 SLE-m5.5 SES7.1 | postgresql17 | 2025-08-27 |
| SUSE | SUSE-SU-2025:03032-1 | SLE12 | python | 2025-08-29 |
| SUSE | SUSE-SU-2025:03051-1 | SLE15 oS15.3 | python-eventlet | 2025-09-02 |
| SUSE | SUSE-SU-2025:03049-1 | MP4.3 SLE15 SLE-m5.1 SLE-m5.2 SLE-m5.3 SLE-m5.4 SLE-m5.5 SES7.1 oS15.3 | python-future | 2025-09-02 |
| SUSE | SUSE-SU-2025:03028-1 | SLE12 | python-future | 2025-08-29 |
| SUSE | SUSE-SU-2025:03029-1 | SLE12 | python-future | 2025-08-29 |
| SUSE | SUSE-SU-2025:03038-1 | SLE15 oS15.4 oS15.6 | python-future | 2025-09-01 |
| SUSE | openSUSE-SU-2025:15507-1 | TW | python311-eventlet | 2025-09-02 |
| SUSE | openSUSE-SU-2025:15508-1 | TW | rekor | 2025-09-02 |
| SUSE | SUSE-SU-2025:02739-2 | MP4.3 SLE15 SES7.1 | ruby2.5 | 2025-09-01 |
| SUSE | SUSE-SU-2025:20561-1 | SLE-m6.0 | sqlite3 | 2025-08-28 |
| SUSE | SUSE-SU-2025:20597-1 | SLE-m6.1 | systemd | 2025-08-29 |
| SUSE | SUSE-SU-2025:03007-1 | SLE15 oS15.6 | thunderbird | 2025-08-28 |
| SUSE | SUSE-SU-2025:03006-1 | SLE15 oS15.6 | tomcat10 | 2025-08-28 |
| SUSE | openSUSE-SU-2025:15510-1 | TW | traefik2 | 2025-09-02 |
| SUSE | SUSE-SU-2025:03053-1 | MP4.3 SLE15 SLE-m5.1 SLE-m5.2 SLE-m5.3 SLE-m5.4 SLE-m5.5 SES7.1 oS15.6 | ucode-intel | 2025-09-02 |
| SUSE | SUSE-SU-2025:03052-1 | SLE12 | ucode-intel | 2025-09-02 |
| SUSE | SUSE-SU-2025:03017-1 | MP4.3 SLE15 SLE-m5.3 SLE-m5.4 SLE-m5.5 oS15.4 oS15.6 | udisks2 | 2025-08-29 |
| SUSE | SUSE-SU-2025:03015-1 | SLE12 | udisks2 | 2025-08-29 |
| SUSE | SUSE-SU-2025:03016-1 | SLE15 SES7.1 | udisks2 | 2025-08-29 |
| SUSE | SUSE-SU-2025:20590-1 | SLE-m6.1 | xz | 2025-08-29 |
| Ubuntu | USN-7728-1 | 14.04 16.04 18.04 20.04 22.04 24.04 | imagemagick | 2025-09-01 |
| Ubuntu | USN-7720-1 | 14.04 | kernel | 2025-08-27 |
| Ubuntu | USN-7726-1 | 20.04 22.04 | linux, linux-aws, linux-aws-5.15, linux-gcp, linux-gcp-5.15, linux-gkeop, linux-hwe-5.15, linux-ibm, linux-intel-iotg, linux-intel-iotg-5.15, linux-lowlatency, linux-lowlatency-hwe-5.15, linux-nvidia, linux-nvidia-tegra, linux-nvidia-tegra-5.15, linux-nvidia-tegra-igx, linux-oracle, linux-raspi, linux-xilinx-zynqmp | 2025-08-28 |
| Ubuntu | USN-7722-1 | 24.04 25.04 | linux, linux-aws, linux-aws-6.14, linux-gcp, linux-hwe-6.14, linux-raspi, linux-realtime, linux-realtime-6.14 | 2025-08-28 |
| Ubuntu | USN-7725-1 | 22.04 24.04 | linux, linux-aws, linux-aws-6.8, linux-gcp, linux-lowlatency, linux-lowlatency-hwe-6.8, linux-oracle, linux-oracle-6.8 | 2025-08-28 |
| Ubuntu | USN-7727-1 | 14.04 16.04 | linux, linux-aws, linux-kvm, linux-lts-xenial | 2025-08-28 |
| Ubuntu | USN-7727-3 | 16.04 | linux-aws | 2025-09-02 |
| Ubuntu | USN-7721-1 | 25.04 | linux-azure | 2025-08-28 |
| Ubuntu | USN-7712-2 | 20.04 | linux-azure-5.15 | 2025-09-02 |
| Ubuntu | USN-7726-3 | 22.04 | linux-fips, linux-aws-fips, linux-gcp-fips | 2025-08-28 |
| Ubuntu | USN-7727-2 | 16.04 | linux-fips | 2025-08-28 |
| Ubuntu | USN-7725-3 | 22.04 24.04 | linux-gcp-6.8, linux-gke, linux-gkeop, linux-hwe-6.8, linux-nvidia, linux-nvidia-6.8, linux-nvidia-lowlatency, linux-raspi | 2025-09-02 |
| Ubuntu | USN-7703-4 | 22.04 24.04 | linux-gke, linux-hwe-6.8, linux-nvidia, linux-nvidia-6.8, linux-nvidia-lowlatency, linux-raspi | 2025-08-28 |
| Ubuntu | USN-7726-4 | 20.04 22.04 | linux-gke, linux-ibm-5.15, linux-kvm | 2025-09-02 |
| Ubuntu | USN-7704-5 | 22.04 | linux-gke, linux-kvm | 2025-08-28 |
| Ubuntu | USN-7724-1 | 24.04 | linux-oem-6.14 | 2025-08-28 |
| Ubuntu | USN-7726-2 | 22.04 | linux-realtime, linux-intel-iot-realtime | 2025-08-28 |
| Ubuntu | USN-7725-2 | 24.04 | linux-realtime, linux-raspi-realtime | 2025-08-28 |
| Ubuntu | USN-7714-1 | 14.04 | open-vm-tools | 2025-08-31 |
| Ubuntu | USN-7713-1 | 14.04 | openldap | 2025-08-29 |
| Ubuntu | USN-7629-2 | 16.04 18.04 20.04 | protobuf | 2025-09-02 |
| Ubuntu | USN-7710-2 | 14.04 16.04 18.04 20.04 22.04 | python2.7 | 2025-08-29 |
| Ubuntu | USN-7723-1 | 14.04 16.04 18.04 20.04 22.04 24.04 25.04 | udisks2 | 2025-08-28 |
Kernel patches of interest
Kernel releases
Architecture-specific
Build system
Core kernel
Development tools
Device drivers
Device-driver infrastructure
Documentation
Filesystems and block layer
Memory management
Networking
Virtualization and containers
Miscellaneous
Page editor: Joe Brockmeier