Welcome to the LWN.net Weekly Edition for September 24, 2026

This edition contains the following feature content:

• Looking forward to Git 2.56 — and 3.0: new features in the latest Git release, and the roadmap beyond.
• Compiling the kernel with gccrs: the status of the gccrs project and a look at the work still needed to compile the kernel.
• Testing compat_linux on NetBSD with the Linux Test Project: using Linux's own test project to test NetBSD's ability to run Linux binaries.
• Thread-identity switcheroo for io_uring: a somewhat radical, maybe even scary, solution to a maintaining io_uring's "never blocks" guarantee.
• Ideas on modernizing the open-source desktop: Scott Jenson wants open source to take the lead on updating the desktop experience.

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)

Looking forward to Git 2.56 — and 3.0

The Git source-code management system is at the core of development processes worldwide, so changes, especially incompatible changes, are of great interest to the developers involved. The Git 2.56 release, which can be expected around the end of September, is currently available in release-candidate form. It is not the most earth-shaking of releases, but the one that follows, which might be the long-awaited Git 3.0, may well be.

What's in Git 2.56

The Git 2.56 release contains something over 700 non-merge commits; it brings a number of nice improvements, but will not fundamentally change the Git experience for most users. One feature that offers some potential in that regard is the addition of the drop subcommand to the (still experimental) git history toolbox:

    $ git history drop commit-id

This command will cause the identified commit to be removed from the history of the current branch, replaying all commits that were added after it. It offers an easier way of removing an offending commit. Unfortunately, it still refuses to work if the history contains merge commits, making it unusable for many (or most) repositories.

The git status command will now suggest a git pull command to update a branch that is behind the branch it tracks. It still, though, will say that a branch is "up to date" even if it lags behind an (unfetched) remote tracking branch.

The git refs command exists to manipulate references at a low level; in 2.56, it has gained a number of new subcommands. Those commands, create, delete, update, and rename, perhaps surprisingly for Git, do exactly what their names suggest they would.

There are a number of minor usability tweaks. The new --delete-merged option to git branch will remove local branches that have been merged into their remote tracking branches. An attempt to delete a branch with git branch -d will fail, with a useful message, if that branch is being used for bisection. Attempts to lock the configuration file will be retried on failures, avoiding annoyance when multiple commands try to modify the file at once. git add has a new --resolved option that only adds files with merge conflicts that have been resolved.

Beyond that, there is the usual long list of bug fixes, refactorings, and performance improvements. All told, 2.56 looks like a solid release, but it also shows the signs of a project that is holding back much of its more significant work for the future. That leads to the question of what comes next.

After 2.56?

In early September, Git maintainer Junio Hamano asked the community what the next release should be. Would it be best to put out the 3.0 release that the community has been working toward for some time, finishing the year on a high note? Or, instead, is there a need for one or more 2.x releases still before the 3.0 release can happen?

This is an important question, because 3.0 will contain a number of compatibility breaks that may make some users pause before upgrading. Of those, perhaps the most significant is the switch to using the SHA-256 hash function by default, rather than the SHA-1 hash that Git has used since the beginning. SHA-1 has long been deemed to be weak, which is worrisome for applications like Git. Hashes are used to identify every object (files, directory trees, commits) in the Git repository, and are used to verify the chain of commits leading to any given point. If SHA-1 can be broken, it can conceivably be used to modify the history of a repository in ways that are difficult or impossible to detect.

Git has long included defenses against the known SHA-1 attacks, and few people appear to be seriously worried about the potential for compromised repositories now. Still, it makes a lot of sense to move to a more secure hash function.

Non-experimental support for SHA-256 has existed in Git since the 2.42 release in 2023, though some of the glue for interoperating with older repositories has taken longer. The biggest concern that has kept the Git developers from moving to SHA-256 by default for some time now has been support (or the lack thereof) at the major forge sites. GitLab has had support since 2024, and Forgejo has support as well. The elephant that is still missing from this room, though, is GitHub; releasing a version of Git that creates GitHub-incompatible repositories is a worrisome prospect. It still is not clear when GitHub might add that support, but it is notable that brian m. carlson, a GitHub employee and a key developer behind the SHA-256 transition, responded to Hamano's question by saying that news on that topic was coming, and that having the next release be 3.0 might be the best choice.

That said, carlson has posted one other change that they would like to see added before 3.0 comes out. While Git has always managed hexadecimal numbers (specifically, object IDs) as lower-case strings, it has also accepted upper-case IDs. That leads to situations where two seemingly different IDs (f00f00 and F00F00, say) are actually the same. Seemingly, bugs and security vulnerabilities have arisen from this ambiguity. So carlson wants to change Git's behavior to only accept IDs in lower case. That is a change that, seemingly, should not cause problems for too many users, but there is almost certainly somebody somewhere who relies on that behavior.

Another significant change that has been waiting for the 3.0 release is the switch to the "reftable" mechanism. A reference (more commonly "ref") in Git is an association between a name and an object in the repository; branches, tags, and remotes are all refs, for example. Git currently (by default) stores each ref as a file under .git/refs/ in the repository. If a repository contains a branch called foo, there will be a file, .git/refs/heads/foo, containing the ID of the commit at the head of that branch. There is also a mechanism to pull all of these refs together into a packed-refs file, which increases performance — to a point.

This mechanism works, but becomes increasingly inefficient as the number of refs grows. In some projects, the number of refs does indeed grow. According to the project's reftable documentation, the Android repository contains over 800,000 refs. At that scale, looking up refs, or determining whether any refs pointing to a specific commit exist, can be an expensive operation. Slowing down development can be a yellow-card-level annoyance, leading to a desire to do something about the refs.

The Git 2.45 release added reftables as a more efficient way of storing refs. It is a binary file optimized for both space efficiency and quick access. Since then, it has been possible to create a repository that uses a reftable rather than the old file-based mechanism, but that has never been the default. Switching to reftable should have no visible consequences (other than better performance) for users of Git itself, but it can be a problem for users of other software packages that access Git repositories. In his email, carlson mentioned libgit2 as a potential concern.

As it turns out, libgit2 will not be a blocker here; Patrick Steinhardt let it be known that he has added reftable support to libgit2, and that SHA-256 support had been enabled by default in August. So libgit2 should be ready for the Git 3.0 transition.

Finally, as mentioned by carlson, there is the Rust question. The project has added some trial support for code written in Rust, but has hesitated to make Rust mandatory for the building of Git. That, too, is expected to change in the 3.0 release; after that, any platform that does not have a working Rust compiler will be unable to upgrade.

After listing these concerns, carlson suggested that they probably should not hold up the 3.0 release:

I think anyone else who is not already extremely far along on SHA-256 (and reftable, for software working with local repositories) is likely not worth considering. JGit and Gitoxide were both informed that SHA-256 was coming in Git 3.0 at least a year ago, for instance. (I know because I did the informing.)

Similarly, I am not aware of anyone who is seriously undertaking Rust support for platforms that do not already support it, so I don't think that should be a blocker, either.

That led to their conclusion that, most likely, designating the next release as 3.0 would be the best choice.

What will actually happen has not, yet, been announced publicly; that is waiting for Hamano to make a decision. As he put it: "this is not a popularity contest, nor is it even a democracy". In the nearly two weeks since his query was posted, though, there has been no strong opposition to moving into the 3.x era and leaving some of Git's early design decisions behind (though, naturally, repositories using SHA-1 and lacking reftables will continue to be fully supported). If the 3.0 release does not happen in 2026, it seems certain to show up shortly thereafter.

Update: at Kernel Recipes, Steinhardt described the plan that had been agreed to regarding releases. The December 2026 release will be called 2.98, as a signal that the 3.0 transition is coming. The 2.99 release will follow in April 2027; that will be a long-term-support release. Git 3.0 will also be released at the same time, and will be the base for all subsequent releases.

Comments (145 posted)

Compiling the kernel with gccrs

Pierre-Emmanuel Patry and Arthur Cohen gave a talk at RustConf 2026 on the status of the Rust frontend for GCC (gccrs), with a particular eye toward the goal of compiling the Linux kernel. Patry gave a follow-up talk for a more kernel-focused audience at Kangrejos the next week, which Cohen could not attend. The gccrs project is making good progress overall, but it will still be some time until the compiler is usable.

Cohen began the RustConf talk by stating that the title of the presentation, "Compiling the Linux kernel with gccrs", was a lie. Gccrs cannot currently compile the Linux kernel, for multiple reasons. One such reason, Cohen said, is that he and Patry were laid off and couldn't dedicate all of their time to gccrs — although Open Source Security has since picked up their contracts. Another reason, which Patry brought up at Kangrejos, was that their current goal was really to "miscompile the Linux kernel". The project needs to get to the point of emitting a binary that can be tested and validated to be said to be "compiling" anything; almost certainly, there will be a delay between the point where gccrs accepts the kernel's Rust code without complaint, and where the output it produces is actually a usable kernel. Nevertheless, the two of them have made substantial progress.

GCC is a nearly 40-year-old project, Cohen explained, that brings together compilers for a number of different languages, such as C, C++, Fortran, Go, and Algol. The gccrs project wants to add a full implementation of a Rust compiler to that list, separate from the Rust project's rustc compiler. That is important for many reasons. For example, GCC supports more backend architectures than rustc does. GCC also supports custom compiler plugins that many existing projects rely on. With Rust code now included in the Linux kernel, it would be nice to be able to compile the kernel with just GCC.

Therefore, the main goal of gccrs has been to compile the Rust code present in the Linux kernel. That code is split into several different crates that depend on each other, Patry explained to both the RustConf and Kangrejos audiences. The most fundamental is core, which provides the "bare minimum to make Rust language features work". For example, for loops in Rust use the Iterator trait, which is defined in core. Without core, the compiler can't support for loops.

Other crates within the kernel include stdarch, which provides architecture-specific operations, alloc, which handles memory allocation, pin_init, which handles creating immovable structures, and others. When gccrs started, Patry said, he and Cohen began by trying to compile small snippets of Rust code in isolation. That approach has reached its limits, so the plan now is to focus on making core work, and then move up the dependency graph to alloc and so on, until the whole kernel compiles.

That approach has been working well, but has caused some problems with trying to parallelize the work, Cohen said. Currently, each problem that comes up with compiling core is hidden behind the previous problem, making it hard to split work across multiple contributors. To address that, Patry and Cohen made a mock version of the core library with only the parts needed by alloc, so that getting that crate to compile could proceed in parallel.

The core library is "really complicated", Cohen added. In many ways, it is the strangest Rust library, since it needs to do so many low-level operations that other code doesn't need to address. The hope is that once gccrs can compile core, it will be able to handle most Rust code, and any remaining libraries will be easy to support. "Maybe I just tell myself that," Cohen added, to general chuckles. The alloc crate also uses some complicated features, such as arbitrary self types, but the version used in the kernel is simpler than the one used in the standard library, so Cohen is not too worried.

The project will eventually need to get the standard-library version working, however. There are two kernel crates that use procedural macros, Patry said, which are Rust code that is called during the compilation process, and can link against the standard library. So, even though the kernel itself does not link the standard library, gccrs will still need to be able to build it in order to compile the kernel.

At Kangrejos, Miguel Ojeda asked whether it would be possible to use procedural macros compiled by rustc, as a temporary workaround until the standard library is usable. Patry wasn't sure, but thought that it was theoretically possible. He was leery of disrupting the ecosystem by introducing strange incompatibilities between procedural macros and the code they generate, however. Ojeda opined that a workaround that gave the kernel access to gccrs a bit earlier would be useful for testing gccrs and finding problems. He then went to check on the use of the standard library in procedural macros in the kernel, and reported a few minutes later that the only uses are via the syn crate, and a single use of a BTreeSet that could probably be replaced.

Gary Guo thought that Ojeda was overlooking the complexity needed to support allocation, however, which is used implicitly by procedural macros. Once allocation is working, "you probably also get B-Trees for free," he remarked. Patry said that he hadn't spent much time looking into getting procedural macros working, since he and Cohen had been focused on the core crate. Maybe some additional thought will find a way to make it work, he suggested.

Compiling core

Cohen went into more detail on what has been involved in getting core to compile. For the past three years, he and Patry have mostly been working on fixing name resolution, the process of linking uses of names to their definitions. The initial implementation was simple, "like how a textbook compiler does name resolution". That implementation proved to be fundamentally flawed, however, because Rust's name resolution is quite complex. There are multiple separate namespaces (for functions and constants, types, labels, and lifetimes), and name resolution sometimes has to cross between them. Additionally, names can be used before they are defined.

Names can also be defined by macros, which themselves rely on being able to resolve names. Therefore, name resolution and macro expansion have to run interleaved with each other, in a fix-point fashion that repeats the process until all names have been discovered. Cohen originally told his boss that this work would take three weeks. Patry and Cohen finished it just before RustConf, nearly three years later. Despite the delays, name resolution is now working correctly, as is declarative macro expansion. It is not particularly fast, but "that is a problem for future Arthur".

