Welcome to the LWN.net Weekly Edition for October 9, 2025

This edition contains the following feature content:

• Upcoming Rust language features for kernel development: several new Rust features aimed at supporting the Rust for Linux project were described at Kangrejos.
• Highlights from systemd v258: part two: the second half of our look at features in systemd v258.
• Kernel hackers at Cauldron, 2025 edition: a GNU Tools Cauldron session on the intersection of the toolchain and the kernel.
• Next steps for BPF support in the GNU toolchain: further discussions between kernel hackers and GNU tools developers, this time focusing on BPF support.
• 6.18 merge window, part 1: the first half of a recap of the features getting merged for Linux 6.18.
• Progress on defeating lifetime-end pointer zapping: a Kangrejos talk by Paul McKenney on solving a knotty problem with pointer provenance for C, C++, and Rust.
• A look at the Robot Operating System: an overview of an SDK for developing robots and related applications.

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)

Upcoming Rust language features for kernel development

The Rust for Linux project has been good for Rust, Tyler Mandry, one of the co-leads of Rust's language-design team, said. He gave a talk at Kangrejos 2025 covering upcoming Rust language features and thanking the Rust for Linux developers for helping drive them forward. Afterward, Benno Lossin and Xiangfei Ding went into more detail about their work on the three most important language features for kernel development: field projections, in-place initialization, and arbitrary self types.

Many people have remarked that the development of new language features in Rust can be quite slow, Mandry said. Partly, that can be attributed to the care the Rust language team takes to avoid enshrining bad designs. But the biggest reason is "alignment in attention". The Rust project is driven by volunteers, which means that if there are not people focusing on pushing a given feature or group of related features forward, they languish. The Rust for Linux project has actually been really helpful for addressing that, Mandry explained, because it is something that a lot of people are excited about, and that focuses effort onto the few specific things that the Linux kernel needs.

Mandry then went through a whirlwind list of upcoming language features, including types without known size information, reference-counting improvements, user-defined function modifiers of the same kind as const, and more. At the end, he asked which of those were most important to Rust for Linux, and how the assembled kernel developers would prioritize them. Beyond the three features to be discussed later, Lossin said that the project definitely wanted the ability to write functions that can be evaluated at compile time (called const functions in Rust) in trait definitions. Danilo Krummrich asked for specialization, which immediately prompted an "Oh no!" from Lossin, due to the feature's nearly decade-long history of causing problems for Rust's type system. Specialization would allow two overlapping implementations for a single trait to exist, with the compiler picking the more specific one. Matthew Maurer asked for some ability to control what the compiler does on integer overflow.

Ultimately, Miguel Ojeda told Mandry that the priority should be on stabilizing the unstable language features that Rust for Linux currently uses, followed by language features that would change how the project structures its code, followed by everything else. The next two talks went into much more detail about the current status and future plans for some of those key language features.

Field projections

Field projection refers to the idea of taking a pointer to a structure, and turning it into a pointer to a field of the structure. Rust does already have this for the built-in reference and pointer types, but it can't always be made to work for user-defined smart-pointer types. Since the Rust for Linux developers would like to have custom smart pointers to handle untrusted data, reference counting, external locking, and related kernel complications, they would benefit from a general language feature allowing field projections for all pointer types using the same syntax. Lossin spoke about his work on the problem, which has been ongoing since Kangrejos 2022. There has been "lots of progress" so far, but the work is still in the design stage, with a few details left to work out.

The built-in field projections all have the same kind of type signature, Lossin explained. For example, the code for converting a reference to an object into a reference to one of its fields and the code for converting a raw pointer to an object into a raw pointer to one of its fields look different, but have similar signatures:

    fn project_reference(r: &MyStruct) -> &Field {
        &r.field
    }

    unsafe fn project_pointer(r: *mut MyStruct) -> *mut Field {
        unsafe { &raw mut (*r).field }
    }

    // The equivalent C code would look like this:
    struct field *project(struct my *r) {
        return &(r->field);
    }

This example uses the relatively recent raw borrow syntax.

The Pin type throws a bit of a wrench into things. The Rust compiler is, by default, free to move structures around for performance reasons. That doesn't work when the structure is being referenced from the C side, so the Pin type is used to mark structures that shouldn't be moved. Projecting a Pin<MyStruct> Pin<&mut MyStruct> [Lossin sent LWN a correction: Pin is always used to wrap a pointer type, not a structure directly] might produce either a Pin<&mut Field> or a plain &mut Field depending on whether the field is also of a type that shouldn't be moved or not. So the most general possible signature for the field projection operation would be something like this, Lossin said:

    Container<'a, Struct> -> Output<'a, Field>

That is, given some pointer type that wraps a structure and must be valid for lifetime a, projecting a field gives a (possibly different) output pointer type wrapping a field of that structure, valid for the same lifetime. Lossin then gave an example of how supporting this could make fully implementing read-copy-update (RCU) support in the kernel's Rust bindings a lot easier.

The RCU mechanism protects readers from concurrent writers, he explained, but it doesn't protect writers from each other. It's somewhat common in the kernel, therefore, to have a mutex protecting some data, with a frequently accessed field of that data being protected by RCU. That way, readers rely on the RCU lock (which is cheap), and writers synchronize with each other using the mutex. Translating that interface to Rust poses problems: Rust doesn't allow any access to the content inside a Mutex without locking it first, so the straightforward translation of this pattern wouldn't work. It would force Rust readers to lock the mutex in order to read the RCU field, which would be an unacceptable performance hit.

With generalized field projection in the language, though, the Rust for Linux developers could write bindings that permit projecting a &Mutex<MyStruct> into an &Rcu<Field> without holding the lock. In driver code, attempting to read from the RCU-protected field would look like a normal access, the same way it is in C — but the compiler would still check that the other, non-RCU-protected data isn't touched without holding the mutex.

Lossin ended by asking the assembled developers to keep an eye on the tracking issue for the feature, and provide feedback on it. Daniel Almeida asked whether testing the feature outside the mainline kernel was really helpful; Ojeda affirmed that it was, because that makes it easier to go to the Rust team and make a case to stabilize the feature. The Rust for Linux project is trying not to use any new unstable features (and to compile with a version of Rust equal to or older than the version packaged on Debian stable), so the feature needs to be completed and make it into Debian 14 (expected in 2027) before it will be widely usable in kernel code.

Andreas Hindborg asked: "Can we have this yesterday, please?", to general amusement. The kernel's Rust bindings already feature a plethora of custom pointers encoding various invariants; this feature, whenever it becomes available to kernel code, may make them a good deal easier to use in driver code.

Arbitrary self types

Ding gave an update immediately afterward about another ergonomic language feature for custom pointers: arbitrary self types. In Rust, a method on a type can have a first argument that is an object of the type or that is a reference to one. Such a method can be called with the .method() syntax, instead of the more general Type::function() syntax. But the proliferation of smart pointers in kernel Rust code means that the programmer frequently does not have a plain reference; often, they instead have a Pin, an Arc, or some other smart-pointer type.

The arbitrary self types proposal that Ding has been working on would let programmers write methods that take smart pointers, instead of normal references:

    impl MyStruct {
        fn method(self: Pin<&mut MyStruct>) {}
    }

Unfortunately, adding this to the compiler has not proved to be straightforward. The interaction with Rust's existing Deref trait, which makes custom smart pointers possible in the first place, complicates the implementation because not all of the type information is available while searching for matching methods. Currently, if the user has a Pin<&mut MyStruct> and they call a method on it, the compiler will first look for a matching method for Pin. If one isn't found, it will try to dereference the type, producing a &mut MyStruct. That type is checked for matching methods, and then is dereferenced one final time, producing a MyStruct. That type will finally have a matching method, or else the compiler will emit a type error.

By the time that procedure begins checking functions associated with MyStruct, it will have already discarded information about the wrapping types, which an implementation of arbitrary self types needs. Ding spent a few minutes explaining the approaches for rectifying the problem that he had tried and discarded, before focusing on the current approach. He has added another trait — tentatively called Receiver — that is used to mark types that can be used with arbitrary self types. Then the compiler can try following the chain of Receiver implementations before following the chain of Deref implementations. That does mean that a pointer type will have to opt into being used as an arbitrary self type, but Ding didn't see that as a downside. Letting the author of a pointer type decide when it should support the new feature eliminates a lot of concerns around accidentally introducing backward compatibility problems. For the kernel, it doesn't really impose a barrier, because the Rust developers can just add Receiver implementations as they run across cases that require them.

Ojeda asked how long Ding thought it would take to finalize the arbitrary self types feature; in particular, would it be ready within a year? Ding agreed that a year was possible, although he would need support from the Rust language team in order to make that happen. He wants to run Crater, the tool that the Rust community uses to check whether compiler changes break any published Rust libraries, against his change before submitting the code. Ojeda offered help with obtaining a large build machine to do that, since Ding has had trouble previously with the memory requirements to compile some packages during a Crater run.

In-place initialization

The other topic that Ding wanted to cover was his work on in-place initialization. Like the other new language features being discussed, this doesn't really enable new use cases, but it does make common kernel code cleaner. Currently, Rust code in the kernel uses the pin_init!() macro to create structures that are fixed in place after initialization (by being wrapped in Pin).

There's nothing wrong with pin_init!(): "We love pin_init!()! We want to make a language feature out of it." Adopting a language feature for in-place initialization would also help with a handful of sharp edges outside kernel code; it could make creating large Future values on the heap more ergonomic, and let some traits become dyn-compatible. The exact design of this language feature was more up in the air; Ding covered three different proposals for how it could work.

The simplest, proposed by Alice Ryhl and Lossin, would be to add a new keyword, init, before a structure-initializing expression in order to ask the compiler to automatically write an implementation of the kernel's PinInit trait. That has the nice benefit of being a fairly minimal change to the language, although it would lock in the use of the PinInit trait in its current form.

Another solution, proposed by Taylor Cramer, would introduce a new type of reference into the language. Rust's existing references can either be read from (&) or read from and written to (&mut). This proposal would add a third type, &out, that can only be written to, not read from. The only way to use an &out reference would be to either write to it, or use projection to break it apart into multiple &out references to various fields. Under this scheme, in-place initialization would look like allocating space on the heap, and then returning an &out reference. The calling code could then fill it in however it wants to, potentially passing off sub-parts to other functions. The compiler would track that the &out references are all used before allowing the code to obtain a normal &mut reference to the heap allocation.

That proposal was considerably less polished than Ryhl and Lossin's approach, however. Ding later told me that he, Mandry, and other compiler contributors at Kangrejos were actually working on figuring out how it would interact with some of the Rust compiler's internals in between talks that day. By the end of the conference, they had a rough idea of how it could be implemented, so a more detailed version of the out-pointer proposal may be forthcoming shortly.

The final design, taking inspiration from C++, would be a form of guaranteed optimization, where constructing a new value and then immediately moving it to the heap causes it to be constructed on the heap in the first place. Ding was less sure about the details of the final proposal; he suggested that the best way forward might be to implement both the PinInit proposal and the out-reference proposal, and see how well each approach works in practice.

Regardless of which approach ends up being chosen, it seems clear that Mandry's point about the Rust for Linux project driving language improvement is correct. While these features are in the early stages, adopting them could significantly simplify code involving user-defined smart pointers, both within and outside the kernel.

Update: Since the talks described in this article, the work on field projection has received an update. Lossin wrote in to inform LWN that all fields of all structures are now considered structurally pinned, so projecting a Pin will now always produce a Pin<&mut Field> or similar value.

Comments (6 posted)

Highlights from systemd v258: part two

Systemd v258 was released on September 17 after more than nine months of development. LWN has already covered some of the features and changes being readied for v258 before it was final. Now that the release is out, it is time to look at more of what came in v258, including a sandbox shell, new boot options, service-level disk quotas, and enhancements to systemd-resolved.

Sandbox shell

Systemd provides several ways to put services into a sandbox to improve system security by removing or restricting access to various functionality. For example, one might set the ProtectSystem=full directive in a service file to set the /boot, /etc, and /usr directories as read-only for a service. The project recommends turning on as many sandboxing options as possible.

To get a sense of what is already sandboxed, systemd has the "systemd-analyze security" command to provide an overview of the sandboxing settings for all service units. The command can also display a full list of settings for a service, their status, and the overall "exposure" level:

    # systemd-analyze security servicename

Inspecting a service's sandbox options is helpful, but it may not be enough if a sandboxed service is failing or misbehaving, as Lennart Poettering points out, "since it's the daemon you sandbox, and your admin tools are outside of that sandbox, it's sometimes challenging to analyze how the daemon sees things".

In v258, the project has added the unit-shell option to systemd-analyze; this opens a shell inside a running service's sandbox. For instance, this command would open a shell with the same environment as the NetworkManager service.

    # systemd-analyze unit-shell NetworkManager.service

Currently this is only available for running services, but Chizoba Odinaka, who developed unit-shell as an Outreachy Google Summer of Code project, said that there will be another option added for non-running services in the future.

New boot options

A few new Type #1 Boot Loader Entry Key options have been added to the systemd-boot UEFI boot manager. Type #1 entries are text-based configurations that are suitable for a number of image types, while Type #2 entries are single-file EFI images that combine a kernel with its configuration, initrd, and other components.

Now systemd-boot supports Type #1 entries for Unified Kernel Images (UKI) located on disk (with the uki option) or images located on a remote server (uki-url). If a system is booted from a network-boot-provided UKI, systemd-stub will write its URL to the LoaderDeviceURL EFI variable, which can be used to look for a root disk image or other resources at the same location. This opens up the ability to boot from a rootfs downloaded over HTTP.

Note that this is HTTP only, not HTTPS. In a discussion about the feature on GitHub, Poettering said that it should not matter if artifacts are "attacked on the wire" because they would be validated using Secure Boot and TPM measurements. He also questioned whether the UEFI certificate database could be kept reasonably up-to-date in order to use HTTPS, unless an organization is enrolling its own certificates in the allowed certificate database.

There is also a new reboot-on-error setting in the systemd-boot configuration file, loader.conf. This allows users to specify whether to reboot or show the EFI menu again in case the system fails to start when using a boot entry. The default is to reboot if boot counting is enabled and the "tries left" counter is greater than zero. This default helps to avoid putting the system into an eternal reboot loop.

Service-level disk quotas

Systemd has long allowed users to control where services store cache, logs, or state information via the per-unit CacheDirectory=, LogsDirectory=, and StateDirectory= settings. These options not only provide control of where services put data, they also makes it simple to query systemd to find out where data is kept for a service, and to clean up afterward by using "systemctl clean servicename" if a service is removed from a system.

With v258, users can also set service-level disk quotas using per-service settings. For example, to set a disk quota for a service's logs, one would use LogsDirectoryAccounting= and LogsDirectoryQuota=. Currently quotas are only supported on ext4 and XFS filesystems; Btrfs is not supported. Poettering said that this is because "quota works completely differently on btrfs", making it more difficult to implement. He said that it is possible that Btrfs support will be added in the future, however.

Miscellaneous

Muhammad Nuzaihan Bin Kamal Luddin submitted a patch in August 2024, for systemd-resolved; he wanted to be able to explicitly enable or disable queries for IPv6 AAAA records, because of problems when trying to resolve A and AAAA records for the same domain name. Poettering felt that was too specific and asked for the feature to be expanded to a RefuseRecordTypes= option that would allow specifying any resource record (RR) types.

After quite a bit of back-and-forth discussion and work to implement and test the feature, systemd-resolved now has the ability to block any type of RR lookup, which allows users to set other policies such as disallowing ActiveDirectory lookups. In addition, systemd-resolved now has a feature for parallel A and AAAA lookups; if a request for a domain name resolves quickly for either the A or AAAA record, then it will shorten the timeout for the other record. The release notes indicate this is aimed at improving performance when a server responds quickly to the A request but slowly or not at all to the AAAA request.

There are many cases when systemd needs to ask the user for a password, such as at boot time when it needs the password to unlock an encrypted disk. Historically, this is done using password agents that are invoked by placing an INI-like file in /run/systemd/ask-password, which was not as simple as using a standard API. Systemd did not have a D-Bus API for this because D-Bus is not available during the early part of a boot sequence, which made it unsuitable for something like getting a disk-encryption password. With v258, systemd has added a varlink API (io.systemd.AskPassword.Ask) that can be used instead of the INI files, so a service can just use an IPC call to get a password instead.

Onward to v259

On September 17, Poettering celebrated getting v258 out the door; he hoped to move to smaller and more frequent releases in the future. Two of the features that look likely to wind up in v259 include Wayland keyboard configuration support in systemd-localed, and a systemd-boot feature that would allow it to natively update system firmware using UEFI capsules.

There are far fewer issues assigned to the milestone tracker for v259 than there were for v258; currently there are 16 tickets that have been closed and 80 that remain open for v259, whereas there were 228 issues closed by the time v258 was released. Of course, it's possible that more work will be added to the board as this release cycle continues.

Comments (6 posted)

Kernel hackers at Cauldron, 2025 edition

The GNU Tools Cauldron is almost entirely focused on user-space tools, but kernel developers need a solid toolchain too. In what appears to be a developing tradition (started in 2024), some kernel developers attended the 2025 Cauldron for the second year in a row to discuss their needs with the assembled toolchain developers. Topics covered in this year's gathering include Rust, better BPF type format (BTF) support, SFrame, and more.

Rust

The initial topic, guided by Miguel Ojeda over a remote link, was support for Rust code in the kernel. The Debian project, it seems, is the first to run into a problem that is likely to be felt more widely: the difficulties facing anyone who needs to compile out-of-tree modules written in Rust. As a general rule, loadable kernel modules should be built with the same version of the compiler that was used for the main kernel, but efforts (including the "modversions" mechanism) have long been made to loosen that requirement. So it will usually work to build a module with whichever version of the compiler happens to be handy.

The Rust compiler is different, though. When compiling code, it creates a number of files that serve in a role similar to that of C header files, and it will consume those files when building other translation units. But the Rust compiler insists on an exact version match or it will be unwilling to use those files, causing compilation to fail. That makes the building of out-of-tree modules nearly impossible if they involve Rust code.

The general consensus in the room was that this was a problem that needed to be fixed in the compiler. Since, for now, the only viable compiler for kernel code is rustc, there was not much that the assembled GCC developers could do about it. José Marchesi asked whether gccrs, the under-development GCC front-end for Rust, would have the same problem; how flexible that compiler will be on this point is unclear, and nobody had an answer to that question.

Inline support for BTF

Alan Maguire, also participating remotely, raised the topic of support for inline call sites in BTF, which describes the types of functions and data structures in the kernel. When the kernel is built, inline functions are directly substituted into the code by the compiler, so there is no separate call site in the resulting binary; that can make tracing those calls more difficult. Representing these call sites, of which there are over 400,000 in a built kernel, would make debugging and performance analysis easier.

Getting there, he said, requires adding three new types to BTF. The BTF_KIND_LOC_PARAM type indicates where a parameter to an inline function call can be found; objects of this type are gathered together under the BTF_KIND_PROTO type, which contains all of the parameters to a call. That, in turn, is pulled into an object of the BTF_KIND_LOCSEC type with the function names, prototypes, and address information. Generating this information in the build process is not a sure thing; Maguire was able to collect full information for 65% of the inline function calls, and partial information (only some of the parameters) for another 17%. After deduplication, the result is 9.5MB of collected BTF data.

Maguire is planning on making this data available via a new virtual file, such as /sys/kernel/btf/vmlinux.extra, to avoid bloating the ordinary BTF data with the inline information. There is also a way to build this information into a separate loadable module so that it need not be resident in memory when not in use.

There was seemingly more to be said about this topic but, at this point, the remote link, which was hosted on a free-of-charge but proprietary service, hit its time limit and abruptly shut down, so the conversation moved on.

Tracing and related

Alexei Starovoitov said that he would like to have a way to inject some assembly code at the call sites of inline functions, providing a hook that would be easy to attach to for tracing purposes. This would make the arguments to the function available, even if they have been optimized out by the compiler. Jakub Jelinek said that inserting the code is easy, but that the compiler's optimization passes can split up an inline function's code and spread it around, making the notion of a specific call site a bit fuzzy. Steve Rostedt said that would make exit tracing especially difficult to implement. Paul McKenney added that this kind of optimization could end up reordering calls to multiple inline functions, adding more potential for confusion.

Segher Boessenkool pointed out that it will often be difficult to reconstruct the arguments to an inline function; part of the whole point of inlining, he said, was to be able to perform global optimizations.

Marchesi asked for an update on which version of SFrame can be expected to land in the kernel. Indu Bhagat said that the deferred unwinding support needed to fully implement SFrame is in the kernel now, but the other pieces have not yet been merged. When the SFrame-specific code lands, it will support the upcoming version-3 specification. That version is also supported by binutils 2.46, which is expected in January. Rostedt said that the SFrame code is waiting for toolchain support, so it will not land in 6.18; it is likely to show up in 6.19 or 6.20. Bhagat added that LLVM will have SFrame support sometime in the (northern-hemisphere) spring.

Nick Clifton, the binutils maintainer, said that he would be willing to move the next binutils release forward to December if that would help, but Rostedt said that there was not that much urgency. Finishing the new version of the SFrame specification needs to happen first, as does the design of a new system call to get SFrame information from the kernel. It could take several kernel releases to get everything right, he said. Sam James said that distributors are waiting for version 3 of the specification as well.

Report from Paris

Thomas Schwinge reported that he had recently attended Kernel Recipes in Paris as a representative of the toolchain community, and had reported on the state of GCC there. The compiler, he said, is receiving commits at a rate of about 600/month — a rate that has remained essentially unchanged for the last two decades. He asked the group there how many were exclusively using LLVM to build their kernels, and only got a handful of responses; GCC is still relevant for kernel building, he said.

Some participants at Kernel Recipes raised concerns about the aging of the GCC development community, but Schwinge answered that there are new contributors coming into the community. There was a request to be able to build for multiple architectures from a single build of the toolchain — something that LLVM can do, but GCC cannot. Boessenkool evidently has a project toward that end, and it is seen as an achievable objective.

Schwinge concluded by noting that participants were happy for the ability to contribute to the toolchain with a developer's certificate of origin rather than a copyright assignment. They also liked the fact that new GCC releases don't tend to routinely break kernel builds, as happened more often in the past. There was a fair amount of interest in the state of gccrs as well.

The session ran out of time and concluded at this point, though much of the same group reconvened to discuss BPF support after lunch (report forthcoming). There was general agreement that this type of meeting between the kernel and toolchain communities is valuable and should be repeated.

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

Comments (8 posted)

Next steps for BPF support in the GNU toolchain

Support for BPF in the kernel has been tied to the LLVM toolchain since the advent of extended BPF. There has been a growing effort to add BPF support to the GNU toolchain as well, though. At the 2025 GNU Tools Cauldron, the developers involved got together with representatives of the kernel community to talk about the state of that work and what needs to happen next.

Integrating BTF and CTF

The BPF type format (BTF) represents the types of kernel data structures and functions; it is used to enable BPF programs to run on multiple kernels, and by the verifier to ensure program correctness, among other uses. It is derived from the Compact C Type Format (CTF), which is a more general-purpose format that makes debugging information available for compiled programs. Nick Alcock gave a high-speed presentation of his work to reunify those two formats.

The libctf library, which works with CTF, is now able to both produce and consume BTF, he began. It can also work with an under-development "CTFv4" format that adds support for some of the trickier cases. This work is being tied into the kernel build, which would allow the creation of BTF directly when building the kernel, rather than as a separate step using the pahole utility as is done now.

There are a couple of enhancements that are needed before BTF can completely replace CTF beyond the kernel, though. A string header field is needed to be able to separate the BTF from each translation unit when the results are all combined. Some sort of agreement on a format for referring to structure members in archives (holding BTF data for multiple translation units) is required for compaction purposes. To be able to use this format in user space, there has to be a representation for floating-point data — a feature the kernel has never needed. With those in place, the extra capabilities provided by CTF would only be needed to represent huge structures (rather larger than would ever make sense in the kernel) and conflicting types with the same name. Then, GCC could create BTF for both kernel and user space, with the toolchain performing deduplication as well.

Alexei Starovoitov questioned the need for these features, saying that BTF is a kernel-specific format that does not have to support user space. José Marchesi agreed to an extent, but said that wider availability and usage of the format is needed to ensure high-quality toolchain support. Sam James asked whether BTF could represent C++ programs; the answer was that CTF is still needed for those. Handling C++ with BTF would be possible, Alcock said, with the addition of some new type codes and not much more.

GCC port status

Marchesi then shifted the discussion to the status of the GCC BPF backend (or "port" in GCC jargon); the goal of that project, he said, is to turn GCC into the primary compiler for BPF code. That is a relatively new objective, he added; the previous goal had been to produce something that worked at all, with no ambitions beyond that.

Starovoitov took over to communicate his highest-priority request: the addition of support for the btf_decl_tag and btf_type_tag attributes to GCC. Their absence, he said, is the biggest blocker to adoption of GCC for compilation to BPF. Pointers in the kernel can carry annotations like __rcu or __user to indicate, respectively, that the pointed-to memory is protected by read-copy-update or is located in user space. When these annotations are reflected in BTF with the requested attributes, the BPF verifier can use them to check that memory is being accessed in a valid and safe way. There are a lot of hacky workarounds in place to cope with their absence now, but Starovoitov would love to be able to replace them with proper attribute support: "Please do it yesterday".

Notably, David Faust, who was in the session, posted a patch series adding this support the following day. Interested readers will find much more information about how these attributes work in the cover letter.

Marchesi returned to quickly go over a number of other bits of news regarding the BPF backend. There is now an extensive test suite in GCC to validate BPF compilation, which is a nice step forward. The BPF port mostly works, but there are various bugs in the compiler that still need to be addressed. It may be necessary to add support for the may_goto instruction to the assembler. And, naturally, there is the constant challenge of producing code that will not run afoul of the BPF verifier — a topic to which the group returned shortly thereafter.

The status update concluded with a request for help from the GCC community to finish getting the BPF port into shape. He and the others working on this code do not do so full time, and BPF itself is an area of active development that is hard to keep up with. A bit of assistance, he said, would enable the job to be finished sooner. Starovoitov answered that BPF developers tend to work with LLVM instead because they can get their changes accepted quickly; the GCC process is slower and harder to work with. Marchesi said that the GCC community can be strict, but it tends to be strict in the right places. Work there can take time, but the quality of the result will be excellent.

Verification challenges

Marchesi then moved on to the generation of code by GCC that can pass the BPF verifier. Without due care, the compiler will produce code that the verifier is unable to prove correct and which, as a result, will not be loadable into the kernel. He has been promoting the idea of a new optimization mode, -Overifiable, focused on producing verifiable code. He then introduced Eduard Zingerman, who delved more deeply into the problem.

The core challenge, Zingerman began, is that the various optimization passes made by the compiler can transform the code significantly, producing a result that is hard or impossible to verify. The verifier is a path-tracing machine, which tracks the state of the stack and registers as it steps through the code, forking its representation at each branch point. It is able to track the ranges of variables through a number of operations, but is unable to track the relationships between scalars and pointers. That inability makes itself felt in a number of ways.

For example, a programmer might write code like:

    offset = ...;
    if (offset < 42) {
        ptr = packet + offset;
	/* ... */

If the verifier knows that the length of the data pointed to by packet is at least 42, it can determine that this pointer assignment is safe. But an optimizer might hoist some of the calculation outside of the conditional branch, producing code like:

    offset = ...;
    ptr = packet + offset;
    if (offset < 42) {
    	/* ... */

Now the verifier is not able to verify that the assignment of ptr is correct, so the code is no longer verifiable. The LLVM BPF port, he said, works around this kind of problem by injecting calls to special intrinsic functions that inhibit this kind of optimization.

Zingerman provided a couple of other examples of how optimization can break verification and the sorts of workarounds that the LLVM developers have adopted to make things work. But, he said, the strategy in the LLVM camp has been almost entirely reactive — wait until something breaks, then figure out a way to prevent it. What, he asked, is the GCC approach? Marchesi replied that, so far, there is no strategy at all, but that needs to change.

In the resulting discussion, it was suggested that the proposed new compiler flag should be -fverifiable instead, a suggestion that seemed to find general acceptance. The actual implementation of that option is a harder task, though. Nick Clifton asked whether the developers could just maintain a list of optimization passes that are known to break verification and should just be skipped. The problem with that approach, Faust said, is that the problems usually come about as the result of specific transformations within a pass that makes a number of other optimizations that are still wanted.

Marchesi added that optimization in general is needed for BPF output; among other things, programs may exceed the limits on the number of BPF instructions without it. His plan is to put the new flag in place, then start adapting the problematic optimization passes to avoid breaking verification. Clifton noted that the verifier might improve over time and accept code that is rejected now, so the compiler needs to be told which version of the verifier is being built for. Others pointed out that there are multiple verifiers in existence, complicating the situation further.

There was a brief mention of Krister Walfridsson's smtgcc tool, which is designed to catch optimization problems in general. Walfridsson, who was present, was not convinced that smtgcc would be helpful for this specific problem, though.

As the time for this extended session ran out, Clifton said that he found the whole idea of verifier-aware compilation to be a bit "distasteful". The more that the compiler avoids verification problems, the less pressure there is on the verifier itself to fix those problems for real. Perhaps it would be better to put effort into improving the verifier instead, he suggested. Marchesi replied that the verifier exists to make it possible to load programs into the kernel and run them safely. The pressure to make that work should be shared among all parties, he said.

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

Comments (2 posted)

6.18 merge window, part 1

At the time of writing, there have been 9,099 commits in the 6.18 merge window, 8,475 non-merges and 624 merges. The changes so far include core-kernel, graphics, and networking work, among others. There are no big surprises, but several items that were discussed at this year's LFSMM+BPF Summit have now been merged.

The most significant changes merged so far include:

Architecture-specific

• The Spectre mitigations for Arm Cortex-A720 CPUs now also apply to Cortex-A720AE CPUs.
• PowerPC now supports BPF arenas and some associated atomic instructions, as does RISC-V. These instructions allow BPF programs to atomically load and store values in BPF arenas for, among other purposes, asynchronous communication with user space.
• x86 has gained a microcode= command-line option to control the behavior of the microcode loader. The new option replaces microcode.force_minrev, although it will also cover broader microcode-loader options in the future.
• The kernel can now use more than 255 CPUs as an x86 guest on FreeBSD version 15.0 or later.
• The nios2 architecture now supports the clone3() system call.

Core kernel

• Kernel namespaces (such as network namespaces) can now be referred to using file handles. The use of file handles to refer to pidfds was previously supported; this change extends that support to namespaces.
• Zswap now uses zsmalloc directly, so the zpool compression-configuration mechanism has been removed.
• Mixed completion queue event (CQE) sizes are now supported in the same ring buffer. With io_uring's growing complexity, users may want to query for the presence of different capabilities; that is also now supported.

Filesystems and block I/O

• The bcachefs filesystem has been removed in its entirety.
• pwritev2() calls can now pass RWF_NOSIGNAL to suppress SIGPIPE signals when writing to disconnected pipes or sockets.
• Procfs now takes an option to specify the associated PID namespace.
• Errors about a mounted filesystem exposing data from a different user namespace will soon be visible to users with a recent version of mount.
• A set of deprecated XFS options has been disabled by default. Several obsolete mount options have also been removed, but online fsck is now enabled by default. Online fsck is no longer considered experimental, and so should be generally usable.
• A new set of lockless bitmaps will improve the performance of the filesystems that use them.

Hardware support

• GPIO and pin control: Nuvoton NCT6694 GPIO controllers, Maxim MAX7360 GPIO and pin controllers, AAeon UP board FPGA pin controllers, NVIDIA Tegra186 pin controllers, Renesas RZ/T2H and RZ/N2H controllers, Broadcom STB pin controllers, Qualcomm Glymur pin controllers, and Qualcomm SDM660 LPASS LPI pin controllers.
• Graphics: Solomon SSD2825 MIPI bridges, Waveshare DSI2DPI bridges, Radxa Ra620 bridges, Realtek RTD2171 bridges, MT8189 Chromebook panels, BOE NV140WUM-N64 panels, SHP LQ134Z1 panels for Dell XPS 9345s, Olimex LCD-OLinuXino-5CTS panels, Samsung AMS561RA01 panels, Hydis HV101HD1 panels, Bestar BSD1218-A101KL68 LCD panels, Ampire AMP19201200B5TZQW-T03 panels, EDT ETML0700Z8DHA panels, Mali G710, G510, G310, Gx15, Gx20, and Gx25 GPUs, Rockchip NPU neural processors, Rockchip RK3576 SoCs, Mayqueen Pixpaper eInk displays, T-HEAD TH1520 GPUs, and Arm Mali CSF-based GPUs (driver written in Rust).
• Hardware monitoring: Kontron SMARC-sAM67 SoCs, GPD device sensors, Monolithic Power Systems MP29502, MP2869, MP29608, MP5998, MP29612, and MP29816 PWM controllers, various ASUS GAMING WIFI motherboard sensors, Texas Instruments INA700 and INA780 power monitors, NXP P3T1750 temperature sensors, Analog Devices sq24905c hotswap controllers, Renesas RAA228244 and RAA228246 PWM controllers, and Sensirion SHT20 and SHT25 humidity and temperature sensors.
• Industrial I/O: Tegra 256 GPIO controllers, Loongson-2K0300 GPIO controllers, Amlogic AL113L2 SPI controllers, Atmel SAMA7D65 SPI controllers, and Atmel SAM9x7 SPI controllers.
• Input: Maxim MAX7360 key switch controllers.
• Interrupt controllers: Aspeed AST2700 SCU interrupt controllers.
• Media: OmniVision OV6211 and OG0VE1B sensors.
• Memory: AMD 0x1a EDAC memory, AMD VersalNET memory controller, and EDAC on ADM Cortex A72 cores.
• Miscellaneous: Loongson Security Engine, RNG, and TPMs, TI TPS6594 power buttons, TI BQ257xx charger ICs, Lumissil Microsystems IS31FL3236A LED drivers, QNAP MCU status LEDs, Loongson-2K BMC IPMI devices, Nuvoton NCT6694 I2C adapters, Nuvoton NCT6694 socket CANfd controllers, Nuvoton NCT6694 watchdog timers, Nuvoton NCT6694 hardware monitors, Maxim MAX7360 pulse-width modulators, Maxim MAX7360 rotary encoders, Amlogic A4 SPI flash controllers, Intel Bay / Cherry Trail Dollar Cove TI batteries, Analog Devices I3C controllers, Aspeed AST2700 reset controllers, and Qualcomm trusted execution environment controllers.
• Networking: Huawei 3rd gen NICs, SpacemiT K1 Ethernet MACs, and Qualcomm packet-process engines, Skyworks Si3474 power-sourcing equipment, NXP NETC V4 timer-based PTP clocks, TI PRU ICSSM Ethernet ports, and Allwinner sun55i GMAC200 Ethernet controllers.
• Power: Maxim MAX77838 power controllers, NXP PF0900 and PF5300 power controllers, Richtek RT5133 power controllers, SpacemiT P1 power controllers, Amlogic S6/S7/S7D power-domain controllers, IMX i.MX91 power-domain controllers, PXA1908 power-domain controllers, AN7583 SoCs, ipq5424 frequency controllers, MT8196 frequency controllers, and AM62D2 frequency controllers.
• Regulator: NXP PF0900/PF0901/PF09XX regulators, NXP PF5300/PF5301/PF5302 regulators, Richtek RT5133 PMIC regulators, Maxim 77838 regulators, and SpacemiT P1 regulators.
• SoCs: ESWIN EIC7700 SOCs and Renesas RZ/T2H, RZ/N2H, RZ/T2H, and RZ/N2H SoCs.
• Sound: Qualcomm PM4125 codecs, TI PCM1754 digital-to-analog converters, TI TAS2783A audio amplifiers, Realtek RT1321, Shanghai FourSemi FS2104/5S auioo amplifiers, Tascam US-144mkII USB sound devices, and Presonus S1824 USB sound devices.
• Thermal: Renesas RZ/G3S and Renesas RZ/G3E SoCs.

Networking

• The work on AccECN, for accurate TCP congestion notification, has been merged.
• UDP receive performance has also been improved, by 47%, according to Eric Dumazet's measurements.
• The direct internal buffer sharing (dibs) work that was discussed at Netdev 0x19 has been merged.
• The default socket receive buffer size has been raised to 4MB.

Security-related

• The audit subsystem can now handle multiple Linux security modules (LSMs) being enabled at the same time. This is part of other work throughout the LSM subsystem to make multiple simultaneously enabled LSMs work smoothly.
• The kernel now supports signing BPF programs — although security policies that can take advantage of this are still in progress.
• Encrypting TCP connections with PSP is now possible as well, with the documentation covering the details.

Virtualization

• The new virtio SPI driver lets SPI device access be provided to virtual machines.

Internal kernel changes

• Filesystem encryption and verification information has been moved out of struct inode, leaving the filesystems that don't implement those features with a lower memory footprint.
• The WQ_UNBOUND workqueue flag is being retired in favor of a WQ_PERCPU flag with the opposite meaning, since many callers were using a per-CPU workqueue when a global workqueue would have sufficed.
• A new "transitional" attribute for kernel configuration options should make changing the names of options less fraught. Options marked as transitional will not be selectable in user interfaces such as make menuconfig, and won't be included in generated configuration files, but will still be understood and processed. That lets a kernel developer set up a new option name with a default setting based on the old option, and anyone running make olddefconfig will be seamlessly migrated.
• The Rust bindings now include now support for Linux-kernel-memory-model-compliant atomic operations, using maple trees, creating DebugFS files, and manipulating bitmaps. A number of other APIs relevant to writing drivers have also been added.
• The kernel now requires LLVM 15.0.0 or newer to build; users of Debian Bookworm and Ubuntu Jammy may need to upgrade their toolchains to continue building the kernel with Clang.
• The work on sheaves, which improves the performance of the slab allocator, has arrived.
• The TEE subsystem can now handle allocating and managing hardware-protected memory.
• The new kmalloc_nolock() allows for allocation with no additional locks taken, a capability that prompted significant discussion on the mailing list.

6.18 is shaping up to be a promising release. While there are no earth-shaking changes, there are a lot of disparate improvements. When the merge window closes, LWN will have a second article on all the changes that were merged after this article was written.

Comments (15 posted)

Progress on defeating lifetime-end pointer zapping

Paul McKenney gave a remote presentation at Kangrejos 2025 following up on the talk he gave last year about the lifetime-end-pointer-zapping problem: certain common patterns for multithreaded code are technically undefined behavior, and changes to the C and C++ specifications will be needed to correct that. Those changes could also impact code that uses unsafe Rust, such as the kernel's Rust bindings. Progress on the problem has been slow, but McKenney believes that a solution is near at hand.

He began by noting that the obvious way to write an atomic last-in-first-out (LIFO) stack as a linked list in C or C++ invites undefined behavior. Specifically, it can end up creating a pointer that has a valid bit pattern, but an invalid provenance. Imagine that a thread wants to push an item (A) onto a stack; it reads the pointer to the current top of the stack (B), stores that into A's next field, and then uses an atomic compare-and-swap instruction to store the pointer to A as the new top item only if the top-of-stack pointer still points to B.

So far, so good. Now suppose that a second thread concurrently pops an item off of the stack, frees it, allocates a new item (C), and then pushes it to the stack. If the new allocation has a different address, then the first thread's compare-and-swap operation will fail, and it will know to retry. But what if the memory allocator, seeing that a piece of memory of the right size has just been freed, gives the same memory back to use for the new item? In that case, the first thread's compare-and-swap operation will succeed, because the pointer to B and the pointer to C are bitwise identical. As far as the actual CPU is concerned, nothing has gone wrong. But according to the C abstract machine, even though the pointer to C and the pointer to B have the same bits, they have different provenance information. This makes the dangling pointer to B (which has been freed) a "zombie pointer", any use of which is undefined behavior. Currently, compilers aren't taking advantage of this particular piece of undefined behavior, but McKenney wants to get out ahead of the problem by agreeing on a solution ahead of time.

Importantly, it's not really possible to change all of the code that works this way, because there are so many open-coded atomic LIFO stacks or equivalent pieces of code spread throughout almost every nontrivial multithreaded project, McKenney said. The first implementation of this kind of stack is unknown, but it probably dates to the 1960s. There was at least one implementation in the 1970s that referred to the technique as being generally known.

Last year, Davis Herring's "angelic provenance" proposal looked as though it would help, but the C++ committee found examples of some code where angelic provenance would "invalidate some really important optimizations". Herring's proposal would add a new rule requiring that when an integer is cast to a pointer (or, if McKenney's separate proposal is adopted, when a pointer is loaded from an atomic type), if there is any choice of pointer provenance that the compiler could make that will prevent the program from having undefined behavior, the compiler has to pick that option.

The modified rule would only require the compiler to consider the provenances of objects that already exist at the time of the operation (but see the sidebar for more information). This is both simpler for compiler authors to implement, and avoids problems with obtaining a pointer to an object before it is actually allocated. McKenney's additional proposal would make angelic provenance work for LIFO stacks by treating any loads through an atomic type as though the loaded pointers were just converted from an integer, so the angelic provenance rule would apply and the obvious way to implement an atomic LIFO stack would be defined behavior ... almost.

In C and C++, any operation with an invalid pointer isn't guaranteed to produce a sensible result. So, while reading a pointer value from an atomic variable for the LIFO stack no longer causes a problem (with the above proposals), writing the pointer value in the first place could be optimized out. So the final piece needed for the existing LIFO stacks to work would be a requirement that when writing an invalid pointer, the actual bits of the pointer are written to the destination, even if the provenance information is no longer usable.

All together, there is "not all that much" work to get all these changes through the committee. "There's less heartburn on current proposals than there has been in the past."

Ryhl raised a question that had come up when considering implementing analogous proposals in Rust — wouldn't the new rules prevent angelic choices from being reordered relative to "demonic" choices? Specifically, there are certain operations, such as memory allocation, where the compiler is allowed to assume that the operation goes as badly as possible for the program being optimized. Therefore, if the program is incorrect in those cases, it's incorrect overall. While Rust doesn't have the same undefined behavior rules as C, programmers writing unsafe Rust still need to uphold various invariants, and so might run into this. She shared this example Rust code from Ralf Jung demonstrating the problem:

    fn nondet() -> bool {
      let b = Box::new(0);
      ptr::from_ref(&*b).to_addr() % 3 == 0
    }

    let a1 = 0; let a2 = 1;
    let a1addr = ptr::from_ref(&a1).to_exposed_addr();
    let a2addr = ptr::from_ref(&a2).to_exposed_addr();
    let b: bool = nondet(); // demonic non-det choice
    let x = ptr::from_exposed_addr(a1addr); // picks provenance of a1 or a2
    let y = if b { x } else { x.with_addr(a2addr) };
    let _val = *y;

In this example, nondet() is a demonic choice (because the compiler knows that a newly allocated heap item could be located anywhere, so for the purposes of determining whether the function might be malformed, it can assume that the location is whatever would cause undefined behavior) and ptr::from_exposed_addr() would be an angelic choice under the proposed rules around integer-to-pointer conversions. The difference between the "exposed" functions and their unexposed variants is an artifact of Rust's experimental exposed-provenance model — when casting an integer to a pointer, only "exposed" provenances can be considered to become the provenance of the pointer. Taken together, this means that the compiler would be required to pick whichever provenance for x (out of a1addr and a2addr) makes the program valid, given its assumptions about b. Ryhl's point was that currently, reordering the assignment to x above the call to nondet() is permitted, since x doesn't depend directly on the value. But that optimization would be invalid under the proposed rules, because then the demonic choice could always pick whatever value makes the answer picked by the angelic choice invalid, and the program would break.

The conservative solution would be to require the compiler to avoid reordering angelic and demonic choices relative to each other, but that could prevent local optimizations such as moving assignment to a variable out of a loop. It's unknown what the practical performance impacts or knock-on effects of a requirement like that would be.

McKenney initially thought the example was broken as-is, until Gary Guo clarified that in Rust, one can have a pointer with an address that points outside the memory of its associated provenance, as long as it is not dereferenced. This is helpful because it allows for valid pointer arithmetic between more objects. That's not how it works in C or C++, so McKenney hadn't considered the problem. But once it was explained, he was thoroughly enthusiastic about the choice to allow pointers to be used in this way.

He complimented the Rust folks for allowing arbitrary pointer arithmetic, which is work that he has put off trying to get through the C++ committee. "I haven't thought about that, because I wanted to only fight one dinosaur in C++ at a time." He acknowledged that the example raised further problems, though, and commented that it would be exciting future work. Hopefully, by Kangrejos next year, he will have a satisfying answer. If the current proposals do get through the C and C++ committees, those languages will likely run into an analogous problem if they ever attempt to loosen the rules around pointer arithmetic.

Comments (18 posted)

A look at the Robot Operating System

Despite its name, the Robot Operating System (ROS) is not an operating system; it is a software development kit (SDK) that provides building blocks for robotic applications. One of the main goals of ROS is to present a common API that abstracts away the details of particular hardware drivers or algorithms to make development easier; developers can focus on what a robot should do rather than the low-level details of specific controllers. The latest release of ROS, Kilted Kaiju, features improvements to the middleware layer that is used to deliver data between components.

Overview

Robots are complex electromechanical systems composed of sensors, actuators, one or more computers, and the software that ties it all together. A simple way to think about a robot is that it uses sensors to gather data about the world around it, interprets that sensor data, and then performs some activity toward a goal using its actuators. Robots use algorithms to carry out tasks that humans want them to do. For example, a robot might process camera data to extract semantic meaning, or use laser scanners to determine the robot's position in a room; it might also use an algorithm to calculate how its arm should move to pick up an object.

There are many ways to do these things, and this is where ROS comes in. It provides the tools and plumbing that helps developers create applications to run on all manner of robots. It provides abstractions so that an application does not need, for example, to deal with how a robot knows its position in space. Instead, an application can simply use the map data and position provided to it.

Before the 2010s, the challenges of developing the robot hardware and software often fell to the same people. In those days, just getting a robot to move was a challenge and it was celebrated when it happened. Unfortunately, that meant that the state of the art of robotics was slow to develop since each university, lab, or company was starting from scratch every time. It was difficult to improve the software that robots need to understand the world before funding ran out or students graduated.

That scenario started to change in the late 2000s to early 2010s with the introduction of cheaper sensors, cheaper computation, and industry-standard hardware like the Arduino. One of the drivers toward standardization and software reuse for robotics was the introduction of ROS in 2010.

A brief history of ROS

The initial version of ROS (now called ROS 1) was released as a set of BSD-licensed libraries in 2010. Before that, it had been developed internally at Willow Garage, a robotics research lab and technology incubator, initially to support the PR2 robot. Early on, it was recognized that the software needed to run this complex robot could also be used in other robots, so the software was purposefully kept as generic as possible.

In 2012, Willow Garage was winding down, and the non-profit Open Source Robotics Foundation (OSRF) was created to shepherd the open-source project. The OSRF owns the copyright to the ROS code, the trademarks, and other IP related to ROS and its sister projects.

The OSRF started to think about the future of ROS and learn from the mistakes made while creating the first version. That led to the initial implementation of ROS 2, the current major release version of ROS. It keeps many of the concepts from ROS 1 while improving the overall implementation and making it production-ready. As of 2025, more than 80% of user downloads from the ROS community are for ROS 2, and support for the final release of ROS 1 ended in May 2025.

Robots are widely used for everything from vacuum cleaners to satellites, in industrial manipulators and humanoid hardware, and many things in between. ROS 2 has been used in all of these contexts, and for different kinds of projects, from hobbyist all the way up to the largest players in the industry. There is a showcase of robots on the ROS web site that illustrates the wide variety of applications that ROS is used in.

Governance

The ROS community is a bit more structured than many open-source projects. Since 2024, the OSRF has managed the ROS community under the Open Source Robotics Alliance (OSRA), which is an initiative created to improve the governance of OSRF's open-source projects, provide funding, and ensure long-term stability for them. According to its explainer, the OSRA is modeled after organizations such as the Linux Foundation and Eclipse Foundation.

OSRA provides a home for several initiatives in addition to ROS 2. This includes the Gazebo robotic simulator, a robotics fleet manager called Open-RMF, and ros2_control, which is a framework for realtime control of robots. OSRA also manages the infrastructure for the build and continuous-integration systems for all of these efforts. Each of the projects has its own project management committee (PMC), which is responsible for the management of the project, including development, support, releases, and responding to security incidents according to the security policy.

The OSRA also collects dues from members and can distribute that money to the individual projects. For instance, if the ROS PMC needs to hire a technical writer for a specific feature, it can submit a request to the OSRA for funds.

Distributions and Releases

The core of ROS 2 includes about 400 packages; these are listed in the ros2.repos file in each release's branch. The code for the core is hosted on GitHub and is mostly Apache-2.0 licensed, with some of the older code using the three-clause BSD license.

The official mascot of ROS is the turtle; as such, ROS 2 releases are made annually on World Turtle Day on May 23. Releases in odd-numbered years have 18 months of support, while releases in even-numbered years have five years of support. The project uses a naming scheme similar to Ubuntu's; each release has a code name that is an adjective followed by a noun. For instance, the 2024 release of ROS 2 is named Jazzy Jalisco and will be supported through 2029, while the 2025 release is named Kilted Kaiju and will be supported until December 2026. This support period aligns with the Ubuntu LTS release schedule; Ubuntu is the recommended platform to use to develop applications with ROS 2, though others are also supported. Releases are almost always referred to by their adjective name, such as Kilted.

A ROS 2 release consists of the release-critical core packages plus thousands of extra packages provided by the larger community; together this is called a ROS distribution. The core contains the SDK for both C++ and Python, basic communication mechanisms, common structures for collecting and exchanging data (called messages), command-line debugging tools, tools for recording and playing back data, visualization tools, tracing tools, and examples.

Packages from the community include SDKs for other languages (like C, Rust, and Java), messages that aren't common enough for the core, hardware drivers, additional debugging tools, experimental tools/drivers/capabilities, and anything else that the community thinks would be helpful to other robotics developers. Each ROS distribution has a YAML file which lists all packages available; for instance, the Kilted YAML file is available on GitHub. Developers are encouraged to add their own packages to that list, which members of the ROS PMC will review for relevance to ROS and merge.

A platform in ROS terms is a combination of an operating system and hardware architecture; for example, Ubuntu Noble on x86-64 is a supported platform, as is Ubuntu Noble on arm64, or Windows 10 on x86-64. Each ROS 2 release defines its supported platforms in a document called REP-2000, which is updated periodically for new releases. A release may be delivered on a platform via Debian packages, RPMs, binary tarballs, or from source. It is often possible to build from source if a platform is not officially supported. The ROS developer documentation site has installation guides and tutorials for each release.

Communication mechanisms

In ROS 2, the unit of computation is referred to as a node, and each node is responsible for "a single, modular purpose". This purpose might be getting data from a sensor, driving an actuator, determining the robot's position, displaying data, or anything else needed to make the robot operate. As mentioned earlier, robots are frequently made up of one or more computers responsible for different parts of the functionality, and nodes may be deployed on any of them.

To facilitate communication between nodes, ROS 2 offers three different network-communication primitives: a publish/subscribe (pub/sub) bus called "topics", a remote procedure call (RPC) mechanism referred to as "services", and a cancelable RPC mechanism called "actions" for longer-running tasks. The connections between nodes, topics, services, and actions are collectively referred to as the "network graph".

By far the most commonly used primitives in ROS are topics, each of which have zero or more publishers that generate data and zero or more subscriptions that receive and process data. Both publishers and subscriptions may be added dynamically to the network "graph", which allows users to easily attach debugging points and additional functionality as a robot grows more complex. Publishers and subscriptions to a particular topic find each other on the graph by using a common name like /right_camera, and a typical robot has hundreds, if not thousands, of individual topics.

The data transferred over the topic is a strongly typed "message", which is specified using an INI-like syntax that is described in the documentation. The core provides a number of common robotic message types, such as an Image, a LaserScan for scans from a laser range finder, and more.

The service mechanism in ROS 2 is more lightly used but it fills an important niche. Services use a call-and-response model; a server provides data to a client when it asks for information. The clients make RPC calls to the server, which calculates and returns a result.

For instance, a typical feature of a robot is a "software emergency stop", where a user or another piece of the robot can send a signal to cut off power to the actuators. This is typically implemented with a service server that has access to the physical emergency-stop hardware; one or more clients can send the signal to emergency stop when the user requests it or when a dangerous situation is detected.

Services find each other in the network graph by using a name like /emergency_stop. It is technically possible, but inadvisable, to have more than one service server with the same name; ROS does not provide a way to define which server will respond and how many responses will be received if more than one server is available.

Like topics, data for each service is transferred using a strongly typed "service message". The ROS 2 core has a few defined services, such as Trigger (where the client sends no data and only receives a boolean response), SetBool (where the client sends a boolean and receives a boolean response), etc. Services have some significant downsides; once a service call has been made, there is no way to cancel it, and there is no way to find out what progress the remote resource has made in performing the task. Because of this, services are typically only used for short-running activities.

For longer-running tasks, actions should be used instead. Actions are similar to services in that they request a remote resource to perform some operation. Unlike services, actions have a cancellation mechanism and a feedback mechanism so they are appropriate for long-running operations, such as asking a robot to move to a location. Actions are built on top of topics and services, thus utilize the same underlying network mechanisms. As with topics and services, data for actions is transferred using a strongly-typed "action message". The ROS project offers tutorials on how actions work, as well as how to create a custom action

Messages for topics, services, and actions can be thought of as the ROS API; by conforming to them, users can add, remove, or replace parts of the ROS stack one at a time, using any language that has a ROS 2 SDK. For instance, a robot may start out using a low-cost laser scanner when its design is being prototyped. As the robot becomes more complex, that laser scanner may not have enough resolution and be replaced with one that has higher fidelity. When this happens, only the driver for the laser scanner needs to be replaced; the rest of the network will still get laser-scanner data, just at a higher resolution. Because of this property, developers are highly encouraged to use existing messages if at all possible. If none of the messages fit the current use case, developers can create their own messages using the same INI-like syntax.

For instance, a custom message to control an RGB LED could look like:

    std_msgs/Header header
    uint8 red
    uint8 green
    uint8 blue

The header field embeds a message type from another package into this one, and the red, green, and blue fields allow control of the LED. More documentation about the syntax, including the available primitive types, is available on the documentation site.

All of the above communication mechanisms can be run locally on the same system or across the network to another system. This allows for straightforward remote debugging and development, as developers can attach to a robot from their laptop, watch what is happening, and make changes.

A new (middleware) hope

Because of its design, ROS 2 heavily depends on efficiently delivering data over the network. One of its big innovations was the addition of an abstraction layer for communication, called the ROS Middleware (RMW), which is pluggable both at compile time and at runtime. The documentation has a diagram of the layering of ROS 2, including the RMW.

When development began in 2014, the team thoroughly evaluated the available pub/sub technology. The result of that research was to choose the Data Distribution Service (DDS) standard by the Object Management Group as the default protocol. As of Kilted, it ships with three fully supported DDS RMW implementations: Fast-DDS (Apache-2.0 licensed), Cyclone DDS (Eclipse 2.0 licensed), and RTI Connext (proprietary licensed). While these DDS implementations have worked, ten years of experience in the field have revealed some shortcomings with the protocol.

Armed with the knowledge of these shortcomings, in 2023 the team reviewed the current landscape of pub/sub protocols to find one that would solve the problems with DDS. The findings of that research were published as a white paper on the ROS Discourse forum, and the team chose Zenoh as additional middleware. Zenoh was created by former DDS developers who were frustrated by the problems in DDS, including the ones affecting ROS 2. The protocol promises to address those problems.

DDS nodes announce themselves and discover other participants, such as nodes, topics, services and actions, on the network when they are started. By design, DDS networks are fully connected, meaning that all participants know about the existence of all other participants. This leads to the first problem, which is that the overhead of discovery in large or complex robots can overwhelm the network, causing problems for the robot and other devices that share the network. The first major improvement of Zenoh over DDS is that Zenoh keeps its network discovery overhead low by having each participant only look for the resources it needs.

Second, DDS has two mechanisms to discover other participants in the network: static peers and UDP multicast. When using static peers, each participant is given a list of hosts to connect to at startup, which is efficient but isn't dynamic. UDP multicast can be used for dynamic discovery, but many networks limit or entirely disable UDP multicast for performance or security reasons. When UDP multicast fails to work, it can be hard to debug the reason that participants in the network can't find each other.

As described in the Zenoh documentation, Zenoh can also use static peers or UDP multicast for discovery, but it adds a third mechanism called "routers". In ROS, Zenoh routers are a separate process configured to only facilitate discovery, and ROS nodes, topics, services, and actions are configured to contact the router on localhost during startup. After receiving a list of peers from the router, these ROS entities establish peer-to-peer connections to deliver data. Zenoh routers can also be configured to connect to other Zenoh routers for discovery and data delivery.

The third problem is that, in some scenarios, DDS can struggle to deliver large pieces of data. DDS uses UDP to send messages so that it can implement features like quality-of-service attributes, but this also means it suffers from performance problems. In particular, the UDP stack on Linux has a small default maximum socket receive size, a relatively small default IP fragmentation maximum size, and it keeps IP fragments around for a large amount of time (up to 30 seconds). With these defaults, large data like images may not fit in the receive buffers, and receivers of fragmented data may not have room to be reassembled. If the network is reliable and the consumer of the data keeps up with processing the socket, this can work for large messages. If either one of those isn't true, then the buffers can fill up, and depending on the quality of service, DDS can spend a lot of time attempting to redeliver fragments of large messages.

In contrast, Zenoh uses TCP for data delivery by default. While TCP isn't a panacea and has its own delivery problems (such as head-of-line blocking and bufferbloat), years of experience have shown that TCP tends to work better on wireless networks and across the internet.

Based on the promised improvements, the ROS 2 team, in collaboration with Zenoh's developers, created a new RMW implementation based on Zenoh called rmw_zenoh. By default, rmw_zenoh sets up one Zenoh router per host and uses it in discovery-only mode.

For the Jazzy release, rmw_zenoh was delivered as a technology preview; for the Kilted release, rmw_zenoh is shipped with the core and supports all security options, supports Windows, and passes all core tests. The team has high hopes that rmw_zenoh will improve the situation for roboticists who depend on ROS. Unfortunately, this will only be known for sure once it is deployed on many different robots running on many types of network infrastructure. Because of this, the default RMW for Kilted is still based on DDS, but rmw_zenoh is fully supported and documented as an option.

The future

It is a large project and it is pulled in many different directions based on what the community is using it for. As with many open-source projects, it can be difficult to tell exactly what will be in the next release; that is often dictated by what the community contributes during the development cycle. However, there are well-known issues and features that would be nice to address in the next release (Lyrical Luth).

The Python SDK is known as rclpy and is used both by developers looking to quickly prototype, and by the core command-line tools. Currently rclpy has some performance issues with sending/receiving large messages and in reacting to new data being available. Improving its performance will expand the number of situations that rclpy can be used in, as well as make the core command-line tools faster.

The logging subsystem takes printf()-style log messages and outputs them to various sinks. This is pretty standard functionality, but it has a bit of a twist in ROS 2 because that data is often written out to some combination of the console, the disk, and a ROS topic. As of today, this subsystem is too slow, and logging can't be used in performance-critical code sections. It is also not as configurable as the community needs. For example, it is not possible to have debug messages go to the disk while only warning messages get printed to the screen. Making this subsystem more performant and configurable would open up new uses for it.

Another feature that has been long sought after is additional flexibility and performance for the message-generation pipeline. As discussed earlier, messages in ROS 2 are defined with an INI-like syntax. The message generation pipeline is used to parse that INI-like syntax, then generate language-specific bindings to allow users to interact with those messages as structures. That pipeline can be slow, particularly when generating messages for many languages and with large message definitions. It is also limited, in that all language generators need to be available at the time the messages are generated; it is not possible to add an SDK for a new language without building the entire ROS 2 core from source. Lifting that limitation would be a major boon to developers looking to add SDKs for other languages.

Better documentation for the project is always needed. The basic tutorials for ROS 2 are fairly extensive, but there aren't many good tutorials for advanced use cases. There also aren't many tutorials for migration from ROS 1 to ROS 2. And it would be great to have tutorials describing particular use cases, such as using it with a manipulator arm, on a drone, or other common uses.

For anyone looking to get involved or learn more, the main ROS communication channels are a Discourse instance for general discussion, a Discord server for realtime communication, and there is a section on Robotics StackExchange for Q&A.

Comments (14 posted)

OpenSSH 10.1 released

OpenSSH 10.1 has been released. Along with "a minor security fix" and some other bug fixes, this release disallows control characters in user names passed via the command line, adds better logging around certificate refusals, and a new RefuseConnection server configuration option.

Comments (22 posted)

Security quote of the week

There are many different specifications being created for the CRA, and many open source groups and developers are helping out with them too. Most of that work is happening right now, and is being crammed into a short window, so that after the drafts of the specs are finished in a few months, they can get widespread public review and comments and adjustments before they are written into final versions. The drafts I have seen so far, while pretty verbose in many places, are semi-sane and I don't think that anyone will have any issues with using open source software to address their requirements.

In short, I think the CRA is going to be a good thing for us overall. Don't fear it, for open source individual developers, it will not affect them contributing at all. For projects that are under an organization like a "foundation", the only thing that it dictates is two requirements that all open source projects should probably be doing already anyway:

• have a way to report security bugs to the project
  
• the project, if it fixes a security bug, should report it to "someone". That "someone" is still being worked out, but should be a simple web form, or json endpoint you can push to. We'll know more in a few months about the specifics there.

That's it, should not really be an issue for any project to follow.

— Greg Kroah-Hartman

Comments (none posted)

Kernel release status

The 6.18 merge window remains open; it can be expected to close on October 12.

Stable updates: 6.16.10, 6.12.50, 6.6.109, 6.1.155, 5.15.194, 5.10.245, and 5.4.300 were released on October 2, followed by 6.17.1, 6.16.11, 6.12.51, and 6.6.110 on October 6.

Comments (none posted)

Quote of the week

Remember: your mom picked up your dirty laundry from your floor, and software people are like the super-moms of the world.

— Linus Torvalds offers advice to hardware designers

Comments (none posted)

Distributions quotes of the week

If you ever wondered why do we need Linux distributions, I would encourage you to take a look at the Release Blocker Review activity run by Adam Williamson and Fedora QA team.

It is not a one-time event, but rather a process run consistently over a long period of time. And it is what makes it possible to ship regular releases of Fedora while not breaking your world every now and then.

— Aleksandra Fedorova

HEEEEEYYYY, let's not go making any overly rash promises, here. :D

— Adam Williamson

Comments (none posted)

Better profile management coming to Firefox

Firefox has long had support for multiple profiles to store personal information such as bookmarks, passwords, and user preferences. However, Firefox did not make profiles particularly discoverable or easy to manage. That is about to change; Mozilla has announced that it is launching a profile-management feature that will make it easier to create and switch between profiles. According to the support page for the feature, it will be rolled out to users gradually beginning on October 14.

Comments (9 posted)

Notes from the 2025 Git Contributor's Summit

Taylor Blau has posted an extensive set of notes from the recently concluded Git Contributor's Summit. Covered topics include the SHA-256 transition, Rust, Change-ID headers, Git 3.0, and many more. The note are also available on Google Docs for those who prefer that format.

Comments (2 posted)

Python 3.14.0 released

Version 3.14.0 of the Python language has been released. There are a lot of changes this time around, including official support for free threading, template string literals, and much more; see the announcement for details.

Comments (11 posted)

U-Boot v2025.10 released

Version 2025.10 of the U-Boot boot loader has been released with new features, including Python tooling improvements, cleanups for implicit header inclusions, better support for numerous Arm platforms, support for new RISC-V platforms, better documentation, and more. Maintainer Tom Rini also reports on some project news:

As I mentioned with the v2025.07 release, I was looking for a few people to step up and help with the overall organization and management of the project. To that end, Peter Robinson and Neil Armstrong have stepped up and have been helping me. This has been part of the process for the project to join up under the Software Freedom Conservancy's (SFC) umbrella and have a legal entity that can help the project work with other legal entities on things like donations.

Full Story (comments: none)

Development quote of the week

It's disturbing how agreeable we are to the AI hype narrative and actively participate in the planned erasure of our craft, and so willingly offer up our means of thinking. We were the lucky ones who got to earn a living from our hobbies. Even if we produce punctilious and rigid processes to counter slop—as some support with a striking similarity to the waterfall model of yore—we've still outsourced the fun part of the job and replaced it with directorial drudgery. What's next, TPS reports?

LLMs seem like a nuke-it-from-orbit solution to the complexities of software. Rather than addressing the actual problems, we reached for something far more complex and nebulous to cure the symptoms. I don't really mind replacing sed with Claude or asking it for answers about a library or framework that, after hours of hunting through docs, I still seek clarity on. But I profoundly do not want to be merely an operator or code reviewer: taking a backseat to the fun and interesting work. I want to drive, immerse myself in craft, play in the orchestra, and solve complex puzzles. I want to remain a programmer, a craftsperson.

I prefer my tools to help me with repetitive tasks (and there are many of those in programming), understanding codebases, and authoring correct programs. I take offense at products that are designed to think for me. To remove the agency of my own understanding of the software I produce, and to cut connections with my coworkers. Even if LLMs lived up to the hype, we would still stand to lose all of that and our craft. Humans matter more than machines and their backing corporations, who are profiting while the rest of us chase the new American Dream they sell. As payment, we offer our critical thinking skills, our fun, our craft, our privacy, and perhaps, our planet.

— Simon Højberg

Comments (none posted)

Ian Kelling is the new FSF president

The Free Software Foundation has announced the selection of Ian Kelling as the organization's president.

Kelling, age forty-three, has held the role of a board member and a voting member since March 2021. The board said of Kelling's confirmation: "His hands-on technical experience resulting from his position as the organization's senior systems administrator proved invaluable for his work on the board of directors. The board is confident Kelling is the right person to help the organization achieve its long-term goals. His commitment to free software comes from a life of exploring ways to exert user control. He has the technical knowledge to speak with authority on most free software issues, and he has a strong connection with the community as an active speaker and blogger."

Comments (6 posted)

CFP Deadlines: October 9, 2025 to December 8, 2025

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

Deadline	Event Dates	Event	Location
October 9	October 1 October 2	OpenALT 2025	Brno, Czechia
October 12	March 23 March 26	KubeCon + CloudNativeCon Europe	Amsterdam, Netherlands
October 15	February 2 February 4	Config Management Camp	Ghent, Belgium
October 27	March 16 March 17	FOSS Backstage	Berlin, Germany
November 16	January 31 February 1	Free and Open source Software Developers' European Meeting	Brussels, Belgium
November 16	February 17	AlpOSS 2026	Échirolles, France
November 30	March 19	Open Tech Day 26: OpenTofu Edition	Nuremberg, Germany

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

Events: October 9, 2025 to December 8, 2025

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

Date(s)	Event	Location
October 12 October 14	All Things Open	Raleigh, NC, US
October 17 October 19	OpenInfra Summit Europe 2025	Paris-Saclay, France
October 18 October 19	OpenFest 2025	Sofia, Bulgaria
October 21 October 24	PostgreSQL Conference Europe	Riga, Latvia
October 23 October 24	GStreamer Conference 2025	London, UK
October 28 October 29	Cephalocon	Vancouver, Canada
November 4 November 5	Open Source Summit Korea	Seoul, South Korea
November 7 November 8	South Tyrol Free Software Conference	Bolzano, Italy
November 7 November 8	Seattle GNU/Linux Conference	Seattle, US
November 8	FOSS for All Conference 2025	Seoul, South Korea
November 13 November 14	ecoCompute 2025	Berlin, Germany
November 15 November 16	Capitole du Libre 2025	Toulouse, France
November 18 November 20	Open Source Monitoring Conference	Nuremberg, Germany
November 19 November 20	Open vSwitch OVN Conf'25	Prague, Czech Republic
November 20	NLUUG Autumn Conference 2025	Utrecht, The Netherlands
December 1 December 3	Critical Decentralisation Cluster at 39C3	Hamburg, Germany
December 2 December 4	Yocto Project Virtual Summit 2025.12	Online
December 6	OLF Conference	Columbus, OH, US
December 6 December 7	EmacsConf	online

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

Alert summary October 2, 2025 to October 8, 2025

Dist.	ID	Release	Package	Date
AlmaLinux	ALSA-2025:17129	8	idm:DL1	2025-10-03
AlmaLinux	ALSA-2025:16904	10	kernel	2025-10-03
AlmaLinux	ALSA-2025:17119	10	perl-JSON-XS	2025-10-01
Debian	DSA-6016-1	stable	chromium	2025-10-02
Debian	DSA-6019-1	stable	dovecot	2025-10-05
Debian	DSA-6018-1	stable	gegl	2025-10-03
Debian	DLA-4323-1	LTS	git	2025-10-06
Debian	DSA-6017-1	stable	haproxy	2025-10-03
Debian	DLA-4322-1	LTS	log4cxx	2025-10-05
Debian	DLA-4321-1	LTS	openssl	2025-10-03
Debian	DSA-6015-1	stable	openssl	2025-10-01
Fedora	FEDORA-2025-49400d941c	F41	apptainer	2025-10-08
Fedora	FEDORA-2025-402b80a0de	F42	apptainer	2025-10-08
Fedora	FEDORA-2025-1d2fb742dd	F43	apptainer	2025-10-07
Fedora	FEDORA-2025-702902f388	F41	bird	2025-10-01
Fedora	FEDORA-2025-f6b553e67d	F42	bird	2025-10-01
Fedora	FEDORA-2025-acc92fcc12	F42	chromium	2025-10-07
Fedora	FEDORA-2025-37da05914f	F43	chromium	2025-10-07
Fedora	FEDORA-2025-247b5416b4	F41	civetweb	2025-10-08
Fedora	FEDORA-2025-1056ea31ed	F42	civetweb	2025-10-08
Fedora	FEDORA-2025-cedb68d233	F43	civetweb	2025-10-07
Fedora	FEDORA-2025-b3288aa9bf	F41	containernetworking-plugins	2025-10-05
Fedora	FEDORA-2025-e36ffc5112	F42	containernetworking-plugins	2025-10-05
Fedora	FEDORA-2025-f4d64845aa	F43	containernetworking-plugins	2025-10-05
Fedora	FEDORA-2025-0f0623b719	F41	dnsdist	2025-10-01
Fedora	FEDORA-2025-b6c24f05eb	F42	dnsdist	2025-10-01
Fedora	FEDORA-2025-48dc56cf48	F41	ffmpeg	2025-10-03
Fedora	FEDORA-2025-2d3009f39f	F41	firebird	2025-10-04
Fedora	FEDORA-2025-10462d0b3e	F43	firebird	2025-10-04
Fedora	FEDORA-2025-b18c05fecd	F41	firefox	2025-10-03
Fedora	FEDORA-2025-ddecb35946	F42	firefox	2025-10-01
Fedora	FEDORA-2025-cdabd887aa	F43	firefox	2025-10-05
Fedora	FEDORA-2025-1a3968c333	F41	freeipa	2025-10-03
Fedora	FEDORA-2025-e41ba62ff1	F42	freeipa	2025-10-03
Fedora	FEDORA-2025-54a485ee85	F43	freeipa	2025-10-03
Fedora	FEDORA-2025-136667dc88	F41	jupyterlab	2025-10-06
Fedora	FEDORA-2025-547bc6efdc	F42	jupyterlab	2025-10-06
Fedora	FEDORA-2025-5ce0931fe3	F43	jupyterlab	2025-10-06
Fedora	FEDORA-2025-2b5c69ffe6	F41	mapserver	2025-10-01
Fedora	FEDORA-2025-38689b7760	F42	mapserver	2025-10-01
Fedora	FEDORA-2025-40b7d151db	F42	mod_http2	2025-10-08
Fedora	FEDORA-2025-4651fb3c55	F41	mupdf	2025-10-04
Fedora	FEDORA-2025-562364d434	F42	mupdf	2025-10-04
Fedora	FEDORA-2025-ee9b86c6d9	F41	ntpd-rs	2025-10-01
Fedora	FEDORA-2025-7fbf258406	F42	ntpd-rs	2025-10-01
Fedora	FEDORA-2025-c355a1291c	F42	openssl	2025-10-08
Fedora	FEDORA-2025-ef1d49c67b	F41	pandoc	2025-10-08
Fedora	FEDORA-2025-ef1d49c67b	F41	pandoc-cli	2025-10-08
Fedora	FEDORA-2025-1be5992b52	F41	python-nh3	2025-10-01
Fedora	FEDORA-2025-7ec84ba6e9	F42	python-nh3	2025-10-01
Fedora	FEDORA-2025-b108c70b29	F43	python-pip	2025-10-03
Fedora	FEDORA-2025-1be5992b52	F41	rust-ammonia	2025-10-01
Fedora	FEDORA-2025-7ec84ba6e9	F42	rust-ammonia	2025-10-01
Fedora	FEDORA-2025-414364f69d	F41	rust-astral-tokio-tar	2025-10-03
Fedora	FEDORA-2025-5e50082948	F42	rust-astral-tokio-tar	2025-10-03
Fedora	FEDORA-2025-b3cc3be834	F43	rust-astral-tokio-tar	2025-10-03
Fedora	FEDORA-2025-ad509c483b	F42	skopeo	2025-10-01
Fedora	FEDORA-2025-39461417a6	F41	sqlite	2025-10-03
Fedora	FEDORA-2025-3af464595a	F42	sqlite	2025-10-01
Fedora	FEDORA-2025-c12211d6bc	F41	thunderbird	2025-10-05
Fedora	FEDORA-2025-cccf7ed7f4	F42	thunderbird	2025-10-01
Fedora	FEDORA-2025-82ee346ee8	F43	thunderbird	2025-10-05
Fedora	FEDORA-2025-414364f69d	F41	uv	2025-10-03
Fedora	FEDORA-2025-5e50082948	F42	uv	2025-10-03
Fedora	FEDORA-2025-b3cc3be834	F43	uv	2025-10-03
Fedora	FEDORA-2025-793513dcf7	F43	webkitgtk	2025-10-03
Fedora	FEDORA-2025-643cc72c6f	F41	xen	2025-10-01
Fedora	FEDORA-2025-873ad6df70	F43	xen	2025-10-03
Oracle	ELSA-2025-17129	OL8	idm:DL1	2025-10-02
Oracle	ELSA-2025-17085	OL10	ipa	2025-10-03
Oracle	ELSA-2025-17084	OL9	ipa	2025-10-02
Oracle	ELSA-2025-20649		kernel	2025-10-08
Oracle	ELSA-2025-16904	OL10	kernel	2025-10-02
Oracle	ELSA-2025-20650	OL7	kernel	2025-10-08
Oracle	ELSA-2025-20650	OL8	kernel	2025-10-08
Oracle	ELSA-2025-20650	OL8	kernel	2025-10-08
Oracle	ELSA-2025-20649	OL9	kernel	2025-10-08
Oracle	ELSA-2025-17119	OL10	perl-JSON-XS	2025-10-01
Oracle	ELSA-2025-17163	OL8	perl-JSON-XS	2025-10-02
Oracle	ELSA-2025-17162	OL9	perl-JSON-XS	2025-10-02
Oracle	ELSA-2025-16117	OL7	python3	2025-10-02
Red Hat	RHSA-2025:16482-01	EL8.6	container-tools:rhel8	2025-10-06
Red Hat	RHSA-2025:16515-01	EL8.8	container-tools:rhel8	2025-10-06
Red Hat	RHSA-2025:17372-01	EL8.2	firefox	2025-10-06
Red Hat	RHSA-2025:17371-01	EL8.4	firefox	2025-10-06
Red Hat	RHSA-2025:17367-01	EL8.6	firefox	2025-10-06
Red Hat	RHSA-2025:17368-01	EL8.8	firefox	2025-10-06
Red Hat	RHSA-2025:17373-01	EL9.0	firefox	2025-10-06
Red Hat	RHSA-2025:17374-01	EL9.2	firefox	2025-10-06
Red Hat	RHSA-2025:17378-01	EL9.4	firefox	2025-10-06
Red Hat	RHSA-2025:8414-01	EL8	git	2025-10-03
Red Hat	RHSA-2025:7409-01	EL9	git	2025-10-03
Red Hat	RHSA-2025:7641-01	EL9.2	git	2025-10-03
Red Hat	RHSA-2025:7640-01	EL9.4	git	2025-10-03
Red Hat	RHSA-2025:16115-01	EL10	gnutls	2025-10-06
Red Hat	RHSA-2025:7076-01	EL9	gnutls	2025-10-06
Red Hat	RHSA-2025:16116-01	EL9	gnutls	2025-10-06
Red Hat	RHSA-2025:17361-01	EL9.2	gnutls	2025-10-06
Red Hat	RHSA-2025:8020-01	EL9.4	gnutls	2025-10-06
Red Hat	RHSA-2025:17348-01	EL9.4	gnutls	2025-10-06
Red Hat	RHSA-2025:9056-01	EL8.6	gstreamer1-plugins-bad-free	2025-10-08
Red Hat	RHSA-2025:17558-01	EL9	iputils	2025-10-08
Red Hat	RHSA-2025:17559-01	EL9.2	iputils	2025-10-08
Red Hat	RHSA-2025:17560-01	EL9.4	iputils	2025-10-08
Red Hat	RHSA-2025:15782-01	EL10	kernel	2025-10-02
Red Hat	RHSA-2025:17396-01	EL10	kernel	2025-10-07
Red Hat	RHSA-2025:17161-01	EL7	kernel	2025-10-02
Red Hat	RHSA-2025:17397-01	EL8	kernel	2025-10-06
Red Hat	RHSA-2025:17124-01	EL8.6	kernel	2025-10-02
Red Hat	RHSA-2025:17377-01	EL9	kernel	2025-10-07
Red Hat	RHSA-2025:17159-01	EL9.0	kernel	2025-10-02
Red Hat	RHSA-2025:17122-01	EL9.2	kernel	2025-10-02
Red Hat	RHSA-2025:11571-01	EL9.2	kernel	2025-10-06
Red Hat	RHSA-2025:17241-01	EL9.4	kernel	2025-10-02
Red Hat	RHSA-2025:17109-01	EL7	kernel-rt	2025-10-02
Red Hat	RHSA-2025:17192-01	EL9.0	kernel-rt	2025-10-02
Red Hat	RHSA-2025:17123-01	EL9.2	kernel-rt	2025-10-02
Red Hat	RHSA-2025:11572-01	EL9.2	kernel-rt	2025-10-06
Red Hat	RHSA-2025:9120-01	EL10	libvpx	2025-10-02
Red Hat	RHSA-2025:9331-01	EL7	libvpx	2025-10-02
Red Hat	RHSA-2025:9119-01	EL8	libvpx	2025-10-02
Red Hat	RHSA-2025:9128-01	EL8.2	libvpx	2025-10-02
Red Hat	RHSA-2025:9127-01	EL8.4	libvpx	2025-10-02
Red Hat	RHSA-2025:9126-01	EL8.6	libvpx	2025-10-02
Red Hat	RHSA-2025:9125-01	EL8.8	libvpx	2025-10-02
Red Hat	RHSA-2025:9118-01	EL9	libvpx	2025-10-02
Red Hat	RHSA-2025:9124-01	EL9.0	libvpx	2025-10-02
Red Hat	RHSA-2025:9123-01	EL9.2	libvpx	2025-10-02
Red Hat	RHSA-2025:9122-01	EL9.4	libvpx	2025-10-02
Red Hat	RHSA-2025:16582-01	EL8	multiple packages	2025-10-06
Red Hat	RHSA-2025:16580-01	EL8.6	multiple packages	2025-10-06
Red Hat	RHSA-2025:16583-01	EL8.8	multiple packages	2025-10-06
Red Hat	RHSA-2025:14599-01	EL9.2	multiple packages	2025-10-06
Red Hat	RHSA-2025:16086-01	EL9	mysql	2025-10-06
Red Hat	RHSA-2025:16861-01	EL8	mysql:8.0	2025-10-06
Red Hat	RHSA-2025:7619-01	EL9.4	nginx	2025-10-06
Red Hat	RHSA-2025:17429-01	EL10.0	open-vm-tools	2025-10-07
Red Hat	RHSA-2025:17509-01	EL8	open-vm-tools	2025-10-08
Red Hat	RHSA-2025:17512-01	EL8.4	open-vm-tools	2025-10-08
Red Hat	RHSA-2025:17511-01	EL8.6	open-vm-tools	2025-10-08
Red Hat	RHSA-2025:17510-01	EL8.8	open-vm-tools	2025-10-08
Red Hat	RHSA-2025:17452-01	EL9.0	open-vm-tools	2025-10-07
Red Hat	RHSA-2025:17446-01	EL9.2	open-vm-tools	2025-10-07
Red Hat	RHSA-2025:17445-01	EL9.4	open-vm-tools	2025-10-07
Red Hat	RHSA-2025:17428-01	EL9.6	open-vm-tools	2025-10-07
Red Hat	RHSA-2025:16480-01	EL9.0	podman	2025-10-06
Red Hat	RHSA-2025:16488-01	EL9.2	podman	2025-10-06
Red Hat	RHSA-2025:16481-01	EL9.4	podman	2025-10-06
Red Hat	RHSA-2025:10668-01	EL9.4	podman	2025-10-08
Red Hat	RHSA-2025:16099-01	EL7	postgresql	2025-10-06
Red Hat	RHSA-2025:17340-01	EL8.2	thunderbird	2025-10-06
Red Hat	RHSA-2025:17341-01	EL8.4	thunderbird	2025-10-06
Red Hat	RHSA-2025:17342-01	EL8.6	thunderbird	2025-10-06
Red Hat	RHSA-2025:17343-01	EL8.8	thunderbird	2025-10-06
Red Hat	RHSA-2025:17344-01	EL9.0	thunderbird	2025-10-06
Red Hat	RHSA-2025:17345-01	EL9.2	thunderbird	2025-10-06
Red Hat	RHSA-2025:17346-01	EL9.4	thunderbird	2025-10-06
Slackware	SSA:2025-276-01		fetchmail	2025-10-03
SUSE	openSUSE-SU-2025:15588-1	TW	afterburn	2025-10-01
SUSE	openSUSE-SU-2025:0386-1	osB15	afterburn	2025-10-06
SUSE	SUSE-SU-2025:03490-1	SLE-m5.2	cairo	2025-10-08
SUSE	SUSE-SU-2025:03450-1	SLE12	cairo	2025-10-02
SUSE	SUSE-SU-2025:03449-1	SLE15 oS15.6	cairo	2025-10-02
SUSE	openSUSE-SU-2025:15601-1	TW	chromedriver	2025-10-06
SUSE	openSUSE-SU-2025:0387-1	osB15	chromium	2025-10-06
SUSE	openSUSE-SU-2025:0388-1	osB15	chromium	2025-10-06
SUSE	openSUSE-SU-2025:15590-1	TW	curl	2025-10-02
SUSE	openSUSE-SU-2025:15589-1	TW	docker-stable	2025-10-01
SUSE	SUSE-SU-2025:03447-1	SLE12	firefox	2025-10-02
SUSE	SUSE-SU-2025:03462-1	SLE15 SES7.1 oS15.6	firefox	2025-10-07
SUSE	openSUSE-SU-2025:15593-1	TW	firefox	2025-10-03
SUSE	SUSE-SU-2025:03453-1	SLE15 oS15.5 oS15.6	frr	2025-10-03
SUSE	SUSE-SU-2025:03460-1	SLE12	ghostscript	2025-10-07
SUSE	SUSE-SU-2025:03461-1	SLE15 oS15.6	ghostscript	2025-10-07
SUSE	openSUSE-SU-2025:15602-1	TW	gimp	2025-10-07
SUSE	SUSE-SU-2025:03459-1	SLE15 oS15.4	gstreamer-plugins-rs	2025-10-07
SUSE	openSUSE-SU-2025:15599-1	TW	haproxy	2025-10-05
SUSE	openSUSE-SU-2025:15591-1	TW	jupyter-jupyterlab	2025-10-02
SUSE	openSUSE-SU-2025:15592-1	TW	libsuricata8_0_1	2025-10-02
SUSE	openSUSE-SU-2025:15595-1	TW	libvmtools-devel	2025-10-03
SUSE	SUSE-SU-2025:03491-1	SLE-m5.1 SLE-m5.2 oS15.6	libxslt	2025-10-08
SUSE	openSUSE-SU-2025:15597-1	TW	logback	2025-10-04
SUSE	SUSE-SU-2025:03456-1	oS15.6	logback	2025-10-07
SUSE	SUSE-SU-2025:03444-1	SLE15 oS15.6	nginx	2025-10-01
SUSE	SUSE-SU-2025:03464-1	SLE12	openssl-1_0_0	2025-10-07
SUSE	SUSE-SU-2025:03463-1	SLE12	openssl-1_1	2025-10-07
SUSE	SUSE-SU-2025:03446-1	SLE15 oS15.6	python-Django	2025-10-02
SUSE	SUSE-SU-2025:03457-1	MP4.3 SLE15 oS15.4	python-xmltodict	2025-10-07
SUSE	openSUSE-SU-2025:15598-1	TW	python311-Django	2025-10-04
SUSE	openSUSE-SU-2025:15596-1	TW	python311-Django4	2025-10-03
SUSE	openSUSE-SU-2025:15600-1	TW	redis	2025-10-05
SUSE	SUSE-SU-2025:03466-1	MP4.2 MP4.3 SLE15	rubygem-puma	2025-10-07
SUSE	SUSE-SU-2025:03467-1	SLE15 oS15.6	rubygem-puma	2025-10-07
SUSE	SUSE-SU-2025:03445-1	SLE15 oS15.6	snpguest	2025-10-01
SUSE	SUSE-SU-2025:03448-1	SLE15 oS15.5 oS15.6	warewulf4	2025-10-02
Ubuntu	USN-7807-1	16.04 18.04	gst-plugins-base1.0	2025-10-07
Ubuntu	USN-7805-1	22.04 24.04 25.04	haproxy	2025-10-06
Ubuntu	USN-7788-1	14.04	libmspack	2025-10-01
Ubuntu	USN-7787-1	14.04 16.04 18.04	libxslt	2025-10-01
Ubuntu	USN-7793-1	20.04 22.04	linux, linux-aws, linux-aws-5.15, linux-gcp, linux-gcp-5.15, linux-gkeop, linux-hwe-5.15, linux-ibm, linux-ibm-5.15, linux-intel-iotg, linux-intel-iotg-5.15, linux-lowlatency, linux-lowlatency-hwe-5.15, linux-nvidia, linux-nvidia-tegra, linux-nvidia-tegra-5.15, linux-oracle, linux-raspi, linux-xilinx-zynqmp	2025-10-01
Ubuntu	USN-7795-1	18.04 20.04	linux, linux-aws, linux-aws-5.4, linux-bluefield, linux-gcp, linux-gcp-5.4, linux-hwe-5.4, linux-ibm, linux-ibm-5.4, linux-iot, linux-kvm, linux-raspi, linux-xilinx-zynqmp	2025-10-02
Ubuntu	USN-7791-1	24.04 25.04	linux, linux-aws, linux-aws-6.14, linux-hwe-6.14, linux-realtime	2025-10-01
Ubuntu	USN-7796-1	16.04 18.04	linux, linux-aws, linux-aws-hwe, linux-azure, linux-azure-4.15, linux-gcp, linux-gcp-4.15, linux-hwe, linux-oracle	2025-10-02
Ubuntu	USN-7792-1	22.04 24.04	linux, linux-aws, linux-gcp, linux-gcp-6.8, linux-gke, linux-gkeop, linux-ibm, linux-ibm-6.8, linux-lowlatency, linux-lowlatency-hwe-6.8, linux-nvidia, linux-nvidia-6.8, linux-nvidia-lowlatency	2025-10-01
Ubuntu	USN-7797-1	16.04	linux, linux-kvm	2025-10-02
Ubuntu	USN-7797-2	14.04	linux-aws, linux-lts-xenial	2025-10-02
Ubuntu	USN-7792-3	22.04	linux-aws-6.8	2025-10-08
Ubuntu	USN-7796-2	18.04	linux-aws-fips, linux-fips, linux-gcp-fips	2025-10-02
Ubuntu	USN-7793-3	22.04	linux-aws-fips, linux-fips, linux-gcp-fips	2025-10-02
Ubuntu	USN-7795-3	20.04	linux-aws-fips	2025-10-08
Ubuntu	USN-7802-1	22.04 24.04	linux-azure, linux-azure-6.8	2025-10-02
Ubuntu	USN-7796-3	14.04	linux-azure	2025-10-02
Ubuntu	USN-7810-1	22.04	linux-azure	2025-10-08
Ubuntu	USN-7808-1	24.04	linux-azure	2025-10-08
Ubuntu	USN-7798-1	25.04	linux-azure	2025-10-02
Ubuntu	USN-7809-1	24.04	linux-azure-nvidia	2025-10-08
Ubuntu	USN-7795-2	20.04	linux-fips, linux-gcp-fips	2025-10-02
Ubuntu	USN-7791-3	24.04 25.04	linux-gcp, linux-gcp-6.14, linux-oem-6.14	2025-10-06
Ubuntu	USN-7793-5	22.04	linux-gke	2025-10-08
Ubuntu	USN-7801-1	22.04	linux-hwe-6.8	2025-10-02
Ubuntu	USN-7793-4	22.04	linux-intel-iot-realtime, linux-realtime	2025-10-02
Ubuntu	USN-7774-4	22.04	linux-kvm	2025-10-01
Ubuntu	USN-7774-5	22.04	linux-nvidia-tegra-igx	2025-10-06
Ubuntu	USN-7811-1	22.04	linux-nvidia-tegra-igx	2025-10-08
Ubuntu	USN-7801-2	24.04	linux-oracle	2025-10-06
Ubuntu	USN-7793-2	20.04	linux-oracle-5.15	2025-10-02
Ubuntu	USN-7789-1	24.04	linux-oracle-6.14	2025-10-01
Ubuntu	USN-7790-1	24.04	linux-raspi	2025-10-01
Ubuntu	USN-7792-2	24.04	linux-raspi	2025-10-02
Ubuntu	USN-7789-2	25.04	linux-raspi	2025-10-08
Ubuntu	USN-7800-1	24.04	linux-raspi-realtime	2025-10-02
Ubuntu	USN-7799-1	22.04 24.04	linux-realtime, linux-realtime-6.8	2025-10-02
Ubuntu	USN-7791-2	24.04	linux-realtime-6.14	2025-10-02
Ubuntu	USN-7691-2	20.04	mysql-8.0	2025-10-06
Ubuntu	USN-7806-1	20.04 22.04 24.04	pam-u2f	2025-10-06
Ubuntu	USN-7803-1	22.04 24.04 25.04	poppler	2025-10-06
Ubuntu	USN-7794-1	14.04 16.04 18.04 20.04 22.04 24.04 25.04	python-django	2025-10-01
Ubuntu	USN-7804-1	22.04 24.04 25.04	squid	2025-10-06

Full Story (comments: none)