|
|
Log in / Subscribe / Register

LWN.net Weekly Edition for February 12, 2026

Welcome to the LWN.net Weekly Edition for February 12, 2026

This edition contains the following feature content:

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)

Evolving Git for the next decade

By Joe Brockmeier
February 11, 2026
FOSDEM

Git is ubiquitous; in the last two decades, the version-control system has truly achieved world domination. Almost every developer uses it and the vast majority of open-source projects are hosted in Git repositories. That does not mean, however, that it is perfect. Patrick Steinhardt used his main-track session at FOSDEM 2026 to discuss some of its shortcomings and how they are being addressed to prepare Git for the next decade.

Steinhardt said that he began to be interested in open-source software around 2002, when he was 11 years old. He bought his first book on programming when he was 12, and made his first contribution to an open-source project in 2011. He became a Git and libgit2 contributor in 2015, has been a backend engineer at GitLab since 2020, and became the manager of the Git team there in 2024.

Git must evolve

Git turned 20 last year; there are millions of Git repositories and even more scripts depending on Git. "The success of Git is indeed quite staggering." However, the world has changed quite a bit since Git was first released in 2005; it was designed for a different era. When Git was released, SHA-1 was considered to be a secure hash function; that has changed, he said, with the SHAttered attack that was announced in 2017 by Centrum Wiskunde & Informatica (CWI) and Google. In 2005, the Linux kernel repository was considered big; now it is dwarfed by Chromium and other massive monorepos. Continuous-integration (CI) pipelines were the exception, he said, in 2005—but now projects have pipelines with lots of jobs that are kicked off every time there's a new commit.

Also, Steinhardt said to general laughter: "Git was very hard to use back then; but to be quite honest, Git's still hard to use nowadays." So, the world has changed and Git needs to change with it. But, he said, the unique position of Git means that it can't have a revolution; too many projects and developers rely on it. Instead, it needs to evolve, and he wanted to highlight some of the important transitions that Git is going through.

SHA-256

The most user-visible change that Git is going through today, he said, is the SHA-256 transition. SHA-1 is a central part of the project's design; every single object stored in Git, such as files (blobs), directory trees, and commits, has an identity that is computed by hashing the contents of the object. Objects are content addressable, "given the contents, you know the name of the object". That name, of course, is computed using the no-longer-secure SHA-1.

The work by CWI and Google proved that attacks on SHA-1 are viable. It requires a lot of compute, about 110 years worth of single-GPU computations, but it is possible. He noted that with all the hype around artificial intelligence, data centers have greatly increased their GPU capacity. "It is very much in reach of a large player to compute hash collisions".

SHAttered kicked off quite a few conversations on the Git mailing lists. During these conversations, he said, it has been asserted that the use of SHA-1 is not primarily for security and a number of arguments have been made to back that up. The SHA-1 object hash is primarily used as an integrity check to detect transmission errors or bit flips. Also, source code is transparent, "if you see a merge request where somebody enters random collision data into your code, then you might probably ask some questions". Additionally, there are other security measures such as GPG signatures, HTTPS transport, and a web of trust among developers that means Git does not rely on SHA-1 alone.

"But the reality is that things are a little bit more complicated", Steinhardt said. Git may not rely on SHA-1 for security, but everyone else does. When developers sign a commit with Git, for example, it is the SHA-1 hash that is signed. It might be noticeable if source code is changed to cause a collision, but binary blobs such as firmware are not human-readable, so there is no way to easily see that there is a malicious file. Tooling around Git also assumes collision resistance, so CI systems, scripts, and such all trust the SHA-1 hash.

Finally, various governments and enterprise requirements have mandated removal of SHA-1 by 2030, so Git needs to move on. And it has: SHA-256 support was added in October 2020, with version 2.29. "But nobody is using it", Steinhardt said, because ecosystem support is lacking. "Unfortunately, this situation looks somewhat grim". There is full support in Git itself, Dulwich Python implementation, and Forgejo collaboration platform. There is experimental support for SHA-256 in GitLab, go-git, and libgit2. Other popular Git tools and forges, including GitHub, have no support for SHA-256 at all. That creates a chicken-and-egg problem, he said. Nobody is moving to SHA-256 because it is not supported by large forges, and large forges are not implementing support because there's no demand.

The problem, Steinhardt said, is that we cannot wait forever. It will become more and more feasible to break SHA-1, and the next cryptographic weakness may be just around the corner. Even if there were full support for SHA-256 today, projects still need time to migrate. Git will make SHA-256 the default for newly created repositories in 3.0, he said. The hope is to force forges and third-party implementations to adapt. "The transition will likely not be an easy one, and it may result in a few hiccups along the road." When 3.0 will be released is still up in the air; a discussion about its release date in October 2025 on the Git mailing list did not result in a firm decision.

He said that the audience could help to move things along. "You can show your favorite code forges that you care about SHA-256 so they bump the priority." He also encouraged people to help by testing SHA-256 with new projects and adding support to third-party tools that depend on Git. "Together, we can hopefully get the ecosystem to move before the next vulnerability".

Reftables

Another significant shift for Git, which he declared his favorite topic for discussion, is the move to reftables. By default, Git stores references as "loose" references, where each is stored as a separate file such as "refs/heads/main". The format for these files is straightforward to understand, he noted, but storing every single reference as a file does not scale well. It is fine for a project with a handful of references, but if there are hundreds or thousands then it becomes really inefficient.

To deal with that inefficiency today, Git will create a packed-refs file; this can be done manually with "git pack-refs --all", but Git will also do it automatically. However, Steinhardt said, Git still needs to change the way it deals with references.

The first reason he gave is that "filesystems are simply weird". Many filesystems, for example, are case-insensitive by default. That means that Git cannot have two branches whose names only differ in case, as just one example. It is also an inefficient design, he said: to create 20 different references, Git has to create 20 different files. That may not take long from a performance perspective, but each reference requires 4KB of storage for typical filesystems. That begins to add up quickly.

Packed references are computationally expensive, he said, which is not a problem if a project only has a few references. "But, Git users are not always reasonable." He said that GitLab hosts one repository with about 20-million references; each time a reference is deleted, the packed-refs file has to be completely rewritten which means rewriting 2GB of data. "To add insult to injury, this repository typically deletes references every couple seconds."

The third problem Steinhardt described is that concurrency is an afterthought. It is impossible to get a consistent view of all references when there are multiple readers and writers in a repository at the same time. When a user writes to a repository while another user is reading the references, it is impossible to know if they are getting a consistent result or a mixture of the old and new state.

Those problems have been known for a long time, he said, and that is where the reftable backend comes into the picture. Users can create a new repository with a reftable today. The tables are now stored in a binary format rather than the text-based, which is more efficient—though it does mean that the files are no longer human-readable. The new data structure also allows Git to perform atomic updates when writing references to the reference table, and Git is no longer subject to filesystem limitations when it comes to naming references.

As with SHA-256, reftables will become the default in Git 3.0. "So if you use Git in scripts or on the server side, you should make sure you don't play weird games by accessing references directly on the filesystem". Instead, Git users should always access references with the git command.

Large files

Steinhardt said that, for most of the people in the room, the scalability problems related to references were mostly theoretical and rarely encountered in practice. When it comes to scalability bottlenecks, "the more important problem tends to be large files". Storing large binary files in Git is, unfortunately, not a use case that is well-supported today. There are third-party workarounds, such as Git LFS and git-annex, but the Git project would like to solve the problem directly.

Large files are a problem for Git because of the way that it compresses objects, he said. It works extremely well when working with text files, such as source code, because that is what Git was designed for. But Git's compression does not work well for binary files, and even small edits to such files means creating entirely new objects.

Another problem is that when cloning a repository, the user gets a full copy of all of its history by default. That's desirable, he said, for normal repositories; but for large monorepos with binary files, "you probably don't want to download hundreds of gigabytes of data". In addition, there is no support for resuming a cloning operation: if it fails, the user has to start over. "So if you have downloaded 400GB out of a 500GB repository and your network disconnects, then you will have to redownload everything."

Code forges also struggle with large files. Users can resort to partial clones to avoid downloading an entire repository, but forges do not have that luxury. The consequence of that is significant storage costs. He said that an analysis of GitLab's hosted repositories has shown that 75% of the site's storage space is consumed by binary files larger than 1MB. Huge repository sizes also cause repository maintenance to become computationally expensive. Other types of web sites might offload large files to content-delivery networks (CDNs), but that is not an option for Git forges, he said. "All data needs to be served by the Git server, and that makes it become a significant bottleneck." Large objects are a significant cost factor for any large Git provider.

Git LFS and partial clones can help users, but those are just band-aids, Steinhardt said. Even though partial clones have been a feature in Git for quite a while, "I bet many of you have never used them before". And even when users do use partial clones, servers still cannot offload the files to a CDN.

The solution is large-object promisors, a remote that is used only to store large blobs and is separate from the main remote that stores other Git objects and the rest of the repository. The functionality is now built directly into Git, and is transparent to the client, he said.

In addition, large-object promisors could be served over protocols other than HTTPS and SSH. That would allow, for example, serving large objects via the S3 API. "This allows us to offload objects to a CDN and store large blobs in a format that is much better suited for them".

Even with promisors, though, Steinhardt said that Git still does not handle binary files efficiently on the client side. "This is where pluggable object databases come into play, which will allow us to introduce a new storage format for a large binary file specifically." Git needs a format designed for binaries, he said, where incremental changes to a binary file only lead to a small storage increase. It needs to be efficient for any file size.

In addition, a new format would need to be compatible with Git's existing storage format so that users could mix and match the old format for text files and use the new format for large binaries. Git's storage format is "deeply baked in" he said, but alternate implementations like libgit2 and go-git already have pluggable storage backends. "So there is no fundamental reason why Git can't do this too. It requires a lot of plumbing and refactoring, but it's certainly a feasible thing."

The two efforts to handle large objects, promisors and pluggable object databases, are progressing in parallel. The promisors effort is farther along, with the initial protocol implementation shipped in Git 2.50, and additional features in Git 2.52, both released in 2025. He said that it is quite close to being usable on the client side, though when support for promisors will arrive in Git forges is still undetermined.

The pluggable object database work is not that far along, he said. Over the past few Git releases the project has spent significant time refactoring how Git accesses objects. In 2.53, which was released a few days after his talk, Git shipped a unified object-database interface that will make it easier to change the format in the future. He said that he expected a proof of concept in Git 2.54, though implementing a viable format for binary files "will probably take a little bit longer".

User-interface improvements

One area of Git that tends to draw plenty of complaints is its user interface, he said. Many of Git's commands are extremely confusing, and some workflows "are significantly harder than they have any right to be". Recently, Git has had competition in the form of the Jujutsu version-control project that has made the Git project take a hard look at what it is doing. (LWN covered Jujutsu in January 2024.)

Jujutsu is a Git-compatible, Rust-based project started by Martin von Zweigbergk. It has a growing community and Steinhardt said that "many people seem to prefer the Jujutsu experience way more" than using Git. That is not much of a surprise, he said; Git's user interface has grown organically over two decades. It has "inconsistencies and commands that just don't feel modern". On the other hand, Jujutsu started from scratch and learned from Git's mistakes.

Early on, Steinhardt said he had looked at Jujutsu and found it confusing. "It just didn't make sense to me at all, so I simply discarded it." However, after noticing that there was a steady influx of people who did like it, he opted for another look. That time, something clicked. "That moment when you realize that a tool simply fixes all the UI issues that you had and that you have been developing for the last 20 years was not exactly great." He had two options: despair or learn from the competition. He chose to learn from it.

There are a number of things that Jujutsu got right, he said. For example, history is malleable by default. "It's almost as if you were permanently in an interactive rebase mode, but without all the confusing parts." When history is rewritten in Jujutsu all dependents update automatically "so if you added a commit, all children are rebased automatically". Conflicts are data, not emergencies. "You can commit them and resolve them at any later point in time." These features are nice to have, he said, and fundamentally change how users think about commits. "You stop treating them as precious artifacts and rather start treating them as drafts that you can freely edit".

But, he said, Git is old: the project cannot simply completely revamp its UI and break users' workflows. There are some things that Git can steal from Jujutsu, though. He discussed the workflow for splitting a Git commit, which involves seven separate commands with Git's current UI. Most users do not know how to do this, he said. The goal is to add several "opinionated subcommands" that make more modern styles of working with merge requests, such as stacked branches, much easier.

This includes two new commands, planned for Git 2.54, "git history split" and "git history reword". Future releases will have more history-editing subcommands and learn more from Jujutsu.

Steinhardt did not have time for questions; he closed the talk by saying that it had been a "whirlwind tour" through what is cooking in Git right now, and hoped that it had provided a clear picture of what the project was up to.

The video for the talk is now available on the FOSDEM 2026 web site. Slides have not yet been published.