At Kangrejos, Patry went into more detail on the performance problem. The core crate is roughly 85,000 lines of code, and gccrs used to take about 42 minutes to compile it. The crate does rely heavily on macros, but most of the time is spent in name resolution. Because name resolution runs until it reaches a fix-point, the compiler makes many of the same calls. Adding a cache for those calls brought the time required to compile core down to three minutes (compared to rustc's 30 seconds), which is "not as fast as rustc, but fast enough to work with".

The other tricky parts, such as inline assembly support, and the lang items system, are mostly working. At this point, each individual bug that the gccrs developers work on could be the last one standing between gccrs and compiling core.

There is still a known problem with passing crate metadata between compilation units, Patry added. Right now, the serialization format for crate metadata is a dump of the crate's abstract syntax tree. That's a temporary hack, he explained, which is working for the moment but that will need to be cleaned up to do cross-crate linking correctly.

Next steps

Cohen then explained some of the next steps for the project. Another known problem is the handling of the Drop trait, which is used to automatically clean up allocations at the end of their scope. Janet Chien, a Google Summer of Code (GSoC) participant working with the gccrs project, has been focused on improving that part of the implementation. When she started work, gccrs did not implement drops at all. Now, it has support for common cases, but can still be tripped up by nonlinear control flow, partial moves, generics, and temporary values. Enes Çevik, another GSoC participant, has been adding infrastructure for compiling and testing the alloc crate.

Once gccrs can compile all of the crates used by the kernel, the next step will be to catch up to stable Rust. For the last several years, gccrs has been targeting parity with rustc version 1.49 and a matching old version of the kernel. The project chose to do that to avoid chasing an endlessly moving target while trying to get basic functionality working at all; eventually, however, it will be time to chase that target. Patry is not too worried about the process of catching up. Most changes to the language come in the form of new library functions and types, and stabilization of existing unstable features, which Cohen expects should be trivial to support.

There are three features in particular that do represent actual changes to the language itself that will have to be dealt with, which Patry called out for the RustConf audience: trait upcasting, the new use<...> syntax, and return-position impl Trait in traits. There is also one additional experimental feature, cfi_encoding, which the kernel uses when generating bindings between C and Rust code. That will be slightly tricky, Patry explained, because it requires changes to GCC's control-flow integrity (CFI) code. There is an existing patch series addressing that, but it has remained unmerged since its introduction in 2025. The gccrs developers may need to work with the rest of the GCC maintainers to figure out whether that series is acceptable and how to get it merged.

After that, the project will have to test kernels compiled with gccrs to ensure that the behavior exactly matches that of binaries compiled with rustc. Since the kernel is not even compiling yet, Patry and Cohen haven't begun major work in that direction, but they have taken a few preliminary steps.

One audience member at RustConf asked whether gccrs implemented any of the intermediate representations that rustc uses. Patry said that it did not — although since the project hopes to reuse the implementation of the next-generation trait solver, the code may eventually have to produce an intermediate representation suitable for that.

Another person asked how well documented the Rust language specification is, and how that affected the validation of gccrs. The specification is not enough to fully implement a compiler, Cohen said, but that isn't the fault of the people working on the specification. The upstream rustc developers are productive, with new features coming with each version of the compiler. Patry and Cohen have tried to improve the specification where it is lacking, which is another benefit of having an independent reimplementation of the language.

[ Thanks to the Linux Foundation, LWN's travel sponsor, for assistance with attending both RustConf and Kangrejos. ]

Comments (6 posted)

Testing compat_linux on NetBSD with the Linux Test Project

NetBSD has long had support for running Linux binaries via its kernel-level compat_linux feature, but test coverage for it was less complete than some might hope. In order to provide better testing for compat_linux, Google Summer of Code (GSoC) participant Henrique Brito opted to work on enabling the Linux Test Project (LTP) test suite to compile and run on NetBSD. At EuroBSDCon 2026, Brito's mentor, Stephen Borrill, provided a report on the project, and the status of LTP on NetBSD. The work has already resulted in some minor fixes, and a good list of additional problems to solve.

I did not attend EuroBSDCon 2026 in person, but had the opportunity to watch Borrill's presentation shortly after it was live-streamed. The video is available along with the other EuroBSDCon 2026 videos on a PeerTube instance, and the slides are linked from his web site.

Borrill, who has been a NetBSD developer since 2007, said that he runs a company that develops thin clients and servers based on NetBSD. Many thin clients need to access virtual desktops using a proprietary Independent Computing Architecture (ICA) application from Citrix. There is no NetBSD-native version of this client, but there is a Linux version that will run under compat_linux, and Borrill maintains its package for the NetBSD Packages Collection (pkgsrc), which is a repository of third-party software.

He ran into a new version of the ICA client that would not run under compat_linux. Instead, it would fail with an ENOSYS error, indicating a system call that was not implemented. That led him to take an interest in compat_linux, and he added an entry to NetBSD's list of suggested projects for GSoC to emulate missing Linux system calls.

compat_linux

The first GSoC project did not solve Borrill's problem; that project led to a native implementation of the splice() system call that can be called by compat_linux. The ENOSYS error he had been running into was fixed separately when the timer_create() call was added; after that, Borrill said, he didn't care much about emulating missing system calls. He was, however, interested in testing linux_compat.

The original title of Borrill's talk included the phrase "Linux emulation" to describe compat_linux, which he said is not quite right; NetBSD runs Linux code natively, with "virtually no performance impact", when compat_linux is enabled. "All we're doing is having a small shim that's making it look like it's Linux in terms of things like system calls and how we access files." The mapping of Linux system calls to NetBSD calls is defined for each architecture in /sys/compat/linux/arch/<ARCH>/syscalls.master, where ARCH would be amd64, i386, etc. The NetBSD Internals documentation, though slightly dated, explains how the operating system examines an executable binary and determines which kernel ABI to use.

The compat_linux feature is not enabled by default in NetBSD's GENERIC kernel, but it is available as a module. Borrill said that "everything's been moved to modules" for security reasons. compat_linux translates Linux system calls into NetBSD system calls and looks for any shared libraries that the application depends on in a "shadow root" directory under /emul/linux (or /emul/linux32 for 32-bit applications). For example, if a Linux binary tries to open /usr/bin/ldd, then NetBSD will first look to /emul/linux/usr/bin/ldd before falling back to /usr/bin/ldd.

As one might expect from NetBSD, compat_linux has support for quite a few architectures, including 32-bit and 64-bit applications for both x86 and Arm. Borrill noted that NetBSD also includes support for running FreeBSD, SunOS, and Ultrix binaries and "used to support a lot more, you know, a really crazy amount". However, the need to run many of the other operating system's binaries has slowly died away—as well the hardware needed to run those binaries in numerous instances.

Testing compat_linux

NetBSD has a native testing framework called Kyua, but it does not have extensive coverage for compat_linux. Rather than trying to add that support into NetBSD's regular test suite, Borrill thought the project might be able to build LTP for NetBSD and use it instead. He noted that LTP has tests for "all sort of things; but for the moment we're only looking at the syscall side of it". He said that consists of about 376 collections of tests with about 1,300 tests in total.

The first decision was how to build LTP; rather than trying to cross-compile it, Brito and Borrill opted to build it with a Linux version of GCC under compat_linux instead. They chose to use the SUSE 15.5 compatibility package from pkgsrc, created a Linux compatibility package for GCC 12 and uploaded that to pkgsrc. Once the test suite was running, he said, they noticed that most of the tests that were run passed, but many were being skipped.

Brito thought that it would turn out to be a boring project if everything passed; Borrill looked into it and noticed that Brito had started with NetBSD 10.1. That release has a compat_linux that presents itself as Linux 3.11, which was released in 2013. Obviously, quite a bit had changed since that kernel was released; the SUSE 15.5 packages for NetBSD, for instance, expect Linux 5.14.21. Testing system calls that were added since 3.11.6 would certainly increase the odds of finding problems as well as help to ensure that more Linux applications would work.

Borrill said that they could just change the configuration to declare a different version of the kernel for compat_linux, but it was decided that a better fix would be to use NetBSD 11, which has a compat_linux that declares 6.3.10 as the Linux kernel version, even though NetBSD 11 had not been released yet. However, the fourth release candidate of NetBSD 11 was available, and the final release was announced on July 30, about two months after the start of coding for this year's GSoC.

Not surprisingly, they also had to skip some of the tests because of features that were not available on NetBSD. For example, Borrill said that LTP attempts to test filesystems that NetBSD does not support, such as Btrfs and XFS, so they restricted the tests to ext2, ext3, ext4, and tmpfs. Ultimately, Brito created a manager script (compat_linux_test_project) to handle running LTP against compat_linux. It accounts for the differences between NetBSD and Linux to compile LTP properly, run tests, and skip tests known to (for example) hang or panic the kernel. They also decided to package the work for others to use with an eye to publishing it via pkgsrc. It is not yet merged into the official pkgsrc tree, but it is currently available in the emulators/compat_linux_test_project directory of Brito's pkgsrc fork on GitHub.

Borrill suggested that they try compiling everything statically, rather than dynamically, so that there would be no additional requirements "like all the Linux libraries and things like that". The package came out to about 80MB in size when compiled dynamically, but when built statically it turned out to be about 5.1GB. "I built this while I was down at the pub and I had time to order and drink a whole pint while it was just trying to build the package into a tarball at the end." That is probably a no-go, he said, but the option to compile everything statically is still available for anyone who wants it.

It takes about 25 minutes to run all of the tests, but the script allows users to specify which system calls they would like the test to avoid having to re-run the entire batch. For example, this command would test the readv(), writev(), open(), and close() system calls.

    $ compat_linux_test_project -s readv, writev, open, close

The script also has options for users to re-run tests and compare them against previous. "We've also included a sort of default baseline of what we believe the current state of affairs is, so you can just compare the run on your machine with the defined baseline we already have."

Failure types

linux_compat has implemented most of the Linux system calls "in that you can generally have a first stab at taking a Linux binary and expect it to work", Borrill said. The ways that it doesn't work, though, are interesting and varied; there are many types of failure that might present themselves.

The easiest ones to deal with are features where it's known that "it's not supported and we don't care about that". Likewise, some system calls will be missing entirely; for example, NetBSD does not support any of the system calls related to Linux namespaces. Later in the talk, he mused that the missing namespace system calls would be nice to have for NetBSD but, "definitely outside the scope of a GSoC project".

In some cases, a test may exercise a system call supported by compat_linux that "might look right on the face of it" but fail because of a Linux-specific flag that is not supported on NetBSD. In other cases failures may turn up something that NetBSD just hasn't implemented yet, or it could be "something that only makes sense within the Linux world".

There are also environmental variables and configurations to consider when running LTP on NetBSD; Borrill noted that LTP looks for the .config file for the Linux kernel to see what to run, but since compat_linux does not supply a kernel, it also lacks a configuration file. Brito's script takes care of supplying the appropriate .config so that LTP skips unsupported subsystems and operations. The last type of failures he mentioned were the exciting ones "where everything crashes, machines die, all those sorts of things".

Examples

He then cited some specific examples, such as lseek() which has two flags that are not implemented: SEEK_DATA and SEEK_HOLE. That caused the test to stop early, so it did not flag later tests as failed.

Many of the file-open tests failed because compat_linux did not support the open() system call's O_TMPFILE and O_PATH flags. A fix for that, he said, might be to actually implement those in the NetBSD kernel so that compat_linux inherits them natively. Another option, for things that would not be useful for NetBSD, would be to implement it only within the compat_linux layer. An example of that is the rt_sigqueueinfo() system call used to send a signal and data to a process; that is only available via compat_linux.

One of the interesting failures, he said, was that the behavior of Linux diverges from BSDs when iovcnt = 0 is passed to writev(). The BSDs, he said, return EINVAL as specified by POSIX—Linux returns "0" instead, indicating that, as requested, no data was transferred. "The tests were failing, but by all the specs, we were doing the right thing. And that's because zero is an invalid value, and so we were returning EINVAL." That would not be implemented natively, but could be implemented in compat_linux in two or three lines to "sort of be bug-compatible" with Linux.

But does compat_linux always need to be bug-compatible? He pointed out that LTP's tests for setsockopt() and shmat() look for known Linux bugs that are not present in NetBSD. "So what do we do with those? Do we just ignore them? Or do we need to be bug-compatible like we were with the writev() one?"

One test failure that was discovered had "a certain sense of irony", he said, because it was related to a system call added in a previous GSoC. The call copy_file_range() causes a kernel panic on NetBSD when off_in or off_out, which give the target ranges to copy from a file and to a file (respectively), are not NULL; the call should support non-null values for the file offset. It was simple, and the fix has already been committed to NetBSD.

What's next?

The GSoC project focused on testing x86 and x86-64. Borrill said that one of the obvious next steps would be to work toward testing on multiple architectures, in particular Arm. "Some of the more esoteric architectures we're probably not going to bother with". Supporting Arm, however, will require updating the SUSE compatibility packages available on pkgsrc to support additional architectures. He said that he had not yet had time to do that, but he thought it would be really useful and planned to "get a Raspberry Pi up and actually give it a go" once he was home from the conference.

As part of the project, Brito has put together a spreadsheet of the test results of system calls considered fundamental; that is, those that are used more often by Linux applications. Borrill said that, because Brito had done the legwork to identify not only which system calls were failing but why, there is now "a shopping list of tasks we can pick up", which may be useful not only for compat_linux, but NetBSD itself.

Borrill wrapped up his talk by thanking Google for supporting NetBSD through GSoC, Brito for his work on the project, and Leonardo Taccari who became involved in NetBSD as a GSoC participant, later became a mentor, and now helps to organize the project's involvement in the program. "He's really gone up the management tree there. His pay grade hasn't gone up, but he's been fantastic at organizing everyone".

Questions

The first person to be called on said: "In the past, I remember that futex() support was a big issue, and that it wasn't well supported in the Linux emulation. Is it better now?" Borrill replied that it was not; it was just one of the things he had not specifically covered during the talk. He noted that it was documented in Brito's spreadsheet.

Another audience member wanted to know whether compat_linux had support for versioning when there were "different versions of the same thing, like earlier version and later version". For example, what if the behavior of a system call was different between Linux 3.11 and 5.15? Did the compatibility layer support both versions, or just emulate the most recent version. Borrill said that the short answer was that he didn't know; NetBSD does have system-call versioning, but "we don't do any of that in the Linux compatibility". It does, he added, support two versions of SUSE binaries, with the latest being 15.5. He referred the questioner to the spreadsheet for more information.

Comments (1 posted)

Thread-identity switcheroo for io_uring

The io_uring subsystem is all about asynchronous execution; applications count on it to not block — unless explicitly requested to. Within io_uring, maintaining the "never blocks" guarantee has sometimes been a challenge, given that many paths in the kernel were never designed for asynchronous execution. This problem has been worked around, but at a significant cost to performance. Now, io_uring maintainer Jens Axboe has posted an RFC patch set with a somewhat radical (and potentially scary) solution to the problem.

A process in user space can submit one or more operations to io_uring by describing them in submission-queue entries (SQEs) in the submission ring, then calling io_uring_enter(). The kernel will initiate processing on all of the entries that were placed into the ring. If possible, the kernel will execute them immediately within the io_uring_enter() call. For example, if a read request can be satisfied with data that is already in the page cache and the user-space buffer is entirely resident within RAM, then the requested data can be copied immediately without blocking.

In cases where blocking is required, though, things become more complicated. Many of the I/O paths within the kernel have asynchronous support built into them; they will carry a new request as far as it can go, and finish the job elsewhere within the kernel once the blocking operation has completed. There are other operations, though, that lack this support; these include the io_uring equivalent of system calls like fdatasync(), statx(), some openat() paths (the O_NONBLOCK flag notwithstanding), and others. The io_uring code must take extra care when implementing these operations, lest io_uring_enter() block partway through processing a set of submitted operations.

In current kernels, any operation that might cause io_uring_enter() to block is handed off to a separate worker thread for execution. That allows the submitting thread to continue; the separate worker can block, if need be, without holding up anything else. This handoff is not free, though; the kernel must wake a waiting worker thread and perform a context switch, among other costs. If the operation does indeed block, those costs may not be significant in the end. In many cases, though, the operation can be completed without blocking. In such cases, the extra overhead becomes a significant part of the overall cost of executing the request. Since developers who turn to io_uring are usually doing so in search of improved application performance, the cost of avoiding blocking that might not happen anyway hurts.

One solution to the problem would be to rework all of the system-call paths in the kernel to be non-blocking. That has been done, in some cases, over the years, but it is not an easy or quick task. An alternative — the one that Axboe has chosen — is to proceed with a potentially blocking operation then handle cases that actually block without blocking the submitting thread.

Detecting operations that do indeed block requires a change to the scheduler. A new flag (PF_IO_HANDOFF) is added to the flags field of the task_struct structure that represents a thread. If a thread is about to block for any reason and it has that flag set, the scheduler will make a call to a new function called io_uring_task_sleeping(). Hooking into the scheduler in this way allows io_uring to be informed about blocking that happens anywhere in the kernel, without having to modify the actual code paths involved.

Once io_uring knows that an operation is going to block, it must do something about the situation. One option, in theory, would be to unwind whatever work had been done up to the blocking point, then to restart the operation in a worker thread. But, since this blocking can happen almost anywhere in the kernel, that is not really an option. As a general rule, once io_uring has started a requested operation involving kernel code paths that are not designed to avoid blocking, it must see that operation through to the finish.

Axboe's solution is "thread identity handoff". When the scheduler informs io_uring about a thread that is about to block, io_uring responds by selecting a worker thread from its thread pool. Rather than hand the ongoing work over to that thread (which is not possible at this point), the code exchanges the identities of the two threads. The worker thread is made to look like the original submitting thread in every way, including its thread ID, signal-handling setup, and more; that thread then continues processing the submission ring before, eventually, returning to user space. The thread that returns from io_uring_enter() has a different task_struct than the one that made the call, but everything else (hopefully) looks the same.

Meanwhile, the original thread, which was about to block executing an operation, takes on the worker thread's identity, then proceeds to block as usual. When it wakes, it will continue the operation through completion, then take its place in the worker-thread pool. The end result is that potentially blocking operations can be executed by the submitting thread and, if they can run without actually blocking, be handled entirely there. The cost of bringing in a worker thread is only paid if the operation really does block.

It sounds simple enough, but this kind of identity exchange is fraught with potential land mines. Before the two threads involved can exchange their task_struct structures, the kernel must make absolutely sure that nothing else in the kernel holds references to those structures. Otherwise, something will eventually be done with a reference to the wrong task_struct, an outcome that will do nothing to reduce the strain on all of the people trying to keep up with the stream of kernel CVEs. That is a result that is deemed to be worth avoiding.

Preventing it means being sure, before starting an operation that might block, that the submitting thread will be able to hand off its identity if the need arises. There is a long list (found in the definitions of thread_handoff_allowed() and thread_handoff_compatible() in this patch) of conditions that would prevent a handoff and require the operation to be executed in the old way. For example, if the thread is being traced with ptrace(), then the tracer holds a reference to its task_struct. By the same logic, if the thread in question is tracing any other tasks, those tasks hold references, so the thread cannot perform a handoff. Other conditions that will prevent a handoff include using perf events, having futex ownership tracked in the kernel, running under a realtime scheduler, holding a core scheduling cookie, performing a vfork(), and several others. This determination seems like the scariest, most fragile part of this series. The task_struct is widely available, so it is hard to know that all of the possibilities for possible references in the kernel have been covered — before one even begins to worry about the addition of new references in the future by developers who are not thinking about io_uring at all.

The potential payoff is large, though. The cover letter includes a number of benchmark results. For some quick, non-blocking operations, the improvements can be huge; an fsync() benchmark run on a tmpfs filesystem showed a nearly 700% improvement. Other improvements are more modest, and some of the tests that always block show regressions. The worst regressions tended to be with a higher queue depth — when there is a longer list of operations all being submitted at once. Immediately pushing each of those operations into a worker thread allows them to be worked on in parallel, while processing them up to the blocking point in the submitting thread serializes that work, slowing it down. Axboe said that he has ideas for addressing that problem, but he is unsure whether they are worth pursuing because, he said, applications that perform these operations tend not to have high queue depths to begin with.

Axboe clearly does not expect to merge this series in the near future; he is more concerned with determining whether the overall approach has any chance of being viable. Comments have been limited so far. Peter Zijlstra pointed out that one of the other conditions blocking identity handoff — if the thread involved is running with a shadow stack — will prevent the use of the feature on most deployed systems; Axboe thinks that the shadow stack can be moved with the rest of the thread's identity. Beyond that, it seems that developers are still mostly digesting this series that, as Gabriel Krisman Bertazi said, is "really cool and seems like very dangerous thing". If this series can convince developers that the "dangerous" part has been dealt with, it may eventually lead to significantly better io_uring performance for a number of workloads.

Comments (13 posted)

Ideas on modernizing the open-source desktop

Scott Jenson has been working on user interfaces (UIs) and user experience (UX) for many years at Apple, Google, and other companies. Now, he's trying to convince open-source projects to experiment more and drive the desktop beyond the age-old "windows, icons, menus, pointer" (WIMP) model. At Akademy 2026, KDE's annual developer conference, he shared his complaints and ideas in a talk aimed at convincing those in attendance to take the lead on desktop design.

He introduced himself as someone who has been doing UX for a long time, much of that time at Google. He said that over that time he had noticed a cultural shift, "because back in 2005 when I joined, we weren't evil; we were really trying to do the right thing". He had worked on the Chrome team for a while, which he said was "filled with people who wanted nothing but open-source, open-web" projects. Things had changed radically, which led him to leave Google, "but I'm trying to atone for my sins working for these companies".

He now does work for Mastodon and Home Assistant, "just kind of trying to squeeze a little bit more good UX design into open source". Jenson said he did not want to be confrontational, but he thought that open source needs a lot of help in the area of UX design. That is challenging, because open-source projects are understaffed.

Innovation

He was at Akademy to discuss his ideas because he had given a talk similar to this at Ubuntu's conference last year, which proved to be popular. "It got more than half a million views on YouTube—which by YouTube standards is trivial, but by Scott standards is enormous." That told him that the topic of desktop UX was something that people wanted to talk about. This time around, he also wanted to show a few examples of prototypes he had to demonstrate his ideas.

He thinks that desktop UX is very different from other kinds of UX. Jenson related a story about working on the Macintosh's Finder application, which is a file manager. The team "wanted to do ellipses" in file names when showing a file in the Finder that had a name too long to display in its entirety. The developers wanted to put the ellipsis at the end of the file name, but he thought that would lose too much information, and suggested that the ellipses should be in the middle of the file names. "It's now considered to be one of those things that's an exciting little attention-to-detail issue the Macintosh does."

Another UX detail that he worked on is the way that clicking and dragging files from one window to another works on the Mac. A mouse click action has two parts: when the user depresses the button (mouse down) and when the user releases the button (mouse up). On the Mac, item selection happens on mouse down, but the window only raises on the mouse up action. In other words, if a user drags an icon from a Finder window into another window, the first window is not raised.

On most Linux systems, though, if a user is trying to click and drag a file from a window in the background it will cause the window to raise as soon as the user does the "mouse down" action. That complicates trying to click and drag a file from one window to another. That is a fundamental action that means that users can't move data into applications quite as easily on Linux as they can on the Mac.

He said that he had talked about that issue two years ago on Mastodon, which raised a response from a KDE developer who thought it was a good idea to separate the mouse down and mouse up actions when dragging data between windows. Then they implemented it a few hours later.

"I forgot who that was. So if anybody here did that", he said, but before he could finish the sentence a voice from somewhere in the room responded, "you're welcome". Jenson yelled "thank you! I've been wanting to meet you for two years!" That was an example, he said, of how open source can be awesome: someone can just say "that's a good idea, I'll just do it" and then rapidly implement and push the feature to the project.

Stabilized

The point he was really trying to make, though, is that the desktop UX had not really changed in 20 years. There were plenty of new ideas and improvements in the 1980s and 1990s, "and then it just stabilized, and not much has really changed". But people are doing much more with their computers today, and he thinks that there are ways for desktop UX to grow.

Much of the UX for Linux systems was originally copied from Windows and the Mac, "KDE even says it's for Windows users, that it wants to be similar to Windows for users". There's nothing wrong with that, but he felt that the Linux community "in general" had been leaning on Microsoft and Apple to do all of the UX research and testing, "and frankly, [make] the mistakes".

Some might point out that GNOME has conducted user research for some of its design changes, and KDE's human-interface guidelines (HIG) were also developed based on research by its contributors. However, it would be fair to say that these are exceptions rather than the norm; certainly, no one is funding or conducting regular UX design research and development for the Linux desktop overall.

He said that it is smart to let Apple and Microsoft do these things first "so we can draft behind them", but the problem is that "they've just kind of given up to an extent". Apple has been letting its desktop UX, and desktop hardware, "languish for years and years and years" because it had shifted its focus to the iPhone and iPad devices. "I mean, like, Apple wanted the Mac to die. They wanted the world to move over to the iPad. Guess what? It didn't."

Apple has since turned its attention back to the Mac, but the things they've done since—such as the Liquid Glass design language—have not been really popular with users. The features that Apple tends to add, he said, are "basically about tying it closer to the iPhone, tying you closer into their ecosystem". That isn't about improving the desktop, it's about increasing their moat.

Microsoft "is just making one mistake after another". He cited the company's attempts to force users to store files using its OneDrive cloud-storage service, the privacy-invasive Windows Recall feature that drew widespread criticism, and "ads everywhere" on the Windows desktop. His point was not to bash Apple or Microsoft, though the audience didn't seem to object to this, it was to point out that the Linux desktop could not follow their example any longer. "The whole Linux community has been just waiting for Apple and Microsoft, more or less, to take all the risks, and they're not taking any more risks."

Three pushbacks

Jenson emphasized that he didn't want to change everything, but he wanted to see experiments and additional development aimed at improving the desktop experience. However, he said that he gets pushback when he tells people that desktop innovation has stopped, and that the Linux desktop "can't just patch and bug fix our way into the future, we have to start taking leadership ourselves".

He grouped the pushback into three categories. The first objection he receives is "mobile won; the desktop is old, just do what mobile does". He dismissed that by saying that mobile has indeed won the consumer market, social media, and other areas, but "it didn't win productivity". People still do their work on computers, because "desktops are silently awesome; they have keyboards and big screens, and they can do amazing things". However, people have lost sight of that and don't really appreciate how good desktops are. "I think we should understand why they're good, and then what we can do to make them better."

The second objection he hears is that there are only so many ways that the WIMP model can work. "Just stop trying to fix it; it's done." He disagreed with that as well, and thought that there was more to be done. The final, particularly strong, objection from the tech community is "don't touch my stuff". People get angry when they have worked hard to get their desktop environment just as they like it and something changes to disrupt that. "And I get that. As I said before, I don't want to change everything." But the world is changing, "and we need to grow our way gently into some new things."

What is UX?

Thinking about where to go next with desktop design gets to the question "what is UX?" He said that term was misunderstood and that people, especially manager types, "they think it's just pixels, but UX is so much more than pixels". It helps to think of UX as having layers, he said. There is style, which consists of white space, iconography, color schemes, and yes, pixels. But there is also structure, he said, which is how the user moves through the application, the navigation model.

Strategy is another part of UX; understanding who the target user is, and determining what they want. Deciding what is important, and what is not; what will the development team prioritize and what will it ignore? "The fastest way a UX designer can save your team time is to help you say no."

There is also a layer he called "stuff": the lower-level limitations of the underlying technology that a platform has which influence UX. For example, he said, if an application is being created for DOS, "you're not going to write a nice Macintosh application. The technology dictates what you can do". The desktop has been evolving for 40 years and has "historical cruft" that carries expected standards.

We just have a bunch of stuff that we just accepted. And I think if we're going to fix the desktop, we have to understand this lower-level limitation, and how do we want to fix that? We just accept that mobile and desktop has stuff today, and we just don't think about fixing it.

People forget, he said, that the original Macintosh screen was "a whopping 342 pixels high". Naturally, windows overlapped a lot. Since then, "we just assumed that Windows have to overlap". But many people have "giant, giant screens", and the existing window-manager model does not work so well for those devices. "I can understand why people use tiled window systems and so forth, because this existing model just does not work very well."

Understanding the future

Early in the talk, he had referenced a saying by Alan Kay, who had led design of the first WIMP interface at Xerox PARC: "Perspective is worth 80 IQ points." Jenson now circled back to Kay: "Who, as you can tell, I really like a lot. [...] He talks about three steps to understand stuff". The first step, he said, was to think about the present, "what is happening right now?" The second is "don't forget the past, know what work has happened before", and the final step is to ensure that "your questions are really clear". Too many people rush to a solution, he said, but they should be rushing to questions. If the questions are clear, then the answers will be better.

He did not want to make the talk about AI, he said, but he had to address it. "I have to talk about AI, and it pisses me off because there's so many cool things we could be talking about, and AI just sucks up all the oxygen, and it's all you can talk about". But, he conceded, there are many things happening with AI on the desktop, albeit in a weird way.

He explained some of the current efforts to integrate AI with the desktop as "trying to sneak AI in" while keeping the UI exactly the same. Other efforts try to use AI to understand what is on the screen and use chatbots to interact with the interface, "which I think is kind of missing the point here". That is, until last summer when Anthropic introduced Claude Code. "It completely changed things, because was looking down into your filesystem" and drew context from the content of a user's files. That allowed it to do more interesting things and interact with the system.

After mentioning Claude, he paused to say he was only speaking about frontier models because everyone else is discussing them. "I have a lot of personal problems with the frontier models. They are ethical and environmental disasters. I am not very excited by them". He said he was excited by Apertus, which is billed as a fully open, responsible model for sovereign AI created by the Swiss AI Initiative. "I do think it's possible to talk about ethically trained small language models running locally, and you don't have to sell your soul to the devil."

The curse of direct manipulation

The key point he wanted to make was not about generative AI uses, but about how giving it access to the filesystem improved its usability. It now had context and could work with the user's data, but it was working at the filesystem level and not using the desktop UX.

He talked about the desktop building blocks, basically the familiar WIMP model plus the desktop clipboard, as the way that users move data around. Expert users can move data around quickly, he said, but there's a problem: the desktop is stateless. He called this the curse of direct manipulation; there is no working memory to the desktop. "If you copy a few too many things to the clipboard, oh sorry, it's gone".

Jenson theorized that the reason there are so many desktop environments, window managers, and Wayland compositors for Linux—as well as alternative clipboard managers—is because the desktop isn't quite working right for users. He thought it was really about working memory: "How do I manage my data in such a way that I can remember it across all of these things and actually use it." His perspective shifted to asking "what would we do to working memory to improve the desktop UX?"

AI may have given him the idea, but he added that he wanted to solve the desktop UX for people first. "If the AI can use it, great. I don't care. That comes later."

Remember your past

There is prior art in trying to create systems that help provide users with more context and working memory related to their data. He referenced a paper called "Lifestreams: a storage model for personal data". That paper made the case that desktop systems are "are ill-equipped to manage the electronic information and events of the typical computer user", and introduced the Lifestreams idea as a metaphor for dynamically organizing a user's computer workspace.

That paper influenced the ill-fated WinFS project from Microsoft, which was an attempt to merge data storage and management based on relational database systems. It was demonstrated in 2003 and scheduled to ship sometime later, but ultimately the project was shelved in 2006. On the free-software side of the house, there was the semantic desktop project NEPOMUK, which was a research project funded by the European Union.

A version of NEPOMUK was included in KDE 4, with the idea was that it would allow applications "to use information from all over the desktop, the web, other devices, and combine it into one coherent interface". It was later removed and replaced with the Baloo file-indexing and search framework for the Plasma desktop, which has some overlap with NEPOMUK's functionality but with a reduced scope of features.

Jenson said that he is concerned that people see the failure of those projects as proof that the ideas were wrong. He argued that is not the case, "I would say that it is the hardware and systems at the time let the vision down. I think it's time to rethink these projects" in light of newer hardware and better systems.

Prototypes

Having visited the present and the past, as Kay recommended, he had come up with a few questions that he thought worth exploring related to desktop UX. The first was "what would happen if we only designed for large monitors?" What would it unlock if there were desktop designs that ignored laptops and only focused on widescreen monitors? Another question he had was how could the desktop capture a user's intent over time?

Those questions led to the prototypes that he said he was a little nervous to show the audience "because technical people love to find mistakes". The demos are about 29 minutes into the video of Jenson's talk. His slides have not yet been published but he told me at the event that they would be at some point.

The first demo was to show how a desktop might make better use of a widescreen display. He noted that the center of a widescreen monitor is good for working with an application, but it becomes more difficult to work on the sides of the monitor. "It's good for peripheral vision, but not good for working".

He demonstrated a desktop layout, a screenshot of which is below, that would put the focus on the window or windows in the middle of the monitor. He had included a grid in the background that tapers off from the middle of the screen to simulate a widescreen monitor. The idea was that a widescreen-first desktop would emphasize information in the middle of the screen, and then use an Exposé-like tiling model to arrange the rest of the desktop's windows. This would make the windows that were not in use easier to interact with, he thought, and be a better model than virtual desktops for managing lots of windows. "I'm not against virtual desktops. Virtual desktops are used by very organized and intelligent people. I know my audience." However, he said, most people can't deal with virtual desktops.

He also demonstrated dragging a music-player window all the way to one side of the screen, which he called "the stash area". As it moved to the edge, it transformed into a widget with just a play button instead of showing the full window. He thought that it would be possible to do the things he was demonstrating with Wayland as it is today.

Jenson put up another demonstration of an improved clipboard model that copied ideas from the Obsidian editor's Canvas feature. Canvas allows users to drag and drop images, text, and files to create a visual layout of information. A user could create a document and drag information from a web browser into the document, drop a file in from another source, "the idea here is that this is now effectively a collection of stuff that I have gathered for this document. And if I close it and then come back tomorrow, it's all still there". He added that a local AI would be able to come in and organize the information a user had gathered, "oh, look, you've got a bunch of hotels, let me organize them for you".

The final idea he discussed was a way of gathering "privacy-preserving data" to help give users a better visualization of things like web-browsing history. A web browser will only give the user a view of their browsing history that "is not very useful" he said, so he tried to gather data "not using AI, just using simple math" that would use attention signals—such as how long the user was on a web page—to tell a story of where they spent their time on the desktop. "I basically came up with this spatial associative episodic memory prompt" to organize data in a helpful, interesting way. He thought that working memory was a good way to explore new ideas for desktop UX.

So the goal with this talk is to say, let's start to take this apart. And I really hope that my prototypes cause you guys to come to me and say, We forgot about this, and let's talk about that. [...] So I just want us to try, because no one else is going to try, and I think someone's got to start.

There was time for a single question. An audience member asked how Jenson's model would protect against all of the privacy concerns that Microsoft faced with Windows Recall. "How are we going to make sure that this history remains only accessible by the user and cannot be hacked in like it could happen with Windows Recall?"

Jenson answered that his idea was to gather telemetry data, "not interesting information", which would significantly reduce the attractiveness of the data to would-be attackers. He said he did not want to underplay the issue, though, and wanted to build prototypes to see if the idea was good first, and then explore ways to encrypt or protect the data. He agreed that even this data could be valuable information. He added that the biggest problem with Windows Recall was "how stupidly they protected it" and he was sure others could do a lot better job.

[I would like to thank the Linux Foundation, LWN's travel sponsor, for its assistance with my trip to Graz, Austria for Akademy 2026.]

Comments (88 posted)

Critical WordPress RCE vulnerability announced

A critical vulnerability has been discovered in WordPress's get_page_template() function for page-template resolution that could allow remote-code execution (RCE) by an unauthenticated attacker, in some limited circumstances. The project has provided an update for the most recent branch of WordPress, as well as backports of the fix for branches back to 4.7. See the vulnerability report for the conditions required for an RCE attack to be successful.

The vulnerability also affects the ClassicPress fork of WordPress, though a security update has not been provided for that project yet. LWN covered ClassicPress in 2024. Users of either content-management system should update soon.

Comments (1 posted)

Critical security vulnerabilities in the Radicle network protocol

The Radicle peer-to-peer code-collaboration project has disclosed two critical vulnerabilities in the network protocol used by Radicle nodes. The first flaw is that the network protocol used by Radicle "does not give the confidentiality it was expected to give", which allows anyone who can observe the network between two nodes to read the data exchanged. The second is that peer authentication is broken and allows impersonation, so an attacker can spoof their Node ID and read private repositories they should not be able to read.

In practice, the two flaws are most useful when they can be exploited together: an attacker on the path sees the Node IDs at both ends of a connection, and both are normally on the allow-list. That attacker can read whatever is exchanged while they watch, and can then use a Node ID they saw to fetch the whole repository on demand. The realistic threat is anyone on the path between your node and node it syncs with, and no setting or allow-list protects against them.

We are publishing this before the security update is available. You can act on it today, and no fix we release later can undo an exposure that has already happened.

See the post for workarounds that can be used today; a major update that will be backward-incompatible is underway.

Comments (7 posted)

Kernel release status

The current development kernel is 7.3-rc4, released on September 20. It is, unsurprisingly at this point, large; Linus said: "We all know the drill by now: 'it's big, yadda yadda'".

This release has seen 17,056 non-merge changesets from 2,720 developers, 649 of whom were first-time kernel contributors. The release history looks like:

RC	Date	Commits
v7.3-rc1	2026-08-30	16267	16267
v7.3-rc2	2026-09-06	681	681
v7.3-rc3	2026-09-13	733	733
v7.3-rc4	2026-09-20	598	598

See the LWN KSDB v7.3 page for a lot more details.

Stable updates: the large 7.2.7, 6.18.53, and 6.12.111 updates were released on September 21.

Comments (none posted)

Systemtap 5.6 released

Version 5.6 of the Systemtap tracing tool has been released.

BPF LSM hooks and XDP packet-processing probes for the --bpf runtime, BTF-based kernel.tracepoint probes, statement execution tracing, a new @enumname() operator, richer runtime error context, dyninst hardware watchpoints, modern systemd service templates, and broad Linux 7.2 runtime/tapset compatibility work. Multithreaded speedups throughout.

Full Story (comments: none)

GNOME 51 released

Version 51 of the GNOME desktop environment has been released. The list of changes includes a number of performance improvements, offline data and better transit information in the Maps application, a new interface for the file previewer, and more.

Comments (41 posted)

Igalia celebrates "Twenty-Five Years Upstream"

The open-source consulting firm Igalia has put out an announcement celebrating 25 years of working on upstream FOSS projects for its clients. The list of projects the company has worked on is rather eye-opening: WebKit, mobile-browser rendering (on Maemo, Moblin, MeeGo, and Tizen), the Linux kernel (CPU and GPU scheduling), 3D graphics drivers, the Orca screen reader, GStreamer, and lots more. Beyond that, the company, which is a worker-owned cooperative, does its work in ways that benefit the community as well as its clients:

None of this is charity. Igalia is a consultancy, and most of the work above was paid for by someone with a product to ship: a device maker who needs the web to run well on their hardware, a platform that needs a feature its users keep asking for, a company whose roadmap depends on something deep in the stack working better than it does today. What they get from us is not a patch to carry forever. We do the work upstream, in the project itself, so it arrives in the next release and keeps working long after the contract ends. Our customers ship products built on code that nobody has to maintain alone, and everyone else gets the same code. That has been the arrangement from the start.

Comments (27 posted)

Systemd v262 released

Systemd v262 has been released. Some of the notable new features include the ability to build systemd as a single statically linked binary for small containers, support for the kernel coredump socket protocol introduced with Linux 6.17, addition of OpenSSL 4 support, and many other changes. See the release notes for a full list of changes.

Comments (1 posted)

Development quotes of the week

In a software context, I think part of the Star Trek utopia we should be striving for (and a sign we've achieved it) is putting a wooden stake through the heart of the word "consumer."

— Matilda Horger

Let's say you're working on a patch, and you want to post it to the list already. There's one more change needed, to fix a design issue. It'd take ~10 minutes of your time, but it's mostly mechanical, anyone can do it. So you post the patch without it, to get the feedback earlier.

This unfortunately has two likely consequences. Some reviewers will point out that one change - which you already planned to do, so it's not very useful feedback. And other reviewers will end up doing the change themselves, and now you've wasted 10 minutes of each reviewer's time.

If you can save time for other people, do it. It may be just 10 minutes of your time, but with multiple people it quickly adds up and it can be 1 hour of "community time."

— Tomas Vondra

Comments (6 posted)

CFP Deadlines: September 24, 2026 to November 23, 2026

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

Deadline	Event Dates	Event	Location
September 28	November 3 November 4	Open vSwitch and OVN 2026 Fall Conference	Heilbronn, Germany
October 1	November 7 November 8	OpenFest 2026	Sofia, Bulgaria
October 1	November 12 November 13	Ubuntu Summit 26.10	Online
October 4	November 7 November 8	OpenALT	Brno, Czechia
October 9	November 20 November 21	OLF Conference	Columbus, Ohio, US
November 1	April 1 April 4	Southern California Linux Expo	Pasadena, CA, US

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

Events: September 24, 2026 to November 23, 2026

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

Date(s)	Event	Location
September 19 September 24	Akademy 2026	Graz, Austria
September 22 September 24	Reproducible Builds Summit	Gothenburg, Sweden
September 25 September 27	PostmarketOS and Alpine Linux Conference	Aachen, Germany
September 28 September 30	X.Org Developers Conference	Toronto, Canada
September 28 October 1	Alpine Linux Persistence and Storage Summit	Lizumerhütte, Tyrol, Austria
September 30 October 1	All Systems Go! 2026	Berlin, Germany
October 1 October 2	embedded Linux for Safe and Secure Applications	Göttingen, Germany
October 1	Open Tech Day | Software-defined Storage	Nuremberg, Germany
October 2 October 4	GNU Tools Cauldron	Prague, Czechia
October 3 October 4	openSUSE.Asia Summit 2026	Yogyakarta, Indonesia
October 3 October 4	Linux Days 2026	Prague, Czechia
October 5 October 7	Linux Plumbers Conference 2026	Prague, Czechia
October 6	Yocto Project Developer Day 2026	Prague, Czechia
October 6	Real-time Linux User Forum	Prague, Czechia
October 7 October 9	Embedded Linux Conference Europe	Prague, Czech Republic
October 7 October 9	Open Source Summit Europe	Prague, Czech Republic
October 8	Linux Security Summit Europe	Prague, Czechia
October 10 October 11	GStreamer Conference 2026	Prague, Czech Republic
October 13 October 15	OpenSSL Conference	Prague, Czech Republic
October 14 October 17	PyCon South Africa	Cape Town, South Africa
October 16 October 18	VideoLAN Developers' Days	Rome, Italy
October 18 October 20	All Things Open	Raleigh, NC, US
October 20 October 23	The Matrix Conference	Malmö, Sweden
October 20 October 23	PostgreSQL Conference Europe	Valencia, Spain
October 30 November 1	Qubes OS Summit	Berlin, Germany
November 3 November 4	Open vSwitch and OVN 2026 Fall Conference	Heilbronn, Germany
November 6 November 7	Texas Linux Festival	Austin, TX, US
November 7 November 8	OpenFest 2026	Sofia, Bulgaria
November 7 November 8	OpenALT	Brno, Czechia
November 12 November 13	Ubuntu Summit 26.10	Online
November 14 November 15	Capitole du Libre 2026	Toulouse, France
November 17 November 19	Open Source Monitoring Conference	Nuremberg, Germany
November 20 November 21	OLF Conference	Columbus, Ohio, US

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

Alert summary September 17, 2026 to September 23, 2026

Dist.	ID	Release	Package	Date
AlmaLinux	ALSA-2026:67530	10	.NET 10.0	2026-09-18
AlmaLinux	ALSA-2026:68676	8	.NET 10.0	2026-09-18
AlmaLinux	ALSA-2026:67613	9	.NET 10.0	2026-09-16
AlmaLinux	ALSA-2026:67525	10	.NET 8.0	2026-09-16
AlmaLinux	ALSA-2026:68316	8	.NET 8.0	2026-09-17
AlmaLinux	ALSA-2026:67524	9	.NET 8.0	2026-09-16
AlmaLinux	ALSA-2026:67528	10	.NET 9.0	2026-09-16
AlmaLinux	ALSA-2026:68233	8	.NET 9.0	2026-09-17
AlmaLinux	ALSA-2026:67614	9	.NET 9.0	2026-09-16
AlmaLinux	ALSA-2026:69113	8	apr-util	2026-09-21
AlmaLinux	ALSA-2026:67886	10	coreutils	2026-09-17
AlmaLinux	ALSA-2026:69964	8	coreutils	2026-09-22
AlmaLinux	ALSA-2026:69277	8	corosync	2026-09-22
AlmaLinux	ALSA-2026:67873	9	corosync	2026-09-17
AlmaLinux	ALSA-2026:69125	10	curl	2026-09-22
AlmaLinux	ALSA-2026:69126	9	curl	2026-09-22
AlmaLinux	ALSA-2026:67585	9	firewalld	2026-09-16
AlmaLinux	ALSA-2026:69387	8	freerdp	2026-09-22
AlmaLinux	ALSA-2026:69100	9	gstreamer1-plugins-base	2026-09-22
AlmaLinux	ALSA-2026:66355	10	kernel	2026-09-17
AlmaLinux	ALSA-2026:67471	10	kernel	2026-09-17
AlmaLinux	ALSA-2026:68507	10	kernel	2026-09-19
AlmaLinux	ALSA-2026:68531	8	kernel	2026-09-18
AlmaLinux	ALSA-2026:67150	9	kernel	2026-09-17
AlmaLinux	ALSA-2026:67470	9	kernel	2026-09-17
AlmaLinux	ALSA-2026:68532	8	kernel-rt	2026-09-17
AlmaLinux	ALSA-2026:69553	10	libarchive	2026-09-22
AlmaLinux	ALSA-2026:67909	10	libevent	2026-09-17
AlmaLinux	ALSA-2026:67908	8	libevent	2026-09-17
AlmaLinux	ALSA-2026:67910	9	libevent	2026-09-17
AlmaLinux	ALSA-2026:68266	8	libsoup	2026-09-17
AlmaLinux	ALSA-2026:68234	9	libsoup	2026-09-17
AlmaLinux	ALSA-2026:68235	10	libsoup3	2026-09-17
AlmaLinux	ALSA-2026:69095	8	libtiff	2026-09-21
AlmaLinux	ALSA-2026:69655	8	libxml2	2026-09-22
AlmaLinux	ALSA-2026:67979	10	microcode_ctl	2026-09-17
AlmaLinux	ALSA-2026:68011	9	microcode_ctl	2026-09-17
AlmaLinux	ALSA-2026:67283	9	nginx:1.26	2026-09-16
AlmaLinux	ALSA-2026:69609	10	openexr	2026-09-22
AlmaLinux	ALSA-2026:69129	10	openssh	2026-09-22
AlmaLinux	ALSA-2026:69266	8	openssh	2026-09-21
AlmaLinux	ALSA-2026:69130	9	openssh	2026-09-22
AlmaLinux	ALSA-2026:68787	8	perl-Net-DNS	2026-09-18
AlmaLinux	ALSA-2026:68786	9	perl-Net-DNS	2026-09-19
AlmaLinux	ALSA-2026:67280	10	postgresql18	2026-09-17
AlmaLinux	ALSA-2026:67166	10	postgresql18-postgis	2026-09-22
AlmaLinux	ALSA-2026:69876	8	postgresql:16	2026-09-22
AlmaLinux	ALSA-2026:67491	9	postgresql:16	2026-09-17
AlmaLinux	ALSA-2026:67848	9	postgresql:18	2026-09-17
AlmaLinux	ALSA-2026:67943	8	python-lxml	2026-09-17
AlmaLinux	ALSA-2026:67584	10	rsyslog	2026-09-16
AlmaLinux	ALSA-2026:69541	10	rsyslog	2026-09-22
AlmaLinux	ALSA-2026:67583	9	rsyslog	2026-09-16
AlmaLinux	ALSA-2026:69540	9	rsyslog	2026-09-22
AlmaLinux	ALSA-2026:68692	10	sudo	2026-09-19
AlmaLinux	ALSA-2026:69123	9	sudo	2026-09-22
AlmaLinux	ALSA-2026:67832	8	tesseract	2026-09-16
AlmaLinux	ALSA-2026:67831	9	tesseract	2026-09-17
AlmaLinux	ALSA-2026:69259	10	tomcat	2026-09-22
AlmaLinux	ALSA-2026:68677	8	tomcat	2026-09-18
AlmaLinux	ALSA-2026:68660	9	tomcat	2026-09-19
AlmaLinux	ALSA-2026:68651	10	tomcat9	2026-09-19
AlmaLinux	ALSA-2026:68291	10	unbound	2026-09-17
AlmaLinux	ALSA-2026:69120	8	unbound	2026-09-21
AlmaLinux	ALSA-2026:68292	9	unbound	2026-09-17
AlmaLinux	ALSA-2026:69098	9	webkit2gtk3	2026-09-22
AlmaLinux	ALSA-2026:69308	10	yggdrasil	2026-09-22
AlmaLinux	ALSA-2026:69099	10	yggdrasil-worker-package-manager	2026-09-22
Debian	DSA-6505-1	stable	bind9	2026-09-17
Debian	DLA-4790-1	LTS	chromium	2026-09-21
Debian	DSA-6506-1	stable	chromium	2026-09-17
Debian	DSA-6508-1	stable	chromium	2026-09-19
Debian	DLA-4781-1	LTS	firefox-esr	2026-09-17
Debian	DSA-6501-1	stable	firefox-esr	2026-09-16
Debian	DSA-6509-1	stable	gimp	2026-09-20
Debian	DSA-6504-1	stable	libapache2-mod-auth-openidc	2026-09-17
Debian	DLA-4789-1	LTS	libde265	2026-09-20
Debian	DLA-4786-1	LTS	libevent	2026-09-18
Debian	DLA-4788-1	LTS	linux-6.12	2026-09-19
Debian	DLA-4791-1	LTS	memcached	2026-09-23
Debian	DSA-6502-1	stable	mkvtoolnix	2026-09-16
Debian	DLA-4784-1	LTS	nginx	2026-09-17
Debian	DLA-4787-1	LTS	ruby-jwt	2026-09-19
Debian	DLA-4782-1	LTS	thunderbird	2026-09-17
Debian	DSA-6503-1	stable	thunderbird	2026-09-16
Debian	DSA-6500-1	stable	tor	2026-09-16
Debian	DSA-6507-1	stable	unbound	2026-09-19
Debian	DLA-4783-1	LTS	xz-utils	2026-09-17
Debian	DLA-4785-1	LTS	zip	2026-09-18
Fedora	FEDORA-2026-c74ff43396	F43	GitPython	2026-09-18
Fedora	FEDORA-2026-040732b5dc	F45	OpenBoard	2026-09-22
Fedora	FEDORA-2026-040732b5dc	F45	Pencil2D	2026-09-22
Fedora	FEDORA-2026-040732b5dc	F45	alsa-plugins	2026-09-22
Fedora	FEDORA-2026-040732b5dc	F45	amarok	2026-09-22
Fedora	FEDORA-2026-040732b5dc	F45	aqualung	2026-09-22
Fedora	FEDORA-2026-9949becb18	F45	asterisk	2026-09-21
Fedora	FEDORA-2026-040732b5dc	F45	atomes	2026-09-22
Fedora	FEDORA-2026-040732b5dc	F45	attract-mode	2026-09-22
Fedora	FEDORA-2026-040732b5dc	F45	audacious-plugins	2026-09-22
Fedora	FEDORA-2026-040732b5dc	F45	audacity	2026-09-22
Fedora	FEDORA-2026-040732b5dc	F45	baresip	2026-09-22
Fedora	FEDORA-2026-040732b5dc	F45	blender	2026-09-22
Fedora	FEDORA-2026-040732b5dc	F45	calibre	2026-09-22
Fedora	FEDORA-2026-040732b5dc	F45	cantata	2026-09-22
Fedora	FEDORA-2026-040732b5dc	F45	cef	2026-09-22
Fedora	FEDORA-2026-040732b5dc	F45	chromaprint	2026-09-22
Fedora	FEDORA-2026-a1a12d9b4f	F43	chromium	2026-09-19
Fedora	FEDORA-2026-441ccd8509	F44	chromium	2026-09-18
Fedora	FEDORA-2026-f910229c11	F44	chromium	2026-09-23
Fedora	FEDORA-2026-6932094a69	F45	chromium	2026-09-19
Fedora	FEDORA-2026-040732b5dc	F45	chromium	2026-09-22
Fedora	FEDORA-2026-97a7ec5786	F43	cyrus-imapd	2026-09-23
Fedora	FEDORA-2026-740bc1c6fa	F44	cyrus-imapd	2026-09-23
Fedora	FEDORA-2026-3bf3e31ef4	F45	cyrus-imapd	2026-09-23
Fedora	FEDORA-2026-040732b5dc	F45	digikam	2026-09-22
Fedora	FEDORA-2026-ad8394dc92	F44	doctl	2026-09-20
Fedora	FEDORA-2026-a205d8bdfd	F45	doctl	2026-09-22
Fedora	FEDORA-2026-04a0116777	F43	dotnet10.0	2026-09-23
Fedora	FEDORA-2026-a5c27e8727	F44	dotnet10.0	2026-09-23
Fedora	FEDORA-2026-fa6de37202	F45	dotnet10.0	2026-09-23
Fedora	FEDORA-2026-d757a4044b	F43	dotnet8.0	2026-09-23
Fedora	FEDORA-2026-0fa8c76e88	F44	dotnet8.0	2026-09-23
Fedora	FEDORA-2026-182712d480	F43	dotnet9.0	2026-09-23
Fedora	FEDORA-2026-9d80c37c0a	F44	dotnet9.0	2026-09-23
Fedora	FEDORA-2026-e8a6485109	F43	dovecot	2026-09-19
Fedora	FEDORA-2026-2e6b786570	F44	dovecot	2026-09-19
Fedora	FEDORA-2026-8b8efbd2b8	F45	dovecot	2026-09-19
Fedora	FEDORA-2026-040732b5dc	F45	dragon	2026-09-22
Fedora	FEDORA-2026-1ea9bbcb29	F43	evolution	2026-09-19
Fedora	FEDORA-2026-99a4ff5552	F44	evolution	2026-09-19
Fedora	FEDORA-2026-040732b5dc	F45	ffmpeg	2026-09-22
Fedora	FEDORA-2026-040732b5dc	F45	ffmpegthumbnailer	2026-09-22
Fedora	FEDORA-2026-040732b5dc	F45	ffmpegthumbs	2026-09-22
Fedora	FEDORA-2026-040732b5dc	F45	ffms2	2026-09-22
Fedora	FEDORA-2026-d7ba4af112	F43	firefox	2026-09-19
Fedora	FEDORA-2026-040732b5dc	F45	fooyin	2026-09-22
Fedora	FEDORA-2026-e9a6f74bd2	F45	forgejo	2026-09-19
Fedora	FEDORA-2026-75bde5d061	F43	freeciv	2026-09-19
Fedora	FEDORA-2026-3b9c14cd66	F44	freeciv	2026-09-19
Fedora	FEDORA-2026-6fe2310246	F45	freeciv	2026-09-19
Fedora	FEDORA-2026-1c8697a163	F44	freeipa	2026-09-21
Fedora	FEDORA-2026-b314830fc3	F45	freeipa	2026-09-21
Fedora	FEDORA-2026-febfd10293	F44	freeipmi	2026-09-23
Fedora	FEDORA-2026-abe39f1809	F45	freeipmi	2026-09-18
Fedora	FEDORA-2026-572a0f4178	F43	gegl04	2026-09-20
Fedora	FEDORA-2026-572a0f4178	F43	gimp	2026-09-20
Fedora	FEDORA-2026-040732b5dc	F45	glaxnimate	2026-09-22
Fedora	FEDORA-2026-d5c7f91202	F43	gnatcoll	2026-09-18
Fedora	FEDORA-2026-11f44e3c2c	F44	gnatcoll	2026-09-18
Fedora	FEDORA-2026-c8b1bb0c97	F45	gnatcoll	2026-09-18
Fedora	FEDORA-2026-040732b5dc	F45	goldendict-ng	2026-09-22
Fedora	FEDORA-2026-040732b5dc	F45	gpac	2026-09-22
Fedora	FEDORA-2026-040732b5dc	F45	gstreamer1-plugin-libav	2026-09-22
Fedora	FEDORA-2026-040732b5dc	F45	guacamole-server	2026-09-22
Fedora	FEDORA-2026-040732b5dc	F45	guvcview	2026-09-22
Fedora	FEDORA-2026-040732b5dc	F45	haruna	2026-09-22
Fedora	FEDORA-2026-040732b5dc	F45	hedgewars	2026-09-22
Fedora	FEDORA-2026-040732b5dc	F45	icecat	2026-09-22
Fedora	FEDORA-2026-040732b5dc	F45	janus	2026-09-22
Fedora	FEDORA-2026-040732b5dc	F45	k3b	2026-09-22
Fedora	FEDORA-2026-040732b5dc	F45	kdenlive	2026-09-22
Fedora	FEDORA-2026-ca91e91bf0	F44	kernel	2026-09-23
Fedora	FEDORA-2026-4c098c462e	F45	kernel	2026-09-23
Fedora	FEDORA-2026-040732b5dc	F45	kf5-kfilemetadata	2026-09-22
Fedora	FEDORA-2026-040732b5dc	F45	kf6-kfilemetadata	2026-09-22
Fedora	FEDORA-2026-040732b5dc	F45	kpipewire	2026-09-22
Fedora	FEDORA-2026-040732b5dc	F45	lazygal	2026-09-22
Fedora	FEDORA-2026-578a96e5f5	F44	lego	2026-09-22
Fedora	FEDORA-2026-9eaee019b6	F45	lego	2026-09-22
Fedora	FEDORA-2026-040732b5dc	F45	libcamera-apps	2026-09-22
Fedora	FEDORA-2026-ba6dbf405c	F44	libheif	2026-09-20
Fedora	FEDORA-2026-73d31ad4c6	F45	libheif	2026-09-19
Fedora	FEDORA-2026-040732b5dc	F45	libheif	2026-09-22
Fedora	FEDORA-2026-040732b5dc	F45	libopenshot	2026-09-22
Fedora	FEDORA-2026-040732b5dc	F45	libopenshot-audio	2026-09-22
Fedora	FEDORA-2026-040732b5dc	F45	libvncserver	2026-09-22
Fedora	FEDORA-2026-743387fdbe	F45	libxmp	2026-09-23
Fedora	FEDORA-2026-040732b5dc	F45	localsearch	2026-09-22
Fedora	FEDORA-2026-040732b5dc	F45	mat2	2026-09-22
Fedora	FEDORA-2026-040732b5dc	F45	minidlna	2026-09-22
Fedora	FEDORA-2026-040732b5dc	F45	mivisionx	2026-09-22
Fedora	FEDORA-2026-040732b5dc	F45	mixxx	2026-09-22
Fedora	FEDORA-2026-040732b5dc	F45	mlt	2026-09-22
Fedora	FEDORA-2026-040732b5dc	F45	monado	2026-09-22
Fedora	FEDORA-2026-040732b5dc	F45	mpd	2026-09-22
Fedora	FEDORA-2026-040732b5dc	F45	mpv	2026-09-22
Fedora	FEDORA-2026-040732b5dc	F45	mpv-mpris	2026-09-22
Fedora	FEDORA-2026-040732b5dc	F45	neatvnc	2026-09-22
Fedora	FEDORA-2026-67f78e732b	F43	nodejs-undici	2026-09-18
Fedora	FEDORA-2026-90bb0fcd50	F44	nodejs-undici	2026-09-18
Fedora	FEDORA-2026-25a6102ac6	F45	nodejs-undici	2026-09-18
Fedora	FEDORA-2026-040732b5dc	F45	notcurses	2026-09-22
Fedora	FEDORA-2026-d7ba4af112	F43	nss	2026-09-19
Fedora	FEDORA-2026-9b9d903069	F45	nss	2026-09-21
Fedora	FEDORA-2026-040732b5dc	F45	nv-codec-headers13.0	2026-09-22
Fedora	FEDORA-2026-040732b5dc	F45	obs-studio	2026-09-22
Fedora	FEDORA-2026-040732b5dc	F45	obs-studio-plugin-droidcam	2026-09-22
Fedora	FEDORA-2026-040732b5dc	F45	obs-studio-plugin-pwvideo	2026-09-22
Fedora	FEDORA-2026-040732b5dc	F45	obs-studio-plugin-vaapi	2026-09-22
Fedora	FEDORA-2026-040732b5dc	F45	obs-studio-plugin-vkcapture	2026-09-22
Fedora	FEDORA-2026-040732b5dc	F45	obs-studio-plugin-webkitgtk	2026-09-22
Fedora	FEDORA-2026-040732b5dc	F45	olive	2026-09-22
Fedora	FEDORA-2026-8cbd9e2c8b	F43	open62541	2026-09-17
Fedora	FEDORA-2026-6d919ea521	F44	open62541	2026-09-17
Fedora	FEDORA-2026-3fd073ad5b	F45	open62541	2026-09-17
Fedora	FEDORA-2026-040732b5dc	F45	openal-soft	2026-09-22
Fedora	FEDORA-2026-040732b5dc	F45	opencv	2026-09-22
Fedora	FEDORA-2026-040732b5dc	F45	openmw	2026-09-22
Fedora	FEDORA-2026-38b019a0f0	F43	opkssh	2026-09-21
Fedora	FEDORA-2026-f7b73f165d	F44	opkssh	2026-09-21
Fedora	FEDORA-2026-559bbb39f5	F45	opkssh	2026-09-21
Fedora	FEDORA-2026-040732b5dc	F45	opustags	2026-09-22
Fedora	FEDORA-2026-040732b5dc	F45	os-autoinst	2026-09-22
Fedora	FEDORA-2026-6ac486039c	F44	parted	2026-09-18
Fedora	FEDORA-2026-6bfd19245e	F45	parted	2026-09-21
Fedora	FEDORA-2026-23dc582dae	F44	patool	2026-09-22
Fedora	FEDORA-2026-3a35235bd6	F45	patool	2026-09-22
Fedora	FEDORA-2026-167a356523	F43	perl-HTML-FormHandler	2026-09-22
Fedora	FEDORA-2026-21850d7df0	F44	perl-HTML-FormHandler	2026-09-22
Fedora	FEDORA-2026-406a152d49	F45	perl-HTML-FormHandler	2026-09-22
Fedora	FEDORA-2026-48a4531e02	F43	perl-Net-DNS	2026-09-23
Fedora	FEDORA-2026-57f107ed83	F44	perl-Net-DNS	2026-09-23
Fedora	FEDORA-2026-caf49a7828	F43	php-pecl-mongodb2	2026-09-17
Fedora	FEDORA-2026-358d3ccdfe	F44	php-pecl-mongodb2	2026-09-17
Fedora	FEDORA-2026-040732b5dc	F45	pianobar	2026-09-22
Fedora	FEDORA-2026-58a319c686	F44	postgresql16-anonymizer	2026-09-23
Fedora	FEDORA-2026-bc7408de42	F45	postgresql16-anonymizer	2026-09-23
Fedora	FEDORA-2026-8590121cf7	F45	prometheus-podman-exporter	2026-09-22
Fedora	FEDORA-2026-040732b5dc	F45	python-audioread	2026-09-22
Fedora	FEDORA-2026-6b28b4e483	F43	python-django5	2026-09-18
Fedora	FEDORA-2026-301e6e2983	F44	python-django5	2026-09-18
Fedora	FEDORA-2026-950089270f	F45	python-django5	2026-09-18
Fedora	FEDORA-2026-6613125727	F44	python-django6	2026-09-17
Fedora	FEDORA-2026-522a9411e7	F45	python-django6	2026-09-17
Fedora	FEDORA-2026-8caad572b0	F44	python-jwcrypto	2026-09-17
Fedora	FEDORA-2026-6d094c5360	F45	python-jwcrypto	2026-09-17
Fedora	FEDORA-2026-040732b5dc	F45	python-torchaudio	2026-09-22
Fedora	FEDORA-2026-040732b5dc	F45	python-torchvision	2026-09-22
Fedora	FEDORA-2026-040732b5dc	F45	qmmp	2026-09-22
Fedora	FEDORA-2026-040732b5dc	F45	qmmp-plugin-pack	2026-09-22
Fedora	FEDORA-2026-040732b5dc	F45	qmplay2	2026-09-22
Fedora	FEDORA-2026-040732b5dc	F45	qt5-qtwebengine	2026-09-22
Fedora	FEDORA-2026-040732b5dc	F45	qt6-qtmultimedia	2026-09-22
Fedora	FEDORA-2026-040732b5dc	F45	qt6-qtwebengine	2026-09-22
Fedora	FEDORA-2026-040732b5dc	F45	qtox	2026-09-22
Fedora	FEDORA-2026-040732b5dc	F45	retroarch	2026-09-22
Fedora	FEDORA-2026-040732b5dc	F45	rocdecode	2026-09-22
Fedora	FEDORA-2026-040732b5dc	F45	rocdecode7.2	2026-09-22
Fedora	FEDORA-2026-821349f438	F43	roundcubemail	2026-09-17
Fedora	FEDORA-2026-38c637be37	F44	roundcubemail	2026-09-17
Fedora	FEDORA-2026-6ab831c1c5	F45	roundcubemail	2026-09-17
Fedora	FEDORA-2026-040732b5dc	F45	rsgain	2026-09-22
Fedora	FEDORA-2026-b3bccd6a30	F43	ruby	2026-09-19
Fedora	FEDORA-2026-fe1549bec3	F43	sblim-cmpi-base	2026-09-18
Fedora	FEDORA-2026-7510dd645d	F44	sblim-cmpi-base	2026-09-18
Fedora	FEDORA-2026-700fe12346	F45	sblim-cmpi-base	2026-09-18
Fedora	FEDORA-2026-040732b5dc	F45	siril	2026-09-22
Fedora	FEDORA-2026-040732b5dc	F45	squeezelite	2026-09-22
Fedora	FEDORA-2026-0cae436fa5	F43	stb	2026-09-19
Fedora	FEDORA-2026-2a592f622a	F44	stb	2026-09-19
Fedora	FEDORA-2026-63e7be05c3	F45	stb	2026-09-19
Fedora	FEDORA-2026-040732b5dc	F45	swayimg	2026-09-22
Fedora	FEDORA-2026-379e77483b	F44	thunderbird	2026-09-21
Fedora	FEDORA-2026-aa0e0deed1	F45	thunderbird	2026-09-20
Fedora	FEDORA-2026-040732b5dc	F45	tigervnc	2026-09-22
Fedora	FEDORA-2026-040732b5dc	F45	timg	2026-09-22
Fedora	FEDORA-2026-3baacede89	F45	unbound	2026-09-21
Fedora	FEDORA-2026-040732b5dc	F45	unpaper	2026-09-22
Fedora	FEDORA-2026-040732b5dc	F45	vlc	2026-09-22
Fedora	FEDORA-2026-040732b5dc	F45	vtk	2026-09-22
Fedora	FEDORA-2026-040732b5dc	F45	waypipe	2026-09-22
Fedora	FEDORA-2026-21b582110b	F45	webkitgtk	2026-09-21
Fedora	FEDORA-2026-040732b5dc	F45	wf-recorder	2026-09-22
Fedora	FEDORA-2026-040732b5dc	F45	wivrn	2026-09-22
Fedora	FEDORA-2026-040732b5dc	F45	wxsvg	2026-09-22
Fedora	FEDORA-2026-040732b5dc	F45	xine-lib	2026-09-22
Fedora	FEDORA-2026-040732b5dc	F45	xmms2	2026-09-22
Fedora	FEDORA-2026-040732b5dc	F45	xpra	2026-09-22
Fedora	FEDORA-2026-040732b5dc	F45	xscreensaver	2026-09-22
Fedora	FEDORA-2026-040732b5dc	F45	yle-dl	2026-09-22
Fedora	FEDORA-2026-855d5949d1	F44	znc	2026-09-22
Fedora	FEDORA-2026-3135766c09	F45	znc	2026-09-22
Fedora	FEDORA-2026-855d5949d1	F44	znc-clientbuffer	2026-09-22
Fedora	FEDORA-2026-3135766c09	F45	znc-clientbuffer	2026-09-22
Mageia	MGASA-2026-0410	10, 9	aom	2026-09-16
Mageia	MGASA-2026-0422	10	bind	2026-09-20
Mageia	MGASA-2026-0408	10, 9	cockpit	2026-09-16
Mageia	MGASA-2026-0435	10, 9	cpio	2026-09-23
Mageia	MGASA-2026-0434	10, 9	diffutils	2026-09-23
Mageia	MGASA-2026-0427	10, 9	gawk	2026-09-20
Mageia	MGASA-2026-0417	10, 9	gdk-pixbuf2.0	2026-09-18
Mageia	MGASA-2026-0415	10, 9	graphicsmagick	2026-09-18
Mageia	MGASA-2026-0418	10, 9	gstreamer1.0-plugins-base	2026-09-19
Mageia	MGASA-2026-0414	10	imagemagick	2026-09-17
Mageia	MGASA-2026-0420	10	libde265	2026-09-20
Mageia	MGASA-2026-0412	10, 9	libgd	2026-09-16
Mageia	MGASA-2026-0416	10, 9	libpcap	2026-09-18
Mageia	MGASA-2026-0425	10, 9	libssh	2026-09-20
Mageia	MGASA-2026-0428	10	mpg123	2026-09-20
Mageia	MGASA-2026-0433	10, 9	nmap	2026-09-21
Mageia	MGASA-2026-0424	10, 9	ntfs-3g	2026-09-20
Mageia	MGASA-2026-0430	10, 9	ntpsec	2026-09-20
Mageia	MGASA-2026-0411	10, 9	packagekit	2026-09-16
Mageia	MGASA-2026-0423	10	patch	2026-09-20
Mageia	MGASA-2026-0431	10, 9	pcre2	2026-09-21
Mageia	MGASA-2026-0437	10, 9	perl-Dancer2	2026-09-23
Mageia	MGASA-2026-0426	10, 9	perl-YAML	2026-09-20
Mageia	MGASA-2026-0429	10, 9	postfix	2026-09-20
Mageia	MGASA-2026-0421	10, 9	python-configargparse	2026-09-20
Mageia	MGASA-2026-0409	10, 9	python-h2	2026-09-16
Mageia	MGASA-2026-0419	10, 9	python-httplib2	2026-09-20
Mageia	MGASA-2026-0413	10	python-starlette	2026-09-17
Mageia	MGASA-2026-0436	10, 9	rest	2026-09-23
Mageia	MGASA-2026-0432	10, 9	vim	2026-09-21
Oracle	ELSA-2026-67530	OL10	.NET 10.0	2026-09-17
Oracle	ELSA-2026-68676	OL8	.NET 10.0	2026-09-21
Oracle	ELSA-2026-67613	OL9	.NET 10.0	2026-09-17
Oracle	ELSA-2026-67525	OL10	.NET 8.0	2026-09-17
Oracle	ELSA-2026-68316	OL8	.NET 8.0	2026-09-18
Oracle	ELSA-2026-67524	OL9	.NET 8.0	2026-09-17
Oracle	ELSA-2026-67528	OL10	.NET 9.0	2026-09-17
Oracle	ELSA-2026-68233	OL8	.NET 9.0	2026-09-18
Oracle	ELSA-2026-67614	OL9	.NET 9.0	2026-09-17
Oracle	ELSA-2026-55758	OL7	389-ds-base	2026-09-22
Oracle	ELSA-2026-67886	OL10	coreutils	2026-09-17
Oracle	ELSA-2026-67873	OL9	corosync	2026-09-17
Oracle	ELSA-2026-69126	OL9	curl	2026-09-22
Oracle	ELSA-2026-54248	OL7	firefox	2026-09-22
Oracle	ELSA-2026-68549	OL8	firefox	2026-09-18
Oracle	ELSA-2026-67585	OL9	firewalld	2026-09-17
Oracle	ELSA-2026-67139-0	OL10	image-builder	2026-09-21
Oracle	ELSA-2026-67138-0	OL9	image-builder	2026-09-21
Oracle	ELSA-2026-500328		kernel	2026-09-18
Oracle	ELSA-2026-65334-0	OL10	kernel	2026-09-17
Oracle	ELSA-2026-67471-0	OL10	kernel	2026-09-17
Oracle	ELSA-2026-68507	OL10	kernel	2026-09-21
Oracle	ELSA-2026-500330	OL7	kernel	2026-09-18
Oracle	ELSA-2026-67468-0	OL8	kernel	2026-09-17
Oracle	ELSA-2026-500329	OL8	kernel	2026-09-18
Oracle	ELSA-2026-500330	OL8	kernel	2026-09-18
Oracle	ELSA-2026-500330	OL8	kernel	2026-09-18
Oracle	ELSA-2026-68531	OL8	kernel	2026-09-21
Oracle	ELSA-2026-67470-0	OL9	kernel	2026-09-17
Oracle	ELSA-2026-500328	OL9	kernel	2026-09-18
Oracle	ELSA-2026-500329	OL9	kernel	2026-09-18
Oracle	ELSA-2026-500329	OL9	kernel	2026-09-18
Oracle	ELSA-2026-68570	OL9	kernel	2026-09-21
Oracle	ELSA-2026-67909	OL10	libevent	2026-09-17
Oracle	ELSA-2026-67908	OL8	libevent	2026-09-21
Oracle	ELSA-2026-67910	OL9	libevent	2026-09-18
Oracle	ELSA-2026-68266	OL8	libsoup	2026-09-18
Oracle	ELSA-2026-68234	OL9	libsoup	2026-09-17
Oracle	ELSA-2026-68235	OL10	libsoup3	2026-09-18
Oracle	ELSA-2026-65147-0	OL8	microcode_ctl	2026-09-17
Oracle	ELSA-2026-67315-0	OL8	nginx:1.24	2026-09-17
Oracle	ELSA-2026-67308-0	OL9	nginx:1.24	2026-09-17
Oracle	ELSA-2026-27746	OL10	openssl-fips-provider	2026-09-22
Oracle	ELSA-2026-68787	OL8	perl-Net-DNS	2026-09-21
Oracle	ELSA-2026-68786	OL9	perl-Net-DNS	2026-09-21
Oracle	ELSA-2026-67162-0	OL8	perl	2026-09-17
Oracle	ELSA-2026-67278-0	OL8	perl:5.32	2026-09-17
Oracle	ELSA-2026-67491	OL9	postgresql:16	2026-09-17
Oracle	ELSA-2026-67848	OL9	postgresql:18	2026-09-17
Oracle	ELSA-2026-67943	OL8	python-lxml	2026-09-21
Oracle	ELSA-2026-64824-0	OL9	redis	2026-09-17
Oracle	ELSA-2026-67463-0	OL10	rsync	2026-09-17
Oracle	ELSA-2026-67462-0	OL9	rsync	2026-09-17
Oracle	ELSA-2026-67584	OL10	rsyslog	2026-09-17
Oracle	ELSA-2026-67583	OL9	rsyslog	2026-09-17
Oracle	ELSA-2026-68692	OL10	sudo	2026-09-21
Oracle	ELSA-2026-69123	OL9	sudo	2026-09-22
Oracle	ELSA-2026-67830	OL10	tesseract	2026-09-17
Oracle	ELSA-2026-67832	OL8	tesseract	2026-09-17
Oracle	ELSA-2026-67831	OL9	tesseract	2026-09-17
Oracle	ELSA-2026-69259	OL10	tomcat	2026-09-22
Oracle	ELSA-2026-68677	OL8	tomcat	2026-09-21
Oracle	ELSA-2026-68660	OL9	tomcat	2026-09-21
Oracle	ELSA-2026-68651	OL10	tomcat9	2026-09-21
Oracle	ELSA-2026-68291	OL10	unbound	2026-09-18
Oracle	ELSA-2026-68292	OL9	unbound	2026-09-17
Oracle	ELSA-2026-69098	OL9	webkit2gtk3	2026-09-22
Oracle	ELSA-2026-69308	OL10	yggdrasil	2026-09-22
Oracle	ELSA-2026-69099	OL10	yggdrasil-worker-package-manager	2026-09-22
Red Hat	RHSA-2026:67872-01	EL10	corosync	2026-09-17
Red Hat	RHSA-2026:67881-01	EL10.0	corosync	2026-09-17
Red Hat	RHSA-2026:68574-01	EL7	corosync	2026-09-17
Red Hat	RHSA-2026:67873-01	EL9	corosync	2026-09-17
Red Hat	RHSA-2026:67878-01	EL9.4	corosync	2026-09-17
Red Hat	RHSA-2026:67879-01	EL9.6	corosync	2026-09-17
Red Hat	RHSA-2026:67128-01	EL9.6	delve	2026-09-17
Red Hat	RHSA-2026:67287-01	EL9.6	git-lfs	2026-09-17
Red Hat	RHSA-2026:67132-01	EL9.6	grafana-pcp	2026-09-17
Red Hat	RHSA-2026:68503-01	EL8.8	gstreamer1-plugins-base	2026-09-17
Red Hat	RHSA-2026:68510-01	EL10.0	libvirt	2026-09-17
Red Hat	RHSA-2026:68514-01	EL9.2	libvirt	2026-09-17
Red Hat	RHSA-2026:68509-01	EL9.4	libvirt	2026-09-17
Red Hat	RHSA-2026:68511-01	EL9.6	libvirt	2026-09-17
Red Hat	RHSA-2026:67974-01	EL10.0	opentelemetry-collector	2026-09-23
Red Hat	RHSA-2026:68527-01	EL9.4	opentelemetry-collector	2026-09-17
Red Hat	RHSA-2026:67975-01	EL9.6	opentelemetry-collector	2026-09-23
Red Hat	RHSA-2026:69293-01	EL9	osbuild-composer	2026-09-23
Red Hat	RHSA-2026:67464-01	EL10	rhc-worker-playbook	2026-09-17
Red Hat	RHSA-2026:68711-01	EL7	vim	2026-09-18
Slackware	SSA:2026-259-01		mozilla-firefox	2026-09-16
Slackware	SSA:2026-259-02		mozilla-thunderbird	2026-09-16
Slackware	SSA:2026-261-01		stunnel	2026-09-18
Slackware	SSA:2026-264-01		util-linux	2026-09-21
SUSE	SUSE-SU-2026:4265-1	SLE12	ImageMagick	2026-09-18
SUSE	openSUSE-SU-2026:11802-1	TW	NetworkManager-applet-l2tp	2026-09-20
SUSE	SUSE-SU-2026:23726-1	SLE16.0	acl, attr	2026-09-16
SUSE	SUSE-SU-2026:23705-1	SLE16.0	acl, attr	2026-09-16
SUSE	SUSE-SU-2026:4210-1	SLE15	alloy	2026-09-16
SUSE	openSUSE-SU-2026:11803-1	TW	alloy	2026-09-20
SUSE	openSUSE-SU-2026:11783-1	TW	alsa	2026-09-17
SUSE	openSUSE-SU-2026:11828-1	TW	amazon-cloudwatch-agent	2026-09-22
SUSE	SUSE-SU-2026:4286-1	SLE12	amazon-ssm-agent	2026-09-22
SUSE	SUSE-SU-2026:23724-1	SLE16.0	ansible-core	2026-09-16
SUSE	SUSE-SU-2026:23704-1	SLE16.0	ansible-core	2026-09-16
SUSE	openSUSE-SU-2026:11829-1	TW	apko	2026-09-22
SUSE	openSUSE-SU-2026:11830-1	TW	apptainer	2026-09-22
SUSE	openSUSE-SU-2026:11831-1	TW	bazel-rules-python-source	2026-09-22
SUSE	SUSE-SU-2026:4285-1	SLE15	bind	2026-09-22
SUSE	openSUSE-SU-2026:0340-1	osB15	cadvisor	2026-09-21
SUSE	openSUSE-SU-2026:21866-1	oS16.0	chirp	2026-09-17
SUSE	openSUSE-SU-2026:21858-1	oS16.0	chromium	2026-09-17
SUSE	openSUSE-SU-2026:0342-1	osB15	chromium	2026-09-21
SUSE	SUSE-SU-2026:4237-1	SLE12	cjose	2026-09-17
SUSE	SUSE-SU-2026:4253-1	SLE15	cjose	2026-09-17
SUSE	SUSE-SU-2026:4251-1	SLE15 oS15.6	cjose	2026-09-17
SUSE	SUSE-SU-2026:4208-1	SLE15 SLE5.5 SLE-m5.5 oS15.4	clamav	2026-09-16
SUSE	SUSE-SU-2026:23727-1	SLE16.0	clamav	2026-09-16
SUSE	SUSE-SU-2026:23706-1	SLE16.0	clamav	2026-09-16
SUSE	SUSE-SU-2026:4209-1	SLE15	containerized-data-importer	2026-09-16
SUSE	openSUSE-SU-2026:0324-1	osB15	coredns	2026-09-21
SUSE	SUSE-SU-2026:4202-1	MP4.3 SLE15 oS15.3	corosync	2026-09-16
SUSE	SUSE-SU-2026:4216-1	SLE12	cups	2026-09-17
SUSE	SUSE-SU-2026:4281-1	SLE15 SLE5.3 SLE5.4 SLE5.5 SLE-m5.3 SLE-m5.4 SLE-m5.5	cups	2026-09-22
SUSE	openSUSE-SU-2026:11785-1	TW	cups	2026-09-17
SUSE	openSUSE-SU-2026:11786-1	TW	discount	2026-09-17
SUSE	SUSE-SU-2026:4212-1	SLE15 oS15.4	distribution	2026-09-16
SUSE	SUSE-SU-2026:4271-1	SLE12	dovecot22	2026-09-21
SUSE	openSUSE-SU-2026:11819-1	TW	fake-gcs-server	2026-09-21
SUSE	openSUSE-SU-2026:11794-1	TW	ffmpeg-8	2026-09-18
SUSE	SUSE-SU-2026:4247-1	SLE12	firefox	2026-09-17
SUSE	SUSE-SU-2026:4264-1	SLE15 oS15.4	firefox	2026-09-18
SUSE	SUSE-SU-2026:23784-1	SLE16.0	firefox	2026-09-21
SUSE	openSUSE-SU-2026:11826-1	TW	firefox	2026-09-22
SUSE	openSUSE-SU-2026:11796-1	TW	firefox-esr	2026-09-18
SUSE	openSUSE-SU-2026:21853-1	oS16.0	firefox	2026-09-17
SUSE	openSUSE-SU-2026:0339-1	osB15	freeciv	2026-09-21
SUSE	SUSE-SU-2026:23746-1	SLE-m6.1	freeipmi	2026-09-21
SUSE	SUSE-SU-2026:4277-1	SLE15 oS15.4	freeipmi	2026-09-22
SUSE	openSUSE-SU-2026:11797-1	TW	freeipmi	2026-09-18
SUSE	SUSE-SU-2026:23849-1	SLE-m6.2	gdb	2026-09-22
SUSE	SUSE-SU-2026:4294-1	SLE12	gdb	2026-09-23
SUSE	openSUSE-SU-2026:21861-1	oS16.0	gh	2026-09-17
SUSE	openSUSE-SU-2026:0333-1	osB15	gh	2026-09-21
SUSE	SUSE-SU-2026:23830-1	SLE-m6.0	glibc	2026-09-22
SUSE	SUSE-SU-2026:23738-1	SLE-m6.1	glibc	2026-09-21
SUSE	SUSE-SU-2026:4204-1	SLE12	glibc	2026-09-16
SUSE	SUSE-SU-2026:4250-1	SLE15 oS15.6	glibc	2026-09-17
SUSE	openSUSE-SU-2026:11787-1	TW	glibc	2026-09-17
SUSE	SUSE-SU-2026:4206-1	MP4.3 SLE15	google-cloud-sap-agent	2026-09-16
SUSE	SUSE-SU-2026:23729-1	SLE16.0	google-cloud-sap-agent	2026-09-16
SUSE	SUSE-SU-2026:23708-1	SLE16.0	google-cloud-sap-agent	2026-09-16
SUSE	SUSE-SU-2026:4270-1	MP4.3 SLE15 SLE5.5 SLE-m5.5	google-guest-agent	2026-09-21
SUSE	SUSE-SU-2026:23831-1	SLE-m6 SLE-m6.0	google-guest-agent	2026-09-22
SUSE	SUSE-SU-2026:23736-1	SLE-m6 SLE-m6.1	google-guest-agent	2026-09-21
SUSE	SUSE-SU-2026:23745-1	SLE-m6.1	google-guest-agent	2026-09-21
SUSE	SUSE-SU-2026:4272-1	SLE12	google-guest-agent	2026-09-21
SUSE	SUSE-SU-2026:4293-1	MP4.3 SLE15 SLE5.5 SLE-m5.5	google-osconfig-agent	2026-09-23
SUSE	SUSE-SU-2026:23841-1	SLE-m6.0	google-osconfig-agent	2026-09-22
SUSE	SUSE-SU-2026:23739-1	SLE-m6.1	google-osconfig-agent	2026-09-21
SUSE	SUSE-SU-2026:4292-1	SLE12	google-osconfig-agent	2026-09-23
SUSE	SUSE-SU-2026:23712-1	SLE16.0	govulncheck-vulndb	2026-09-16
SUSE	SUSE-SU-2026:23692-1	SLE16.0	govulncheck-vulndb	2026-09-16
SUSE	SUSE-SU-2026:4200-1	SLE12	gvfs	2026-09-16
SUSE	SUSE-SU-2026:4238-1	SLE15 oS15.4	gvfs	2026-09-17
SUSE	SUSE-SU-2026:4240-1	SLE15 oS15.6	gvfs	2026-09-17
SUSE	SUSE-SU-2026:23730-1	SLE-m6.1	helm	2026-09-21
SUSE	SUSE-SU-2026:23688-1	SLE16.0	helm	2026-09-16
SUSE	openSUSE-SU-2026:0337-1	osB15	hugo	2026-09-21
SUSE	SUSE-SU-2026:23735-1	SLE-m6.1	jq	2026-09-21
SUSE	SUSE-SU-2026:4275-1	SLE15 SLE5.3 SLE5.4 SLE5.5 SLE-m5.3 SLE-m5.4 SLE-m5.5	jq	2026-09-21
SUSE	SUSE-SU-2026:23728-1	SLE16.0	jq	2026-09-16
SUSE	SUSE-SU-2026:23707-1	SLE16.0	jq	2026-09-16
SUSE	openSUSE-SU-2026:11789-1	TW	jq	2026-09-17
SUSE	SUSE-SU-2026:23844-1	SLE-m6.0	kbd	2026-09-22
SUSE	SUSE-SU-2026:23742-1	SLE-m6.1	kbd	2026-09-21
SUSE	SUSE-SU-2026:4211-1	SLE15	kbd	2026-09-16
SUSE	SUSE-SU-2026:4207-1	SLE15 SLE5.3 SLE5.4 SLE5.5 SLE-m5.3 SLE-m5.4 SLE-m5.5 oS15.4	kbd	2026-09-16
SUSE	openSUSE-SU-2026:11821-1	TW	kbfs	2026-09-21
SUSE	SUSE-SU-2026:4284-1	MP4.3 SLE15 SLE5.3 SLE5.4 SLE-m5.3 SLE-m5.4	kernel	2026-09-22
SUSE	SUSE-SU-2026:4282-1	SLE12	kernel	2026-09-22
SUSE	SUSE-SU-2026:4254-1	SLE15	kernel	2026-09-17
SUSE	SUSE-SU-2026:4279-1	SLE15 SLE5.3 SLE5.4 SLE-m5.3 SLE-m5.4	kernel	2026-09-22
SUSE	openSUSE-SU-2026:11805-1	TW	kernel-devel	2026-09-20
SUSE	openSUSE-SU-2026:0334-1	osB15	keybase-client	2026-09-21
SUSE	openSUSE-SU-2026:11774-1	TW	kubernetes1.34-apiserver	2026-09-16
SUSE	openSUSE-SU-2026:11775-1	TW	kubernetes1.35-apiserver	2026-09-16
SUSE	openSUSE-SU-2026:11822-1	TW	kyverno	2026-09-22
SUSE	SUSE-SU-2026:4205-1	SLE15 oS15.6	lcms2	2026-09-16
SUSE	openSUSE-SU-2026:11784-1	TW	libcjose-devel	2026-09-17
SUSE	SUSE-SU-2026:23715-1	SLE16.0	libcupsfilters	2026-09-16
SUSE	SUSE-SU-2026:23695-1	SLE16.0	libcupsfilters	2026-09-16
SUSE	SUSE-SU-2026:4276-1	SLE15	libheif	2026-09-21
SUSE	openSUSE-SU-2026:11825-1	TW	libipa_hbac-devel	2026-09-22
SUSE	openSUSE-SU-2026:11777-1	TW	liblzmasdk26	2026-09-16
SUSE	openSUSE-SU-2026:11790-1	TW	libmbedcrypto7	2026-09-17
SUSE	SUSE-SU-2026:23829-1	SLE-m6.0	libpcap	2026-09-22
SUSE	SUSE-SU-2026:23737-1	SLE-m6.1	libpcap	2026-09-21
SUSE	SUSE-SU-2026:4239-1	SLE12	libpcap	2026-09-17
SUSE	openSUSE-SU-2026:11823-1	TW	libsoup-3_0-0	2026-09-22
SUSE	SUSE-SU-2026:23800-1	SLE-m6.2	libsoup	2026-09-21
SUSE	SUSE-SU-2026:23848-1	SLE-m6.2	libsoup	2026-09-22
SUSE	SUSE-SU-2026:4274-1	SLE15 oS15.4	libsoup	2026-09-21
SUSE	SUSE-SU-2026:4273-1	SLE15 oS15.6	libsoup	2026-09-21
SUSE	SUSE-SU-2026:4278-1	SLE5.3 SLE5.4 SLE5.5 SLE-m5.3 SLE-m5.4 SLE-m5.5 oS15.3	libtpms	2026-09-22
SUSE	SUSE-SU-2026:23731-1	SLE-m6.1	libzypp, zypper	2026-09-21
SUSE	SUSE-SU-2026:23709-1	SLE16.0	libzypp, zypper	2026-09-16
SUSE	SUSE-SU-2026:23689-1	SLE16.0	libzypp, zypper	2026-09-16
SUSE	openSUSE-SU-2026:21864-1	oS16.0	mbedtls-2	2026-09-17
SUSE	openSUSE-SU-2026:0341-1	osB15	mbedtls	2026-09-21
SUSE	openSUSE-SU-2026:11778-1	TW	mistral-vibe	2026-09-16
SUSE	SUSE-SU-2026:4249-1	SLE15 oS15.6	netcdf	2026-09-17
SUSE	openSUSE-SU-2026:11807-1	TW	nginx	2026-09-20
SUSE	SUSE-SU-2026:4248-1	SLE12	nodejs18	2026-09-17
SUSE	SUSE-SU-2026:4261-1	SLE15 oS15.4	nodejs18	2026-09-18
SUSE	SUSE-SU-2026:2685-2	SLE12	openCryptoki	2026-09-21
SUSE	openSUSE-SU-2026:21870-1	oS16.0	openai-codex	2026-09-17
SUSE	SUSE-SU-2026:23717-1	SLE16.0	opensc	2026-09-16
SUSE	SUSE-SU-2026:23697-1	SLE16.0	opensc	2026-09-16
SUSE	SUSE-SU-2026:4287-1	SLE11	openssl-certs	2026-09-22
SUSE	SUSE-SU-2026:4242-1	SLE12	openvpn	2026-09-17
SUSE	SUSE-SU-2026:4217-1	SLE15 oS15.4	openvpn	2026-09-17
SUSE	SUSE-SU-2026:4213-1	SLE15 oS15.6	openvpn	2026-09-16
SUSE	SUSE-SU-2026:23840-1	SLE-m6.0	pcre2	2026-09-22
SUSE	SUSE-SU-2026:23740-1	SLE-m6.1	pcre2	2026-09-21
SUSE	SUSE-SU-2026:4201-1	SLE12	pcre2	2026-09-16
SUSE	SUSE-SU-2026:4241-1	SLE15 oS15.6	pcre2	2026-09-17
SUSE	SUSE-SU-2026:4280-1	SLE12	perl-Authen-SASL	2026-09-22
SUSE	openSUSE-SU-2026:21859-1	oS16.0	perl-net-dns	2026-09-17
SUSE	SUSE-SU-2026:4283-1	SLE15 oS15.4	php-composer2	2026-09-22
SUSE	SUSE-SU-2026:4288-1	SLE15 oS15.6	php-composer2	2026-09-22
SUSE	openSUSE-SU-2026:0329-1	osB15	python-asteval	2026-09-21
SUSE	SUSE-SU-2026:23722-1	SLE16.0	python-jwcrypto	2026-09-16
SUSE	SUSE-SU-2026:23702-1	SLE16.0	python-jwcrypto	2026-09-16
SUSE	openSUSE-SU-2026:0328-1	osB15	python-jwcrypto	2026-09-21
SUSE	SUSE-SU-2026:23845-1	SLE-m6.0	python311	2026-09-22
SUSE	SUSE-SU-2026:23743-1	SLE-m6.1	python311	2026-09-21
SUSE	openSUSE-SU-2026:11824-1	TW	python313-PyMuPDF	2026-09-22
SUSE	openSUSE-SU-2026:11799-1	TW	python313-aiosmtplib	2026-09-18
SUSE	openSUSE-SU-2026:11815-1	TW	python313-ansi2html	2026-09-21
SUSE	openSUSE-SU-2026:11800-1	TW	python313-litellm	2026-09-18
SUSE	SUSE-SU-2026:23796-1	SLE-m6.2	rpm	2026-09-21
SUSE	SUSE-SU-2026:23787-1	SLE16.0	rpm	2026-09-21
SUSE	SUSE-SU-2026:23782-1	SLE16.0 SLE-m6.2	rpm	2026-09-21
SUSE	openSUSE-SU-2026:11818-1	TW	shadowsocks-rust	2026-09-21
SUSE	openSUSE-SU-2026:11791-1	TW	sngrep	2026-09-17
SUSE	openSUSE-SU-2026:0330-1	osB15	sofia-sip	2026-09-21
SUSE	SUSE-SU-2026:4268-1	SLE15 oS15.4	thunderbird	2026-09-18
SUSE	openSUSE-SU-2026:11827-1	TW	thunderbird	2026-09-22
SUSE	SUSE-SU-2026:4252-1	SLE12	tiff	2026-09-17
SUSE	SUSE-SU-2026:4203-1	SLE15	tomcat	2026-09-16
SUSE	SUSE-SU-2026:23720-1	SLE16.0	tomcat	2026-09-16
SUSE	SUSE-SU-2026:23700-1	SLE16.0	tomcat	2026-09-16
SUSE	SUSE-SU-2026:23711-1	SLE16.0	tomcat10	2026-09-16
SUSE	SUSE-SU-2026:23690-1	SLE16.0	tomcat10	2026-09-16
SUSE	SUSE-SU-2026:23710-1	SLE16.0	tomcat11	2026-09-16
SUSE	SUSE-SU-2026:23691-1	SLE16.0	tomcat11	2026-09-16
SUSE	openSUSE-SU-2026:0335-1	osB15	trivy	2026-09-21
SUSE	SUSE-SU-2026:4296-1	SLE12	util-linux	2026-09-23
SUSE	openSUSE-SU-2026:11782-1	TW	znc	2026-09-17
Ubuntu	USN-8777-1	22.04 24.04 26.04	bison	2026-09-17
Ubuntu	USN-8779-1	18.04 20.04 22.04 24.04 26.04	bubblewrap	2026-09-17
Ubuntu	USN-8779-2	18.04 20.04 22.04 24.04 26.04	bubblewrap	2026-09-17
Ubuntu	USN-8788-1	22.04 24.04 26.04	clamav	2026-09-21
Ubuntu	USN-8790-1	14.04 16.04 18.04 20.04 22.04 24.04 26.04	expat	2026-09-21
Ubuntu	USN-8791-1	22.04 24.04 26.04	ghostscript	2026-09-21
Ubuntu	USN-8794-1	14.04 16.04 18.04 20.04 22.04 24.04 26.04	glib2.0	2026-09-21
Ubuntu	USN-8797-1	16.04 18.04 20.04 22.04 24.04 26.04	gst-plugins-base1.0	2026-09-21
Ubuntu	USN-8778-1	16.04 18.04 20.04 22.04 24.04 26.04	gst-plugins-good1.0	2026-09-17
Ubuntu	USN-8798-1	16.04 18.04 20.04 22.04 24.04 26.04	gst-plugins-good1.0	2026-09-21
Ubuntu	USN-8773-1	22.04 24.04	guix	2026-09-16
Ubuntu	USN-8733-2	14.04 18.04 20.04	gzip	2026-09-23
Ubuntu	USN-8774-1	26.04	libheif	2026-09-16
Ubuntu	USN-8780-1	16.04 18.04 20.04 22.04 24.04 26.04	libsoup2.4, libsoup3	2026-09-21
Ubuntu	USN-8799-1	14.04 16.04 18.04 20.04 22.04	libssh2	2026-09-22
Ubuntu	USN-8787-1	14.04 16.04 18.04 20.04 22.04 24.04 26.04	libxml2	2026-09-21
Ubuntu	USN-8730-5	20.04 22.04	linux-aws, linux-aws-5.15, linux-aws-fips, linux-nvidia-tegra-igx	2026-09-22
Ubuntu	USN-8725-2	16.04	linux-aws	2026-09-18
Ubuntu	USN-8715-2	20.04	linux-aws-fips	2026-09-18
Ubuntu	USN-8726-4	26.04	linux-azure, linux-oracle	2026-09-22
Ubuntu	USN-8730-3	20.04 22.04	linux-azure-5.15, linux-azure-fde-5.15, linux-azure-fips	2026-09-18
Ubuntu	USN-8714-3	18.04 20.04	linux-azure-5.4, linux-gcp-fips	2026-09-18
Ubuntu	USN-8761-3	22.04	linux-azure-6.8	2026-09-21
Ubuntu	USN-8728-2	24.04	linux-azure-7.0	2026-09-22
Ubuntu	USN-8801-1	24.04 26.04	linux-azure-fde, linux-azure-fde-7.0	2026-09-22
Ubuntu	USN-8730-4	22.04	linux-azure-fde, linux-intel-iotg, linux-kvm, linux-oracle, linux-xilinx-zynqmp	2026-09-21
Ubuntu	USN-8793-1	24.04	linux-azure-fde	2026-09-21
Ubuntu	USN-8793-2	22.04	linux-azure-fde-6.8	2026-09-22
Ubuntu	USN-8761-2	24.04	linux-azure-fips	2026-09-18
Ubuntu	USN-8729-3	22.04 24.04	linux-gcp-6.8, linux-ibm, linux-xilinx	2026-09-21
Ubuntu	USN-8726-3	26.04	linux-ibm	2026-09-21
Ubuntu	USN-8729-4	22.04 24.04	linux-lowlatency, linux-lowlatency-hwe-6.8	2026-09-22
Ubuntu	USN-8760-2	26.04	linux-nvidia	2026-09-22
Ubuntu	USN-8800-1	26.04	linux-nvidia-bos	2026-09-22
Ubuntu	USN-8781-1	24.04	linux-nvidia-tegra	2026-09-18
Ubuntu	USN-8802-1	22.04 24.04	linux-oracle, linux-oracle-6.8	2026-09-22
Ubuntu	USN-8668-2	22.04	linux-raspi	2026-09-21
Ubuntu	USN-8661-5	22.04	linux-raspi	2026-09-22
Ubuntu	USN-8726-2	26.04	linux-raspi	2026-09-18
Ubuntu	USN-8729-2	24.04	linux-raspi-realtime	2026-09-18
Ubuntu	USN-8792-1	22.04 24.04 26.04	memcached	2026-09-21
Ubuntu	USN-8795-1	18.04 20.04 22.04 24.04 26.04	openjdk-17	2026-09-22
Ubuntu	USN-8796-1	20.04 22.04 24.04 26.04	openjdk-21	2026-09-22
Ubuntu	USN-8783-1	22.04 24.04 26.04	openjdk-25	2026-09-21
Ubuntu	USN-8784-1	16.04 18.04 20.04 22.04 24.04 26.04	openjdk-8	2026-09-21
Ubuntu	USN-8785-1	18.04 20.04 22.04 24.04 26.04	openjdk-lts	2026-09-21
Ubuntu	USN-8804-1	14.04 16.04 18.04 20.04	openssh	2026-09-22
Ubuntu	USN-8736-2	24.04	perl	2026-09-16
Ubuntu	USN-8776-1	18.04 26.04	python-cryptography	2026-09-16
Ubuntu	USN-8782-1	22.04 24.04 26.04	rclone	2026-09-18
Ubuntu	USN-8786-1	16.04 18.04 20.04 22.04 24.04 26.04	rsyslog	2026-09-21
Ubuntu	USN-8775-1	18.04 20.04 22.04 24.04 26.04	sqlite3	2026-09-17
Ubuntu	USN-8789-1	22.04 24.04 26.04	strongswan	2026-09-21
Ubuntu	USN-8803-1	24.04 26.04	sudo	2026-09-22
Ubuntu	USN-8771-1	24.04 26.04	valkey	2026-09-17

Full Story (comments: none)