Welcome to the LWN.net Weekly Edition for October 1, 2026

This edition contains the following feature content:

• The kernel from a PostgreSQL point of view: Andres Freund's thoughts on how PostgreSQL could help the kernel project.
• Native support for Rust on the GPU: a vision for how GPUs could become an ordinary compiler target for Rust.
• The year in Plasma and what's ahead: Marco Martin's highlights on new features and upcoming developments for the Plasma desktop.
• Reducing undefined behavior in the C language: thoughts on whether C can become a memory-safe language.
• Listening to the radio with Rust: decoding radio signals with cheap hardware and Rust.
• How KDE got funding to add enterprise features: turning public funds into open-source features that benefit everyone.
• Comparing Chromium development at Google and Igalia: how contributing to Chromium works from the inside and outside of Google.

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)

The kernel from a PostgreSQL point of view

Andres Freund has a few claims to fame, but chief among them is his many years of work to improve the performance of the PostgreSQL relational database management system. That work requires working with — or around — many Linux kernel features and behaviors. He put in an appearance at the 2026 edition of Kernel Recipes to talk about his experience working with the kernel project, how the kernel could better support applications like PostgreSQL, and some interesting developments in the PostgreSQL world.

He started with a quick list of "fun" experiences he has had with Linux, starting with the fallout from the 2018 discovery that the kernel could silently lose data in response to I/O errors; he called this episode "fsyncgate". More recently, there were problems with io_uring that broke multi-process applications; he made a point of saying that he has a productive collaborative relationship with io_uring maintainer Jens Axboe that has led to solutions for many of these problems. There is, he said, a steady stream of bugs and crashes resulting from kernel changes that must be dealt with, and random performance changes that must be tracked down.

For some reason, he said, handling these problems always ends up involving him, perhaps because he likes operating-systems topics and works on the lower levels of PostgreSQL. There was a time when he thought that reading the linux-kernel mailing list would make him smarter; there is currently "some newer technology" that would appear to have come to the same conclusion, he added to a laugh from the audience. He is lucky enough to know some of the right people to ask when problems arise, but he doesn't scale and cannot always keep up with those problems.

Why are there not more PostgreSQL people interacting with kernel developers? Many of them, he said, do not know Linux well and feel unqualified to ask questions. The kernel's communication style is seen as intimidating; it has gotten better over time, but people still don't like the idea of being sworn at. It doesn't help that, if somebody brings up a problem, kernel developers will often say contradictory things; it is important to know whose opinions can be disregarded. And keeping up with the kernel is hard; he mentioned that he had only heard about the b4 tool earlier in the conference.

What's happening in PostgreSQL

There are plenty of developments within the PostgreSQL community that might be of interest to kernel developers. The project is slowly moving away from its process-centric model toward one built on threads (a topic that was covered here in 2023). Having a shared address space makes many things easier, and the performance benefits of better translation lookaside buffer (TLB) usage and faster context switches are attractive. The project also, over the long term, wants to separate database connections from the processes or threads that handle those connections.

The PostgreSQL system famously uses buffered I/O, while most high-performance database systems use direct I/O. But even PostgreSQL is slowly moving toward an asynchronous I/O model rather than "just using the page cache to hide I/O latency". He has been working on using io_uring for this purpose, but io_uring is complex, and he has been surprised at how well the model of just using a lot of worker threads can perform. There will be support for direct I/O (which requires asynchronous I/O to perform well) in the future, but it will probably never be the default. There are too many systems where PostgreSQL runs alongside other applications, and it is hard to tune direct-I/O use properly in such settings.

He has been playing with atomic writes — multi-block write operations that are guaranteed to succeed or fail in their entirety. But Linux currently only supports atomic direct I/O, which PostgreSQL does not (yet) use; he is hoping that support for buffered atomic writes will be ready soon. Proper atomic-write support will help PostgreSQL to keep its journal smaller, he said.

He has also been experimenting with time-slice extension, but it has not proved to be all that beneficial so far. The limitations on what a thread can do while requesting an extended time slice are too restrictive for PostgreSQL, so this feature cannot be used in all situations.

The good and the bad

There are, he said, a lot of "great things" happening with the Linux kernel. Writeback and reclaim have gotten much better — by a factor of two to four. The addition of RWF_ATOMIC (to request an atomic write) is a huge improvement, and io_uring is great in a number of ways. But, of course, there are some problems as well.

For example, scalability is still often a problem. He put up a slide (the full set is available) showing how a specific system performs (the number of queries processed) as the number of clients grows; it can be seen on the right. What this plot shows is that performance scales linearly with the number of clients — to a point. Then it drops and plateaus until the client count grows much larger, at which point it returns, more-or-less, to the original line.

What is happening here? The fact that this problem can be "solved" by disabling the cpuidle subsystem is a significant clue; the load is not sufficient to keep the CPUs in a high-power state, so they go idle and the performance of the system is wrecked. Only when the load grows to the point that the CPUs stay in a high-power state can the performance pick up again. That said, the real problem is likely to be the interaction of several independent factors; he hopes to write it up properly soon.

The inability to use transparent huge pages for program text hurts, he said. The READ_ONLY_THP_FOR_FS hack helps, but that option is not enabled by most distributors and, in any case, kernel developers are removing it. Without this support, performance suffers, and it can be hard to get consistent results (which is painful for benchmarking).

PostgreSQL uses futexes for synchronization between processes, but there are problems here as well. A futex provides 32 bits for application information, but that is not enough for PostgreSQL, which needs to store more state there. Futexes are also simply not that fast, with the hash lookups within the kernel taking 25% of the CPU in some cases. Normal futexes have no priority inheritance, leading to large tail latencies, but priority-inheritance futexes are not usable at all. They make even less state available and, while they do improve tail latency, the fairness built into them kills performance overall. Directed wakeups controlled by user space would help considerably, if they were available.

Out-of-memory handling in control groups is another pain point. The PostgreSQL developers like to set vm.overcommit_memory=2 on production systems (which disables overcommitment of memory, see this page for details). But that mode does not work within control groups unless the entire system is running out of memory. That makes control groups useless for administrators who want to run PostgreSQL with overcommit disabled.

PostgreSQL depends on knowing that writes of checkpoint data will succeed, so it reserves space on the storage device ahead of time, using fallocate(). But that tends to cause fragmentation, hurting performance. Each write to the disk region that was allocated that way can, on a journaling filesystem, cause journal writes as well, which also hurts. There is also the problem that allocating space in this way does not work on copy-on-write filesystems, which will try to allocate space anew when it it written to.

Some users, he said, have been using 1GB huge pages to run PostgreSQL, but that tends not to work as well as one might like. Pages that large end up creating contention on the folio head — for reference counting primarily — and that can cut performance in half.

Finally, he said that the reserved-buffers mechanism in io_uring can help performance, but they impose a 1GB limit on I/O operations. That can force PostgreSQL to use smaller writes, which hurts. Apparently Axboe has some ideas about how that situation can be improved. A related io_uring problem is that the rings themselves are charged against the process's locked-memory resource limit, but the amount required can vary between kernel versions, leading to the inability to use the feature at times.

Conclusion

Freund concluded by noting that there are a number of companies that employ both PostgreSQL developers and kernel developers; it is natural to wonder why some of those kernel developers don't help more with PostgreSQL problems. At his employer, the PostgreSQL group is off by itself and does not interact much with the rest of the company; that means it lacks influence when it comes to getting other resources to help. He suspects that the situation in other companies may be similar.

There are, he said, a number of ways in which PostgreSQL might be able to help the kernel project. Many of the problems that the database runs into are not specific to PostgreSQL; solving them will benefit many users. The testing that the PostgreSQL developers do (and could do more of) can help to identify regressions before they make it into a released kernel. And, he said, perhaps PostgreSQL developers could help the kernel community to find some better benchmarks that can identify more real-world performance problems. In the end, both PostgreSQL and the kernel are old, open-source projects; they have much in common and a lot to gain by working more closely together.

The video of this talk is available on YouTube.

[Thanks to the Linux Foundation, LWN's travel sponsor, for supporting my travel to this event.]

Comments (none posted)

Native support for Rust on the GPU

Christian Legnitto is the maintainer of rust-gpu and Rust CUDA, two libraries that make it possible to program a computer's graphics processing unit (GPU) from Rust. He isn't satisfied with the current state of GPU support in Rust, however. In a talk at RustConf 2026, he explained his vision for how the GPU could become an ordinary compiler target for normal Rust code, without the need for any special libraries or new ecosystem support. That vision is not yet fully implemented, but he does have a prototype that he is preparing to release.

Today

There are lots of existing libraries that can be used to program GPUs from Rust, including the ones Legnitto maintains. The problem with them, as he sees it, is that they start by looking at the features of the GPU and trying to represent them in Rust. This does work — these projects produce good code, which runs in production — but it causes friction where there are mismatches in expectations between the GPU and Rust. Worse, it forks the Rust ecosystem, in that projects written to use one library are usually incompatible with projects written to use a different library.

The current GPU libraries for Rust seem to implicitly assume that "GPUs are weird" and need special treatment. Legnitto doesn't think that is the case. The thing is that "CPUs are also really weird," Legnitto said, "we're just used to it." Recently, he has been exploring a different approach: start with a Rust-first design, rather than a GPU-first design. His goal is to preserve Rust's native semantics at all costs, even if that causes some inefficiency. The result, while still experimental, is a system that can run normal Rust applications, including libraries that are not intended for use on a GPU, directly on the GPU's parallel hardware.

Rust already has support for a variety of CPU architectures, each of which has its own problems and quirks. The language handles this by using zero-cost abstractions where possible, and opt-in escape hatches, target-specific compilation, and inline assembly where it isn't. The standard library is, in many ways, a facade over the various incompatible implementations of the same basic concepts.

The plan for his experiment is to do anything that the GPU can reasonably support on the GPU itself, with other operations (such as filesystem interaction, etc.) being dispatched to the host CPU. The standard library already does this on the CPU, except that operations are dispatched to the kernel, instead of a different piece of hardware. The key point is that Rust application code does not need to know or care how its requests are handled.

Tomorrow

The one part that requires more thought is the integration of concurrency primitives. The thing that GPUs do better than CPUs, and the reason to use them at all, is that the hardware supports a greater degree of parallelism. Still, Legnitto thought that the parallelism provided by GPUs mapped well to the use of processes, threads, and single instruction multiple data (SIMD) instructions in typical Rust code.

To run code on a GPU, he said, the CPU first sets any necessary configuration up, and then "launches a kernel" on the GPU. This can be considered a kind of process that is assigned some number of "blocks" and "warps" (smaller hardware units that provide concurrency) on the GPU. Multiple kernels can run at once, as long as they are assigned to different sets of warps. The difference between a GPU kernel and a CPU process is that the kernel runs on all of its assigned warps at once; it does not start on a specific CPU core. Still, there is an obvious way to remedy that: just have all but one of the running GPU kernel instances go to sleep (entering a busy loop, because they cannot sleep in the way that processes do) before handing execution off to the user's code. Legnitto acknowledged the inefficiency of that solution, but did not think it was too much of a problem.

Hardware components such as warps don't enforce the use of concurrency, Legnitto said. They describe how much concurrency is possible, but the code remains in control of how it is actually used. Anything that might normally be done with a process can be implemented by launching a kernel: "it has a lifecycle, multiple can run in parallel, there's a heap, etc.". Kernels can even launch new ones by making a request to the CPU to launch them on their behalf. So, everything that Rust code expects to be able to do with processes can be implemented in terms of kernel launches.

Similarly, GPU warps can mostly fulfill the role of threads. They have shared memory, a program counter, a stack, thread-local storage, etc. The one difference is that warps can't create new warps, since a warp is a physical piece of hardware, of which there are a fixed number. The solution is to make use of the other kernel instances that went to sleep when the kernel started executing. A warp that wants to spawn a new thread pushes a function pointer to a shared list, and then sets a flag that is checked by the busy-looping kernel instances. One of them grabs the function pointer and calls it. In that way, even though the actual number of warps is fixed, a dynamic number of Rust threads can essentially be scheduled across them.

Finally, the CPU's SIMD instructions are a perfect match for GPU "lanes" — the smallest parallel piece of hardware in the GPU, which can apply a single simple operation across multiple inputs simultaneously. On both the CPU and GPU, these represent the lowest level of concurrency, with a static hardware width and limited supported operations (mostly math). The only real difference is that GPUs tend to be wider, but CPUs vary in how wide their SIMD instructions are, so the Rust compiler already needs to handle that.

Legnitto then showed an example of what Rust code for a GPU using this approach would look like. At the time of writing, he has not shared his slides, but a simple example that spawns a thread and uses SIMD intrinsics to add four pairs of numbers at once would look like this:

    fn example() {
        let handle = thread::spawn(|| {
            let a = i32x4::from_array([10, 20, 30, 40]);
            let b = i32x4::from_array([1, 2, 3, 4]);
            let result = a + b;
            println!("SIMD Result: {:?}", result.to_array());
        });

        handle.join().unwrap();
    }

That same code would run unmodified on a CPU. Real code would typically spawn more threads and do something more interesting with them, but the fundamental operations remain the same.

This approach is not, in theory, any slower than current approaches, he said. A Rust program that spawns multiple threads which all start using SIMD should have performance equivalent to hand-written CUDA code. The real benefit is that "normal Rust stuff" just works. Existing libraries and language features are usable as-is, and can have their performance improved by incrementally adopting threading and SIMD where it makes sense, which will also benefit users running on the CPU. For truly performance-critical sections, it's still possible to drop down into inline assembly and write code for the GPU directly.

It also means that all Rust programmers become GPU programmers overnight, without having to learn anything new, Legnitto said. If a proposal like his lands, it would make Rust the largest GPU ecosystem in the world, he continued.

That's not to say that this approach is without drawbacks. For some hardware, there may be better ways to structure GPU programs that aren't compatible with Rust's model. Also, if libraries originally written for the CPU work, that might deter people from writing better GPU-specific libraries. The size of compiled binaries could also be a problem; most GPU code is short and simple compared to an entire Rust application. GPU code has become more complex over the years, he said, so he does think that all GPUs are going to need to deal with larger programs — Rust applications would just encounter the problem immediately.

Improving the language

It's also possible that adopting Rust on the GPU could motivate the design and adoption of language features that would be useful elsewhere. For example a "disjoint slice" type that allows referencing multiple non-overlapping parts of an array would be useful on both the GPU and CPU. Standard library support for tensors and matrix multiplication is another area that Rust will probably need to incorporate at some point anyway, Legnitto claimed. "Just because something is useful on GPUs doesn't mean that it's GPU-specific."

Ultimately, Legnitto believes that having first-class support for GPUs in Rust is essential to the future of the language. More software is making use of GPUs all the time, and newer CPU designs are increasingly incorporating GPU-like elements. There will always be competing software ecosystems, he said, and software that does not work well on GPUs or GPU-like CPU cores will be at a disadvantage.

There was a short time for questions. One audience member asked about whether compilers that had been optimized for CPUs really produced GPU code that worked well. Auto-vectorization for GPU code is still "pretty raw", Legnitto admitted. That is to be expected, however, given that this is the first time that LLVM is being applied in this way. There will be additional optimizations that bring performance more up to par with existing GPU toolkits, he said.

[ Thanks to the Linux Foundation, LWN.net's travel sponsor, for assistance in traveling to RustConf. ]

Comments (none posted)

The year in Plasma and what's ahead

A lot has happened in the KDE Plasma desktop environment in the last year. Marco Martin, a KDE contributor who spends most of his time working on Plasma, took the stage at Akademy 2026 in Graz, Austria to give an update on Plasma's major new features, some of the minor-but-interesting ones, and a preview of what's coming soon. The biggest upcoming change, dropping X11 support from Plasma, has been well-advertised; but there are also plans afoot to further improve remote-desktop support and more.

Numbers

Martin was introduced as being one of the contributors who has been active in Plasma development for the longest time. He began contributing, according to this interview, in 2007. But he was not at Akademy to talk about his work from days gone by on projects like Plasma Netbook; he wanted to focus on the last year of Plasma development, and how much had changed since the Akademy 2025 conference.

In that time, he said, there had been "roughly four point releases" that he was going to talk about: Plasma 6.4, which was released in June 2025, through Plasma 6.8. That release is due in mid-October to coincide with KDE's 30th anniversary. The first beta for 6.8 was announced on September 10.

He started with "some boring numbers" to provide a quantitative overview of how much work had happened since last year. Martin led with the number of bugs that were addressed: a total of 5,286 bugs reports were closed as "RESOLVED", but that includes duplicates, invalid bugs, and so forth. In total, there were 1,681 bugs that were closed with the "FIXED" status. Those, of course, were the bug reports where contributors agreed there was a problem and were able to solve it.

Martin said he had used the GitLab API to gather the number of merge requests that had been created over the past year in five project repositories under the Plasma group: KWin, Plasma Workspace, Plasma Desktop, Discover, and Union. There are many other repositories under the Plasma group, but those were the ones Martin felt were most representative of Plasma development overall. In total, there were 7,903 merge requests. The KWin window manager for the Plasma desktop received the most attention, 1,847 merge requests, "because it's a very central part [...] if it doesn't work, your screen is not displaying anything".

The Union style engine for KDE applications was at the bottom of the list, with 261 merge requests—but that number may be deceptive. Union is a relatively new addition to KDE; Arjen Hiemstra introduced it in early 2025, and the styling engine first shipped with KDE 6.7. Martin said that Union was important in solving the problem of providing a coherent visual interface for all Qt and QML applications. He noted that it had received a lot of attention over the past year, with many user-interface and usability improvements, as well as work to improve its performance. Hiemstra's May update gives a good overview of the work that had gone into Union just prior to its inclusion in Plasma 6.7.

Out of the 7,903 merge requests that were opened, a total of 6,556 were accepted, or about 82%. However, Martin warned that he was starting to see "an increase of purely LLM-generated merge requests" where it was clear that the description and code were entirely LLM-generated "and the person that is submitting it doesn't really know what the patch does". He said that it's "not that many" yet, but he felt that there was a need for an explicit AI policy so that maintainers had guidelines they could rely on and point potential contributors to. Nate Graham had started work on such a policy, but it appears that has been abandoned after the policy became a lightning rod for online criticism. Whether he, or another KDE contributor, will pick that up again is unclear.

What changed?

"Those were just numbers", Martin said; he wanted to look at some of the new features that had been introduced in Plasma and KWin and had chosen "a completely arbitrary" set of changes, starting from Plasma 6.5, to talk about. Plasma has long had light and dark themes; the 6.5 release introduced the ability to have the theme change automatically so that the light theme would be used during the day and the dark theme used at night. Users can configure the transition to happen automatically at sunrise and sunset based on the device's location, or choose the time of day to switch from dark to light and back again.

Another improvement that made its way into 6.5 is clipboard sharing between the local and remote desktops when using the remote-desktop protocol (RDP). So, for example, a user can copy text on their local desktop session and paste it into an application in the remote session. Martin mentioned that there were "many little paper-cut fixes" as well, such as visual improvements for the Sticky Notes widget, several updates to the Folder View widget, and more.

The KDE clipboard added a feature that allows users to create a QR code for sharing text to a mobile device; after copying text to the clipboard, a user can select "Show QR Code" and then scan the code with their phone or other mobile device to copy the text to the mobile device's clipboard.

New keyboard

The first change that Martin discussed in Plasma 6.6 was the official release of Plasma Keyboard, a virtual keyboard for touchscreens. It replaced the "aging and not well maintained" Maliit Keyboard that KDE had been using. "So now we have an in-house virtual keyboard that we can improve as much as we want."

Plasma has a number of clock widgets for users to choose from. In the past each clock widget had implemented similar features independently, but 6.6 introduced a new libclock library that helped to reduce the amount of code duplication, which Martin was happy about. "I really love when merge requests have more red lines than green lines. That's the best merge request." Users will also be likely to appreciate another removal: Plasma's system settings will no longer display a KDE Configuration Module (KCM) page for hardware that is not present. Previous releases of Plasma would display, for example, a Thunderbolt settings page even if a system did not have the accompanying hardware—which could be confusing for users.

The addition of the Union styling engine in 6.7 will make it much easier for developers to work with styles without having to use Qt's QStyle to implement themes. "It's just a horrible experience to code. It's thousands of lines of C++, no thanks." Instead, developers can style Plasma applications and so forth using CSS. Martin gave a shout out to Akseli Lahtinen who "suffered through the pain of doing a QStyle that understands Union themes so nobody else will have to touch QStyle anymore".

Martin also touted, once again, many paper-cut fixes in 6.7 such as better auto-hiding for panels when using multiple screens. The new virtual keyboard gained more granular controls, he said, so that users can configure it to only appear if a device is in tablet mode, or to appear when using a touch screen or a mouse.

6.8 is coming

There has been a lot of work for 6.8, he said, the first highlight of the upcoming release was "not a thing we added, but a thing that we removed: X11 support is going away". The audience applauded at some length after Martin said that. This should not come as a surprise, as it was announced by the Plasma team in November 2025. Martin said that the removal of X11-specific code will simplify maintaining Plasma's panel, taskbar, and other features, "which will also hopefully mean [they will be] much less buggy, a bit faster, and all of that".

"We also saved some microseconds in loading wallpapers", he said, "which actually matters because you could have three screens with three 4K wallpapers". Faster loading of wallpapers means that Plasma will start more quickly. The rollout of the Union styling engine continues in 6.8 with support for Qt widgets. "It's still not perfect", Martin said, but it's getting there. He thought that Plasma's default theme, Breeze, could be entirely Union-based within one or two releases.

Something that will not be visible in the 6.8 release, but will pay off later, is work to port many of Plasma's KCMs to the Kirigami user-interface library, or Framework in KDE parlance. When all of the KCMs have been ported to Kirigami components, he said, it will be possible to do a "big restyle all at once" to offer a more modern look for configuration modules used in KDE's System Settings application and elsewhere.

Martin also sped through a few new features that had appeared in KWin over the past year or so. He noted there had been "much improvement" in its screen-mirroring features, though he did not go into detail. In the 6.6 release, KWin gained the ability to allow virtual screens that are only shared on remote desktops, which allows for different color depths, refresh rates, and so forth for virtual screens that only appear via an RDP session.

A big thing that has been missing in Plasma on Wayland, he said, is the session-restore protocol; this is something that many X11 users were particularly attached to, and finally appeared in the 6.7 release. "Now, when you log out from Plasma, you can say 'save all my windows'. In Wayland we couldn't do that, now we can."

KWin 6.7 also added the ability to switch virtual desktops independently from one screen to another; prior to that release, switching of virtual desktops was always synchronized across all monitors. "It has been the one feature that I've the seen most people happy about." He said that the "various Linux YouTubers" were all talking about it, "so that's good, since it makes many users happy, apparently". He added that KWin had also seen "some improvement" in support for multiple GPUs, which would be useful for laptops that have both Intel and NVIDIA GPUs.

Questions

Martin left a good amount of time for questions. One attendee asked him what he thought the top pain points were for users of Plasma. Martin said that one would be "still a bit of a look of complexity" in some areas. He said that the defaults for Plasma and major applications like Dolphin were good, but if a user went into their settings to change defaults "all the complexity is all of a sudden thrown at you at once, still". He wanted to make it easier for users when they are "slightly outside the default". He added that multi-screen setups were still not "perfect, perfect, perfect".

Another audience member wanted a concrete example of how removing X11 had made Martin's life easier. Martin said that there was a great deal of complexity, for example, in the Plasma panels. "We had two completely different code paths for managing the positioning, the auto-hide, and whatnot on X11 and Wayland" that amounted to two completely different implementations of the same features which meant the code was "very not elegant". He also raised multi-monitor setups and managing screen configuration changes as complex with different code paths. "Only on the Wayland one could we do a nice, very reproducible autotest. The X11 one was a bit YOLO. So all that code is dead now and I'm very happy."

The video of the talk is available on media.ccc.de. The slides have not yet been published.

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

Comments (10 posted)

Reducing undefined behavior in the C language

As a professor of biomedical engineering, Martin Uecker perhaps does not fit the profile of a typical presenter at Kernel Recipes. He is, however, a longtime Linux user, and works on free software for controlling magnetic resonance imaging (MRI) scanners. He was at the conference to talk about the C programming language, the specific problem of undefined behavior in C, and whether it can eventually be made into a memory-safe language.

Why bother with C in 2026? It is, he said, still a great language. C is portable, stable over the long term, offers fast compilation, and the resulting binary code is fast. "What you see is what you get"; it is easy to look at C code and have some idea of what the computer will actually do. There are a lot of tools for working with the language, and C gets out of the way when necessary.

C does have a long history, and that affects the language as we see it today, he said. The C89 standard had to cope with a wide variety of hardware, including machines with signed-magnitude or one's-complement integer representations, segmented memory, exotic pointer representations, and surprising sizes for types. Some Honeywell machines, for example, had nine-bit bytes. That greatly complicated the task of writing a standard that would enable the writing of portable code.

The approach that was taken was to define the semantics of the language in terms of an abstract machine. All operations are to be executed as if they had run on that abstract machine, which may not exactly match the actual hardware. The observable behavior of the program must be what the abstract machine would have done. The "observable" part matters: access to volatile variables, being defined as observable, must happen exactly according to the abstract machine; everything else just has to produce the same eventual result.

The standard gives a lot of freedom to compiler implementers; only the observable behavior has to be preserved. There are many aspects of that behavior that are either undefined or implementation-defined. These are not observable behavior, and thus do not constrain what compiler implementers can do. There are, of course, other specifications that can constrain compiler developers where the C standard does not; these include ABI requirements, standards like POSIX, or the need for backward compatibility.

Undefined behavior comes about when a program does something that is either not portable or not defined by the standard at all. In such cases, the C89 standard states that it "imposes no requirements" on the implementation. Undefined behavior exists for a number of reasons. It allows implementations to support extensions, manage interactions with hardware-based safety mechanisms, and perform aggressive optimization, all while allowing difficult-to-detect errors to be ignored. It explicitly gives the compiler the right to ignore whole classes of hard-to-detect errors.

Nasal demons

The problem, Uecker said, is that the standard allows a compiler to do anything in response to undefined behavior, up to the point of invoking nasal demons. If a program contains any undefined behavior at all, according to compiler writers, then it has no expected semantics. The C++23 standard goes further to explicitly state that the standard imposes no requirements for these programs. That has led to widespread disagreements between developers about what can be expected from the language.

For example, if you zero an entire structure (perhaps with a call to memset()), then write to specific fields, what will happen if you read from any padding bytes in that structure? Might they contain security-relevant data? A 2015 survey showed that there was no consensus on what should happen in that case. Or consider this simple code:

    extern int x;

    int f(int a, int b)
    {
    	x = b ? 42 : 43;
	return a/b;
    }

If b is zero, then the return statement is a division by zero, which is undefined behavior. In this case, is the compiler entitled to omit the test entirely and just execute x = 42? After all, the b = 0 case has no expected semantics, and can thus be ignored. There are compilers that will do exactly that. In the undefined-behavior case, the store to x is not observable behavior. But now consider this case:

    extern void g(int x);

    int f(int a, int b)
    {
        g(b ? 42 : 43);
	return a/b;
    }

This might seem to be the same situation, with the compiler being entitled to remove the test and just pass 42 to g(), and some compilers have treated that way — but that compiler behavior was a bug. Imagine a definition of g() that calls exit() if b is zero. In that case, the division will never happen and the program's behavior is not undefined. So eliding the test and simply passing 42 to g() is incorrect.

One more interesting case:

    volatile int x;

    int foo(int a, int b, bool store_to_x)
    {
	if (! store_to_x)
	    return a/b;
	x = b;
	return a/b;
    }

The question here is: can the compiler hoist the final division operation above assignment to x? If there are no semantics associated with the b = 0 case, then there is no change in observable behavior. This, too, is something compilers have done, but the C23 standard added a "no time travel" stipulation to disallow it. In C++, instead, hoisting must be explicitly prevented by inserting a call to std::observable_checkpoint().

Time-travel bugs should eventually go away, but there are a lot of other situations where, even if the standard is clear, compiler writers often disagree. These include reading of uninitialized variables (which is almost always defined), and equality comparisons of pointers, which is always defined, but is also miscompiled by both Clang and GCC.

Fighting undefined behavior

To try to address all of these problems and more, the C committee runs three study groups focused specifically on the memory object model, memory safety, and undefined behavior. There are currently about 100 instances of undefined behavior in the C standard, but the in-progress C2y draft has removed 45 of them. The situation is indeed getting better.

There is an increasingly rich set of tools aimed at finding issues: compiler warnings, static analyzers, sanitizers, LLM-based tools, formal verification, and more. The number of situations where a compiler will emit a warning where possible undefined behavior is detected is growing; recent examples include better warnings for integer overflows and potential use-after-free situations. Static analyzers are available as standalone tools, but are also increasingly being built into the compilers themselves; GCC can now warn about a number of potential buffer-overflow situations, for example. Sanitizers work by inserting run-time checks; they can catch a lot of undefined behavior and, in trapping mode, be used for hardening as well.

Memory safety has never been one of C's strong points, but Uecker wanted to make the point that it can be improved. That problem breaks down into three sub-problems: type safety, spatial memory safety, and temporal memory safety.

C, he said, has a strong type system, and the remaining problems are fixable. Tagless unions, for example, can create type confusion, but the compiler can enforce types with some additional annotations. New diagnostics can catch unsafe casts from void. Type checking across translation units is traditionally not a huge problem in C, since header files are used to ensure consistent types, but the situation could be improved with a link-time checker.

Spatial memory safety — bounds checking — is a partially solved problem; the compilers can perform array-bounds checking in many situations now. In some cases, some code changes are needed to fully benefit from this checking. Use of the counted_by attribute can enable checking for flexible array members, for example.

Temporal memory safety — avoiding use-after-free bugs and the like — is harder, Uecker said, and Rust definitely has an advantage there. Still, better temporal memory-safety enforcement is possible. Architectures like CHERI can help here is well. Fil-C can find a lot of temporal-safety bugs.

Can all of these tools and language changes get us to full memory safety? Completely solving the problem will require either expensive run-time checking or formal verification, he said. In the near future, the most complete results will be had with the combination of a restricted language and formal verification tools.

Overall, he concluded, C is still a living language and is still improving. The C23 standard removed a number of problematic features, including old-style (K&R) function definitions, support for sign-magnitude and one's-complement machines, and trigraphs. It added bit-precise integer types, checked integer operations, and more. C2y will go further, adding case ranges, named for loops, the _Countof() macro to determine array lengths, and a lot of "demon removal". It will not achieve full memory safety for C, but that is an eventual possibility, and will become more practical over time. He ended by encouraging interested people to participate in the working groups.

The video and slides from this talk are available.

[Thanks to the Linux Foundation, LWN's travel sponsor, for supporting my travel for this event.]

Comments (114 posted)

Listening to the radio with Rust

Many of the transmissions sent over the radio spectrum can be decoded with a relatively cheap hardware dongle. Thomas Eckert presented at RustConf 2026 in Montreal about his hobby: decoding radio transmissions with Rust. In his presentation, he covered all of the math necessary to get started with software-defined radio, and gave demonstrations of listening to AM and FM radio, as well as decoding transmissions from aircraft transponders. His slides and example code are available on GitHub.

Eckert said that all of his demos relied on the same fundamental pipeline. He then ran a program that started picking up a FM radio station from Montreal's Mt. Royal. That signal starts as a current being applied to the transmitting antenna, pushing the electrons in the metal back and forth. A changing electric field means a changing magnetic field and vice versa; the changing field propagates out through the air until it reaches his antenna. For the FM and AM radio demos, that antenna was clipped to the side of the podium; for the aircraft demo, which uses a different wavelength, the antenna in question was located up on the roof, with the data relayed by a Raspberry Pi that the conference organizers had allowed him to place up there.

Antennas receive the entire radio spectrum at once, Eckert explained, but different antennas are more sensitive to different parts of the spectrum. Generally, for simple linear antennas, the ideal length is one quarter of the wavelength of the radio signal. The FM radio station that he had briefly tuned into was broadcasting with a wavelength of about three meters, so the ideal antenna was 77 centimeters long — exactly the length to which he had extended the silvery collapsible antenna at the podium. For aircraft transponders, the ideal length drops to about five centimeters.

No matter the length, the electrons in the receiving antenna oscillate in time with the incoming radio wave, producing a current. The software-defined radio dongle that Eckert was using — the RTL-SDR Blog V3, a small $30 device with a USB cord on one side and a coaxial antenna cable on the other — samples that current to turn the analog wave into digital data. It also has a tuning circuit that focuses on one relatively narrow slice of the radio spectrum at a time. The data that comes out of the dongle is a stream of pairs of numbers. These numbers represent two separate components of the radio wave at right angles to each other: a cosine wave (also called the "in-phase component") and a sine wave (called the "quadrature"). The dongle provides these as a continuous stream of unsigned bytes. The code centers and scales them to produce floats between -1 and +1. Combining these as a complex number gives an "I/Q" signal. The distance of an I/Q sample from the origin is the amplitude, and the speed at which successive samples rotate about the origin is the frequency.

The hardware in the dongle uses chips originally designed for television receivers, Eckert said. It only digitizes the signal as it exists; it has no circuitry for detecting amplitude modulation (AM) or frequency modulation (FM) signals. All of the decoding of the signal happens in code.

Exactly what that decoding looks like depends on the kind of signal being interpreted. The dongle produces millions of samples per second, covering a 960-kilohertz slice of the radio spectrum. That is enough bandwidth to fit five FM channels next to each other, for example. To focus on just one station, the code needs to separate out one particular frequency component to analyze. Practically, that means using a low-pass filter to attenuate out the uninteresting signals. For AM radio, which is the simplest, the audio is then encoded into changes in the amplitude of the signal. Each sample is converted into a distance from the origin, and then the whole signal is shifted and rescaled to fit into the range of signals that sound cards expect. Then the data can be put into a ring buffer for the sound card and played directly.

FM radio is slightly more complicated: the data comes from changes in the frequency. Therefore, the decoding implementation has to look at the difference in phase (angle) between the previous sample and the current sample. That data can be rescaled and played directly, but it will sound harsh and thin. That's because FM is more sensitive to small changes in the signal, which tends to introduce more noise, especially in high-frequency sounds. Therefore, FM radio stations boost the treble component of their signals to drown out the noise, and the radio receiver has to undo the transformation to get the original sound back. The boost is "75 µs" in North America and "50 µs" in Europe. That measurement doesn't actually represent a time shift; it's a short-hand convention for how to tune a resistor-capacitor circuit to shape the signal. Once the boost has been corrected for, however, the output can again be used directly as audio samples.

Eckert then went on to explain that he chose Rust because the dongle provides more than one million samples per second, so he has one microsecond per sample to do any necessary analysis. And the audio card is going to keep playing samples from its ring buffer whether or not new values have been provided — this is a real-time task that demands a language with good, predictable performance. Even a pause of a few milliseconds would cause an audible gap in the output. Working with a simple decoding pipeline like this in Rust has been pleasant, he said.

The last demonstration that he wanted to share was looking at a digital signal, rather than an analog one. Every plane with an automatic dependent surveillance-broadcast transponder, which is most of them, broadcasts telemetry information twice a second. That data is sent at a frequency of 1090 MHz, which requires a small antenna with a good view of the sky. The signal is amplitude-modulated, just like AM radio, but rather than conveying sound, the magnitude is a pattern of digital pulses. Each message starts with a recognizable eight-microsecond preamble, and lasts for a total of 120 µs, encoding 112 bits. Each bit lasts for one microsecond, and is split into two parts, called half-slots. A high-to-low transition is a one, and low-to-high transition is a zero. That way a constant signal, high or low, is not interpreted as actual data.

At the maximum frequency that Eckert's dongle samples, 2.4MHz, each half-slot is 1.2 samples wide, which puts it right on the boundary of signals that he can correctly decode. His code scans over the signal in search of something that matches the preamble, and then samples the two halves of each bit and subtracts them, to eliminate any constant bias in the signal. Then, the resulting bits are parsed into a Rust structure that encapsulates different possible messages. The code sends that structured data to a small web application that plots the received information on a map, showing each aircraft's identity, position, and velocity.

His first implementation of the decoding logic did not work well; it only found about a sixth of the information that is present in the signal, Eckert said. It took a good deal of thought to produce an implementation that was robust to interference and sampling errors. That's one thing that makes this a good hobby, he explained: there are so many things that use the radio spectrum, which means there is always something new to look at. Basic decoding of analog signals is simple enough to get working without much effort, but it's always possible to go more in-depth on better decoding methods, or to look at new types of signals.

So far, Eckert has experimented with receiving AM and FM radio, timing-synchronization signals, and aircraft transponders, but there is much more than that out there. There are weather reports, complete with weather maps, polarization-modulated digital signals, HAM radio, and many more. All one needs to start are a relatively cheap hardware dongle, a working knowledge of complex numbers, and a programming language — Rust in his case.

[ Thanks to the Linux Foundation, LWN's travel sponsor, for assistance with traveling to RustConf. ]

Comments (8 posted)

How KDE got funding to add enterprise features

The Sovereign Tech Agency (STA) is investing nearly €1.3 million in KDE through 2027. At Akademy 2026 in Graz, Austria, Nate Graham and Kevin Ottens, two of the contributors who helped bring in the investment, explained how the funding was secured, provided tips on how projects should approach organizations like STA, and talked about how that money will be improving KDE for everyone. In addition to keeping the community informed about the work, the pair hoped to pass on what they have learned to encourage others to help raise funds for development as well.

Graham is the co-owner and CEO of a KDE-focused software-development consultancy, Techpaladin Software, that specializes in doing work on KDE. He said that he also writes the "This Week in Plasma" blog posts, does other KDE promotional work, and tries to do as much software development as he still can. Ottens, who has been involved in KDE since the early 2000s, is a tech lead, manager, and partner at enioka Haute Couture, a software-development agency.

How it started

Graham said that the STA's funding of KDE is one of the largest outside investments made in the project in a long time. The funding from STA is not "a necessary thing", he said: "All of us here have been doing amazing KDE things for years. The purpose of outside investment is not to make what we do possible, but to accelerate it." He hoped that by sharing what he and Ottens had learned, "all of you can benefit by going out and getting lots more external investment for KDE".

The search for funding started, on the Techpaladin side, with the KDE Linux project created by Harald Sitter. Graham said that a bunch of people within the company and the larger community were excited about KDE Linux and its potential to transform KDE in the future. "And we realized that our vision for it required more investment from outside to realize the ambitious goals we had."

Ottens said that his company also works on projects related to KDE. The requests that it gets are often focused on KDE Plasma, Frameworks, and office applications; however, it was not receiving many KDE PIM-related requests coming from its customers. KDE PIM provides the Kontact suite of applications that includes the KMail email client, KOrganizer calendar and to-do manager, as well as the set of libraries used by the suite.

"But it turns out we like KDE PIM. We have a history with it. Some of us have even been contributing to it in the past, even in our spare time." Ottens said that it used to be popular, "but we are seeing people giving up [on it] and turning to Thunderbird". Because people at enioka liked KDE PIM, it had been discussing ways to find funds to focus on its development once again. It started by pursuing grants from the NLnet Foundation as a way to test the waters, but that did not work out.

Ottens said that enioka decided to prepare a proposal for the STA and then learned that "there was something larger brewing up" through its discussions with the board of the KDE e.V. nonprofit that supports KDE. "And so we thought we would join forces" with the e.V. and Techpaladin.

The proposal

Social relationships, Graham said, are an important part of an effort to land funding. The STA, being in Germany, where KDE is already an established institution with a good reputation, already knew about KDE. "They also liked [KDE], because we do great work and we're nice and friendly." People from STA were invited to attend Akademy in 2025, which kicked off the conversations about funding.

The parties involved wanted to find an angle that would provide funding for work on KDE Linux and KDE PIM; after some discussion, it was obvious that larger institutions were the ones that cared most about the operating system and the productivity software in KDE PIM. "Most kids these days are just on Gmail on their phones, but companies care about both these topics", Graham said. "Not just companies, but larger institutions" with managed environments that want everything to be easy to set up and "unbreakable by normal users who are maybe not very technical".

So that led to the proposal's vision: a focus on larger deployments where an enterprise would distribute laptops running the image-based KDE Linux distribution provisioned by a mobile-device-management (MDM) system to its employees. The systems would be configured automatically, including email, calendaring, and default applications, on first boot after an employee enters their email and password.

Once the group had a vision of improving KDE for larger deployments, Graham said, it was time to specify the work that would be proposed.

This is the really hard part, because it's easy to have a vision for what you want to do, but it can be very challenging to divide that into a set of actionable steps and specific projects and work packages. So this took a long time to do. We had to structure everything so that it looked plausible and the goals appeared achievable.

The process of estimating the work with price tags for each deliverable was a huge effort, he said, but it was necessary to signal that the team asking for funding was "capable of marshaling the skills of the people who are doing the work" and capable of delivering the finished product.

Ottens described the process of figuring out what work would need to be done, and then estimating its costs. The project vision, expressed as a set of bullet points, indicated what the "work packages" would be. The next step was to break the work packages into tasks, which could then be evaluated to estimate how long the work would take.

When it comes time to calculate estimates, "that's generally where we developers just run out of the room screaming". But it doesn't have to be that way; there are techniques that can help, such as three-point estimates. He said that he has a template spreadsheet that he uses to get a rough idea of how much work any task would require. Unlike the earlier phases, this requires some "light research" to figure out what it would take to implement something: "You don't have to do the actual implementation work, but you need to get into analysis."

For each task, he did a three-point estimate to generate the cost of implementation to come up with the amount of time it would take to complete a task based on the best-case, worst-case, and most-likely scenarios. So, for example, he might calculate that creating a set of tests for basic CalDAV support in KDE PIM would take five days in the most likely scenario, but only three days if all goes really well—or seven days if there are problems.

Ottens explained that he does the analysis with someone else to help challenge his assumptions, and that he looks for patterns in other people's estimates that might indicate that they have cut corners. Some developers, he said, might just come up with estimates for the amount of work they expect something to take, and then halve that number for the best-case scenario, and triple the number for the worst-case scenario.

The STA does not ask for all of the estimates that Ottens is used to generating, he said, but they do want proposal submitters to provide cost estimates. He said that STA provides a template for proposals that is "among the most friendly" he has encountered. The agency is interested in ensuring that its funds help the public interest and the community, and its templates are designed to help make that case.

It's not gatekeeping. They want you to succeed, and the Sovereign Tech Agency personnel will actually help you get there as much as they can. I didn't feel like we were doing our thing in our own corner and trying to justify it to them, right? It really felt like we were working together on that proposal.

Ultimately, the proposal was accepted by STA. Even though there are multiple parties participating in the project, the investment is granted to a single entity: in this case, KDE e.V. It is providing the administrative support, reviewing the work, and is responsible for some engineering assistance as well. When work is completed, KDE e.V. invoices the STA and disburses the money to enioka, Techpaladin, and other contractors.

What was funded?

Graham said that was "enough about the process of getting here; I know the part everybody's interested in is what was funded." One of the largest work packages funded by STA is for the QA infrastructure for Plasma and KDE Linux. "Some of you might be thinking, I don't run KDE Linux. Who cares?" The advantage to doing QA on KDE Linux, he said, is that it acts as an integration test for everything. Many parts of KDE can't be tested well in isolation, so testing KDE Linux benefits users of other distributions as well. "By way of illustration, this QA system has already detected and helped in fixing issues in KWin, KWallet, Arch Linux packaging, and even GCC itself." This work package is almost done, Graham said.

It's easy for people to accidentally mess up their Plasma desktop because it is "a very complicated piece of software", he said, though he didn't go into specifics. To help users who have broken their setup, the STA has funded work on a "safe mode" for the desktop that would make it easier, especially for non-technical people, to return Plasma to a working state. That work is in progress, he said. There is also a work package to provide a "factory reset" function for KDE Linux.

This is a very institutional-oriented feature where, let's say you're moving a device to somebody else in the same department or in a different department, or even selling the device, getting rid of it. In all of these cases, reinstalling the OS from scratch is a pain in the butt. You don't want to do that. So we're building a feature to make it a lot easier to do [a reset] for non-technical people.

Organizational support is a major theme of STA's funding overall. Graham said that there is funding for "a lot of boring stuff that people like us often don't care about" in the form of improved infrastructure for organizational usage. That means features like facial recognition for authentication, multi-factor authentication, better user experience for disk locking and encryption, as well as complete support for Secure Boot. "These are things that it's hard to get volunteers excited about because the features are pretty boring, which is why an outside investment really helps for this sort of thing."

Graham said that there is also a lot of work being done on data backup and restore systems for KDE, as well as a user interface for browsing and restoring from Btrfs snapshots. While Btrfs snapshots are not backups, he clarified, they can be useful when a user wants to quickly recover some files they had deleted. "So it's sort of a layered strategy where you have an off-device backup and you also have snapshots of different versions of your files" on the local disk. That work is already well underway—Bharadwaj Raju wrote about its status in late August.

KDE has great support for accessing network shares over NFS, Samba, SFTP, and so forth, Graham said, but only "if you restrict yourself to only ever using KDE software". The experience gets worse when a KDE user is running software like LibreOffice or Blender and tries to access files over a network share. So, part of the STA funding is dedicated to improving the network-shares experience throughout Plasma and the KDE stack.

PIM topics

Ottens said that there was one big similarity between the work on KDE PIM and KDE Linux, "we started with the QA infrastructure". He said that there were already tests for different components throughout KDE PIM, but there was a need for a good end-to-end test suite as well. That work is mostly completed, and there is now comprehensive testing for IMAP, CalDAV, and so on. There are still a few pain points, he said, on the continuous-integration (CI) side, "but apart from that it's mostly done".

The QA infrastructure was needed, Ottens said, because they are also working on the protocol support for KDE PIM. "So we needed to have that to make sure that we were not breaking something as we were adding something else." For example, there is work to improve KDE PIM support for IMAP4v2 extensions and speeding up IMAP resource synchronization. Support is also underway for WebDAV push notifications, which is a draft specification. Typically WebDAV clients poll the server for updates, but support for push notifications would allow servers to notify a client that there have been changes.

The STA is also funding work to improve the delivery of KDE PIM applications in the Flatpak format, though that work has not yet begun. Ottens said that the goal is to rework KDE PIM applications to have better integration between Flatpak-packaged data sources and the Plasma user session. Currently, Flatpak applications are "insulated" and provide poor integration with Plasma for use cases like event notifications or searching for a user's contacts in KDE PIM. "So we'll be doing some work on Plasma itself to see how to interact differently with this kind of applications, and then we will benefit from it on the Flatpak side."

Call to arms

Ottens said that there are a number of expected outcomes from the engagement with the STA. Some are technical, such as better QA for KDE, harder-to-break Plasma sessions, and more reliable, easier-to-configure software. He hoped that the end result of the work would also be more trust from users about what the KDE community produces, and more usage of KDE by business users.

If what we do here is actually a success, that means that KDE is an ecosystem, and [that] KDE is an ecosystem where you can get some money to pay your mortgages and your bills, [it] becomes a bigger pie, right? So there's more to actually get more people to get in and make a living out of it. And that's because you get more deployments, so there will be more needs. If there's more needs, there's more requests for improvements, right? So then it snowballs, hopefully.

The STA project will run through the third quarter of 2027, and then the funding comes to an end. Ottens said that the KDE community needed to keep pushing even after that, though he hoped that "most of the grueling work" would be done by then.

Questions

The first person to offer a question asked if there were any plans for instant-messaging support with KDE PIM. Ottens said there were no plans around instant messaging in the proposal, in part because things were in a "state of flux" on the server side. It was unclear which instant-messaging protocols KDE should support, and he did not feel confident in trying to pick a winner.

Another person asked about user authentication methods; since part of the work was to support enterprise authentication, the audience member wanted to know if there are plans to hand out smart cards to random KDE contributors to help test those features. Graham said that was not specifically written into the STA proposal, "but I think it makes a lot of sense to do that, especially since it's fairly exotic hardware that many of us are not going to personally possess".

One audience member asked if there were any concrete plans to spotlight the work that was happening as part of the STA funding "outside of the usual crowd" at Akademy. Graham said that they are writing a quarterly blog post series called "This Quarter in Digital Sovereignty" on KDE Blogs. The series is syndicated on Planet KDE and he encouraged everyone who is interested to help promote it. "Put it on Mastodon, put it on Reddit, put it on your aunt's smartphone". Aside from that, there were no concrete promotional plans "but we're probably going to be promoting it via the channels we have available".

Ottens added that the companies doing the work would be adding it to their portfolios and sharing it with future customers. Graham said that gets to the topic of helping KDE contributors pay the bills.

I think this is all fairly important, and especially as the community gets older and more mature, people have financial needs. It's really important to be creating opportunities for people to stay within KDE and be earning their living working on KDE, and it's a part of that.

The final question was whether there were any plans to add JMAP support to KDE PIM as part of the STA work. Ottens said that he would like to add JMAP support, but the price tag would have been too high because "we would have started from nothing". He said he would definitely like to explore JMAP support at some point, though. Graham added that it was important to remember that "when you do work like this, you can't make it a grab bag to just work on whatever you want. You have to stick to the proposal."

The slides and video from the presentation are online.

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

Comments (1 posted)

Comparing Chromium development at Google and Igalia

Sharon Yang is a Chromium developer who worked at Google on the browser and now works on it at Igalia. On the final day of FOSSY 2026, she gave a presentation on her experiences with both of those companies, comparing and contrasting the ways each one operates and how that affects work on the code base. She enjoyed working at Google and feels the same about Igalia, so the talk was not aimed at complaints—instead it was meant to give a feel for two companies that are rather different.

The talk was entitled "From Corporate to Co-op" highlighting one of the main differences between the enormous company, Google, and the employee-owned cooperative at Igalia. She is from Vancouver and went to the University of British Columbia, where FOSSY was held. While she was a student, she did an internship at Google, working on the Chrome browser, which is the Google product based on Chromium. In her slides, she showed a photo of herself—complete with propeller hat—in front of a Google sign.

When she was a student, her life was measured in semesters, but some of the people she worked with at Google had been working on Chrome for four years, which was amazing to her at the time. She ended up working at Google full-time for six years, all of it on Chrome. Most of her work was on the content layer of the browser, which is part of the open-source Chromium browser. So she works in the same repository (GitHub mirror), and with many of the same people, at Igalia as she did at Google. She briefly reflected on her time at Google: "I had a good time working on Chrome, the people were nice, I enjoyed it, it was cool, there was lunch, it was good stuff", she said to laughter.

Eventually, she thought it might be time to move on, and perhaps out of the Seattle area where she was living, so she started looking around at the end of 2024. She had seen Igalia email addresses in the code base and met some of the people from the company at the BlinkOn conferences. Igalia is an open-source consulting company that is hired to work on various things, including Chromium; it is the largest contributor to Chromium that is not a browser maker, in fact. She joined Igalia and moved back to Canada a little less than a year before the talk in August.

Contrasts

She contrasted the two companies, starting with the number of employees: Google has around 180,000, while Igalia has around 180. In terms of revenue, last year Google had more than $400 billion, "Igalia, much smaller, we'll just say under a billion dollars", which was greeted with laughter. Google is owned by institutional investors, while Igalia is owned by employees, which the audience applauded. Google has a wide range of compensation, from the CEO's $600 million salary package to her pay (somewhere in the range of $100,000-$300,000) when she worked there; at Igalia, all employees are paid the same, top to bottom and across the globe.

While they are "massively different entities", both companies have teams working on things in common; she works on Chromium, but there are also teams from each working on accessibility and on web standards.

Chrome and Chromium are "kind of the same, they're kind of not". Chrome is a Google product, with Google branding and colors, while Chromium is an open-source project that anyone can use to build a browser. Chromium is missing proprietary pieces like digital rights management (DRM), "AI integration", and certain codecs; "and it's blue". There are various other browsers based on Chromium, including Microsoft Edge and Brave, as well.

Most of the Google Chrome team members do most or all of their work in the Chromium repository. Obviously, the proprietary pieces are handled elsewhere, but she and other Google Chrome developers rarely have to interact with that code. Near the end of her time at Google, she had to get help to do a simple task that required access to the "totally different universe" where the proprietary parts live.

She then compared the experience of working for the two companies. The first week is pretty much the same at any new job, she said. The initial steps are getting to know your coworkers, reading internal documentation, learning how to communicate internally, and so on. Igalia has a whole set of open-source tools that it uses, which is nice.

There are some differences, as well. For example, there is a system for doing faster builds of Chromium, "otherwise you'll just spend all your time building Chromium". That system is immediately available to Google employees, but external users have to request access to it. A bigger area of friction is access to bug reports, which are meant to be open to everyone unless they are security bugs. Due to a bug-tracker migration a few years ago, though, there are bugs that should be visible to outsiders, but are only visible to Google employees. "It is not a malicious thing", and it is easy enough to get the access fixed, but it is something extra she has to do once a week or so.

There is other information that could be more readily available to the public, but is not because it is stored in Google Docs without being shared. Ensuring that the public has access "is a best-effort thing and people forget", which is unfortunate. In addition, all of the tools for tasks like bug tracking are maintained by Google and, essentially, for Google, so outsiders have no way to provide feedback or request features and changes. They are "relatively minor points of friction" but they are enough to feel that "I am now separate from this".

After a month in her new job, she started to see even more similarities with her previous one. The team members are all still available via the same communication channels (e.g. Slack), and she is likewise available to them. Some of the work that Igalia does comes directly or indirectly from Google; she is working a Chromium project that comes through the Linux Foundation, which Google is a member of. "I'm working on the same repository, I'm using the same tools, I'm getting money from Google, what's changed here?"

Projects

The answer it seems is "kind of everything and kind of nothing". The types of projects are different at Igalia, though. At Google, she worked on the projects that were important to the people in her management chain; those are often new features or "a flashy metric that they want to improve". They are often aimed at getting promotions for the engineers and those in the reporting chain.

The projects handed to Igalia to work on come directly from the technical staff, so they tend to be "code-health or tech-debt kind of projects". For example, Igalia worked on componentizing the Chromium code base and its current project is "improving web-platform-test interoperability between browsers". It is important work that is good to do, but "it is just so hard to imagine anyone at Google doing it for their day job"; it is "not the kind of work that gets prioritized or rewarded". Many of the people that she worked with on Chromium at Google would love to be able to do that work. "These are people who care about the code base, they want it to be good, but there's just no room in their day job to do that, which is too bad."

She was initially attracted to the Chrome team because all of the people on it seemed to be welcoming. That remained true throughout her tenure at Google and has continued into her work at Igalia. "People who work on Chromium have just generally been friendly and inclusive in all domains, which is good, and is not to be taken for granted." She has been able to maintain relationships her former coworkers, review their patches, leave comments on work that they have in common, and so on. "It's a nicer experience than sending a code review to some stranger."

Hierarchy

She put up a slide of an organization chart from a typical company, with her picture in a leaf node as the only filled-in box. In a chart like that, the engineer is at the bottom of the hierarchy; they have a manager, who has a more senior manager, and so on. An engineer is concerned with technical decisions, such as which language to use or how to test the code being written, while at the top, they are deciding things like company direction and vision. The people in the middle are doing some technical work, but it is often not entirely clear what it is that they do; "who knows?", she said to laughter. "The people at the top are paid a lot more than the people at the bottom."

At Igalia, things are quite different. The "org chart is intentionally flat" and there are no managers. There are various teams, such as the Chromium team that she is on, a Linux kernel team, and more. The flat hierarchy means that "all of the employees do a lot of work that you typically wouldn't do as a leaf-node employee at a big company", which includes making company decisions, such as which projects to take on, whether to increase headcount, and how much vacation time there is.

Igalia is a cooperative, so votes are taken on those kinds of questions. "These are not decisions you have any influence at all over at a big company." One of the nice things about that arrangement is that the people who are making the decision are the ones who are affected by it, which is "just not the case at a standard company". The most obvious example for that is layoffs, Yang said.

There is a cost to doing things that way, of course. The meetings for those decisions are lengthy and run for two days—in a European time zone. When she was at Google, she was in the dominant time zone (US Pacific), and her teammates elsewhere had to have meetings at weird times, so this feels a bit like karma for her, she said. But that is a "minor price to pay" for a structure that is "so fundamentally different and feels good".

It took her a while to fully recognize just how different Igalia's structure is; the impacts of it did not sink in right away. The biggest impact for her was promotions, which do not exist in a flat organization where everyone is paid the same amount. When she was a new graduate, promotion was her focus because it is expected of new hires; "Meta literally fires you if you don't reach a certain level in a certain time".

Trying to ensure that she was working on the right projects and "demonstrating the right skills" in order to be promoted was stressful and took a lot of effort. Much of it is out of the engineer's hands and is up to their manager. She was lucky and had a great manager at Google, but even if they are good, they have multiple people reporting to them. "For you, it's like your whole professional life, but for them it's one of the million things that they have to do."

The flat pay structure is also a welcome change—there are no pay discrepancies. As a woman and someone who was formerly working on a visa, "these are very real concerns you have, and now that's just all gone". Everyone is on the same level playing field, which leads to more trust and collaboration. "If that sounds fun, go join or start a coop", she said to applause. That was the end of her prepared talk, but she had plenty of time for questions, which were numerous, perhaps unsurprisingly.

Q&A

The first was about where direction came from in a flat structure; how are decisions made about what she should work on? That depends on the project, Yang said, some are closely aligned with the engineers at the client company, while other projects are less hands-on. When working with the client's engineers, the direction likely comes from the client side as in a more typical organization. Sometimes projects are more open-ended, where the client agrees to pay for work on a specific task for, say, a year to see where things end up; in that case, the Igalia team decides on what to tackle.

Another attendee wondered what it was that Igalia's clients needed done with Chromium. Once again, it varies, she said. Her project is cleaning up the testing, which is something that Google wants and it does not fit anywhere in its team. Other clients want customized browsers for internal use, so parts of the Igalia Chromium team are also working on downstream projects.

The hiring process was up next. One attendee wondered how Igalia decided that it needed to hire for a position and how the person to hire was chosen. "Which teams get headcount is decided at a company level", she said, so if the Chromium team wants to hire, it makes a pitch to the assembly, which is the voting body. If that is approved, the team will interview candidates and choose who it thinks should be hired, which goes back to the assembly. Normally, that choice will be approved unless there is some red flag that someone elsewhere in the company is aware of. Yang reminded attendees that she was still fairly new at Igalia, but that there were other employees sitting in on the talk who might chime in to help clarify things; in this case she just got a thumbs up from them, she said.

Having 180 employees in a flat structure already sounds a bit unwieldy, an attendee noted, is there a size where Igalia will essentially be forced into a hierarchical structure just because of its size? Yang said that she asked the same thing when she was interviewing, "everyone agreed that this is definitely an issue but there's not a clear solution yet". Her partner suggested that honeybees might provide a reasonable model of how a split could be done; when a hive gets too big, part of the hive leaves as a swarm to found a new hive.

An employee at another employee-owned coop suggested that there were synergies between open source and cooperatives, which might help when the time comes to split up. He wondered if there were plans for Igalia to release its internal tools and coop-operating documents as open source, which could facilitate a new, separate company if that was needed. Yang noted that her coworker Danielle Mayabb had a session in the next slot about running the company using FOSS tools.

A researcher who studied companies with flat structures asked whether some of the organizational structure came back into the picture within the different teams. The teams are responsible for decisions like whether to take a project or not, Yang said, and there are product managers that coordinate between teams. The product managers work closely with clients, but they have no inherent extra power, like a manager at a typical job.

Along the way, she had said that she was not yet part of the assembly, so an attendee asked how that worked, how long it took, whether a vote was needed, and so on. Yang recommended the video of a talk by Valerie Young at the first FOSSY in 2023, which goes into more detail. Yang said that somewhere around the one-year mark it would be decided whether an employee would join the assembly, though she did not specify exactly how that was done. "If you've done an exceptionally bad job, you won't be permitted in."

That was a good segue to the next question, which was about what would prevent an employee in the coop from just ceasing to work. In a flat hierarchy, who is monitoring what employees are doing? Can someone just stop working without detection? She joked that she would give it a try and come back next year with a talk on that. More seriously, there are people who are providing feedback on the performance of their coworkers; each person has a mentor in the company who fills some of the roles of a manager at other companies, including gathering assessments of the work that is being done. "People are monitoring your performance and it is a collection of all of the people that you work with."

An attendee noted that there is a saying in the coop movement: "If you've seen one coop, you've seen one coop." That is why it is so helpful for coops to share their internal structure; as with open-source software, other coops can learn from the trial and error that went into forming the coop. Yang noted that there used to be a coop track at FOSSY and that there was talk of bringing it back for next year.

[I would like to thank the Linux Foundation, LWN's travel sponsor, for its assistance with my trip to Vancouver for FOSSY.]

Comments (11 posted)

Research into file-notification attacks on Linux

Sudheendra Raghav Neela, a member of a group of researchers from Graz University of Technology, has announced the release of research into file-notification attacks that would allow spying on user activity on Android, Linux, macOS, and Windows. The group has published a paper with details on the research as well as a web site with demonstrations of the vulnerabilities.

On Linux, an attacker can use inotifywatch to monitor a directory to conduct an inter-keystroke timing attack—even if they do not have read access to the files within a directory. The group also discovered a method to conduct a UI-redress attack (or "clickjacking" attack) on KDE 5 and KDE 6 by monitoring /usr/bin/pkexec to detect when Polkit spawns an authentication prompt. An attacker could draw a fake password window on top of the real window to collect a user's credentials.

Both of these flaws are still present today, though the Linux kernel did partially mitigate the issue with a fix that was included in the 5.10.248, 5.15.198, 6.1.160, 6.6.120, 6.12.65, and 6.18.3 kernels shipped in January. See the web site for more information and a mitigation to prevent password-prompt windows from losing focus.

Comments (18 posted)

Security quote of the week

CVE ID         : CVE-2024-52560 CVE-2024-58094 CVE-2024-58095 CVE-2025-21817
                 CVE-2025-22104 CVE-2025-22108 CVE-2025-22127 CVE-2025-38203
                 CVE-2025-38205 CVE-2025-38206 CVE-2025-38237 CVE-2025-38621
                 CVE-2025-39833 CVE-2025-39925 CVE-2025-40064 CVE-2025-40102
                 CVE-2025-40139 CVE-2025-40168 CVE-2026-23137 CVE-2026-43198
                 CVE-2026-43344 CVE-2026-45963 CVE-2026-52944 CVE-2026-53010
                 CVE-2026-53089 CVE-2026-53102 CVE-2026-53113 CVE-2026-53250
                 CVE-2026-53313 CVE-2026-64058 CVE-2026-64070 CVE-2026-64082

[... 1,264 CVEs elided...]

                 CVE-2026-98128 CVE-2026-98129 CVE-2026-98130 CVE-2026-98142
                 CVE-2026-98151 CVE-2026-98152 CVE-2026-98154 CVE-2026-98155
                 CVE-2026-98157 CVE-2026-98158 CVE-2026-98159 CVE-2026-98160
                 CVE-2026-100070 CVE-2026-100071 CVE-2026-100075 CVE-2026-100078
                 CVE-2026-100079
Debian Bug     : 1108860

Several vulnerabilities have been discovered in the Linux kernel that
may lead to a privilege escalation, denial of service or information
leaks.

— The Debian Project redefines "several"

Comments (none posted)

Kernel release status

The current development kernel is 7.3-rc5, released on September 27. Linus said: "I don't think there's any real pattern to it other than 'big'. But nothing looks particularly alarming, I think that despite the diffstat it's just the same old, same old."

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

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

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

Stable updates: 7.2.8 and 6.18.54 were released on September 25.

Comments (none posted)

The Kernel Report 2026 edition

After a two-year hiatus, LWN's Jonathan Corbet presented an updated edition of his Kernel Report at the Kernel Recipes conference. Corbet looked at what is happening in the kernel community, how it's dealing with a period of accelerated change, and where things might go in the future. Video of the talk is available on YouTube for those who'd like to tune in.

Comments (40 posted)

Kernel Recipes videos posted

The full set of videos from the recently concluded Kernel Recipes conference has been posted. Also noteworthy are the associated caricature drawings, by Frank Tizzoni, of attendees and the speakers.

Comments (1 posted)

The Linux Foundation Technical Advisory Board 2026 election approaches

The election for members of the Linux Foundation Technical Advisory Board will be held electronically after the close of the upcoming Linux Plumbers Conference. The call for candidates is open, with a nomination deadline of October 8. There are five seats to fill this time, including the one vacated by the unfortunate passing of Dan Williams.

Serving on the TAB is a good way to help the kernel-development community. Please see this article from last year for an overview of what the TAB does and why membership is rewarding, then consider putting in your nomination.

Comments (none posted)

Quote of the week

At the same time I'm very impressed by the overall code quality these days. Regressions are very rare for us. Even mindless slop that people send is an order of magnitude better than code we used to merge 2 years ago. But more importantly with multiple frontier models reviewing each merged patch the math on the risk of regressions changes quite a bit.

— Jakub Kicinski

Comments (none posted)

F-Droid 2.0: A new chapter for Android freedom

The F-Droid project has announced the release of F-Droid 2.0, which is a complete redesign of the official app. Notable changes in the release include making it easier to discover and install applications, more useful app categories, improved search, and much more.

For more than a decade, F-Droid has helped people discover and install free and open source Android apps. F-Droid 2.0 builds on that foundation with a modern interface, better app discovery, improved search, and a simpler experience that works well, whether you're new to F-Droid or have been using it for years.

This isn't just a visual refresh. The user experience was redesigned to integrate smoothly with current Android patterns, like Material Design, while keeping familiar F-Droid interactions in place. Key components were reworked and rewritten using Kotlin Compose, the standard toolkit these days, creating a foundation that will help us deliver improvements more quickly in the years ahead.

Comments (15 posted)

Distributions quote of the week

There are two approaches. The one I'm going to call the Good One (my opinion) is that we build a coherent distribution with one version of each package. Libraries are built with stable APIs and backwards compatibility in mind. Programs are flexible about their dependencies. Changes go upstream. Security vulnerabilities are fixed once. (And yes, this is all a bit more work and requires people to actually act like professional engineers.)

The Bad One is we just chuck everything together and do what works, without caring about the long term. This is certainly effective at making something that works, but hides long term debt, including serious security issues, which matters more than ever.

— Richard W.M. Jones

Comments (none posted)

Firefox 157.0 released

Version 157.0 of the Firefox browser has been released. It features "Firefox's biggest visual refresh in years", the ability to use hardware AV1 decoding with WebRTC calls, and a number of fixes.

Comments (27 posted)

GDB 18.1 released

Version 18.1 of the GDB interactive debugger has been released. Changes include new commands to manipulate the environment of the subprocess, the ability to save the command history to a file, support for a couple of new targets, several Python API additions, and more. See the NEWS file for the complete list.

Full Story (comments: none)

Git v2.56.0 released

Version 2.56 of the Git distributed version-control system has been released. It has 748 non-merge commits since Git 2.55 was released back in June; those commits came from 104 developers, 39 of whom are first-time contributors. New features include a safer workflow for conflict resolution, smaller path-walk repacks, a new git history drop sub-command, and much more. LWN looked at Git 2.56 recently and the GitHub blog has a lengthy look at 2.56 as well.

Full Story (comments: none)

A summary from the 2026 Git Contributors' Summit

Johannes Schindelin has posted a detailed summary of the discussions held at the 2026 Git Contributors' Summit. Topics covered include Git 3.0, security process, documentation, the pluggable object database, use of LLMs, and more.

Comments (1 posted)

Reports from the 2026 Python Language Summit

The 2026 Python Language Summit was held on July 14 in Kraków, Poland; there is now a series of reports available on the topics that were discussed there. They include the memory buffer protocol, garbage collection, free-threaded Python, and "Spicycrab".

Comments (none posted)

CFP Deadlines: October 1, 2026 to November 30, 2026

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

Deadline	Event Dates	Event	Location
October 1	November 7 November 8	OpenFest 2026	Sofia, Bulgaria
October 1	November 12 November 13	Ubuntu Summit 26.10	Online
October 4	November 7 November 8	OpenALT	Brno, Czechia
October 9	November 20 November 21	OLF Conference	Columbus, Ohio, US
November 1	April 1 April 4	Southern California Linux Expo	Pasadena, CA, US

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

Events: October 1, 2026 to November 30, 2026

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

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

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

Alert summary September 24, 2026 to September 30, 2026

Dist.	ID	Release	Package	Date
AlmaLinux	ALSA-2026:64791	8	389-ds:1.4	2026-09-30
AlmaLinux	ALSA-2026:70640	9	buildah	2026-09-24
AlmaLinux	ALSA-2026:71543	10	cockpit-image-builder	2026-09-28
AlmaLinux	ALSA-2026:63163	8	container-tools:rhel8	2026-09-30
AlmaLinux	ALSA-2026:70391	9	containernetworking-plugins	2026-09-23
AlmaLinux	ALSA-2026:72448	8	expat	2026-09-28
AlmaLinux	ALSA-2026:67129	10	firefox	2026-09-23
AlmaLinux	ALSA-2026:69461	10	firefox	2026-09-25
AlmaLinux	ALSA-2026:68549	8	firefox	2026-09-23
AlmaLinux	ALSA-2026:71652	8	firefox	2026-09-25
AlmaLinux	ALSA-2026:67133	9	firefox	2026-09-23
AlmaLinux	ALSA-2026:22112	8	go-toolset:rhel8	2026-09-30
AlmaLinux	ALSA-2026:54243	8	grafana	2026-09-30
AlmaLinux	ALSA-2026:64794	8	httpd:2.4	2026-09-30
AlmaLinux	ALSA-2026:72279	10	ipa	2026-09-29
AlmaLinux	ALSA-2026:70564	9	ipa	2026-09-26
AlmaLinux	ALSA-2026:70402	8	kernel	2026-09-23
AlmaLinux	ALSA-2026:71329	8	kernel	2026-09-24
AlmaLinux	ALSA-2026:71213	8	kernel	2026-09-24
AlmaLinux	ALSA-2026:72468	8	kernel	2026-09-28
AlmaLinux	ALSA-2026:68570	9	kernel	2026-09-23
AlmaLinux	ALSA-2026:70459	9	kernel	2026-09-26
AlmaLinux	ALSA-2026:71232	9	kernel	2026-09-26
AlmaLinux	ALSA-2026:71700	9	kernel	2026-09-29
AlmaLinux	ALSA-2026:70403	8	kernel-rt	2026-09-23
AlmaLinux	ALSA-2026:71016	8	kernel-rt	2026-09-24
AlmaLinux	ALSA-2026:71330	8	kernel-rt	2026-09-24
AlmaLinux	ALSA-2026:72467	8	kernel-rt	2026-09-28
AlmaLinux	ALSA-2026:71586	10	libxml2	2026-09-25
AlmaLinux	ALSA-2026:71641	8	libxml2	2026-09-25
AlmaLinux	ALSA-2026:71585	9	libxml2	2026-09-25
AlmaLinux	ALSA-2026:62219	8	nodejs:22	2026-09-30
AlmaLinux	ALSA-2026:69608	9	openexr	2026-09-23
AlmaLinux	ALSA-2026:70753	10	perl-DBI	2026-09-24
AlmaLinux	ALSA-2026:71608	8	perl-DBI	2026-09-25
AlmaLinux	ALSA-2026:71422	9	perl-DBI	2026-09-25
AlmaLinux	ALSA-2026:69112	8	perl-DBI:1.641	2026-09-24
AlmaLinux	ALSA-2026:70201	10	podman	2026-09-23
AlmaLinux	ALSA-2026:69961	9	podman	2026-09-23
AlmaLinux	ALSA-2026:69607	9	postgresql	2026-09-23
AlmaLinux	ALSA-2026:70186	10	postgresql16	2026-09-23
AlmaLinux	ALSA-2026:69924	8	postgresql:12	2026-09-30
AlmaLinux	ALSA-2026:69923	8	postgresql:15	2026-09-30
AlmaLinux	ALSA-2026:69914	9	postgresql:15	2026-09-24
AlmaLinux	ALSA-2026:71658	10	python-cryptography	2026-09-25
AlmaLinux	ALSA-2026:72424	9	resteasy	2026-09-28
AlmaLinux	ALSA-2026:72785	10	ruby	2026-09-29
AlmaLinux	ALSA-2026:72286	9	ruby	2026-09-28
AlmaLinux	ALSA-2026:72427	10	ruby4.0	2026-09-28
AlmaLinux	ALSA-2026:72485	9	ruby:3.3	2026-09-28
AlmaLinux	ALSA-2026:72484	9	ruby:4.0	2026-09-28
AlmaLinux	ALSA-2026:70191	9	runc	2026-09-23
AlmaLinux	ALSA-2026:70641	9	skopeo	2026-09-24
AlmaLinux	ALSA-2026:70390	8	tar	2026-09-23
AlmaLinux	ALSA-2026:70642	9	thunderbird	2026-09-25
AlmaLinux	ALSA-2026:71419	10	unbound	2026-09-24
AlmaLinux	ALSA-2026:70754	8	unbound	2026-09-24
AlmaLinux	ALSA-2026:71487	9	unbound	2026-09-25
Debian	DSA-6513-1	stable	chromium	2026-09-25
Debian	DSA-6526-1	stable	dovecot	2026-09-28
Debian	DLA-4796-1	LTS	evolution-data-server	2026-09-26
Debian	DSA-6522-1	stable	exim4	2026-09-27
Debian	DSA-6524-1	stable	flatpak	2026-09-28
Debian	DSA-6516-1	stable	ghostscript	2026-09-25
Debian	DLA-4800-1	LTS	glance	2026-09-29
Debian	DSA-6518-1	stable	incus	2026-09-26
Debian	DSA-6416-2	stable	jq	2026-09-25
Debian	DSA-6528-1	stable	kernel	2026-09-29
Debian	DLA-4797-1	LTS	lemonldap-ng	2026-09-26
Debian	DSA-6520-1	stable	lemonldap-ng	2026-09-27
Debian	DLA-4793-1	LTS	libdatetime-timezone-perl	2026-09-23
Debian	DLA-4798-1	LTS	libdbi-perl	2026-09-28
Debian	DSA-6523-1	stable	libheif	2026-09-28
Debian	DSA-6512-1	stable	libreoffice	2026-09-24
Debian	DSA-6529-1	stable	libwebsockets	2026-09-29
Debian	DLA-4799-1	LTS	lxml	2026-09-28
Debian	DSA-6517-1	stable	nodejs	2026-09-26
Debian	DLA-4795-1	LTS	openssl	2026-09-25
Debian	DSA-6531-1	stable	openssl	2026-09-30
Debian	DSA-6530-1	stable	pcre2	2026-09-29
Debian	DSA-6514-1	stable	php8.4	2026-09-25
Debian	DLA-4794-1	LTS	redis	2026-09-24
Debian	DSA-6527-1	stable	rsync	2026-09-28
Debian	DSA-6521-1	stable	ruby-oj	2026-09-27
Debian	DLA-4801-1	LTS	swift	2026-09-29
Debian	DSA-6519-1	stable	swift	2026-09-26
Debian	DLA-4792-1	LTS	tzdata	2026-09-23
Debian	DSA-6515-1	stable	vlc	2026-09-25
Debian	DSA-6525-1	stable	wordpress	2026-09-28
Debian	DSA-6510-1	stable	xdg-dbus-proxy	2026-09-23
Debian	DSA-6511-1	stable	znc	2026-09-23
Fedora	FEDORA-2026-0b8bc362b1	F43	389-ds-base	2026-09-25
Fedora	FEDORA-2026-b16c9cbc0f	F44	389-ds-base	2026-09-25
Fedora	FEDORA-2026-c1e25a4642	F45	389-ds-base	2026-09-25
Fedora	FEDORA-2026-d3a0471c75	F43	NetworkManager-iodine	2026-09-29
Fedora	FEDORA-2026-5463db437e	F44	NetworkManager-iodine	2026-09-29
Fedora	FEDORA-2026-ccf41b012c	F45	NetworkManager-iodine	2026-09-29
Fedora	FEDORA-2026-1b63888725	F43	NetworkManager-l2tp	2026-09-29
Fedora	FEDORA-2026-3a264a1bb3	F44	NetworkManager-l2tp	2026-09-29
Fedora	FEDORA-2026-48a7996f9c	F45	adwaita-icon-theme	2026-09-30
Fedora	FEDORA-2026-313e66c007	F45	bcm283x-firmware	2026-09-25
Fedora	FEDORA-2026-dd12c89e57	F43	chromium	2026-09-24
Fedora	FEDORA-2026-8729b61cd3	F43	chromium	2026-09-29
Fedora	FEDORA-2026-1e015b5959	F44	chromium	2026-09-27
Fedora	FEDORA-2026-735231f9e0	F45	chromium	2026-09-26
Fedora	FEDORA-2026-c4d5a488fe	F45	cinnamon	2026-09-28
Fedora	FEDORA-2026-c836eb1b43	F45	cinnamon	2026-09-30
Fedora	FEDORA-2026-c4d5a488fe	F45	cinnamon-desktop	2026-09-28
Fedora	FEDORA-2026-c4d5a488fe	F45	cinnamon-session	2026-09-28
Fedora	FEDORA-2026-c4d5a488fe	F45	cinnamon-settings-daemon	2026-09-28
Fedora	FEDORA-2026-cc3b077d5b	F43	ckermit	2026-09-27
Fedora	FEDORA-2026-32742a29dc	F44	ckermit	2026-09-27
Fedora	FEDORA-2026-d375ea9e79	F45	cockpit	2026-09-25
Fedora	FEDORA-2026-48a7996f9c	F45	dconf	2026-09-30
Fedora	FEDORA-2026-4284af73e4	F45	dnf5	2026-09-28
Fedora	FEDORA-2026-48a7996f9c	F45	epiphany	2026-09-30
Fedora	FEDORA-2026-5debc0de2b	F45	evolution	2026-09-24
Fedora	FEDORA-2026-5debc0de2b	F45	evolution-data-server	2026-09-24
Fedora	FEDORA-2026-5debc0de2b	F45	evolution-ews	2026-09-24
Fedora	FEDORA-2026-9b73fdb8e6	F44	flatpak-builder	2026-09-30
Fedora	FEDORA-2026-c450ece4a4	F45	flatpak-builder	2026-09-25
Fedora	FEDORA-2026-b1ae715f03	F45	forgejo	2026-09-27
Fedora	FEDORA-2026-5812baee0f	F43	freeipa	2026-09-29
Fedora	FEDORA-2026-ff8f6f4444	F45	freerdp	2026-09-29
Fedora	FEDORA-2026-48a7996f9c	F45	gcr	2026-09-30
Fedora	FEDORA-2026-48a7996f9c	F45	gdm	2026-09-30
Fedora	FEDORA-2026-48a7996f9c	F45	gjs	2026-09-30
Fedora	FEDORA-2026-48a7996f9c	F45	glib-networking	2026-09-30
Fedora	FEDORA-2026-48a7996f9c	F45	glib2	2026-09-30
Fedora	FEDORA-2026-48a7996f9c	F45	gnome-backgrounds	2026-09-30
Fedora	FEDORA-2026-48a7996f9c	F45	gnome-calendar	2026-09-30
Fedora	FEDORA-2026-48a7996f9c	F45	gnome-characters	2026-09-30
Fedora	FEDORA-2026-48a7996f9c	F45	gnome-chess	2026-09-30
Fedora	FEDORA-2026-48a7996f9c	F45	gnome-clocks	2026-09-30
Fedora	FEDORA-2026-48a7996f9c	F45	gnome-connections	2026-09-30
Fedora	FEDORA-2026-48a7996f9c	F45	gnome-console	2026-09-30
Fedora	FEDORA-2026-48a7996f9c	F45	gnome-contacts	2026-09-30
Fedora	FEDORA-2026-48a7996f9c	F45	gnome-control-center	2026-09-30
Fedora	FEDORA-2026-48a7996f9c	F45	gnome-desktop3	2026-09-30
Fedora	FEDORA-2026-48a7996f9c	F45	gnome-initial-setup	2026-09-30
Fedora	FEDORA-2026-48a7996f9c	F45	gnome-keyring	2026-09-30
Fedora	FEDORA-2026-48a7996f9c	F45	gnome-kiosk	2026-09-30
Fedora	FEDORA-2026-48a7996f9c	F45	gnome-maps	2026-09-30
Fedora	FEDORA-2026-48a7996f9c	F45	gnome-remote-desktop	2026-09-30
Fedora	FEDORA-2026-48a7996f9c	F45	gnome-settings-daemon	2026-09-30
Fedora	FEDORA-2026-48a7996f9c	F45	gnome-shell	2026-09-30
Fedora	FEDORA-2026-48a7996f9c	F45	gnome-shell-extensions	2026-09-30
Fedora	FEDORA-2026-48a7996f9c	F45	gnome-system-monitor	2026-09-30
Fedora	FEDORA-2026-48a7996f9c	F45	gnome-text-editor	2026-09-30
Fedora	FEDORA-2026-48a7996f9c	F45	gnome-user-docs	2026-09-30
Fedora	FEDORA-2026-48a7996f9c	F45	gnote	2026-09-30
Fedora	FEDORA-2026-a95c9d3b51	F45	gnucash	2026-09-30
Fedora	FEDORA-2026-a95c9d3b51	F45	gnucash-docs	2026-09-30
Fedora	FEDORA-2026-5c0d326b15	F43	goose	2026-09-27
Fedora	FEDORA-2026-24f75e4c7a	F44	goose	2026-09-27
Fedora	FEDORA-2026-cb99e9b2ac	F45	goose	2026-09-27
Fedora	FEDORA-2026-72dbe745c7	F45	grub2	2026-09-29
Fedora	FEDORA-2026-48a7996f9c	F45	gsettings-desktop-schemas	2026-09-30
Fedora	FEDORA-2026-654bf10275	F45	gssntlmssp	2026-09-26
Fedora	FEDORA-2026-48a7996f9c	F45	gtk4	2026-09-30
Fedora	FEDORA-2026-ebccf08143	F45	hplip	2026-09-30
Fedora	FEDORA-2026-8202400aa0	F43	kernel	2026-09-24
Fedora	FEDORA-2026-48a7996f9c	F45	libadwaita	2026-09-30
Fedora	FEDORA-2026-48a7996f9c	F45	libdex	2026-09-30
Fedora	FEDORA-2026-022ff83e3e	F43	libheif	2026-09-26
Fedora	FEDORA-2026-cfdbb8b2f0	F44	libheif	2026-09-26
Fedora	FEDORA-2026-78461b38b3	F45	libheif	2026-09-24
Fedora	FEDORA-2026-4401b94ad0	F43	libpcap	2026-09-26
Fedora	FEDORA-2026-1e23d80c94	F45	librsvg2	2026-09-26
Fedora	FEDORA-2026-48a7996f9c	F45	libsecret	2026-09-30
Fedora	FEDORA-2026-48a7996f9c	F45	libshumate	2026-09-30
Fedora	FEDORA-2026-47ffcebe44	F43	libxmp	2026-09-30
Fedora	FEDORA-2026-c40eb5767e	F44	libxmp	2026-09-30
Fedora	FEDORA-2026-4e6575b35f	F43	mingw-gdk-pixbuf	2026-09-25
Fedora	FEDORA-2026-16f1152378	F44	mingw-gdk-pixbuf	2026-09-25
Fedora	FEDORA-2026-26573b6029	F45	mingw-gdk-pixbuf	2026-09-25
Fedora	FEDORA-2026-d5e9ea2b8c	F44	mingw-gstreamer1	2026-09-27
Fedora	FEDORA-2026-0d2736f2fe	F45	mingw-gstreamer1	2026-09-27
Fedora	FEDORA-2026-d5e9ea2b8c	F44	mingw-gstreamer1-plugins-bad-free	2026-09-27
Fedora	FEDORA-2026-0d2736f2fe	F45	mingw-gstreamer1-plugins-bad-free	2026-09-27
Fedora	FEDORA-2026-d5e9ea2b8c	F44	mingw-gstreamer1-plugins-base	2026-09-27
Fedora	FEDORA-2026-0d2736f2fe	F45	mingw-gstreamer1-plugins-base	2026-09-27
Fedora	FEDORA-2026-d5e9ea2b8c	F44	mingw-gstreamer1-plugins-good	2026-09-27
Fedora	FEDORA-2026-0d2736f2fe	F45	mingw-gstreamer1-plugins-good	2026-09-27
Fedora	FEDORA-2026-e03c0baa59	F45	mingw-llvm	2026-09-30
Fedora	FEDORA-2026-98f3f016c4	F43	mingw-pcre2	2026-09-24
Fedora	FEDORA-2026-e9c6062c07	F44	mingw-pcre2	2026-09-24
Fedora	FEDORA-2026-68e2c40a81	F45	mingw-pcre2	2026-09-24
Fedora	FEDORA-2026-9359fb439f	F43	mingw-python3	2026-09-27
Fedora	FEDORA-2026-cee8eac8cc	F44	mingw-python3	2026-09-27
Fedora	FEDORA-2026-19a92359f8	F45	mingw-python3	2026-09-27
Fedora	FEDORA-2026-b4c749cdd2	F43	mongo-c-driver	2026-09-27
Fedora	FEDORA-2026-4286ff2dfd	F44	mongo-c-driver	2026-09-27
Fedora	FEDORA-2026-0fcc2d09c6	F45	mongo-c-driver	2026-09-27
Fedora	FEDORA-2026-c4d5a488fe	F45	muffin	2026-09-28
Fedora	FEDORA-2026-48a7996f9c	F45	mutter	2026-09-30
Fedora	FEDORA-2026-48a7996f9c	F45	nautilus	2026-09-30
Fedora	FEDORA-2026-c4d5a488fe	F45	nemo	2026-09-28
Fedora	FEDORA-2026-c4d5a488fe	F45	nemo-extensions	2026-09-28
Fedora	FEDORA-2026-c495e95154	F43	nextcloud	2026-09-28
Fedora	FEDORA-2026-362f1943c8	F44	nextcloud	2026-09-28
Fedora	FEDORA-2026-5c1bbb46c3	F45	nextcloud	2026-09-28
Fedora	FEDORA-2026-4cf3c816ec	F44	nginx-mod-modsecurity	2026-09-24
Fedora	FEDORA-2026-574792845e	F45	nginx-mod-modsecurity	2026-09-24
Fedora	FEDORA-2026-9e18ff28a6	F45	openssl3	2026-09-25
Fedora	FEDORA-2026-b56266ea73	F43	parted	2026-09-30
Fedora	FEDORA-2026-96efddc493	F43	pcs	2026-09-25
Fedora	FEDORA-2026-ee77e0c099	F44	pcs	2026-09-25
Fedora	FEDORA-2026-7c46481544	F43	perl-Catalyst-Plugin-Static-Simple	2026-09-29
Fedora	FEDORA-2026-2d96cf2594	F44	perl-Catalyst-Plugin-Static-Simple	2026-09-29
Fedora	FEDORA-2026-4d5a716383	F45	perl-Catalyst-Plugin-Static-Simple	2026-09-29
Fedora	FEDORA-2026-3b893ccf2d	F44	perl-Dancer2	2026-09-29
Fedora	FEDORA-2026-5e3eab9a07	F45	perl-Dancer2	2026-09-29
Fedora	FEDORA-2026-219b6aef6c	F43	perl-HTML-FormFu	2026-09-29
Fedora	FEDORA-2026-18537daffc	F44	perl-HTML-FormFu	2026-09-29
Fedora	FEDORA-2026-94d32d2e8e	F45	perl-HTML-FormFu	2026-09-29
Fedora	FEDORA-2026-625ab5c382	F43	perl-Imager	2026-09-30
Fedora	FEDORA-2026-12f0a70554	F44	perl-Imager	2026-09-30
Fedora	FEDORA-2026-8e3688d489	F45	perl-Imager	2026-09-30
Fedora	FEDORA-2026-dddd2792e3	F43	pgadmin4	2026-09-27
Fedora	FEDORA-2026-c070c47328	F44	pgadmin4	2026-09-27
Fedora	FEDORA-2026-035cf95dc5	F45	pgadmin4	2026-09-27
Fedora	FEDORA-2026-bb0d483289	F43	postgresql16-postgis	2026-09-27
Fedora	FEDORA-2026-0fe48ab374	F44	postgresql16-postgis	2026-09-27
Fedora	FEDORA-2026-bb0d483289	F43	postgresql17-postgis	2026-09-27
Fedora	FEDORA-2026-0fe48ab374	F44	postgresql17-postgis	2026-09-27
Fedora	FEDORA-2026-bb0d483289	F43	postgresql18-postgis	2026-09-27
Fedora	FEDORA-2026-0fe48ab374	F44	postgresql18-postgis	2026-09-27
Fedora	FEDORA-2026-9a652403b1	F45	python-quart-trio	2026-09-29
Fedora	FEDORA-2026-700dc0d93d	F44	python-streamlink	2026-09-29
Fedora	FEDORA-2026-9a652403b1	F45	python-streamlink	2026-09-29
Fedora	FEDORA-2026-700dc0d93d	F44	python-urllib3	2026-09-29
Fedora	FEDORA-2026-9a652403b1	F45	python-urllib3	2026-09-29
Fedora	FEDORA-2026-48a7996f9c	F45	quadrapassel	2026-09-30
Fedora	FEDORA-2026-f5733c1dd0	F43	rootlesskit	2026-09-30
Fedora	FEDORA-2026-3e60aed77e	F44	rootlesskit	2026-09-30
Fedora	FEDORA-2026-6b8872b8ac	F45	rootlesskit	2026-09-30
Fedora	FEDORA-2026-c66f1af6a3	F43	rust-cryptoki	2026-09-25
Fedora	FEDORA-2026-738ce6f6f8	F44	rust-cryptoki	2026-09-25
Fedora	FEDORA-2026-b9e02a8684	F45	rust-cryptoki	2026-09-25
Fedora	FEDORA-2026-1e23d80c94	F45	rust-librsvg	2026-09-26
Fedora	FEDORA-2026-1e23d80c94	F45	rust-xml5ever	2026-09-26
Fedora	FEDORA-2026-48a7996f9c	F45	rygel	2026-09-30
Fedora	FEDORA-2026-48a7996f9c	F45	shotwell	2026-09-30
Fedora	FEDORA-2026-b0077de9df	F43	sipp	2026-09-26
Fedora	FEDORA-2026-e377b4938d	F44	sipp	2026-09-26
Fedora	FEDORA-2026-3059115f48	F45	sipp	2026-09-26
Fedora	FEDORA-2026-e5174fc4cf	F43	sngrep	2026-09-30
Fedora	FEDORA-2026-3ff086aa2a	F44	sngrep	2026-09-30
Fedora	FEDORA-2026-019108693f	F45	sngrep	2026-09-30
Fedora	FEDORA-2026-56c3705788	F44	squid	2026-09-25
Fedora	FEDORA-2026-9e8f1c83d0	F45	squid	2026-09-25
Fedora	FEDORA-2026-5588cdf367	F44	suricata	2026-09-28
Fedora	FEDORA-2026-9cf326b4f4	F45	suricata	2026-09-28
Fedora	FEDORA-2026-48a7996f9c	F45	sushi	2026-09-30
Fedora	FEDORA-2026-48a7996f9c	F45	sysprof	2026-09-30
Fedora	FEDORA-2026-48a7996f9c	F45	tecla	2026-09-30
Fedora	FEDORA-2026-e3bf7f4ecb	F45	tesseract	2026-09-26
Fedora	FEDORA-2026-a387125860	F43	thunderbird	2026-09-30
Fedora	FEDORA-2026-313e66c007	F45	uboot-tools	2026-09-25
Fedora	FEDORA-2026-996b326401	F44	unbound	2026-09-24
Fedora	FEDORA-2026-ad90eab763	F44	vlc	2026-09-29
Fedora	FEDORA-2026-40db9b80a2	F44	webkitgtk	2026-09-25
Fedora	FEDORA-2026-c66009e517	F45	webkitgtk	2026-09-24
Fedora	FEDORA-2026-48a7996f9c	F45	xdg-desktop-portal-gnome	2026-09-30
Fedora	FEDORA-2026-c836eb1b43	F45	xdotool	2026-09-30
Fedora	FEDORA-2026-c4d5a488fe	F45	xreader	2026-09-28
Mageia	MGASA-2026-0440	10	borgbackup	2026-09-23
Mageia	MGASA-2026-0439	10	coreutils	2026-09-23
Mageia	MGASA-2026-0457	10	erlang	2026-09-27
Mageia	MGASA-2026-0441	10, 9	firefox, nss	2026-09-23
Mageia	MGASA-2026-0447	10	fuse3	2026-09-24
Mageia	MGASA-2026-0454	10, 9	gpsd	2026-09-25
Mageia	MGASA-2026-0444	10, 9	kbd	2026-09-24
Mageia	MGASA-2026-0438	10	libnfs	2026-09-23
Mageia	MGASA-2026-0456	10	libreswan	2026-09-27
Mageia	MGASA-2026-0442	10, 9	libwebsockets	2026-09-24
Mageia	MGASA-2026-0459	10	libxml2	2026-09-28
Mageia	MGASA-2026-0460	10	p11-kit	2026-09-28
Mageia	MGASA-2026-0461	10	pam	2026-09-28
Mageia	MGASA-2026-0448	10, 9	perl-Net-DNS	2026-09-24
Mageia	MGASA-2026-0445	10, 9	perl-URI	2026-09-24
Mageia	MGASA-2026-0458	9	php	2026-09-28
Mageia	MGASA-2026-0443	10, 9	pipewire	2026-09-24
Mageia	MGASA-2026-0450	10, 9	python-gitpython	2026-09-25
Mageia	MGASA-2026-0452	10, 9	python-webob	2026-09-25
Mageia	MGASA-2026-0455	10	python3 & python-pip	2026-09-26
Mageia	MGASA-2026-0449	10, 9	thunderbird, thunderbird-l10n	2026-09-24
Mageia	MGASA-2026-0453	10	udisks2	2026-09-25
Mageia	MGASA-2026-0451	10, 9	unbound	2026-09-25
Mageia	MGASA-2026-0446	10, 9	xdg-dbus-proxy	2026-09-24
Oracle	ELSA-2026-48866	OL7	abrt	2026-09-28
Oracle	ELSA-2026-69121	OL7	abrt	2026-09-25
Oracle	ELSA-2026-69113	OL8	apr-util	2026-09-24
Oracle	ELSA-2026-70640	OL9	buildah	2026-09-25
Oracle	ELSA-2026-71543	OL10	cockpit-image-builder	2026-09-25
Oracle	ELSA-2026-70391	OL9	containernetworking-plugins	2026-09-23
Oracle	ELSA-2026-69964	OL8	coreutils	2026-09-24
Oracle	ELSA-2026-69277	OL8	corosync	2026-09-25
Oracle	ELSA-2026-69125	OL10	curl	2026-09-23
Oracle	ELSA-2026-69461	OL10	firefox	2026-09-23
Oracle	ELSA-2026-69462	OL9	firefox	2026-09-23
Oracle	ELSA-2026-69387	OL8	freerdp	2026-09-24
Oracle	ELSA-2026-69100	OL9	gstreamer1-plugins-base	2026-09-23
Oracle	ELSA-2026-53416	OL7	host-metering	2026-09-24
Oracle	ELSA-2026-70564	OL9	ipa	2026-09-25
Oracle	ELSA-2026-70459	OL9	kernel	2026-09-28
Oracle	ELSA-2026-71232	OL9	kernel	2026-09-25
Oracle	ELSA-2026-69553	OL10	libarchive	2026-09-23
Oracle	ELSA-2026-69095	OL8	libtiff	2026-09-24
Oracle	ELSA-2026-71586	OL10	libxml2	2026-09-28
Oracle	ELSA-2026-69655	OL8	libxml2	2026-09-24
Oracle	ELSA-2026-71641	OL8	libxml2	2026-09-28
Oracle	ELSA-2026-71585	OL9	libxml2	2026-09-28
Oracle	ELSA-2026-69609	OL10	openexr	2026-09-25
Oracle	ELSA-2026-69608	OL9	openexr	2026-09-23
Oracle	ELSA-2026-69266	OL8	openssh	2026-09-24
Oracle	ELSA-2026-69130	OL9	openssh	2026-09-23
Oracle	ELSA-2026-70753	OL10	perl-DBI	2026-09-24
Oracle	ELSA-2026-71422	OL9	perl-DBI	2026-09-25
Oracle	ELSA-2026-69112	OL8	perl-DBI:1.641	2026-09-25
Oracle	ELSA-2026-70201	OL10	podman	2026-09-23
Oracle	ELSA-2026-69961	OL9	podman	2026-09-24
Oracle	ELSA-2026-69607	OL9	postgresql	2026-09-25
Oracle	ELSA-2026-70186	OL10	postgresql16	2026-09-23
Oracle	ELSA-2026-67166-0	OL10	postgresql18-postgis	2026-09-23
Oracle	ELSA-2026-69924	OL8	postgresql:12	2026-09-24
Oracle	ELSA-2026-69923	OL8	postgresql:15	2026-09-24
Oracle	ELSA-2026-69914	OL9	postgresql:15	2026-09-24
Oracle	ELSA-2026-69876	OL8	postgresql:16	2026-09-24
Oracle	ELSA-2026-69541	OL10	rsyslog	2026-09-23
Oracle	ELSA-2026-69540	OL9	rsyslog	2026-09-23
Oracle	ELSA-2026-70191	OL9	runc	2026-09-23
Oracle	ELSA-2026-70641	OL9	skopeo	2026-09-24
Oracle	ELSA-2026-70390	OL8	tar	2026-09-24
Oracle	ELSA-2026-70642	OL9	thunderbird	2026-09-25
Oracle	ELSA-2026-71419	OL10	unbound	2026-09-25
Oracle	ELSA-2026-69120	OL8	unbound	2026-09-24
Oracle	ELSA-2026-70754	OL8	unbound	2026-09-25
Oracle	ELSA-2026-71487	OL9	unbound	2026-09-28
Oracle	ELSA-2026-57417	OL7	yelp	2026-09-25
Red Hat	RHSA-2026:64777-01	EL10	buildah	2026-09-30
Red Hat	RHSA-2026:63332-01	EL10	buildah	2026-09-30
Red Hat	RHSA-2026:70640-01	EL9	buildah	2026-09-30
Red Hat	RHSA-2026:63163-01	EL8	container-tools:rhel8	2026-09-30
Red Hat	RHSA-2026:70391-01	EL9	containernetworking-plugins	2026-09-30
Red Hat	RHSA-2026:65918-01	EL10.0	delve	2026-09-30
Red Hat	RHSA-2026:67313-01	EL9.2	delve	2026-09-30
Red Hat	RHSA-2026:67153-01	EL9.4	delve	2026-09-30
Red Hat	RHSA-2026:64788-01	EL10	git-lfs	2026-09-30
Red Hat	RHSA-2026:67149-01	EL10.0	git-lfs	2026-09-30
Red Hat	RHSA-2026:67161-01	EL8	git-lfs	2026-09-30
Red Hat	RHSA-2026:72805-01	EL8.6	git-lfs	2026-09-30
Red Hat	RHSA-2026:72737-01	EL8.8	git-lfs	2026-09-30
Red Hat	RHSA-2026:66364-01	EL9	git-lfs	2026-09-30
Red Hat	RHSA-2026:72276-01	EL9.4	git-lfs	2026-09-30
Red Hat	RHSA-2026:63022-01	EL10	grafana	2026-09-30
Red Hat	RHSA-2026:67518-01	EL9.6	grafana	2026-09-30
Red Hat	RHSA-2026:63119-01	EL10	grafana-pcp	2026-09-30
Red Hat	RHSA-2026:66459-01	EL10.0	grafana-pcp	2026-09-30
Red Hat	RHSA-2026:63124-01	EL8	grafana-pcp	2026-09-30
Red Hat	RHSA-2026:63136-01	EL9	grafana-pcp	2026-09-30
Red Hat	RHSA-2026:67160-01	EL9.2	grafana-pcp	2026-09-30
Red Hat	RHSA-2026:67159-01	EL9.4	grafana-pcp	2026-09-30
Red Hat	RHSA-2026:71619-01	EL7	host-metering	2026-09-30
Red Hat	RHSA-2026:65335-01	EL10.0	ignition	2026-09-30
Red Hat	RHSA-2026:65359-01	EL9.2	ignition	2026-09-30
Red Hat	RHSA-2026:65880-01	EL9.4	ignition	2026-09-30
Red Hat	RHSA-2026:65534-01	EL10	image-builder	2026-09-30
Red Hat	RHSA-2026:65886-01	EL9	image-builder	2026-09-30
Red Hat	RHSA-2026:65895-01	EL10	osbuild-composer	2026-09-30
Red Hat	RHSA-2026:66016-01	EL8	osbuild-composer	2026-09-30
Red Hat	RHSA-2026:69235-01	EL8.6	osbuild-composer	2026-09-30
Red Hat	RHSA-2026:68504-01	EL8.8	osbuild-composer	2026-09-30
Red Hat	RHSA-2026:65153-01	EL9	osbuild-composer	2026-09-30
Red Hat	RHSA-2026:62754-01	EL9.2	osbuild-composer	2026-09-30
Red Hat	RHSA-2026:62753-01	EL9.4	osbuild-composer	2026-09-30
Red Hat	RHSA-2026:62803-01	EL9.6	osbuild-composer	2026-09-30
Red Hat	RHSA-2026:70201-01	EL10	podman	2026-09-30
Red Hat	RHSA-2026:69961-01	EL9	podman	2026-09-30
Red Hat	RHSA-2026:63127-01	EL10	rhc	2026-09-30
Red Hat	RHSA-2026:69103-01	EL10.0	rhc	2026-09-30
Red Hat	RHSA-2026:64786-01	EL8	rhc	2026-09-30
Red Hat	RHSA-2026:63130-01	EL9	rhc	2026-09-30
Red Hat	RHSA-2026:69104-01	EL9.2	rhc	2026-09-30
Red Hat	RHSA-2026:69105-01	EL9.4	rhc	2026-09-30
Red Hat	RHSA-2026:69107-01	EL9.6	rhc	2026-09-30
Red Hat	RHSA-2026:70103-01	EL10.0	rhc-worker-playbook	2026-09-30
Red Hat	RHSA-2026:70191-01	EL9	runc	2026-09-30
Red Hat	RHSA-2026:64818-01	EL10	skopeo	2026-09-30
Red Hat	RHSA-2026:70641-01	EL9	skopeo	2026-09-30
Red Hat	RHSA-2026:69308-01	EL10	yggdrasil	2026-09-30
Red Hat	RHSA-2026:69099-01	EL10	yggdrasil-worker-package-manager	2026-09-30
Red Hat	RHSA-2026:71420-01	EL10.0	yggdrasil-worker-package-manager	2026-09-30
Slackware	SSA:2026-271-01		groff	2026-09-28
Slackware	SSA:2026-272-01		mozilla-firefox	2026-09-29
Slackware	SSA:2026-271-02		pcre2	2026-09-28
Slackware	SSA:2026-267-01		php	2026-09-24
SUSE	SUSE-SU-2026:4380-1	SLE15	389-ds	2026-09-28
SUSE	SUSE-SU-2026:23916-1	SLE16.0	389-ds	2026-09-29
SUSE	openSUSE-SU-2026:21950-1	oS16.0	389-ds	2026-09-25
SUSE	SUSE-SU-2026:4334-1	SLE15 oS15.4	ImageMagick	2026-09-24
SUSE	SUSE-SU-2026:4376-1	SLE15 oS15.6	ImageMagick	2026-09-28
SUSE	SUSE-SU-2026:23901-1	SLE16.0	ImageMagick	2026-09-29
SUSE	openSUSE-SU-2026:11854-1	TW	ImageMagick	2026-09-26
SUSE	SUSE-SU-2026:23865-1	SLE16.0	alloy	2026-09-24
SUSE	SUSE-SU-2026:23853-1	SLE16.0	alloy	2026-09-24
SUSE	openSUSE-SU-2026:21899-1	oS16.0	alloy	2026-09-24
SUSE	SUSE-SU-2026:4388-1	MP4.3 SLE15 oS15.4	amazon-cloudwatch-agent	2026-09-29
SUSE	SUSE-SU-2026:4372-1	MP4.3 SLE15	amazon-ssm-agent	2026-09-28
SUSE	openSUSE-SU-2026:21884-1	oS16.0	amazon-ssm-agent	2026-09-24
SUSE	openSUSE-SU-2026:11856-1	TW	ansible-lint	2026-09-26
SUSE	openSUSE-SU-2026:21891-1	oS16.0	ant	2026-09-24
SUSE	SUSE-SU-2026:4308-1	SLE15 oS15.6	apptainer	2026-09-23
SUSE	openSUSE-SU-2026:21927-1	oS16.0	apptainer	2026-09-24
SUSE	openSUSE-SU-2026:21913-1	oS16.0	chromium	2026-09-24
SUSE	openSUSE-SU-2026:21921-1	oS16.0	chromium	2026-09-24
SUSE	SUSE-SU-2026:23910-1	SLE16.0	cjose	2026-09-29
SUSE	SUSE-SU-2026:4387-1	SLE12	corosync	2026-09-29
SUSE	SUSE-SU-2026:23850-1	SLE16.0	corosync	2026-09-24
SUSE	openSUSE-SU-2026:21887-1	oS16.0	corosync	2026-09-24
SUSE	SUSE-SU-2026:4392-1	SLE15 oS15.4	cosign	2026-09-29
SUSE	SUSE-SU-2026:23877-1	SLE-m6.0	cups	2026-09-28
SUSE	SUSE-SU-2026:23925-1	SLE-m6.1	cups	2026-09-30
SUSE	openSUSE-SU-2026:21929-1	oS16.0	cyrus-imapd	2026-09-24
SUSE	SUSE-SU-2026:23864-1	SLE16.0	distribution	2026-09-24
SUSE	SUSE-SU-2026:23852-1	SLE16.0	distribution	2026-09-24
SUSE	openSUSE-SU-2026:21898-1	oS16.0	distribution	2026-09-24
SUSE	openSUSE-SU-2026:11872-1	TW	distribution-registry	2026-09-29
SUSE	SUSE-SU-2026:4358-1	oS15.3	erlang27	2026-09-28
SUSE	SUSE-SU-2026:4374-1	SLE15 oS15.4	exiv2	2026-09-28
SUSE	SUSE-SU-2026:23860-1	SLE16.0	exiv2	2026-09-24
SUSE	SUSE-SU-2026:23871-1	SLE16.0	exiv2	2026-09-24
SUSE	openSUSE-SU-2026:21904-1	oS16.0	exiv2	2026-09-24
SUSE	SUSE-SU-2026:23894-1	SLE-m6.2	expat	2026-09-29
SUSE	SUSE-SU-2026:23912-1	SLE16.0	expat	2026-09-29
SUSE	openSUSE-SU-2026:21877-1	oS16.0	ffmpeg-7	2026-09-24
SUSE	SUSE-SU-2026:23918-1	SLE16.0	firefox	2026-09-29
SUSE	openSUSE-SU-2026:21951-1	oS16.0	firefox	2026-09-25
SUSE	openSUSE-SU-2026:11873-1	TW	flatpak	2026-09-29
SUSE	openSUSE-SU-2026:11845-1	TW	flatpak-builder	2026-09-25
SUSE	openSUSE-SU-2026:11846-1	TW	forgejo-longterm	2026-09-25
SUSE	openSUSE-SU-2026:21883-1	oS16.0	freeipmi	2026-09-24
SUSE	SUSE-SU-2026:23873-1	SLE-m6.0	gdb	2026-09-28
SUSE	openSUSE-SU-2026:21890-1	oS16.0	gdb	2026-09-24
SUSE	SUSE-SU-2026:4309-1	SLE15 oS15.4	gimp	2026-09-23
SUSE	openSUSE-SU-2026:21959-1	oS16.0	gimp	2026-09-25
SUSE	openSUSE-SU-2026:21955-1	oS16.0	gitoxide	2026-09-25
SUSE	SUSE-SU-2026:23880-1	SLE-m6.0	glib2	2026-09-28
SUSE	SUSE-SU-2026:23928-1	SLE-m6.1	glib2	2026-09-30
SUSE	SUSE-SU-2026:4348-1	SLE12	glib2	2026-09-25
SUSE	SUSE-SU-2026:4367-1	SLE15 oS15.6	glib2	2026-09-29
SUSE	openSUSE-SU-2026:21888-1	oS16.0	gnome-remote-desktop	2026-09-24
SUSE	SUSE-SU-2026:4350-1	SLE12	gnome-shell	2026-09-25
SUSE	SUSE-SU-2026:4373-1	SLE15	gnome-shell	2026-09-28
SUSE	SUSE-SU-2026:23874-1	SLE-m6.0	google-guest-agent	2026-09-28
SUSE	SUSE-SU-2026:23876-1	SLE-m6.0	google-osconfig-agent	2026-09-28
SUSE	SUSE-SU-2026:23924-1	SLE-m6.1	google-osconfig-agent	2026-09-30
SUSE	openSUSE-SU-2026:11847-1	TW	google-osconfig-agent	2026-09-25
SUSE	openSUSE-SU-2026:21882-1	oS16.0	google-osconfig-agent	2026-09-24
SUSE	openSUSE-SU-2026:11874-1	TW	goose	2026-09-29
SUSE	SUSE-SU-2026:23863-1	SLE16.0	govulncheck-vulndb	2026-09-24
SUSE	SUSE-SU-2026:23855-1	SLE16.0	govulncheck-vulndb	2026-09-24
SUSE	openSUSE-SU-2026:21897-1	oS16.0	govulncheck-vulndb	2026-09-24
SUSE	openSUSE-SU-2026:21875-1	oS16.0	gvfs	2026-09-24
SUSE	openSUSE-SU-2026:21958-1	oS16.0	haveged	2026-09-25
SUSE	openSUSE-SU-2026:11848-1	TW	helm	2026-09-25
SUSE	openSUSE-SU-2026:11875-1	TW	helm	2026-09-29
SUSE	SUSE-SU-2026:4335-1	SLE12	hplip	2026-09-24
SUSE	SUSE-SU-2026:4362-1	SLE15	hplip	2026-09-28
SUSE	SUSE-SU-2026:4371-1	SLE15 oS15.4	hplip	2026-09-28
SUSE	SUSE-SU-2026:4364-1	SLE15 oS15.6	hplip	2026-09-28
SUSE	openSUSE-SU-2026:21911-1	oS16.0	imagemagick	2026-09-24
SUSE	SUSE-SU-2026:4394-1	SLE15	jackson-annotations, jackson-bom, jackson-core, jackson- databind, jackson-dataformat-xml, jackson-dataformats-binary, jackson-modules- base	2026-09-29
SUSE	openSUSE-SU-2026:11876-1	TW	jackson-core	2026-09-29
SUSE	openSUSE-SU-2026:11877-1	TW	jackson-databind	2026-09-29
SUSE	openSUSE-SU-2026:11879-1	TW	jackson-dataformat-csv	2026-09-29
SUSE	SUSE-SU-2026:4339-1	SLE15	java-11-openjdk	2026-09-24
SUSE	SUSE-SU-2026:4393-1	SLE15	jsoup, re2j	2026-09-29
SUSE	SUSE-SU-2026:23867-1	SLE16.0	jsoup, re2j	2026-09-24
SUSE	SUSE-SU-2026:23856-1	SLE16.0	jsoup, re2j	2026-09-24
SUSE	SUSE-SU-2026:23893-1	SLE-m6.2	kbd	2026-09-29
SUSE	SUSE-SU-2026:23911-1	SLE16.0	kbd	2026-09-29
SUSE	openSUSE-SU-2026:21939-1	oS16.0	kbd	2026-09-25
SUSE	SUSE-SU-2026:4347-1	SLE15 SLE5.5 SLE-m5.5 oS15.5	kernel	2026-09-24
SUSE	SUSE-SU-2026:4369-1	SLE15 oS15.6	kernel	2026-09-28
SUSE	SUSE-SU-2026:23902-1	SLE16.0	kernel	2026-09-29
SUSE	SUSE-SU-2026:23897-1	SLE16.0	kernel	2026-09-29
SUSE	SUSE-SU-2026:23887-1	SLE16.0 SLE-m6.2	kernel	2026-09-29
SUSE	SUSE-SU-2026:23881-1	SLE16.0 SLE-m6.2	kernel	2026-09-29
SUSE	openSUSE-SU-2026:21910-1	SLE16.0 oS16.0	kernel	2026-09-24
SUSE	openSUSE-SU-2026:21925-1	oS16.0	keybase-client	2026-09-24
SUSE	openSUSE-SU-2026:11881-1	TW	kubectl-cnpg	2026-09-29
SUSE	openSUSE-SU-2026:11833-1	TW	libX11-6	2026-09-23
SUSE	SUSE-SU-2026:23885-1	SLE-m6.2	libX11	2026-09-29
SUSE	SUSE-SU-2026:23899-1	SLE16.0	libX11	2026-09-29
SUSE	SUSE-SU-2026:23886-1	SLE-m6.2	libXrender	2026-09-29
SUSE	SUSE-SU-2026:4395-1	SLE12	libXrender	2026-09-29
SUSE	SUSE-SU-2026:4397-1	SLE15 SLE5.3 SLE5.4 SLE5.5 SLE-m5.3 SLE-m5.4 SLE-m5.5	libXrender	2026-09-29
SUSE	SUSE-SU-2026:23900-1	SLE16.0	libXrender	2026-09-29
SUSE	SUSE-SU-2026:4378-1	SLE15	libheif	2026-09-28
SUSE	SUSE-SU-2026:23892-1	SLE-m6.2	libpcap	2026-09-29
SUSE	SUSE-SU-2026:23907-1	SLE16.0	libpcap	2026-09-29
SUSE	openSUSE-SU-2026:11835-1	TW	librepods	2026-09-23
SUSE	SUSE-SU-2026:4368-1	SLE15 SLE5.3 SLE5.4 SLE5.5 SLE-m5.3 SLE-m5.4 SLE-m5.5 oS15.4 oS15.5 oS15.6	libsodium	2026-09-28
SUSE	SUSE-SU-2026:23875-1	SLE-m6.0	libsoup	2026-09-28
SUSE	SUSE-SU-2026:23923-1	SLE-m6.1	libsoup	2026-09-30
SUSE	SUSE-SU-2026:23866-1	SLE16.0	libsoup	2026-09-24
SUSE	SUSE-SU-2026:23857-1	SLE16.0	libsoup	2026-09-24
SUSE	openSUSE-SU-2026:21871-1	oS16.0	libsoup	2026-09-24
SUSE	openSUSE-SU-2026:21901-1	oS16.0	libsoup	2026-09-24
SUSE	SUSE-SU-2026:23878-1	SLE-m6.0	libtpms	2026-09-28
SUSE	SUSE-SU-2026:23926-1	SLE-m6.1	libtpms	2026-09-30
SUSE	SUSE-SU-2026:4363-1	SLE15 oS15.6	libtpms	2026-09-28
SUSE	openSUSE-SU-2026:21908-1	oS16.0	libx11	2026-09-24
SUSE	openSUSE-SU-2026:21909-1	oS16.0	libxrender	2026-09-24
SUSE	openSUSE-SU-2026:21886-1	oS16.0	mcphost	2026-09-24
SUSE	openSUSE-SU-2026:21872-1	oS16.0	memcached	2026-09-24
SUSE	SUSE-SU-2026:4391-1	SLE15	netty, netty-tcnative	2026-09-29
SUSE	SUSE-SU-2026:4355-1	SLE15 oS15.4	nodejs16	2026-09-28
SUSE	openSUSE-SU-2026:11861-1	TW	obs-service-cargo	2026-09-26
SUSE	openSUSE-SU-2026:11849-1	TW	openai-codex	2026-09-25
SUSE	openSUSE-SU-2026:21873-1	oS16.0	opensc	2026-09-24
SUSE	openSUSE-SU-2026:21952-1	oS16.0	opensuse-signkey-cert	2026-09-25
SUSE	openSUSE-SU-2026:21954-1	oS16.0	osmo-iuh	2026-09-25
SUSE	SUSE-SU-2026:23891-1	SLE-m6.2	pcre2	2026-09-29
SUSE	SUSE-SU-2026:23906-1	SLE16.0	pcre2	2026-09-29
SUSE	SUSE-SU-2026:4302-1	SLE15	perl-Authen-SASL	2026-09-23
SUSE	SUSE-SU-2026:23913-1	SLE16.0	perl-Authen-SASL	2026-09-29
SUSE	SUSE-SU-2026:4346-1	SLE12	perl-DBI	2026-09-24
SUSE	SUSE-SU-2026:4386-1	SLE15 oS15.6	perl-DBI	2026-09-29
SUSE	SUSE-SU-2026:23919-1	SLE16.0	perl-DBI	2026-09-29
SUSE	openSUSE-SU-2026:21956-1	oS16.0	perl-mojolicious	2026-09-25
SUSE	SUSE-SU-2026:4311-1	SLE15 oS15.3	podofo	2026-09-23
SUSE	SUSE-SU-2026:4349-1	oS15.5	poppler	2026-09-25
SUSE	SUSE-SU-2026:4351-1	SLE12	python-WebOb	2026-09-25
SUSE	openSUSE-SU-2026:11864-1	TW	python-WebOb-doc	2026-09-27
SUSE	SUSE-SU-2026:4298-1	oS15.4	python-WebOb	2026-09-23
SUSE	openSUSE-SU-2026:21874-1	oS16.0	python-gitpython	2026-09-24
SUSE	SUSE-SU-2026:4398-1	SLE15 oS15.3	python-pymongo	2026-09-30
SUSE	SUSE-SU-2026:4365-1	SLE15 oS15.6	python-soupsieve	2026-09-28
SUSE	openSUSE-SU-2026:21928-1	oS16.0	python-weasyprint	2026-09-24
SUSE	SUSE-SU-2026:4390-1	oS15.4	python310	2026-09-29
SUSE	SUSE-SU-2026:4396-1	MP4.3 SLE15 oS15.4	python311	2026-09-29
SUSE	openSUSE-SU-2026:11839-1	TW	python313-graphifyy	2026-09-23
SUSE	openSUSE-SU-2026:11867-1	TW	python313-vllm	2026-09-27
SUSE	openSUSE-SU-2026:11868-1	TW	python314	2026-09-27
SUSE	SUSE-SU-2026:23869-1	SLE16.0	rabbitmq-server	2026-09-24
SUSE	SUSE-SU-2026:23859-1	SLE16.0	rabbitmq-server	2026-09-24
SUSE	openSUSE-SU-2026:21903-1	oS16.0	rabbitmq-server	2026-09-24
SUSE	SUSE-SU-2026:4370-1	SLE15 oS15.6	redis	2026-09-28
SUSE	SUSE-SU-2026:4375-1	SLE15 oS15.5	redis7	2026-09-28
SUSE	SUSE-SU-2026:4377-1	SLE15 oS15.6	redis7	2026-09-28
SUSE	openSUSE-SU-2026:21878-1	oS16.0	ruby3.4	2026-09-24
SUSE	openSUSE-SU-2026:21933-1	oS16.0	sdbootutil	2026-09-25
SUSE	SUSE-SU-2026:3843-2	SLE15	suseconnect-ng	2026-09-28
SUSE	SUSE-SU-2026:23879-1	SLE-m6.0	swtpm	2026-09-28
SUSE	SUSE-SU-2026:23927-1	SLE-m6.1	swtpm	2026-09-30
SUSE	SUSE-SU-2026:4366-1	SLE15	swtpm	2026-09-29
SUSE	SUSE-SU-2026:4389-1	MP4.3 SLE15	terraform-provider-susepubliccloud	2026-09-29
SUSE	SUSE-SU-2026:23884-1	SLE-m6.2	util-linux	2026-09-29
SUSE	SUSE-SU-2026:23870-1	SLE16.0	util-linux	2026-09-24
SUSE	SUSE-SU-2026:23861-1	SLE16.0	util-linux	2026-09-24
SUSE	openSUSE-SU-2026:21905-1	oS16.0	util-linux	2026-09-24
SUSE	SUSE-SU-2026:4379-1	SLE15	wireshark	2026-09-28
SUSE	SUSE-SU-2026:23868-1	SLE16.0	zstd-jni	2026-09-24
SUSE	SUSE-SU-2026:23858-1	SLE16.0	zstd-jni	2026-09-24
SUSE	openSUSE-SU-2026:21902-1	oS16.0	zstd-jni	2026-09-24
Ubuntu	USN-8807-1	18.04 20.04 22.04 24.04 26.04	Open-iSNS	2026-09-23
Ubuntu	USN-8839-1	16.04 18.04 20.04 22.04 24.04 26.04	atril	2026-09-29
Ubuntu	USN-8832-1	18.04 20.04 22.04 24.04	booth	2026-09-29
Ubuntu	USN-8844-1	26.04	c-ares	2026-09-29
Ubuntu	USN-8838-1	16.04 18.04 20.04 22.04 24.04	catdoc	2026-09-29
Ubuntu	USN-8487-2	14.04	curl	2026-09-29
Ubuntu	USN-8820-1	16.04 18.04 20.04 22.04 24.04 26.04	curl	2026-09-24
Ubuntu	USN-8828-1	16.04 18.04 20.04 22.04 24.04 26.04	dracut	2026-09-29
Ubuntu	USN-8835-1	24.04 26.04	emacs	2026-09-29
Ubuntu	USN-8827-1	14.04 16.04 18.04 20.04 22.04 24.04 26.04	erlang	2026-09-29
Ubuntu	USN-8834-1	22.04 24.04 26.04	exim4	2026-09-28
Ubuntu	USN-8813-1	14.04 16.04 18.04 20.04 22.04 24.04 26.04	expat	2026-09-24
Ubuntu	USN-8843-1	14.04 16.04 18.04 20.04 22.04 24.04 26.04	freeipmi	2026-09-29
Ubuntu	USN-8836-1	24.04 26.04	freerdp3	2026-09-28
Ubuntu	USN-8812-1	14.04 16.04 18.04 20.04 22.04 24.04 26.04	gdal	2026-09-24
Ubuntu	USN-8810-1	14.04 16.04 18.04 20.04 22.04 24.04 26.04	imagemagick	2026-09-24
Ubuntu	USN-8815-1	14.04 18.04 20.04 24.04 26.04	libass	2026-09-24
Ubuntu	USN-8841-1	14.04 16.04 18.04 20.04 22.04 24.04 26.04	libdbi-perl	2026-09-30
Ubuntu	USN-8840-1	14.04 16.04 18.04 20.04 22.04 24.04 26.04	libevent	2026-09-29
Ubuntu	USN-8809-1	16.04 18.04 20.04 22.04 24.04 26.04	libgit2	2026-09-23
Ubuntu	USN-8846-1	18.04 20.04 22.04 24.04 26.04	libheif	2026-09-29
Ubuntu	USN-8824-1	14.04 16.04 18.04 20.04 22.04 24.04 26.04	libpcap	2026-09-25
Ubuntu	USN-8831-1	22.04 24.04 26.04	libvirt	2026-09-28
Ubuntu	USN-8833-1	26.04	libvirt-hwe	2026-09-28
Ubuntu	USN-8822-1	20.04 22.04 24.04 26.04	libwebsockets	2026-09-28
Ubuntu	USN-8816-1	24.04 26.04	linux, linux-aws, linux-aws-7.0, linux-hwe-7.0, linux-ibm, linux-oracle, linux-raspi, linux-realtime	2026-09-24
Ubuntu	USN-8851-1	18.04 20.04	linux, linux-aws, linux-azure, linux-fips, linux-gcp, linux-gcp-5.4, linux-gcp-fips, linux-hwe-5.4, linux-iot, linux-kvm, linux-oracle, linux-oracle-5.4, linux-raspi, linux-xilinx-zynqmp	2026-09-30
Ubuntu	USN-8817-1	22.04 24.04	linux, linux-azure, linux-azure-6.8, linux-azure-fde, linux-azure-fde-6.8, linux-azure-fips, linux-fips, linux-gcp, linux-gcp-6.8, linux-gcp-fips, linux-gke, linux-gkeop, linux-ibm, linux-lowlatency, linux-lowlatency-hwe-6.8, linux-oracle, linux-oracle-6.8, linux-raspi, linux-raspi-realtime, linux-realtime, linux-realtime-6.8	2026-09-24
Ubuntu	USN-8819-1	16.04 18.04	linux, linux-hwe, linux-kvm	2026-09-25
Ubuntu	USN-8818-4	22.04	linux, linux-nvidia	2026-09-30
Ubuntu	USN-8729-6	22.04 24.04	linux-aws, linux-aws-6.8	2026-09-29
Ubuntu	USN-8818-1	20.04 22.04	linux-aws, linux-aws-fips, linux-azure, linux-azure-fde, linux-azure-fips, linux-gcp, linux-gcp-fips, linux-gke, linux-gkeop, linux-hwe-5.15, linux-ibm, linux-intel-iot-realtime, linux-intel-iotg, linux-kvm, linux-lowlatency, linux-lowlatency-hwe-5.15, linux-oracle, linux-realtime, linux-xilinx-zynqmp	2026-09-24
Ubuntu	USN-8819-2	16.04 18.04	linux-aws, linux-gcp, linux-gcp-4.15, linux-gcp-fips	2026-09-25
Ubuntu	USN-8818-3	20.04	linux-aws-5.15, linux-azure-5.15, linux-azure-fde-5.15, linux-intel-iotg-5.15	2026-09-29
Ubuntu	USN-8819-4	18.04	linux-aws-fips, linux-azure-fips, linux-fips	2026-09-30
Ubuntu	USN-8729-5	24.04	linux-aws-fips	2026-09-25
Ubuntu	USN-8817-2	24.04	linux-aws-fips	2026-09-30
Ubuntu	USN-8819-3	14.04 16.04 18.04	linux-aws-hwe, linux-azure, linux-azure-4.15	2026-09-29
Ubuntu	USN-8850-1	20.04	linux-bluefield	2026-09-30
Ubuntu	USN-8730-7	22.04	linux-fips	2026-09-30
Ubuntu	USN-8816-2	24.04 26.04	linux-gcp, linux-gcp-7.0, linux-oem-7.0	2026-09-29
Ubuntu	USN-8818-2	20.04	linux-ibm-5.15	2026-09-25
Ubuntu	USN-8730-6	20.04	linux-intel-iotg-5.15	2026-09-25
Ubuntu	USN-8842-1	22.04 24.04	linux-nvidia, linux-nvidia-6.8, linux-nvidia-lowlatency	2026-09-29
Ubuntu	USN-8849-1	20.04	linux-nvidia-tegra-5.15	2026-09-30
Ubuntu	USN-8728-3	24.04	linux-oracle-7.0	2026-09-29
Ubuntu	USN-8826-1	16.04 18.04 20.04 22.04 24.04 26.04	lxc	2026-09-28
Ubuntu	USN-8805-1	16.04 18.04	moodle	2026-09-24
Ubuntu	USN-8806-1	26.04	network-manager	2026-09-23
Ubuntu	USN-8814-1	22.04 24.04 26.04	octavia	2026-09-24
Ubuntu	USN-8847-2	14.04 16.04 18.04 20.04	openssl, openssl1.0	2026-09-30
Ubuntu	USN-8847-1	22.04 24.04 26.04	openssl	2026-09-29
Ubuntu	USN-8837-1	16.04 18.04 20.04 22.04 24.04	pdfminer	2026-09-29
Ubuntu	USN-8830-1	16.04 18.04 20.04 22.04 24.04 26.04	php-phpseclib	2026-09-29
Ubuntu	USN-8829-1	16.04	plasma-workspace	2026-09-29
Ubuntu	USN-8823-1	16.04 18.04 20.04 22.04 24.04 26.04	pyjwt	2026-09-28
Ubuntu	USN-8811-1	16.04 18.04 20.04	python-urllib3	2026-09-24
Ubuntu	USN-8825-1	20.04 22.04 24.04 26.04	requests	2026-09-28
Ubuntu	USN-8808-1	16.04 18.04 20.04 22.04 24.04 26.04	sqlparse	2026-09-23
Ubuntu	USN-8821-1	26.04	swift	2026-09-24
Ubuntu	USN-8287-2	24.04 26.04	xdg-desktop-portal	2026-09-23

Full Story (comments: none)