[I would like to thank the Linux Foundation, LWN's travel sponsor, for funding my travel to Brussels to attend FOSDEM.]

Comments (55 posted)

Kernel control-flow-integrity support comes to GCC

By Daroc Alden
February 6, 2026

Control-flow integrity (CFI) is a set of techniques that make it more difficult for attackers to hijack indirect jumps to exploit a system. The Linux kernel has supported forward-edge CFI (which protects indirect function calls) since 2020, with the most recent implementation of the feature introduced in 2022. That version avoids the overhead introduced by the earlier approach by using a compiler flag (-fsanitize=kcfi) that is present in Clang but not in GCC. Now, Kees Cook has a patch set adding that support to GCC that looks likely to land in GCC 17.

CFI has a tricky problem to solve: a program should only make indirect function calls that the developer intends to make. If there were no bugs in the program, this would be straightforward — the function pointers involved would always be correct, and there would be nothing to worry about. The kernel is not free of bugs, however, and there is always the possibility that an attacker will manage to overwrite a function pointer with some value they control. How can the compiler protect against incorrect function calls when the function pointers involved are potentially compromised?

The approach that the kernel's forward-edge CFI takes is to split functions up according to their type signature. If some piece of code is expecting to call a function that takes a long, but the function pointer actually takes a char *, for example, that's a sign that something has gone off the rails. By recognizing that kind of type confusion and panicking the kernel, forward-edge CFI can prevent some attacks. This isn't a perfect solution: an attacker could still redirect an indirect function call as long as the function signatures match. It's still more protection than the alternative, though.

This kind of mitigation is typical of the Linux kernel self-protection project, on behalf of which Cook did this work. The project is based on the reality that many bugs in the kernel have a long lifetime. LWN recently did an in-depth breakdown of bug lifetime for the 6.17 kernel (showing, among other things, that it usually takes several years to find the majority of bugs known to exist in a given kernel version). LWN subscribers can see the details for any kernel version in the LWN kernel source database. Given that bugs have a way of sticking around, the kernel self-protection project supports work on techniques to keep the kernel secure even in the presence of those bugs. The project tracks work-in-progress at its GitHub issue tracker.

Clang implements -fsanitize=kcfi by computing a hash of the function's type, and storing it just before the function implementation in memory. When a call site in the code makes an indirect call, it first verifies that the hash matches what it expects. The plan is for GCC to implement the feature in the same way, but unfortunately adding support isn't quite as simple as it may seem. The patch set has gone through nine versions since the initial version in August 2025.

One complication is in the handling of type aliases: these are frequently used for readability in C code, and it would break existing kernel code to generate a different hash for two type aliases that refer to the same underlying type. Therefore, most type aliases are resolved during the hashing process and the underlying type is used instead. There is one case where type aliases are usually meaningful in C code: as names for otherwise-anonymous structures, unions, and enumeration types. If two anonymous unions happen to have the same fields, but they are named differently, it is almost always the case that the programmer would like to ensure that one is not confused for the other. Here, the compiler uses the type alias name as part of the hash. 

    // This is treated the same as a plain int:
    typedef int port_number;

    // But these two types are considered different:
    typedef struct {
        void *data;
    } foo;

    typedef struct {
        void *data;
    } bar;

The other complication comes from a desire for compatibility with LLVM. In the past, a kernel build was theoretically performed entirely with GCC or with Clang. In practice, Cook wants to support CFI for kernels where the C code is built with GCC while the Rust code is built with rustc (which uses LLVM for code generation). Eventually, once GCC's Rust front end is working, this may not be necessary. But for now, C code that makes an indirect function call to Rust code or vice versa needs to compute the same type hash as the other language so that the values will match at run time. Clang's type hashes are based on the function-name mangling required by the Itanium C++ ABI; Cook implemented the same algorithm for GCC. Sami Tolvanen does not seem to have recorded why the Itanium ABI was chosen for LLVM's original implementation, but it may be because the Itanium ABI is the only ABI standard for POSIX systems that actually specifies name-mangling rules, rather than leaving them to the compiler.

The relevant hashes need to be calculated at every call site, but they also need to be calculated for every function that could be called indirectly. Since C files are compiled separately, there's no way to know whether a function that has its address taken is actually called or not. To be safe, GCC calculates and embeds hashes for every function that has its address taken, plus every function that is directly visible to other translation units.

The actual checks that the type hashes match are implemented late in the compiler pipeline, to ensure that they are not optimized out or otherwise broken up. Therefore, there's some architecture-specific code to implement the checks. Cook's patch set includes support for x86_64, 32- and 64-bit Arm, and RISC-V.

While there was a good deal of discussion on earlier versions, the current version has not attracted much commentary from GCC developers. Jeffrey Law believes the patch set is ready to go into GCC 17 as soon as the last GCC 16 release is made. Even though support hasn't quite landed in GCC, the kernel has already renamed the relevant configuration option from CONFIG_CFI_CLANG to CONFIG_CFI in version 6.18. The configuration option uses feature detection, so older stable kernels will support the option with GCC 17 despite the name.

There is still more work to be done, however. For example, there was a discussion in 2022 about the possibility of adding a programmer-specified per-function seed to the CFI hash. That would let programmers manually partition sets of functions with identical signatures into different groups with different CFI hashes. Bill Wendling and Aaron Ballman added support for that to LLVM in August 2025, although the kernel doesn't yet make use of it.

Advances in kernel security don't come all at once. CHERI-like hardware-enforced capabilities can be used to completely block indirect-jump-based attacks. Modern CPUs are increasingly adding hardware support for CFI operations. For older devices, software fixes like Clang's CFI support help make up the gap. Now, GCC will bring that same CFI scheme to the people who choose to use GCC for reasons of compatibility or ideology. Eventually, perhaps, this kind of mitigation will simply be the default.

Comments (9 posted)

Modernizing swapping: the end of the swap map

By Jonathan Corbet
February 5, 2026
The first installment in this series introduced several data structures in the kernel's swap subsystem and described work to replace some of those with a new "swap table" structure. The work did not stop there, though; there is more modernization of the swap subsystem queued for an upcoming development cycle, and even more for multiple kernel releases after that. Once that work is done, the swap subsystem will be both simpler and faster than it is now.

The data structures introduced thus far include the swap cluster, which represents a 2MB set of swap slots within a swap file, and the new swap table, stored within the swap cluster, that tracks the state of each swap slot. The introduction of the swap table allowed the removal of entire arrays of XArray structures that were, prior to the 6.18 kernel release, used to track the status of individual swap slots within a swap file. That was not a complete list of swap-related data structures, though. The first article, as a way of minimizing the complexity of the picture as much as possible, skipped over an important swap-subsystem component: the swap map.

The swap map

The time has come to fill in that gap, as the swap map is the core target of the ongoing swap-improvement effort. At first glance, the swap map, as found in current kernels, is as simple as data structures get. There is one for each swap device, stored in struct swap_info_struct, and declared as: 

    unsigned char *swap_map;  /* vmalloc'ed array of usage counts */

This field points to an array with one byte for every slot in the swap device; the value stored in each byte is the number of references that exist to that swap slot. There will be one reference for every page-table entry pointing to that slot, regardless of whether the page assigned to that slot is resident in RAM.

Of course, this is the swap code that is being discussed, so there are complications, and that some of the bits in the swap-map entries have special meaning. The most significant of those, for the purposes of this article, is bit six (0x40) of the reference count; it is called SWAP_HAS_CACHE, and it is used to indicate that a swap slot has a page assigned to it. There can be various windows of time where a swap slot is assigned, but no page-table references to that slot yet exist, leading to a reference count of zero. The SWAP_HAS_CACHE bit distinguishes that state from a slot being unassigned.

This flag is also used as a sort of bit lock; there are numerous race conditions that might cause the kernel to try to swap in a page (or make other changes) multiple times in parallel. In such cases, the thread that succeeds in setting the SWAP_HAS_CACHE bit in the entry is the one that proceeds to do the work. This use of SWAP_HAS_CACHE as a synchronization mechanism has led to a number of problems over the years; the swap code has a number of delay-and-retry loops (example) waiting for this bit to clear.

There are some other special values in the swap map; a value of 0x3f (SWAP_MAP_BAD) means, for example, that the underlying storage is bad and should not be used. As a result, the maximum reference count that can be stored in the swap map (SWAP_MAP_MAX — 0x3e) is 62. That presents a problem; in cases where a large number of tasks are sharing an anonymous page, the number of references could easily exceed that value. The way this situation is handled is, to put it mildly, interesting.

Every time that the reference count for a swap slot is incremented, a check must be made for overflow. Should the count already be at the maximum, the topmost bit (0x80 — COUNT_CONTINUED) will be set, the count in the swap map will be set to zero, and a new page will be allocated to provide eight more-significant bits for the reference count (and for all the others on the same original swap-map page). That page will be linked to the swap-map page using the LRU list head in the associated page structures. If an entry has a lot of references and the count in the overflow page also overflows, yet another page will be allocated and added to the list.

The overflow pages only need to be accessed when the principal swap-map entry overflows or underflows, which is good considering that these operations are supposed to be fast. While the motivation behind this somewhat baroque design isn't documented anywhere, one can assume that, while the overflow case must be handled correctly, it is also relatively rare. Massive sharing of anonymous pages is not the common case. When reference counts are lower, this structure offers quick access and minimal memory overhead.

Swap-cache bypass and SWAP_HAS_CACHE

One of the purposes of the swap cache is to hold (and track) folios that are under I/O to or from the swap device. If, for example, a page fault occurs on a swapped-out folio, a new folio will have to be allocated and its contents read from the swap file. That read operation can take some time, though. So the folio is added to the swap cache, the read operation is initiated, and the faulting process made to wait until the read is complete. Often, the swap subsystem will also attempt to read ahead of the current fault location, making a bet that the process will soon fault in subsequent pages as well.

The situation changed a bit in the 2018 4.15 release, though. Once upon a time, swapping was mostly done to rotating storage devices, which are slow. Increasingly, though, swapping looks a lot like just copying data from one part of memory to another. The "swap device" may be a bank of slower memory, or it may be an in-memory compression scheme like zram. On such devices, swap I/O is no longer slow, and behavior like readahead may harm performance rather than helping it.

In 4.15, Minchan Kim added the "swap bypass" feature. Specifically, if a swap device has the SWP_SYNCHRONOUS_IO flag (indicating that the device is so fast that I/O should be done synchronously) set, and if a specific slot in the swap map has a reference count of one, then a request to swap in the page stored in that slot will happen synchronously, readahead will not be performed, and the newly read page will not be added to the swap cache. This optimization added a fair amount of complexity to the swap subsystem, resulting in various bugs over time, but it also resulted in significantly better performance for swap-heavy workloads. That improvement was due to two factors: avoiding the relatively expensive swap-cache maintenance and preventing the use of readahead.

Fast-forwarding now to 2026, first part of the phase-two patch series from Kairui Song is dedicated to removing the bypass feature. The work done in the first phase — specifically the introduction of the swap table — made swap-cache operations much faster, to the point that there is no real value to bypassing the swap-cache even when fast swap devices are in use. Additional work in this series separates out the control of readahead and essentially disables its use entirely for fast devices. Having all swap I/O go through the swap cache simplifies the code and reduces the number of troublesome race conditions. The new code will immediately remove swapped-in folios from the swap cache for SWP_SYNCHRONOUS_IO devices as a way of freeing the memory used for the swapped data.

There is one interesting side effect of removing the swap-bypass code. In current kernels, large (multi-page) folios can only be swapped in intact if their reference count is one — only in the bypass case, in other words. Removal of the bypass feature makes it possible to swap in large folios from fast devices regardless of the reference count.

Removal of swap bypass simplifies the swap-map management and makes it easier for the rest of the series to coalesce swap-slot management into a small set of well-defined functions. Among other things, these functions are all folio-based, reducing the historical page orientation of the swap subsystem. All of those functions use a combination of the cluster lock and the folio lock to manage the swap cache. From there, it is just one more step to use those locks to control access to the swap map as well.

Once the swap cache takes on the role of managing concurrency, there is only one last need for the SWAP_HAS_CACHE bit: marking swap slots that are allocated, but which have a reference count of zero. On the swap-out side, this situation is eliminated by immediately adding a folio to the swap cache once its slot has been assigned. At the other end, when pages are removed from the swap cache, swap slots with zero references are freed immediately. At that point, SWAP_HAS_CACHE is no longer needed; this patch near the end of the series removes it.

Removing the swap map

The work described above is, as of this writing, in the mm-unstable repository (and thus linux-next) and could be merged into the mainline as soon as the 7.0 release. But there is more to come. The third phase of this work is currently under review; this relatively short series eliminates the swap map entirely.

Recall, from the previous installment, that the entries in the new swap table, which are simple unsigned long values, were the same as those stored in the XArray data structures in previous kernels. A value of zero indicates an empty slot. For a resident folio, the entry contains the folio address; for swapped folios, the entry contains the shadow information used to track which pages are quickly faulted back in from swap. The third phase changes the format of this table to support five different types of entries:

  • A value of zero still indicates an empty slot.
  • If bit zero is set, then this is a shadow entry for a swapped-out folio, but the upper part of the entry holds the reference count for this entry. The specific number of bits available for this count will vary depending on the architecture.
  • If the bottom two bits are 10, then the entry is for a folio that is resident in memory. As with shadow entries, the uppermost bits hold the reference count. To make room for that count, the page-frame number of the underlying page is stored rather than its address.
  • A "pointer" entry is marked by setting the bottom three bits to 100; pointers are not used in the current series.
  • Setting the bottom four bits to 1000 marks a bad slot that should not be used.

This organization takes the final remaining purpose for the swap map — tracking the reference counts — and shoehorns it into the swap table; that allows the swap map to be removed altogether. The result is a more compact memory representation and some significant memory savings; Song estimates that about 30% of the swap subsystem's metadata overhead is gone, saving 256MB of memory for a 1TB swap file. Until now, the kernel has maintained the swap map (tracking the status of slots in a swap file) and the swap cache (which tracks the pages that have been placed into swap) separately. The unification of those two data structures, Song says, reduces the amount of record-keeping overhead significantly, speeding the swap system overall.

The new format can keep a larger reference count than the swap map can. For example, x86_64 systems will need 40 bits to hold the page-frame number, plus two for the resident-folio marker; that leaves 22 bits for the reference count. That size will be smaller on some other architectures (especially 32-bit systems) and, in any case, the possibility of overflow still exists. The complex system used to handle reference-count overflow in current kernels has been removed, though. Instead, if a reference count overflows, an array of unsigned long counts will be allocated for the entire cluster.

The third phase is in its second revision. Thus far, neither version has received much in the way of review comments; that suggests that the removal of the swap map is not yet imminent. Even once this happens, though, the work is not done; Song has alluded to a later phase that will integrate the swapping limits from the memory controller into the swap table as well. So, just like the rest of the kernel, the swap subsystem is unlikely to be considered complete anytime soon.

Comments (2 posted)

Development statistics for 6.19

By Jonathan Corbet
February 9, 2026
Linus Torvalds released the 6.19 kernel on February 8, as expected. This development cycle brought 14,344 non-merge changesets into the mainline, making it the busiest release since 6.16 in July 2025. As usual, we have put together a set of statistics on where these changes come from, along with a quick look at how long new kernel developers stay around.

As a reminder: LWN subscribers can find much of the information below — and more — at any time in the LWN kernel source database.

The 6.19 development cycle brought in the work from 2,141 developers, which just barely beats the previous record (2,134) set for 6.18; 333 of those developers made their first contribution to the kernel in 6.19, also a relatively high number. The most active developers for 6.19 were:

Most active 6.19 developers
By changesets
Kuninori Morimoto 4593.2%
Christian Brauner 2711.9%
Johan Hovold 1581.1%
Ville Syrjälä 1531.1%
Ian Rogers 1401.0%
Russell King 1240.9%
Josh Poimboeuf 1010.7%
Andy Shevchenko 1000.7%
Krzysztof Kozlowski 930.6%
Jani Nikula 910.6%
Sean Christopherson 880.6%
Filipe Manana 870.6%
Marco Crivellari 870.6%
Christoph Hellwig 860.6%
Thomas Zimmermann 850.6%
Eric Dumazet 850.6%
Peter Zijlstra820.6%
Marc Zyngier 820.6%
Frank Li 780.5%
SeongJae Park 780.5%
By changed lines
Miguel Ojeda 580007.8%
Cyril Chao 197552.6%
Christian Brauner 166042.2%
YiPeng Chai 132931.8%
Dmitry Baryshkov 122441.6%
Ian Rogers 109331.5%
Jason Gunthorpe 108511.5%
Eric Biggers 95491.3%
Daniel Scally 94291.3%
AngeloGioacchino Del Regno 62010.8%
Josh Poimboeuf 60100.8%
Ilya Bakoulin 60090.8%
Rob Herring57770.8%
Johannes Berg 57070.8%
Svyatoslav Ryhel 56100.8%
Akhil P Oommen 55160.7%
Mauro Carvalho Chehab 51960.7%
Neilay Kharwadkar 51620.7%
Igor Belwon 51550.7%
Lorenzo Stoakes 48300.6%

Kuninori Morimoto, who was first seen during the 2.6.28 development cycle in 2008, was the biggest contributor of changesets by virtue of a major refactoring effort in the sound subsystem. Christian Brauner, the maintainer of the virtual filesystem layer, refactored the handling of credentials, added the listns() system call, and added many self tests, among other contributions. Johan Hovold fixed numerous bugs and did a lot of cleanups in various driver subsystems. Ville Syrjälä worked extensively in the i915 graphics-driver subsystem, and Ian Rogers contributed a long list of improvements to the perf tool.

Looking at lines changed, Miguel Ojeda topped the list with the addition of a modified version of the Rust syn crate. Cyril Chao's first-ever kernel contribution, which put him into second place in the "lines-changed" list, was a driver for MediaTek mt8189 platform devices. YiPeng Chai worked with the amdgpu graphics driver, and Dmitry Baryshkov updated devicetree files for a number of Qualcomm devices.

A full 10% of the patches merged for 6.19 had Tested-by tags, while 56% had Reviewed-by tags; both of those numbers are slightly higher than usual. The top testers and reviews for this release were:

Test and review credits in 6.19
Tested-by
Dan Wheeler 894.8%
Joe Lawrence 633.4%
Mark Brown 553.0%
Randy Dunlap 532.9%
Fuad Tabba 532.9%
Lad Prabhakar 372.0%
Shaopeng Tan 351.9%
James Clark 341.8%
Carl Worth 341.8%
Hanjun Guo 331.8%
Gavin Shan 321.7%
Zeng Heng 321.7%
Ryan Walklin 301.6%
Kai Huang 291.6%
Fenghua Yu 281.5%
Yan Zhao 281.5%
Reviewed-by
Charles Keepax 3102.8%
Dmitry Baryshkov 1911.7%
Geert Uytterhoeven 1641.5%
Frank Li 1581.4%
Krzysztof Kozlowski 1561.4%
David Sterba 1441.3%
Christoph Hellwig 1391.3%
Konrad Dybcio 1251.1%
Simon Horman 1251.1%
Ilpo Järvinen 1181.1%
Jan Kara 1181.1%
Jeff Layton 1131.0%
AngeloGioacchino Del Regno 1111.0%
Jonathan Cameron 1091.0%
Andrew Lunn 1091.0%
Ville Syrjälä 1051.0%

The list of top reviewers is a bit different than in the past; somehow Charles Keepax managed to review 310 commits — more than four for every day of this 70-day release cycle — mostly within the sound-driver subsystem. The other top reviewers were focused on system-on-chip drivers and devicetree-related changes. The list of top testers is more typical, with Daniel Wheeler on top as usual.

The development of the 6.19 kernel was supported by 227 employers that we know of. The most active employers were:

Most active 6.19 employers
By changesets
Intel159111.1%
(Unknown)14109.8%
Google10997.7%
Red Hat8295.8%
Renesas Electronics7415.2%
AMD6124.3%
(None)5543.9%
Qualcomm4853.4%
SUSE4623.2%
Microsoft4343.0%
NVIDIA4072.8%
(Consultant)3922.7%
Meta3792.6%
Oracle3712.6%
NXP Semiconductors3252.3%
Linaro3192.2%
Huawei Technologies2601.8%
IBM2361.6%
Arm2001.4%
Bootlin1601.1%
By lines changed
Google10172813.6%
(Unknown)701259.4%
Intel599348.0%
AMD450256.0%
Qualcomm363224.9%
NVIDIA325854.4%
Red Hat314294.2%
Microsoft306214.1%
(None)272853.7%
MediaTek232233.1%
Ideas on Board148802.0%
Renesas Electronics143501.9%
Meta142321.9%
Collabora140881.9%
Huawei Technologies132571.8%
SUSE132091.8%
Oracle129431.7%
Arm127611.7%
IBM122301.6%
Linaro90151.2%

These numbers are reasonably consistent with recent history; hardware vendors are still contributing a large share of the changes. When considering which companies are most influential in kernel development, though, one should also look at the Signed-off-by tags added to patches by maintainers as they apply those patches to their repositories:

Non-author signoffs in 6.19
Individual
Jakub Kicinski 9917.5%
Mark Brown 9467.2%
Andrew Morton5844.4%
Alex Deucher 4783.6%
Greg Kroah-Hartman 4063.1%
Jens Axboe 2772.1%
Hans Verkuil 2572.0%
Bjorn Andersson 2451.9%
Paolo Abeni 2181.7%
Christian Brauner 2001.5%
Namhyung Kim 1961.5%
Shawn Guo 1851.4%
Martin K. Petersen 1841.4%
Peter Zijlstra 1841.4%
David Sterba 1791.4%
Jonathan Cameron 1671.3%
Alexei Starovoitov 1411.1%
Geert Uytterhoeven 1291.0%
Jonathan Corbet 1210.9%
Ilpo Järvinen 1210.9%
By employer
Meta154411.8%
Google12969.9%
Intel12439.5%
Arm11718.9%
AMD8486.5%
Linaro7866.0%
Red Hat6474.9%
Qualcomm5644.3%
Linux Foundation4413.4%
Microsoft4323.3%
SUSE4233.2%
(Unknown)4093.1%
NVIDIA3122.4%
Cisco2572.0%
Oracle2351.8%
Huawei Technologies2331.8%
(None)2091.6%
LG Electronics1961.5%
Renesas Electronics1741.3%
IBM1331.0%

The top two companies here are both of the hyperscaler variety, with the top being Meta, which appears rather farther down in the list of changeset contributors. While Meta does contribute a lot of patches — and significant core patches at that — it also employs the maintainers that handle a lot more patches authored by others. Arm, too, shows a bigger influence by this metric.

Developer longevity

For as long as the kernel community has existed, people have worried about its ability to attract new developers. I have often pointed out that each release features the work of roughly 300 first-time developers; the response is often to ask how long those developers stay around. The time has come to try to give at least a partial answer to that question. The plot below was generated by accumulating a list of the 5,424 developers who made their first contribution to one of the 5.x mainline kernels, then looking at how many other releases each contributed to.

[longevity plot]

What we see is that 1,943 of those first-time contributors — 36% of the total — were never seen again after contributing to one release. Another 883 developers (16%) showed up for one other release, and so on. In the end, 32% of the first-time contributors during this period have been present for at least four kernel releases. At the long tail of the distribution, there are two first-time developers (Andrii Nakryiko and Vladimir Oltean) who have only missed one release and two (Stephan Gerhold and Stefano Garzarella) who have contributed to every release from 5.0 to 6.19.

To provide one other small data point: the first-time contributors being studied here arrived between early 2019 (the 5.0 release) and mid-2022 (5.19). Of those 5,424 developers, 1,067 (just under 20%) of them contributed to at least one of the releases made in 2025. It seems reasonable to consider that group as still being active in the kernel community. Whether these results are good or bad is probably a matter for debate, but it does seem clear that, while a lot of contributors pass through quickly, others are staying around for the long haul.

The kernel community as a whole is also clearly here for the long haul; the process shows no real signs of slowing down. As of this writing, there are just short of 11,000 changesets in the linux-next repository; most of those will move into the mainline in the upcoming merge window. The next kernel, which will be called 7.0, will continue to demonstrate the community's fast pace; stay tuned for the details.

Comments (20 posted)

FOSS in times of war, scarcity, and AI

By Joe Brockmeier
February 10, 2026
FOSDEM

Michiel Leenaars, director of strategy at the NLnet Foundation, used his keynote at FOSDEM to sound warnings for the community for free and open-source software (FOSS); in particular, he talked about the threats posed by geopolitical politics, dangerous allies, and large language models (LLMs). His talk was a mix of observations and suggestions that pertain to FOSS in general and to Europe in particular as geopolitical tensions have mounted in recent months.

Leenaars began by saying that there is a lot of good open source out there, but it is not being used for good. The irony is that in trying to empower people to take control of their own computing destiny, the FOSS community has empowered the wrong people—those who would like to use software to control others. The ideals of global cooperation and reuse have enabled abuse as well.

[Michiel Leenaars]

So how did we get here? Leenaars referred back to the birth of the World Wide Web at CERN in Switzerland. The thinking was, "we should do things for the world, we should not have boundaries; let's see if we can share". Economies were booming, technology was advancing, money was being made, and parliamentary democracies were taking over. Everybody was in a positive, constructive mood. It was the "end of history", a political philosophy put forward by Francis Fukuyama in his book The End of History and the Last Man. The thesis of the book was that, with liberal democracy, humanity had reached its final form of government.

Leenaars's talk description had been shared on Hacker News well before FOSDEM; he noted that one of the comments said that it sounded like "the official obituary for the 90s techno-optimism many of us grew up on". He said that it is, in a sense.

As FOSS evolved, the community chose "dangerous allies" in the tech companies and future public cloud "hyperscalers". "We thought we could control that; it was not a realistic assumption." There was a darker narrative going on instead, he said; the US National Security Agency (NSA) was carrying out mass surveillance and spying on politicians in other countries, which came to light when Edward Snowden leaked documents that revealed the existence of those programs.

SCRAPS

Despite "this dark layer underneath", though, people, organizations, and governments in Europe were not upset enough to stop working with and trusting businesses in the US. Instead, Europe continued to depend on US tech companies, and to host its data in the public clouds anchored there. He said that Europeans felt like equals with the US, and that it was safe to trust "our friends and long-time allies" in building public clouds that it could rely on. "We can focus on our core business, and look at the total cost of ownership" instead of infrastructure.

That dependence, he said, "makes you incompetent, a victim of potential abuse". It's fine in the short term, but the pain comes afterward. If the entire European Union depends on external providers, and it does, it draws the short straw. "We don't have capacity. We are literally incompetent". CTOs were proud of "cloud-first" strategies; he proposed a different term, "strategic computer rental and anchoring to proprietary services" (SCRAPS).

Even SCRAPS are not guaranteed. Providers of cloud services can refuse to do business with an organization, or be compelled to do so. He referred to sanctions against the International Criminal Court that caused Microsoft to block the email account of the court's chief prosecutor. "We're now at the mercy of the same people who profit off of us, and they still hold the kill switch."

European people, Leenaars said, are now in panic mode and looking for government to keep society afloat. "We shouldn't have become so dependent, but that's about three decades too late". Still, many people inside governments are running toward the fire instead of away from it. He mentioned the Netherlands Ministry of Finance that has been working on a migration to Microsoft 365. The ministry has seen the whole situation, but it's put so much effort into it and has been "locked in to the same company for 50 years". A sort of Stockholm Syndrome has evolved, he said. But he agreed it has a problem with their current tools. "I filed a freedom of information request with them three months ago, and they have not been able to produce a single document". He thought it would be nice if the ministry had gained some situational awareness and would stop putting people in danger.

History did not end

The government's answer is, "let's get more European startups, lots of competitors", he said, but that is the wrong approach. "We don't need to breed more predators; we need mission-driven organizations, we need companies that are public stewards." He called for a pipeline from academia to engineering, to nonprofits and service companies that do not seek to be captive platforms. Simply having a public cloud that is owned by European businesses is not the answer if those businesses follow the same models as the US ones.

The world, Leenaars said, is in the worst shape that it's been in for decades. It turned out that history did not end after all. He talked about social media and described it as "95% FOSS and the rest is cognitive warfare". He had complaints not only about disinformation being spread online, but the short-form content that is popular today as well. Kids, he worried, were becoming dependent on short content that did not deal with complexity. "I don't fear World War III as much as I fear de-enlightenment and a subsequent second dark ages."

His next worry for FOSS was as a target for state actors in warfare. Countries are now targeting the enemy's software and devices as well as waging traditional warfare. He referenced the Lebanon electronic device attacks (dubbed "Operation Grim Beeper") carried out by Israel in September 2024; those attacks made use of pagers and two-way radios carried by Hezbollah members that had been compromised at some point in the supply chain. That had enabled Israel to eavesdrop on its targets' communications until it then detonated the devices on September 17 and 18.

He also discussed the backdooring of XZ in 2024: an attack that was conducted by "Jia Tan" after gaining trust with the original XZ maintainer over a long period of time. The average company has 25,000 software dependencies, he said, and any of them could be used to break in. There are millions of packages, and millions of people maintaining them; all of those maintainers and packages are potential weak spots. But if the new people coming in to help cannot be trusted, or if maintainers are too paranoid and chase contributors away, "we're also screwed".

Cavalry or Trojan Horse?

At this point, Leenaars said, we see horses on the horizon in the form of LLMs; is that the cavalry coming to the aid of FOSS or an army of next-generation Trojan Horses galloping through the gates of the village? The promise of LLMs is that they can take responsibility off of developers' hands, and allow organizations to focus on the core business. "That's a thing we've heard before. The product framing is super-good. Sounds so legit." He reminded the audience of the saying that there is no cloud, only other people's computers. In this context, though, he suggested: "there is no Claude, only other people's code."

Leenaars said that LLMs do a good job of some things, but claimed it was fundamentally impossible for them to do all the things they are expected to do. It is possible, he allowed, that LLM-tools could do "a lot of the janitoring we can do that humans are really weary of doing". There are, after all, many boring tasks in software development humans might like to offload. He recommended that the audience be cautious about what machines are allowed to do. Keep security in mind, and keep LLMs contained; but even then, he said he was not convinced that there was a problem that needed solving by LLMs.

Instead, if FOSS has such a large attack surface in the form of so many libraries and dependencies, trying to reduce the attack surface makes more sense than adding LLMs into the mix. It also makes sense to try to reduce maintainer burnout. He called on "people in the military who are seeing huge budgets" to spend some of that money on talented programmers who could improve FOSS and reduce its attack surface. There are billions and billions of Euros that will be invested in Europe's defenses, some of that money should be spent on FOSS. "The FOSS ecosystem should not build stuff for weapons, but should get money from people who need to defend us. We are their defense, we are their infrastructure." Europeans should be telling politicians that they do not just need to support FOSS to enable digital sovereignty, but also for defense. With that, Leenaars wrapped up the talk, without any time for questions.

Overall the talk was a bit disjointed, and Leenaars presented few concrete suggestions for the audience. But the talk seemed to resonate with the packed main room, and he touched on topics that were prevalent at FOSDEM all weekend: wariness of the changing political picture in the US, distrust of AI/LLMs, as well as a desire to reduce dependence on US companies and services.

[Thanks to the Linux Foundation, LWN's travel sponsor, for funding my travel to Brussels to attend FOSDEM.]

Comments (52 posted)

Page editor: Joe Brockmeier

Brief items

Kernel development

Kernel release status

The 6.19 kernel is out; it was released on February 8. Linus said: "No big surprises anywhere last week, so 6.19 is out as expected - just as the US prepares to come to a complete standstill later today watching the latest batch of televised commercials."

The most significant changes in 6.19 include initial support for Intel's linear address-space separation feature, support for Arm Memory system resource Partitioning And Monitoring, the listns() system call, a reworked restartable-sequences implementation, support for large block sizes in the ext4 filesystem, some networking changes for improved memory safety, the live update orchestrator, and much more. See the LWN merge-window summaries (part 1, part 2) and the KernelNewbies 6.19 page for details.

Stable updates: 6.18.9, 6.12.69, 6.6.123, 6.1.162, 5.15.199, and 5.10.249 were released on February 6, followed by 6.18.10, 6.6.124, 6.12.70, 6.1.163, 5.15.200, and 5.10.250 on February 11.

Comments (none posted)

An in-kernel machine-learning library

For those wanting more machine learning in the kernel, Viacheslav Dubeyko has posted a new in-kernel library for that purpose.

What is the goal of using ML models in Linux kernel? The main goal is to employ ML models for elaboration of a logic of particular Linux kernel subsystem based on processing data or/and an efficient subsystem configuration based on internal state of subsystem. As a result, it needs: (1) collect data for training, (2) execute ML model training phase, (3) test trained ML model, (4) use ML model for executing the inference phase. The ML model inference can be used for recommendation of Linux kernel subsystem configuration or/and for injecting a synthesized subsystem logic into kernel space (for example, eBPF logic).

It is rigorously undocumented and there are no real users, so it's not entirely clear what the purpose is, but there are undoubtedly interesting things that could be done with it.

Comments (41 posted)

Quotes of the week

It doesn't matter whether C is good or not. It matters that if I write code in two languages that aren't C, and I want it to all be part of the same process, I need to care about C. C pervades all. You cannot escape it. C will outlive all of us. The language will die and the ABI will persist. The far future will involve students learning about C just to explain their present day. Our robot overlords will use null terminated strings. C will outlive fungi.
— Matthew Garrett

Unfortunately, we haven't been able to raise enough support to continue my Smatch work. I have still been filtering zero day bot warnings and I am a bit worried that people have the impression that I'm reviewing static checker warnings when I am not.

The situation isn't great. The zero day bot can't do cross function analysis and it only looks at checks with a low false positive rate. We're missing out on a bunch of bugs.

— Dan Carpenter

If you want a CVE for your CV, come fix a Linux kernel bug! We are giving out 13 CVEs a day, plenty to go around for everyone! :)
— Greg Kroah-Hartman

Comments (none posted)

Distributions

Debian's tag2upload considered stable

Sean Whitton has announced that Debian's tag2upload service is now out of beta and ready for use by Debian developers and maintainers.

During the beta we encountered only a few significant bugs. Now that we've fixed those, our rate of successful uploads is hovering around 95%. Failures are almost always due to packaging inconsistencies that older workflows don't detect, and therefore only need fixing once per package.

We don't think you need explicit approval from your co-maintainers anymore. Your upload workflows can be different to your teammates. They can be using dput, dgit or tag2upload.

LWN covered tag2upload in July 2024.

Comments (none posted)

Linux from Scratch to drop System V versions

The Linux From Scratch (LFS) project provides step-by-step instructions on building a customized Linux system entirely from source. Historically, the project has provided separate System V and systemd editions, which gave users a choice of init systems. Bruce Dubbs has announced the project will no longer produce the System V version:

There are two reasons for this decision. The first reason is workload. No one working on LFS is paid. We rely completely on volunteers. In LFS there are 88 packages. In BLFS there are over 1000. The volume of changes from upstream is overwhelming the editors. In this release cycle that started on the 1st of September until now, there have been 70 commits to LFS and 1155 commits to BLFS (and counting). When making package updates, many packages need to be checked for both System V and systemd. When preparing for release, all packages need to be checked for each init system.

The second reason for dropping System V is that packages like GNOME and soon KDE's Plasma are building in requirements that require capabilities in systemd that are not in System V. This could potentially be worked around with another init system like OpenRC, but beyond the transition process it still does not address the ongoing workload problem.

[...] As a personal note, I do not like this decision. To me LFS is about learning how a system works. Understanding the boot process is a big part of that. systemd is about 1678 "C" files plus many data files. System V is "22" C files plus about 50 short bash scripts and data files. Yes, systemd provides a lot of capabilities, but we will be losing some things I consider important.

The next version, 13.0, is expected in March and will only focus on systemd.

Comments (27 posted)

postmarketOS FOSDEM 2026 and hackathon recap

The postmarketOS project has published a recap from FOSDEM 2026, including the FOSS on Mobile devroom, and a summary of its post-FOSDEM hackathon. This includes decisions on governance and the project's AI policy:

AI policy: our current AI policy does not state that we forbid the use of generative AI in postmarketOS, so far this document just lists why we think it is a bad idea and misaligned with the project values. We discussed this and will soon change it (via merge request) to clearly state that we don't want generative AI to be used in the project. It was also noted that currently the policy is too long, it would make sense to split it into the actual policy and still keep, but separate the reasoning from it.

[...] Power delegation and teams: in over two hours we discussed how to move forward with [postmarketOS change request] PMCR 0008 to organize ourselves better, and how it fits with soon having a legal entity. We figured that we need to rename "The Board" (which is currently for financial oversight) to "Financial Team", as we will soon have a new board for the legal entity. In the end our idea was to have the new board refer to an "assembly" for all important decisions, and this "assembly" would just be all Trusted Contributors in postmarketOS. The Core Contributors team would be dissolved in favor of having several topic-specific teams (a lot of which we already have, such as the infra team). This way we would have a very flat decision structure. The PMCR will be updated soon and discussed further there. Casey also asked on fedi for further feedback and got a lot of input.

Other topics include reaching out to resellers to sell phones with postmarketOS preinstalled, security, and more.

Comments (none posted)

Distributions quotes of the week

Even from a strict "our priorities are our users" standpoint, I think Debian's security and stability guarantees are more valuable to our users than an increase in package breadth. Users who want a package that we don't currently package have a wealth of options to install it; users who want fairly strong guarantees about consistency and security support have no good alternative if we weaken our guarantees.
— Russ Allbery

Yeah, this is a very hard problem because a LOT of software is being used in ways no one really knows. Removing said software from the distribution will only fire up a 'where did my software go???' usually 2 to 3 years after it has been removed because whatever was working fine until a hardware outage caused a full rebuild to occur or an audit requires upgrading to something supported.

I expect that Chris's ufiformat is being used by some system to run payroll for an orphanage and no one knows it. This is one of the problems of doing a 'everything including the kitchen sink' distro like Fedora and Debian. There are a lot of things which get put somewhere because it solved a problem and never needed to be updated or fixed because the problem didn't change and the solution still works. Trying to work out what those are turns out to be a lot of work because no one wants to tell you until its gone, and if they tell you you have to comply with all kinds of privacy rules to make sure you don't know who they were.

— Stephen Smoogen

Comments (none posted)

Development

Ardour 9.0 released

The Ardour digital-audio-workstation (DAW) project has announced the release of version 9.0.
This is a major release for the project, seeing several substantive new features that users have asked for over a long period of time. Region FX, clip recording, a touch-sensitive GUI, pianoroll windows, clip editing and more, not to mention dozens of bug fixes, new MIDI binding maps, improved GUI performance on macOS (for most) ...

We expect to get feedback on some of the major new features in this release, and plan to take that into account as we improve and refine them and the rest of Ardour going forward. We have no doubt that there will be both delight and disappointment with certain things - rather than assume that we don't know what we're doing, please leave us feedback on the forums so that Ardour gets better over time. Those of you new to our clip launching implementation might care to read up on the differences with Ableton Live.

In the coming weeks, we'll begin to sketch out what we have planned next for Ardour, in addition to responding to the feedback we get on this 9.0 release.

Comments (9 posted)

GTK hackfest, 2026 edition (GTK Development Blog)

Matthias Clasen has published a short summary of the GTK hackfest held prior to FOSDEM 2026. Topics include discussions on unstable APIs, a decision to bump the C runtime requirement to C11 in the next development cycle, limiting changes in GTK3 to crash and build fixes, as well as the state of accessibility:

On the accessibility side, we are somewhat worried about the state of AccessKit. The code upstream is maintained, but we haven't seen movement in the GTK implementation. We still default to the AT-SPI backend on Linux, but AccessKit is used on Windows and macOS (and possibly Android in the future); it would be nice to have consumers of the accessibility stack looking at the code and issues.

On the AT-SPI side we are still missing proper feature negotiation in the protocol; interfaces are now versioned on D-Bus, but there's no mechanism to negotiate the supported set of roles or events between toolkits, compositors, and assistive technologies, which makes running newer applications on older OS versions harder.

Comments (none posted)

Linux man pages 6.17 released

Version 6.17 of the Linux manual-page collection has been released. Along with a long list of updates to the man pages themselves, it includes some new utility programs of interest.

The grepc(1) program is something that originated in this project, as it helped me find code quickly in glibc and the Linux kernel. However, I've found it incredibly useful outside of this project. I'll take some space to announce it, as it's much more than just a tool for writing manual pages, and I expect it to be useful to most --if not all-- C programmers.

It is a command-line tool that finds C source code (for example, a function definition) in arbitrary projects. It doesn't use any indexing mechanism (unlike ctags and similar tools). This means that it can be used right after cloning some repository, without having to first generate an index.

Comments (10 posted)

Offpunk 3.0 released

Version 3.0 of the Offpunk offline-first, command-line web, Gemini, and Gopher browser has been released. Notable changes in this release include integration of the unmerdify library to "remove cruft" from web sites, the xkcdpunk standalone tool for viewing xkcd comics in the terminal, and a cookies command to enable browsing web sites (such as LWN.net) while being logged in.

Something wonderful happened on the road leading to 3.0: Offpunk became a true cooperative effort. Offpunk 3.0 is probably the first release that contains code I didn't review line-by-line. Unmerdify (by Vincent Jousse), all the translation infrastructure (by the always-present JMCS), and the community packaging effort are areas for which I barely touched the code.

So, before anything else, I want to thank all the people involved for sharing their energy and motivation. I'm very grateful for every contribution the project received. I'm also really happy to see "old names" replying from time to time on the mailing list. It makes me feel like there's an emerging Offpunk community where everybody can contribute at their own pace.

There were a lot of changes between 2.8 and 3.0, which probably means some new bugs and some regressions. We count on you, yes, you!, to report them and make 3.1 a lot more stable. It's as easy at typing "bugreport" in offpunk!

See the "Installing Offpunk" page to get started.

Comments (6 posted)

Development quote of the week

To sum up: "by using sixteen copies of our our massive language model, whose training data includes every version of GCC ever released, a warehouse full of GPUs, all the public code in the world and having it autocorrect itself by testing its output against GCC, we managed to make a C compiler that self-reports that it mostly works. This took two weeks and cost $20,000 and, gosh, I have so many feelings."
— Mike Hoye

Comments (56 posted)

Miscellaneous

Dave Farber RIP

From the NANOG list comes the sad news of the passing of Dave Farber.

His professional accomplishments and impact are almost endless, but often captured by one moniker: "grandfather of the Internet," acknowledging the foundational contributions made by his many students at the University of California, Irvine; the University of Delaware; the University of Pennsylvania; and Carnegie Mellon University.

See also: this announcement by Manny Farber on Farber's "Interesting People" list.

Comments (none posted)

Page editor: Daroc Alden

Announcements

Newsletters

Distributions and system administration

DistroWatch Weekly February 9
This week in F-Droid February 9
LineageOS Changelog 31 February 8
Linux Mint Monthly News January
openSUSE Tumbleweed Review of the Week February 6
Ubuntu Weekly Newsletter February 7

Development

Emacs News February 9
What's cooking in git.git February 5
What's cooking in git.git February 7
What's cooking in git.git February 10
This Week in GNOME February 6
GNU Tools Weekly News February 8
Golang Weekly February 6
Last Week in Kubernetes Development February 5
LibreOffice project and community recap February 9
LLVM Weekly February 9
This Week in Matrix February 6
OCaml Weekly News February 10
Perl Weekly February 9
This Week in Plasma February 7
PyCoder's Weekly February 10
Weekly Rakudo News February 9
Ruby Weekly News February 5
This Week in Rust February 4
Wikimedia Tech News February 9

Meeting minutes

Fedora FESCO meeting minutes February 10

Calls for Presentations

CFP Deadlines: February 12, 2026 to April 13, 2026

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

DeadlineEvent Dates EventLocation
February 14 April 23 OpenSUSE Open Developers Summit Prague, Czech Republic
February 15 July 13
July 19		 EuroPython Kraków, Poland
February 15 April 27
April 28		 foss-north Gothenburg, Sweden
February 20 April 25
April 26		 Sesja Linuksowa (Linux Session) Wrocław, Poland
February 23 May 27
May 28		 Embedded Recipes Nice, France
March 2 June 8
June 12		 RISC-V Summit Europe 2026 Bologna, Italy
March 10 May 2 22nd Linux Infotag Augsburg Augsburg, Germany
March 13 August 6
August 9		 FOSSY 2026 Vancouver, Canada
March 15 May 21
May 22		 Linux Security Summit North America Minneapolis, Minnesota, US
March 15 May 30
May 31		 Journées du Logiciel Libre 2026 Lyon, France
March 22 July 6 Hong Kong Open Source Conference Hong Kong, Hong Kong
March 29 May 29 Yocto Project Developer Day Nice, France

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

Upcoming Events

Events: February 12, 2026 to April 13, 2026

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

Date(s)EventLocation
February 17 AlpOSS 2026 Échirolles, France
February 24
February 25		 Linux Foundation Member Summit Napa, CA, US
March 5
March 8		 SCALE Pasadena, CA, US
March 9
March 10		 FOSSASIA Summit Bangkok, Thailand
March 16
March 17		 FOSS Backstage Berlin, Germany
March 19 Open Tech Day 26: OpenTofu Edition Nuremberg, Germany
March 23
March 26		 KubeCon + CloudNativeCon Europe Amsterdam, Netherlands
March 28 Central Pennsylvania Open Source Conference Lancaster, Pennsylvania, US
March 28
March 29		 Chemnitz Linux Days Chemnitz, Germany
April 10
April 11		 Grazer Linuxtage Graz, Austria

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

Security updates

Alert summary February 5, 2026 to February 11, 2026

Dist. ID Release Package Date
AlmaLinux ALSA-2026:2042 9 brotli 2026-02-05
AlmaLinux ALSA-2026:1825 10 curl 2026-02-05
AlmaLinux ALSA-2026:1905 10 fence-agents 2026-02-10
AlmaLinux ALSA-2026:1906 8 fence-agents 2026-02-10
AlmaLinux ALSA-2026:1903 9 fence-agents 2026-02-10
AlmaLinux ALSA-2026:2271 10 firefox 2026-02-09
AlmaLinux ALSA-2026:2230 10 fontforge 2026-02-10
AlmaLinux ALSA-2026:2039 9 fontforge 2026-02-09
AlmaLinux ALSA-2026:2222 10 freerdp 2026-02-10
AlmaLinux ALSA-2026:2081 8 freerdp 2026-02-06
AlmaLinux ALSA-2026:2048 9 freerdp 2026-02-10
AlmaLinux ALSA-2026:1690 10 kernel 2026-02-05
AlmaLinux ALSA-2026:2264 8 kernel 2026-02-09
AlmaLinux ALSA-2026:1617 9 kernel 2026-02-06
AlmaLinux ALSA-2026:2378 8 kernel-rt 2026-02-10
AlmaLinux ALSA-2026:2225 10 keylime 2026-02-10
AlmaLinux ALSA-2026:2215 8 libsoup 2026-02-09
AlmaLinux ALSA-2026:2216 9 libsoup 2026-02-10
AlmaLinux ALSA-2026:2182 10 libsoup3 2026-02-09
AlmaLinux ALSA-2026:1843 10 nodejs22 2026-02-09
AlmaLinux ALSA-2026:1842 10 nodejs24 2026-02-09
AlmaLinux ALSA-2026:1907 10 opentelemetry-collector 2026-02-10
AlmaLinux ALSA-2026:1908 9 opentelemetry-collector 2026-02-10
AlmaLinux ALSA-2026:1837 10 osbuild-composer 2026-02-09
AlmaLinux ALSA-2026:2124 8 osbuild-composer 2026-02-09
AlmaLinux ALSA-2026:1902 10 python-wheel 2026-02-05
AlmaLinux ALSA-2026:2128 8 python3 2026-02-06
AlmaLinux ALSA-2026:1828 10 python3.12 2026-02-05
AlmaLinux ALSA-2026:2090 8 python3.12-wheel 2026-02-06
AlmaLinux ALSA-2026:1939 9 python3.12-wheel 2026-02-10
AlmaLinux ALSA-2026:1831 10 qemu-kvm 2026-02-09
AlmaLinux ALSA-2026:1904 8 resource-agents 2026-02-10
AlmaLinux ALSA-2026:2286 10 thunderbird 2026-02-09
AlmaLinux ALSA-2026:2220 8 thunderbird 2026-02-10
AlmaLinux ALSA-2026:1852 8 util-linux 2026-02-10
AlmaLinux ALSA-2026:1913 9 util-linux 2026-02-10
Debian DLA-4469-1 LTS alsa-lib 2026-02-06
Debian DSA-6122-1 stable chromium 2026-02-05
Debian DLA-4467-1 LTS containerd 2026-02-05
Debian DLA-4471-1 LTS debian-security-support 2026-02-06
Debian DLA-4475-1 LTS kernel 2026-02-11
Debian DSA-6127-1 stable kernel 2026-02-09
Debian DSA-6126-1 stable kernel 2026-02-09
Debian DLA-4476-1 LTS linux-6.1 2026-02-11
Debian DLA-4477-1 LTS munge 2026-02-10
Debian DSA-6129-1 stable munge 2026-02-10
Debian DSA-6119-1 stable openjdk-25 2026-02-05
Debian DLA-4470-1 LTS phpunit 2026-02-06
Debian DLA-4474-1 LTS rlottie 2026-02-09
Debian DSA-6128-1 stable shaarli 2026-02-09
Debian DLA-4472-1 LTS sudo 2026-02-06
Debian DLA-4478-1 LTS tcpflow 2026-02-10
Debian DSA-6120-1 stable tomcat10 2026-02-05
Debian DSA-6121-1 stable tomcat11 2026-02-05
Debian DLA-4468-1 LTS tomcat9 2026-02-05
Debian DSA-6125-1 stable usbmuxd 2026-02-09
Debian DSA-6124-1 stable wireshark 2026-02-08
Debian DSA-6123-1 stable xrdp 2026-02-07
Debian DLA-4473-1 LTS zabbix 2026-02-08
Fedora FEDORA-2026-b2c7b71136 F42 accel-ppp 2026-02-11
Fedora FEDORA-2026-93a70b14d8 F43 accel-ppp 2026-02-11
Fedora FEDORA-2026-f400579a21 F43 asciinema 2026-02-10
Fedora FEDORA-2026-6388b28850 F42 atuin 2026-02-11
Fedora FEDORA-2026-f400579a21 F43 atuin 2026-02-10
Fedora FEDORA-2026-3d05d1fbaa F42 babl 2026-02-11
Fedora FEDORA-2026-f5de9aeaf1 F43 babl 2026-02-11
Fedora FEDORA-2026-34c921d252 F42 bind 2026-02-07
Fedora FEDORA-2026-34c921d252 F42 bind-dyndb-ldap 2026-02-07
Fedora FEDORA-2026-6388b28850 F42 bustle 2026-02-11
Fedora FEDORA-2026-f400579a21 F43 bustle 2026-02-10
Fedora FEDORA-2026-24ed079b30 F42 cef 2026-02-10
Fedora FEDORA-2026-792b1b7bbd F43 cef 2026-02-10
Fedora FEDORA-2026-db342a4417 F43 chromium 2026-02-08
Fedora FEDORA-2026-4dbf1cfc0a F43 endless-sky 2026-02-11
Fedora FEDORA-2026-6388b28850 F42 envision 2026-02-11
Fedora FEDORA-2026-f400579a21 F43 envision 2026-02-10
Fedora FEDORA-2026-ba7953a484 F43 ettercap 2026-02-11
Fedora FEDORA-2026-fa48aae22d F43 fapolicy-analyzer 2026-02-11
Fedora FEDORA-2026-8c36bd3dcf F42 firefox 2026-02-11
Fedora FEDORA-2026-6388b28850 F42 glycin 2026-02-11
Fedora FEDORA-2026-f400579a21 F43 glycin 2026-02-10
Fedora FEDORA-2026-cbe470dac7 F43 gnome-settings-daemon 2026-02-11
Fedora FEDORA-2026-d5c00a447f F43 gnupg2 2026-02-05
Fedora FEDORA-2026-8cde291fa0 F43 go-fdo-client 2026-02-11
Fedora FEDORA-2026-08f0f3952e F43 greenboot-rs 2026-02-11
Fedora FEDORA-2026-6388b28850 F42 greetd 2026-02-11
Fedora FEDORA-2026-f400579a21 F43 greetd 2026-02-10
Fedora FEDORA-2026-6388b28850 F42 helix 2026-02-11
Fedora FEDORA-2026-f400579a21 F43 helix 2026-02-10
Fedora FEDORA-2026-62e39bdc10 F43 hwdata 2026-02-11
Fedora FEDORA-2026-1ad57632f2 F42 java-21-openjdk 2026-02-10
Fedora FEDORA-2026-1ad57632f2 F42 java-25-openjdk 2026-02-10
Fedora FEDORA-2026-1ad57632f2 F42 java-latest-openjdk 2026-02-10
Fedora FEDORA-2026-847455954a F43 k9s 2026-02-08
Fedora FEDORA-2026-6388b28850 F42 keylime-agent-rust 2026-02-11
Fedora FEDORA-2026-f400579a21 F43 keylime-agent-rust 2026-02-10
Fedora FEDORA-2026-7039520d8a F42 kiwi 2026-02-11
Fedora FEDORA-2026-17be999f99 F43 kiwi 2026-02-11
Fedora FEDORA-2026-964c89fec4 F42 libdrm 2026-02-11
Fedora FEDORA-2026-57ba9d6f85 F42 libgit2 2026-02-08
Fedora FEDORA-2026-c0124f91bf F43 libgit2 2026-02-08
Fedora FEDORA-2026-6388b28850 F42 maturin 2026-02-11
Fedora FEDORA-2026-f400579a21 F43 maturin 2026-02-10
Fedora FEDORA-2026-2c53d4d272 F42 mingw-glib2 2026-02-08
Fedora FEDORA-2026-607c3364fd F43 mingw-glib2 2026-02-08
Fedora FEDORA-2026-6388b28850 F42 mirrorlist-server 2026-02-11
Fedora FEDORA-2026-f400579a21 F43 mirrorlist-server 2026-02-10
Fedora FEDORA-2026-126cd91d11 F42 node-exporter 2026-02-09
Fedora FEDORA-2026-9ba46f22d5 F43 node-exporter 2026-02-09
Fedora FEDORA-2026-6388b28850 F42 ntpd-rs 2026-02-11
Fedora FEDORA-2026-f400579a21 F43 ntpd-rs 2026-02-10
Fedora FEDORA-2026-92d2ec5e9b F43 ogr2osm 2026-02-11
Fedora FEDORA-2026-33c6aa1881 F42 open-vm-tools 2026-02-11
Fedora FEDORA-2026-55bb6efd14 F43 open-vm-tools 2026-02-07
Fedora FEDORA-2026-84de1534b1 F42 openqa 2026-02-06
Fedora FEDORA-2026-7eae275162 F43 perl-App-Cme 2026-02-11
Fedora FEDORA-2026-1005690ea1 F43 perl-Net-RDAP 2026-02-11
Fedora FEDORA-2026-1005690ea1 F43 perl-rdapper 2026-02-11
Fedora FEDORA-2026-3062e10d87 F42 pgadmin4 2026-02-06
Fedora FEDORA-2026-4e47f4d911 F43 pgadmin4 2026-02-05
Fedora FEDORA-2026-1d1c8f5df2 F42 phpunit10 2026-02-06
Fedora FEDORA-2026-ff411cd463 F43 phpunit10 2026-02-05
Fedora FEDORA-2026-c3b42a28dd F42 phpunit11 2026-02-06
Fedora FEDORA-2026-8ccfe50c58 F43 phpunit11 2026-02-05
Fedora FEDORA-2026-8c25940d05 F42 phpunit12 2026-02-06
Fedora FEDORA-2026-470a48f838 F43 phpunit12 2026-02-05
Fedora FEDORA-2026-8a7678fa99 F42 phpunit8 2026-02-06
Fedora FEDORA-2026-dad4e31f49 F43 phpunit8 2026-02-05
Fedora FEDORA-2026-a1cb6b0f95 F42 phpunit9 2026-02-06
Fedora FEDORA-2026-8d8a292bba F43 phpunit9 2026-02-05
Fedora FEDORA-2026-0d819a3a70 F42 plantuml 2026-02-09
Fedora FEDORA-2026-e25e1b1d0f F43 plantuml 2026-02-09
Fedora FEDORA-2026-b1cf13226b F42 polymake 2026-02-11
Fedora FEDORA-2026-8194bb5c8c F43 polymake 2026-02-11
Fedora FEDORA-2026-c1832f0a55 F43 python-requests-ratelimiter 2026-02-11
Fedora FEDORA-2026-eb55353491 F42 python-tqdm 2026-02-11
Fedora FEDORA-2026-274eb5a4b6 F43 python-tqdm 2026-02-11
Fedora FEDORA-2026-f5514402fd F42 python3.6 2026-02-10
Fedora FEDORA-2026-d68ca022b1 F43 python3.6 2026-02-10
Fedora FEDORA-2026-6388b28850 F42 rust-add-determinism 2026-02-11
Fedora FEDORA-2026-f400579a21 F43 rust-add-determinism 2026-02-10
Fedora FEDORA-2026-6388b28850 F42 rust-afterburn 2026-02-11
Fedora FEDORA-2026-f400579a21 F43 rust-afterburn 2026-02-10
Fedora FEDORA-2026-6388b28850 F42 rust-ambient-id 2026-02-11
Fedora FEDORA-2026-f400579a21 F43 rust-ambient-id 2026-02-10
Fedora FEDORA-2026-6388b28850 F42 rust-app-store-connect 2026-02-11
Fedora FEDORA-2026-f400579a21 F43 rust-app-store-connect 2026-02-10
Fedora FEDORA-2026-6388b28850 F42 rust-bat 2026-02-11
Fedora FEDORA-2026-f400579a21 F43 rust-bat 2026-02-10
Fedora FEDORA-2026-6388b28850 F42 rust-below 2026-02-11
Fedora FEDORA-2026-f400579a21 F43 rust-below 2026-02-10
Fedora FEDORA-2026-6388b28850 F42 rust-btrd 2026-02-11
Fedora FEDORA-2026-f400579a21 F43 rust-btrd 2026-02-10
Fedora FEDORA-2026-6388b28850 F42 rust-busd 2026-02-11
Fedora FEDORA-2026-f400579a21 F43 rust-busd 2026-02-10
Fedora FEDORA-2026-6388b28850 F42 rust-bytes 2026-02-11
Fedora FEDORA-2026-f400579a21 F43 rust-bytes 2026-02-10
Fedora FEDORA-2026-6388b28850 F42 rust-cargo-c 2026-02-11
Fedora FEDORA-2026-f400579a21 F43 rust-cargo-c 2026-02-10
Fedora FEDORA-2026-6388b28850 F42 rust-cargo-deny 2026-02-11
Fedora FEDORA-2026-f400579a21 F43 rust-cargo-deny 2026-02-10
Fedora FEDORA-2026-6388b28850 F42 rust-coreos-installer 2026-02-11
Fedora FEDORA-2026-f400579a21 F43 rust-coreos-installer 2026-02-10
Fedora FEDORA-2026-6388b28850 F42 rust-crypto-auditing-agent 2026-02-11
Fedora FEDORA-2026-f400579a21 F43 rust-crypto-auditing-agent 2026-02-10
Fedora FEDORA-2026-6388b28850 F42 rust-crypto-auditing-client 2026-02-11
Fedora FEDORA-2026-f400579a21 F43 rust-crypto-auditing-client 2026-02-10
Fedora FEDORA-2026-6388b28850 F42 rust-crypto-auditing-event-broker 2026-02-11
Fedora FEDORA-2026-f400579a21 F43 rust-crypto-auditing-event-broker 2026-02-10
Fedora FEDORA-2026-6388b28850 F42 rust-crypto-auditing-log-parser 2026-02-11
Fedora FEDORA-2026-f400579a21 F43 rust-crypto-auditing-log-parser 2026-02-10
Fedora FEDORA-2026-6388b28850 F42 rust-dua-cli 2026-02-11
Fedora FEDORA-2026-f400579a21 F43 rust-dua-cli 2026-02-10
Fedora FEDORA-2026-6388b28850 F42 rust-eif_build 2026-02-11
Fedora FEDORA-2026-f400579a21 F43 rust-eif_build 2026-02-10
Fedora FEDORA-2026-6388b28850 F42 rust-git-delta 2026-02-11
Fedora FEDORA-2026-f400579a21 F43 rust-git-delta 2026-02-10
Fedora FEDORA-2026-6388b28850 F42 rust-git-interactive-rebase-tool 2026-02-11
Fedora FEDORA-2026-f400579a21 F43 rust-git-interactive-rebase-tool 2026-02-10
Fedora FEDORA-2026-6388b28850 F42 rust-git2 2026-02-11
Fedora FEDORA-2026-f400579a21 F43 rust-git2 2026-02-10
Fedora FEDORA-2026-6388b28850 F42 rust-gst-plugin-dav1d 2026-02-11
Fedora FEDORA-2026-f400579a21 F43 rust-gst-plugin-dav1d 2026-02-10
Fedora FEDORA-2026-6388b28850 F42 rust-gst-plugin-reqwest 2026-02-11
Fedora FEDORA-2026-f400579a21 F43 rust-gst-plugin-reqwest 2026-02-10
Fedora FEDORA-2026-6388b28850 F42 rust-heatseeker 2026-02-11
Fedora FEDORA-2026-f400579a21 F43 rust-heatseeker 2026-02-10
Fedora FEDORA-2026-6388b28850 F42 rust-ingredients 2026-02-11
Fedora FEDORA-2026-f400579a21 F43 rust-ingredients 2026-02-10
Fedora FEDORA-2026-6388b28850 F42 rust-jsonwebtoken 2026-02-11
Fedora FEDORA-2026-f400579a21 F43 rust-jsonwebtoken 2026-02-10
Fedora FEDORA-2026-6388b28850 F42 rust-lsd 2026-02-11
Fedora FEDORA-2026-f400579a21 F43 rust-lsd 2026-02-10
Fedora FEDORA-2026-6388b28850 F42 rust-monitord 2026-02-11
Fedora FEDORA-2026-f400579a21 F43 rust-monitord 2026-02-10
Fedora FEDORA-2026-6388b28850 F42 rust-monitord-exporter 2026-02-11
Fedora FEDORA-2026-f400579a21 F43 rust-monitord-exporter 2026-02-10
Fedora FEDORA-2026-6388b28850 F42 rust-muvm 2026-02-11
Fedora FEDORA-2026-f400579a21 F43 rust-muvm 2026-02-10
Fedora FEDORA-2026-6388b28850 F42 rust-nu 2026-02-11
Fedora FEDORA-2026-f400579a21 F43 rust-nu 2026-02-10
Fedora FEDORA-2026-6388b28850 F42 rust-num-conv 2026-02-11
Fedora FEDORA-2026-f400579a21 F43 rust-num-conv 2026-02-10
Fedora FEDORA-2026-6388b28850 F42 rust-onefetch 2026-02-11
Fedora FEDORA-2026-f400579a21 F43 rust-onefetch 2026-02-10
Fedora FEDORA-2026-6388b28850 F42 rust-oo7-cli 2026-02-11
Fedora FEDORA-2026-f400579a21 F43 rust-oo7-cli 2026-02-10
Fedora FEDORA-2026-6388b28850 F42 rust-pleaser 2026-02-11
Fedora FEDORA-2026-f400579a21 F43 rust-pleaser 2026-02-10
Fedora FEDORA-2026-6388b28850 F42 rust-pore 2026-02-11
Fedora FEDORA-2026-f400579a21 F43 rust-pore 2026-02-10
Fedora FEDORA-2026-6388b28850 F42 rust-pretty-git-prompt 2026-02-11
Fedora FEDORA-2026-f400579a21 F43 rust-pretty-git-prompt 2026-02-10
Fedora FEDORA-2026-6388b28850 F42 rust-procs 2026-02-11
Fedora FEDORA-2026-f400579a21 F43 rust-procs 2026-02-10
Fedora FEDORA-2026-6388b28850 F42 rust-rbspy 2026-02-11
Fedora FEDORA-2026-f400579a21 F43 rust-rbspy 2026-02-10
Fedora FEDORA-2026-6388b28850 F42 rust-rbw 2026-02-11
Fedora FEDORA-2026-f400579a21 F43 rust-rbw 2026-02-10
Fedora FEDORA-2026-6388b28850 F42 rust-rd-agent 2026-02-11
Fedora FEDORA-2026-f400579a21 F43 rust-rd-agent 2026-02-10
Fedora FEDORA-2026-6388b28850 F42 rust-rd-hashd 2026-02-11
Fedora FEDORA-2026-f400579a21 F43 rust-rd-hashd 2026-02-10
Fedora FEDORA-2026-6388b28850 F42 rust-redlib 2026-02-11
Fedora FEDORA-2026-f400579a21 F43 rust-redlib 2026-02-10
Fedora FEDORA-2026-6388b28850 F42 rust-resctl-bench 2026-02-11
Fedora FEDORA-2026-f400579a21 F43 rust-resctl-bench 2026-02-10
Fedora FEDORA-2026-6388b28850 F42 rust-resctl-demo 2026-02-11
Fedora FEDORA-2026-f400579a21 F43 rust-resctl-demo 2026-02-10
Fedora FEDORA-2026-6388b28850 F42 rust-routinator 2026-02-11
Fedora FEDORA-2026-f400579a21 F43 rust-routinator 2026-02-10
Fedora FEDORA-2026-6388b28850 F42 rust-sccache 2026-02-11
Fedora FEDORA-2026-f400579a21 F43 rust-sccache 2026-02-10
Fedora FEDORA-2026-6388b28850 F42 rust-scx_layered 2026-02-11
Fedora FEDORA-2026-f400579a21 F43 rust-scx_layered 2026-02-10
Fedora FEDORA-2026-6388b28850 F42 rust-scx_rustland 2026-02-11
Fedora FEDORA-2026-f400579a21 F43 rust-scx_rustland 2026-02-10
Fedora FEDORA-2026-6388b28850 F42 rust-scx_rusty 2026-02-11
Fedora FEDORA-2026-f400579a21 F43 rust-scx_rusty 2026-02-10
Fedora FEDORA-2026-6388b28850 F42 rust-sequoia-chameleon-gnupg 2026-02-11
Fedora FEDORA-2026-f400579a21 F43 rust-sequoia-chameleon-gnupg 2026-02-10
Fedora FEDORA-2026-6388b28850 F42 rust-sequoia-keystore-server 2026-02-11
Fedora FEDORA-2026-f400579a21 F43 rust-sequoia-keystore-server 2026-02-10
Fedora FEDORA-2026-6388b28850 F42 rust-sequoia-octopus-librnp 2026-02-11
Fedora FEDORA-2026-f400579a21 F43 rust-sequoia-octopus-librnp 2026-02-10
Fedora FEDORA-2026-6388b28850 F42 rust-sequoia-sq 2026-02-11
Fedora FEDORA-2026-f400579a21 F43 rust-sequoia-sq 2026-02-10
Fedora FEDORA-2026-6388b28850 F42 rust-sevctl 2026-02-11
Fedora FEDORA-2026-f400579a21 F43 rust-sevctl 2026-02-10
Fedora FEDORA-2026-6388b28850 F42 rust-shadow-rs 2026-02-11
Fedora FEDORA-2026-f400579a21 F43 rust-shadow-rs 2026-02-10
Fedora FEDORA-2026-6388b28850 F42 rust-sigul-pesign-bridge 2026-02-11
Fedora FEDORA-2026-f400579a21 F43 rust-sigul-pesign-bridge 2026-02-10
Fedora FEDORA-2026-f400579a21 F43 rust-snpguest 2026-02-10
Fedora FEDORA-2026-6388b28850 F42 rust-speakersafetyd 2026-02-11
Fedora FEDORA-2026-f400579a21 F43 rust-speakersafetyd 2026-02-10
Fedora FEDORA-2026-6388b28850 F42 rust-tealdeer 2026-02-11
Fedora FEDORA-2026-f400579a21 F43 rust-tealdeer 2026-02-10
Fedora FEDORA-2026-6388b28850 F42 rust-time 2026-02-11
Fedora FEDORA-2026-f400579a21 F43 rust-time 2026-02-10
Fedora FEDORA-2026-6388b28850 F42 rust-time-core 2026-02-11
Fedora FEDORA-2026-f400579a21 F43 rust-time-core 2026-02-10
Fedora FEDORA-2026-6388b28850 F42 rust-time-macros 2026-02-11
Fedora FEDORA-2026-f400579a21 F43 rust-time-macros 2026-02-10
Fedora FEDORA-2026-6388b28850 F42 rust-tokei 2026-02-11
Fedora FEDORA-2026-f400579a21 F43 rust-tokei 2026-02-10
Fedora FEDORA-2026-6388b28850 F42 rust-weezl 2026-02-11
Fedora FEDORA-2026-f400579a21 F43 rust-weezl 2026-02-10
Fedora FEDORA-2026-6388b28850 F42 rust-wiremix 2026-02-11
Fedora FEDORA-2026-f400579a21 F43 rust-wiremix 2026-02-10
Fedora FEDORA-2026-6388b28850 F42 rust-ybaas 2026-02-11
Fedora FEDORA-2026-f400579a21 F43 rust-ybaas 2026-02-10
Fedora FEDORA-2026-6388b28850 F42 rustup 2026-02-11
Fedora FEDORA-2026-f400579a21 F43 rustup 2026-02-10
Fedora FEDORA-2026-6388b28850 F42 sad 2026-02-11
Fedora FEDORA-2026-f400579a21 F43 sad 2026-02-10
Fedora FEDORA-2026-8f6a77c7d9 F42 strawberry 2026-02-11
Fedora FEDORA-2026-069be90e7d F43 strawberry 2026-02-11
Fedora FEDORA-2026-326d72dbcf F43 systemd 2026-02-11
Fedora FEDORA-2026-6388b28850 F42 tbtools 2026-02-11
Fedora FEDORA-2026-f400579a21 F43 tbtools 2026-02-10
Fedora FEDORA-2026-535d92a4a5 F43 transmission 2026-02-11
Fedora FEDORA-2026-cb46a401b0 F42 trustedqsl 2026-02-11
Fedora FEDORA-2026-25456a0023 F43 trustedqsl 2026-02-11
Fedora FEDORA-2026-6388b28850 F42 tuigreet 2026-02-11
Fedora FEDORA-2026-f400579a21 F43 tuigreet 2026-02-10
Fedora FEDORA-2026-6388b28850 F42 uv 2026-02-11
Fedora FEDORA-2026-f400579a21 F43 uv 2026-02-10
Fedora FEDORA-2026-24091e6ead F42 vdr-extrecmenung 2026-02-11
Fedora FEDORA-2026-b9d1bc0a13 F43 vdr-extrecmenung 2026-02-11
Fedora FEDORA-2026-b409dad73e F42 xorgxrdp 2026-02-08
Fedora FEDORA-2026-febea89ac3 F43 xorgxrdp 2026-02-08
Fedora FEDORA-2026-b409dad73e F42 xrdp 2026-02-08
Fedora FEDORA-2026-febea89ac3 F43 xrdp 2026-02-08
Fedora FEDORA-2026-2809f801f3 F42 yarnpkg 2026-02-06
Fedora FEDORA-2026-a75abb3f2b F43 yarnpkg 2026-02-05
Mageia MGASA-2026-0031 9 expat 2026-02-04
Mageia MGASA-2026-0034 9 fontforge 2026-02-09
Mageia MGASA-2026-0033 9 nginx 2026-02-09
Mageia MGASA-2026-0032 9 python-django 2026-02-06
Oracle ELSA-2026-2389 OL8 brotli 2026-02-11
Oracle ELSA-2026-1905 OL10 fence-agents 2026-02-06
Oracle ELSA-2026-2271 OL10 firefox 2026-02-09
Oracle ELSA-2026-2230 OL10 fontforge 2026-02-09
Oracle ELSA-2026-2222 OL10 freerdp 2026-02-09
Oracle ELSA-2026-2323 OL8 git-lfs 2026-02-11
Oracle ELSA-2026-1838 OL10 image-builder 2026-02-06
Oracle ELSA-2026-0931 OL7 java-1.8.0-openjdk 2026-02-11
Oracle ELSA-2026-2282 OL10 kernel 2026-02-11
Oracle ELSA-2026-50100 OL7 kernel 2026-02-09
Oracle ELSA-2026-50100 OL8 kernel 2026-02-09
Oracle ELSA-2026-50100 OL8 kernel 2026-02-09
Oracle ELSA-2026-2264 OL8 kernel 2026-02-11
Oracle ELSA-2026-50095 OL9 kernel 2026-02-06
Oracle ELSA-2026-50095 OL9 kernel 2026-02-06
Oracle ELSA-2026-50094 OL9 kernel 2026-02-09
Oracle ELSA-2026-2212 OL9 kernel 2026-02-11
Oracle ELSA-2026-2225 OL10 keylime 2026-02-09
Oracle ELSA-2026-2224 OL9 keylime 2026-02-09
Oracle ELSA-2026-2215 OL8 libsoup 2026-02-11
Oracle ELSA-2026-2216 OL9 libsoup 2026-02-09
Oracle ELSA-2026-2182 OL10 libsoup3 2026-02-06
Oracle ELSA-2026-2410 OL10 libsoup3 2026-02-11
Oracle ELSA-2026-2420 OL8 nodejs:24 2026-02-11
Oracle ELSA-2026-2124 OL8 osbuild-composer 2026-02-06
Oracle ELSA-2026-1537 OL7 python 2026-02-09
Oracle ELSA-2026-2419 OL8 python3.12 2026-02-11
Oracle ELSA-2026-1831 OL10 qemu-kvm 2026-02-04
Oracle ELSA-2026-2286 OL10 thunderbird 2026-02-09
Oracle ELSA-2026-2220 OL8 thunderbird 2026-02-11
Oracle ELSA-2026-50094 uek-kernel 2026-02-09
Oracle ELSA-2026-1852 OL8 util-linux 2026-02-04
Red Hat RHSA-2026:1240-01 EL8 fence-agents 2026-02-11
Red Hat RHSA-2026:2279-01 EL8.4 fence-agents 2026-02-11
Red Hat RHSA-2026:1803-01 EL8.4 fence-agents 2026-02-11
Red Hat RHSA-2026:1792-01 EL8.6 fence-agents 2026-02-11
Red Hat RHSA-2026:1791-01 EL8.8 fence-agents 2026-02-11
Red Hat RHSA-2026:1239-01 EL9 fence-agents 2026-02-11
Red Hat RHSA-2026:1734-01 EL9.0 fence-agents 2026-02-11
Red Hat RHSA-2026:1735-01 EL9.2 fence-agents 2026-02-11
Red Hat RHSA-2026:1717-01 EL9.4 fence-agents 2026-02-11
Red Hat RHSA-2026:1706-01 EL9.6 fence-agents 2026-02-11
Red Hat RHSA-2026:1838-01 EL10 image-builder 2026-02-09
Red Hat RHSA-2026:0786-01 EL10 kernel 2026-02-05
Red Hat RHSA-2026:0747-01 EL10.0 kernel 2026-02-05
Red Hat RHSA-2026:0444-01 EL8 kernel 2026-02-05
Red Hat RHSA-2026:0643-01 EL8.2 kernel 2026-02-05
Red Hat RHSA-2026:0533-01 EL8.4 kernel 2026-02-05
Red Hat RHSA-2026:0536-01 EL8.6 kernel 2026-02-05
Red Hat RHSA-2026:0532-01 EL8.8 kernel 2026-02-05
Red Hat RHSA-2026:0576-01 EL9.0 kernel 2026-02-05
Red Hat RHSA-2026:0535-01 EL9.2 kernel 2026-02-05
Red Hat RHSA-2026:0489-01 EL9.4 kernel 2026-02-05
Red Hat RHSA-2026:0443-01 EL8 kernel-rt 2026-02-05
Red Hat RHSA-2026:0537-01 EL9.0 kernel-rt 2026-02-05
Red Hat RHSA-2026:0534-01 EL9.2 kernel-rt 2026-02-05
Red Hat RHSA-2026:1908-01 EL9 opentelemetry-collector 2026-02-05
Red Hat RHSA-2026:1837-01 EL10 osbuild-composer 2026-02-09
Red Hat RHSA-2026:1086-01 EL10 python-urllib3 2026-02-11
Red Hat RHSA-2026:1726-01 EL10.0 python-urllib3 2026-02-11
Red Hat RHSA-2026:1254-01 EL8 python-urllib3 2026-02-11
Red Hat RHSA-2026:1087-01 EL9 python-urllib3 2026-02-11
Red Hat RHSA-2026:1618-01 EL9.0 python-urllib3 2026-02-11
Red Hat RHSA-2026:1693-01 EL9.2 python-urllib3 2026-02-11
Red Hat RHSA-2026:1674-01 EL9.4 python-urllib3 2026-02-11
Red Hat RHSA-2026:1729-01 EL9.6 python-urllib3 2026-02-11
Red Hat RHSA-2026:1224-01 EL8 python3.11-urllib3 2026-02-11
Red Hat RHSA-2026:1676-01 EL8.8 python3.11-urllib3 2026-02-11
Red Hat RHSA-2026:1089-01 EL9 python3.11-urllib3 2026-02-11
Red Hat RHSA-2026:1546-01 EL9.2 python3.11-urllib3 2026-02-11
Red Hat RHSA-2026:1712-01 EL9.4 python3.11-urllib3 2026-02-11
Red Hat RHSA-2026:1704-01 EL9.6 python3.11-urllib3 2026-02-11
Red Hat RHSA-2026:1226-01 EL8 python3.12-urllib3 2026-02-11
Red Hat RHSA-2026:1088-01 EL9 python3.12-urllib3 2026-02-11
Red Hat RHSA-2026:1957-01 EL9.4 python3.12-urllib3 2026-02-11
Red Hat RHSA-2026:1619-01 EL9.6 python3.12-urllib3 2026-02-11
Red Hat RHSA-2026:2090-01 EL8 python3.12-wheel 2026-02-05
Red Hat RHSA-2026:1939-01 EL9 python3.12-wheel 2026-02-05
Red Hat RHSA-2026:1241-01 EL8 resource-agents 2026-02-11
Red Hat RHSA-2026:1805-01 EL8.4 resource-agents 2026-02-11
Red Hat RHSA-2026:1793-01 EL8.6 resource-agents 2026-02-11
Red Hat RHSA-2026:1794-01 EL8.8 resource-agents 2026-02-11
Slackware SSA:2026-037-02 openssl 2026-02-06
Slackware SSA:2026-037-01 p11 2026-02-06
SUSE SUSE-SU-2026:0384-1 SLE12 ImageMagick 2026-02-04
SUSE SUSE-SU-2026:0381-1 SLE-m5.4 SLE-m5.5 oS15.5 abseil-cpp 2026-02-04
SUSE SUSE-SU-2026:0412-1 SLE12 abseil-cpp 2026-02-10
SUSE SUSE-SU-2026:20214-1 SLE16 alloy 2026-02-05
SUSE SUSE-SU-2026:0422-1 SLE12 avahi 2026-02-11
SUSE openSUSE-SU-2026:20183-1 oS16.0 chromium 2026-02-08
SUSE openSUSE-SU-2026:0041-1 osB15 chromium 2026-02-09
SUSE openSUSE-SU-2026:0042-1 osB15 chromium 2026-02-09
SUSE openSUSE-SU-2026:10154-1 TW cockpit-354 2026-02-07
SUSE openSUSE-SU-2026:10147-1 TW cockpit-machines-346 2026-02-06
SUSE SUSE-SU-2026:0397-1 SLE-m5.2 cockpit-machines 2026-02-06
SUSE SUSE-SU-2026:0396-1 SLE-m5.2 cockpit-machines 2026-02-06
SUSE openSUSE-SU-2026:10148-1 TW cockpit-packages 2026-02-06
SUSE openSUSE-SU-2026:10155-1 TW cockpit-podman 2026-02-07
SUSE openSUSE-SU-2026:10150-1 TW cockpit-subscriptions 2026-02-06
SUSE SUSE-SU-2026:20229-1 SLE-m6.2 cups 2026-02-05
SUSE SUSE-SU-2026:20231-1 SLE16 cups 2026-02-11
SUSE SUSE-SU-2026:20209-1 SLE-m6.2 dpdk 2026-02-04
SUSE SUSE-SU-2026:20218-1 SLE16 dpdk 2026-02-05
SUSE SUSE-SU-2026:0386-1 SLE-m5.2 expat 2026-02-05
SUSE openSUSE-SU-2026:10144-1 TW expat 2026-02-05
SUSE SUSE-SU-2026:0421-1 SLE15 oS15.4 freerdp 2026-02-10
SUSE SUSE-SU-2026:0417-1 SLE15 oS15.6 freerdp 2026-02-10
SUSE openSUSE-SU-2026:10132-1 TW freerdp 2026-02-04
SUSE SUSE-SU-2026:20210-1 SLE-m6.2 glib2 2026-02-04
SUSE SUSE-SU-2026:20221-1 SLE16 glib2 2026-02-05
SUSE SUSE-SU-2026:20232-1 SLE16 golang-github-prometheus-prometheus 2026-02-11
SUSE SUSE-SU-2026:0403-1 oS15.6 govulncheck-vulndb 2026-02-09
SUSE openSUSE-SU-2026:10133-1 TW java-11-openj9 2026-02-04
SUSE SUSE-SU-2026:0414-1 SLE15 oS15.6 java-11-openjdk 2026-02-10
SUSE openSUSE-SU-2026:10134-1 TW java-17-openj9 2026-02-04
SUSE SUSE-SU-2026:0415-1 SLE15 oS15.4 oS15.6 java-17-openjdk 2026-02-10
SUSE SUSE-SU-2026:0382-1 SLE12 java-1_8_0-ibm 2026-02-04
SUSE SUSE-SU-2026:0390-1 SLE15 oS15.6 java-1_8_0-ibm 2026-02-05
SUSE SUSE-SU-2026:0389-1 SLE15 oS15.6 java-1_8_0-openj9 2026-02-05
SUSE openSUSE-SU-2026:10135-1 TW java-1_8_0-openj9 2026-02-04
SUSE openSUSE-SU-2026:10136-1 TW java-1_8_0-openjdk 2026-02-04
SUSE openSUSE-SU-2026:10137-1 TW java-21-openj9 2026-02-04
SUSE SUSE-SU-2026:20215-1 SLE16 java-25-openjdk 2026-02-05
SUSE SUSE-SU-2026:0385-1 SLE11 kernel 2026-02-04
SUSE SUSE-SU-2026:0411-1 SLE15 SLE-m5.3 SLE-m5.4 kernel 2026-02-10
SUSE SUSE-SU-2026:20220-1 SLE16 kernel 2026-02-05
SUSE SUSE-SU-2026:20228-1 SLE16 kernel 2026-02-05
SUSE SUSE-SU-2026:20207-1 SLE16 SLE-m6.2 kernel 2026-02-04
SUSE SUSE-SU-2026:0399-1 SLE15 oS15.6 kubernetes-old 2026-02-06
SUSE openSUSE-SU-2026:10146-1 TW libpainter0 2026-02-05
SUSE openSUSE-SU-2026:10157-1 TW libsnmp45-32bit 2026-02-07
SUSE openSUSE-SU-2026:10139-1 TW libsoup-3_0-0 2026-02-04
SUSE SUSE-SU-2026:20205-1 SLE-m6.2 libsoup 2026-02-04
SUSE SUSE-SU-2026:20212-1 SLE16 libsoup 2026-02-05
SUSE SUSE-SU-2026:0418-1 SLE-m5.2 libsoup2 2026-02-10
SUSE SUSE-SU-2026:0419-1 SLE12 libsoup2 2026-02-10
SUSE SUSE-SU-2026:0391-1 SLE-m5.5 oS15.5 oS15.6 libxml2 2026-02-05
SUSE SUSE-SU-2026:20233-1 SLE16 libxml2 2026-02-11
SUSE openSUSE-SU-2026:20178-1 oS16.0 libxml2 2026-02-06
SUSE openSUSE-SU-2026:10162-1 TW localsearch 2026-02-08
SUSE openSUSE-SU-2026:10156-1 TW micropython 2026-02-07
SUSE openSUSE-SU-2026:10159-1 TW opencloud-server 2026-02-07
SUSE SUSE-SU-2026:20211-1 SLE-m6.2 openssl-3 2026-02-04
SUSE SUSE-SU-2026:20223-1 SLE16 openssl-3 2026-02-05
SUSE openSUSE-SU-2026:10140-1 TW patch 2026-02-04
SUSE openSUSE-SU-2026:0037-1 osB15 python-Django 2026-02-05
SUSE openSUSE-SU-2026:20184-1 oS16.0 python-django 2026-02-08
SUSE openSUSE-SU-2026:0038-1 osB15 python-djangorestframework 2026-02-07
SUSE SUSE-SU-2026:20216-1 SLE16 python-filelock 2026-02-05
SUSE openSUSE-SU-2026:20180-1 oS16.0 python-maturin 2026-02-06
SUSE SUSE-SU-2026:0420-1 SLE12 python-pip 2026-02-10
SUSE SUSE-SU-2026:20217-1 SLE16 python-wheel 2026-02-05
SUSE openSUSE-SU-2026:10160-1 TW python311-Django 2026-02-07
SUSE openSUSE-SU-2026:10151-1 TW python311-wheel 2026-02-06
SUSE openSUSE-SU-2026:10145-1 TW python312-Django6 2026-02-05
SUSE openSUSE-SU-2026:10152-1 TW python315 2026-02-06
SUSE SUSE-SU-2026:0383-1 SLE15 oS15.4 oS15.6 rekor 2026-02-04
SUSE openSUSE-SU-2026:10141-1 TW rizin 2026-02-04
SUSE SUSE-SU-2026:0395-1 SLE12 sqlite3 2026-02-06
SUSE SUSE-SU-2026:0388-1 SLE15 oS15.6 thunderbird 2026-02-05
SUSE openSUSE-SU-2026:10143-1 TW traefik2 2026-02-05
SUSE SUSE-SU-2026:20206-1 SLE-m6.2 udisks2 2026-02-04
SUSE SUSE-SU-2026:20213-1 SLE16 udisks2 2026-02-05
SUSE SUSE-SU-2026:20222-1 SLE16 wireshark 2026-02-05
SUSE SUSE-SU-2026:0394-1 SLE-m5.3 SLE-m5.4 oS15.4 xen 2026-02-05
SUSE SUSE-SU-2026:0404-1 SLE12 xrdp 2026-02-09
SUSE openSUSE-SU-2026:20167-1 oS16.0 xrdp 2026-02-04
Ubuntu USN-8022-1 14.04 16.04 18.04 20.04 22.04 25.10 expat 2026-02-11
Ubuntu USN-8004-2 18.04 20.04 22.04 24.04 freerdp2 2026-02-09
Ubuntu USN-8012-1 24.04 gh 2026-02-04
Ubuntu USN-7942-2 14.04 16.04 18.04 20.04 glib2.0 2026-02-10
Ubuntu USN-8017-1 22.04 24.04 25.10 glib2.0 2026-02-05
Ubuntu USN-8021-1 14.04 16.04 18.04 20.04 22.04 24.04 imagemagick 2026-02-10
Ubuntu USN-8020-1 22.04 24.04 25.10 libsoup3 2026-02-09
Ubuntu USN-8013-1 20.04 22.04 linux, linux-aws, linux-azure, linux-azure-5.15, linux-gcp, linux-gke, linux-gkeop, linux-hwe-5.15, linux-ibm, linux-ibm-5.15, linux-intel-iotg, linux-intel-iotg-5.15, linux-kvm, linux-lowlatency, linux-lowlatency-hwe-5.15, linux-nvidia, linux-nvidia-tegra, linux-nvidia-tegra-5.15, linux-oracle, linux-raspi 2026-02-04
Ubuntu USN-8014-1 24.04 25.10 linux, linux-aws, linux-azure, linux-gcp, linux-oem-6.17, linux-oracle, linux-raspi, linux-realtime 2026-02-04
Ubuntu USN-8015-1 22.04 24.04 linux, linux-gke, linux-gkeop, linux-hwe-6.8, linux-oracle, linux-oracle-6.8, linux-raspi 2026-02-04
Ubuntu USN-7988-3 14.04 16.04 18.04 linux-azure, linux-azure-4.15, linux-gcp, linux-gcp-4.15 2026-02-05
Ubuntu USN-8013-2 22.04 linux-fips, linux-aws-fips, linux-azure-fips, linux-gcp-fips 2026-02-04
Ubuntu USN-8015-3 24.04 linux-fips, linux-aws-fips, linux-gcp-fips 2026-02-06
Ubuntu USN-8016-1 22.04 24.04 linux-nvidia, linux-nvidia-6.8, linux-nvidia-lowlatency 2026-02-04
Ubuntu USN-8013-3 22.04 linux-realtime, linux-intel-iot-realtime 2026-02-04
Ubuntu USN-8015-2 22.04 24.04 linux-realtime, linux-realtime-6.8, linux-raspi-realtime 2026-02-04
Ubuntu USN-8010-1 16.04 18.04 20.04 python-pip 2026-02-09
Ubuntu USN-8018-1 14.04 16.04 18.04 20.04 22.04 24.04 25.10 python3.14, python3.13, python3.12, python3.11, python3.10, python3.9, python3.8, python3.7, python3.6, python3.5, python3.4 2026-02-05
Ubuntu USN-8019-1 22.04 24.04 25.10 tracker-miners 2026-02-05
Full Story (comments: none)

Kernel patches of interest

Kernel releases

Linus Torvalds Linux 6.19 Feb 08
Freedo GNU Linux-libre 6.19-gnu Feb 09
Greg Kroah-Hartman Linux 6.18.10 Feb 11
Greg Kroah-Hartman Linux 6.18.9 Feb 06
Greg Kroah-Hartman Linux 6.12.70 Feb 11
Greg Kroah-Hartman Linux 6.12.69 Feb 06
Greg Kroah-Hartman Linux 6.6.124 Feb 11
Greg Kroah-Hartman Linux 6.6.123 Feb 06
Greg Kroah-Hartman Linux 6.1.163 Feb 11
Greg Kroah-Hartman Linux 6.1.162 Feb 06
Greg Kroah-Hartman Linux 5.15.200 Feb 11
Greg Kroah-Hartman Linux 5.15.199 Feb 06
Greg Kroah-Hartman Linux 5.10.250 Feb 11
Greg Kroah-Hartman Linux 5.10.249 Feb 06

Architecture-specific

Magnus Lindholm alpha: add support for SECCOMP and SECCOMP_FILTER Feb 05
Mukesh Kumar Chaurasiya (IBM) Rust support for powerpc Feb 05
Andrew Jones riscv: hwprobe: Introduce rva23u64 base behavior Feb 05
Menglong Dong bpf: fsession support for riscv Feb 06
Dave Hansen [v2] x86/cpu: Take Intel platform into account for old microcode checks Feb 06
Dapeng Mi Support SIMD/eGPRs/SSP registers sampling for perf Feb 09
Colton Lewis ARM64 PMU Partitioning Feb 09

Build system

Sathvika Vasireddy objtool: Fixup alternate feature relative addresses Feb 09

Core kernel

Amery Hung Remove task and cgroup local storage percpu counters Feb 04
Lyude Paul SpinLockIrq for rust Feb 05
Jason Miu Make KHO Stateless Feb 05
Qiliang Yuan Implementation of Dynamic Housekeeping & Enhanced Isolation (DHEI) Feb 06
Frederic Weisbecker tick/sched: Refactor idle cputime accounting Feb 06
Marcelo Tosatti Introduce QPW for per-cpu operations Feb 06
Ankur Arora barrier: Add smp_cond_load_{relaxed,acquire}_timeout() Feb 08
Andrei Vagin exec: inherit HWCAPs from the parent process Feb 09
Joanne Koong io_uring: add kernel-managed buffer rings Feb 09
Tim Chen Cache Aware Scheduling Feb 10
Breno Leitao workqueue: Detect stalled in-flight workers Feb 11
Leon Hwang bpf: Extend BPF syscall with common attributes support Feb 11
Pavel Begunkov BPF controlled io_uring Feb 11

Development tools

Maciej Wieczor-Retman kasan: x86: arm64: KASAN tag-based mode for x86 Feb 04
Miaohe Lin selftests/mm: add memory failure selftests Feb 06
Eugene Loh DTrace 2.0.5 Feb 09
Mathieu Desnoyers LTTng-modules 2.14.4 (Linux kernel tracer) Feb 09
Vignesh Raman drm/ci: add new jobs, uprev IGT and mesa Feb 10
Dmitry Ilvokhin mm: zone lock tracepoint instrumentation Feb 11

Device drivers

Biju Add RZ/G3L IRQC support Feb 04
Lukasz Majewski net: mtip: Add support for MTIP imx287 L2 switch driver Feb 05
Joey Lu Add support for Nuvoton MA35D1 GMAC Feb 05
Ryan Chen Add AST2700 INTC0/INTC1 support Feb 05
Marius Cristea Add support for Microchip EMC1812 Feb 05
Yulin Lu Add driver support for Eswin EIC7700 SoC SATA PHY Feb 05
Wei Fang net: fec: improve XDP copy mode and add AF_XDP zero-copy support Feb 05
Yongxing Mou phy: qcom: edp: Add DP/eDP switch for phys Feb 05
Xuyang Dong Add driver support for ESWIN eic700 SoC clock controller Feb 05
Adrian Hunter i3c: mipi-i3c-hci-pci: Enable IBI while runtime suspended for Intel controllers Feb 05
Vivek Pernamitta net: mhi: Add support to enable ethernet interface Feb 05
Langyan Ye support for taiguan-xti05101-01a MIPI-DSI panel Feb 05
Marcelo Schmitt Add SPI offload support to AD4030 Feb 05
Richard Fitzgerald ASoC: cs35l56: More support for new Dell laptops Feb 05
Miquel Raynal (Schneider Electric) spi: cadence-qspi: Add Renesas RZ/N1 support Feb 05
Manaf Meethalavalappu Pallikunhi hwmon: Add Qualcomm PMIC BCL hardware monitor driver Feb 06
André Draszik pmdomain: samsung: add support for Google GS101 Feb 05
illusion.wang nbl driver for Nebulamatrix NICs Feb 06
John Hubbard gpu: nova-core: firmware: Hopper/Blackwell support Feb 05
Honglei Huang drm/amdkfd: Add batch userptr allocation support Feb 06
Wangao Wang media: qcom: iris: encoder feature enhancements batch2 Feb 06
Tzu-Hao Wei Add eMMC PHY support for Axiado AX3000 SoC Feb 06
Xianwei Zhao via B4 Relay Add Amlogic general DMA Feb 06
Xu Yang add DWC3 i.MX driver based on flatten devicetree Feb 06
Biju Add support for Renesas RZ/G3L GBETH clocks Feb 06
Jason Gunthorpe Provide udata helpers and use them in bnxt_re Feb 05
Maíra Canal drm/vc4: Switch to DRM GPU scheduler Feb 05
Antoniu Miclaus iio: adc: ad4080: add support for AD4880 dual-channel ADC Feb 06
Svyatoslav Ryhel ASoC: tegra: Add support for WM8962 and CPCAP codecs Feb 06
Praveen Talari Enable I2C on SA8255p Qualcomm platforms Feb 06
Daniel Golle net: dsa: initial support for MaxLinear MxL862xx switches Feb 07
Zong Li RISC-V IOMMU HPM support Feb 07
Xuan Zhuo eea: Add basic driver framework for Alibaba Elastic Ethernet Adaptor Feb 08
Chuan Liu via B4 Relay clk: amlogic: Introduce A9 PLL and CCU driver support Feb 09
Koichiro Den PCI: endpoint: pci-ep-msi: Add embedded doorbell fallback Feb 09
Arkadiusz Kubalewski ice: add support for unmanaged DPLL on E830 NIC Feb 09
Gary Yang Add support for Cix Sky1 resets Feb 09
Dikshita Agarwal media: qcom: iris: Add Gen2 HFI support for SC7280 Feb 09
Cyrille Pitchen drm/microchip: add GFX2D support for SAM9X60 and SAM9X75 Feb 09
Svyatoslav Ryhel mfd: Add support for Asus Transformer embedded controller Feb 09
Jishnu Prakash Add support for QCOM SPMI PMIC5 Gen3 ADC Feb 09
Liviu Dudau iommu/io-pgtable: Add support for Arm Mali v10+ GPUs page table format Feb 09
Gatien Chevallier soc: st: add RISAB dump debug driver. Feb 09
Binbin Zhou dmaengine: Add Loongson Multi-Channel DMA controller support Feb 09
Vishnu Sankar TrackPoint doubletap enablement and user control Feb 09
Fabio Baltieri Input: cros_ec_keyb - add function key support Feb 09
Rishikesh Donadkar media: cadence,ti: CSI2RX Multistream Support Feb 10
Smita Koralahalli dax/hmem, cxl: Coordinate Soft Reserved handling with CXL and HMEM Feb 10
Tomas Melin iio: adc: ad9467: Support alternative backends Feb 10
Oleksij Rempel iio: dac: ds4424: add DS4402/DS4404 support and scale Feb 10
Jai Luthra media: Add support for Broadcom/RPi BCM2835 ISP Feb 10
Richard Acayan SDM670 LPASS LPI pin controller support Feb 09
Richard Acayan SDM670 cache controller support Feb 09
Richard Acayan Support for the Pixel 3a XL with the Tianma panel Feb 09
Michael Tretter drm/panel: add LXD M9189A Feb 10
John Madieu PCI: renesas: Add RZ/G3E PCIe controller support Feb 10
Shenwei Wang Enable Remote GPIO over RPMSG on i.MX Platform Feb 10
Frank Li media: synopsys: Add imx93 support Feb 10
Rodrigo Alencar via B4 Relay iio: amplifiers: ad8366: driver update and dt support Feb 10
Sriharsha Basavapatna RDMA/bnxt_re: Support uapi extensions Feb 10
Yunfei Dong media: mediatek: vcodec: support video decoder in mt8196 Feb 11
Odelu Kukatla Enable QoS configuration on QCS615 Feb 11
Abhinaba Rakshit Enable ICE clock scaling Feb 11
Cheng Ming Lin mtd: spi-nand: Add support for randomizer feature Feb 11
Richard Acayan SDM660 internal sound card support Feb 10
Boris Brezillon drm/panthor: Add a GEM shrinker Feb 11

Device-driver infrastructure

Cristian Ciocaltea Introduce BACKGROUND_COLOR DRM CRTC property Feb 04
Peter Colberg rust: pci: add abstractions for SR-IOV capability Feb 05
Kevin Hilman (TI) PM: QoS/pmdomains: support resume latencies for system-wide PM Feb 05
Lyude Paul Rust bindings for gem shmem + iosys_map Feb 06
Markus Probst rust: leds: add led classdev abstractions Feb 07
Joel Fernandes rust: Add CList and GPU buddy allocator bindings Feb 09
Jiri Pirko dma-buf: heaps: system: add an option to allocate explicitly decrypted memory Feb 09
Christian König Independence for dma_fences! v7 Feb 10
alistair23@gmail.com lib: Rust implementation of SPDM Feb 11

Documentation

Hans Verkuil docs: media: multicommitters model documentation Feb 05

Filesystems and block layer

Namjae Jeon ntfs filesystem remake Feb 06
Benjamin Coddington kNFSD Signed Filehandles Feb 06
Daniel Vacek btrfs: add fscrypt support Feb 06
Dorjoy Chowdhury openat2: new OPENAT2_REGULAR flag support Feb 07
T.J. Mercier kernfs: Add inotify IN_DELETE_SELF, IN_IGNORED support for files Feb 09
Alex Markuze ceph: add subvolume metrics reporting support Feb 10
Kees Cook fs: Keep long filenames in isolated slab buckets Feb 10

Memory management

Qi Zheng Eliminate Dying Memory Cgroup Feb 05
Vernon Yang Improve khugepaged scan logic Feb 07
Nhat Pham Virtual Swap Space Feb 08
Baolin Wang support batch checking of references and unmapping for large folios Feb 09
Mike Rapoport arch, mm: consolidate empty_zero_page Feb 09
Luiz Capitulino mm: thp: always enable mTHP support Feb 09
Mika Penttilä Migrate on fault for device pages Feb 11
Usama Arif mm: thp: split time allocation of page table for THPs Feb 11

Networking

Vishwanath Seshagiri virtio_net: add page_pool support Feb 04
Maxime Chevallier net: phy_port: SFP modules representation and phy_port listing Feb 05
Tariq Toukan devlink: add per-port resource support Feb 05
Marc Suñé discard ARP/NDP b/mcast/null announce (poison) Feb 04
Daniel Jurgens virtio_net: Add ethtool flow rules support Feb 04
Tom Herbert ipv6: Address ext hdr DoS vulnerabilities Feb 04
Alice Mikityanska BIG TCP without HBH in IPv6 Feb 05
Felix Maurer hsr: Implement more robust duplicate discard algorithm Feb 05
Pablo Neira Ayuso prepare for EXPR_SET_ELEM removal Feb 05
Linus Lüssing net: bridge: reduce multicast checks in fast path Feb 06
Jesper Dangaard Brouer net: sched: refactor qdisc drop reasons into dedicated tracepoint Feb 05
Rishikesh Jethwani tls: Add TLS 1.3 hardware offload support Feb 05
Allison Henderson net/rds: RDS-TCP reconnect and fanout improvements Feb 05
Vishwanath Seshagiri virtio_net: add page_pool support for buffer allocation Feb 08
Lorenzo Bianconi Add the the capability to load HW RX checsum in eBPF programs Feb 10
Chuck Lever svcrdma performance scalability enhancements Feb 10

Security-related

Jari Ruusu Announce loop-AES-v3.8h file/swap crypto package Feb 10

Virtualization and containers

Stanislav Kinsburskii Improve Hyper-V memory deposit error handling Feb 05
Jim Mattson KVM: x86: nSVM: Improve PAT virtualization Feb 05
Jim Mattson KVM: x86/pmu: Add support for AMD Host-Only/Guest-Only bits Feb 06

Miscellaneous

Steven Rostedt libtraceevent 1.9 released Feb 04
Mykyta Yatsenko bpf: Introduce resizable hash map Feb 05
Viacheslav Dubeyko Machine Learning (ML) library in Linux kernel Feb 06
Andreas Hindborg rust: xarray: add entry API with preloading Feb 06
Ian Rogers perf tool: Add evsel to perf_sample Feb 09
Leon Hwang bpf: Introduce 64bit bitops kfuncs Feb 09
Luis Augenstein add SPDX SBOM generation script Feb 10

Page editor: Joe Brockmeier


Copyright © 2026, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds