Linus Torvalds released 6.19-rc1 and closed the 6.19 merge window on December 14 (Japan time), after having pulled 12,314 non-merge commits into the mainline. Over 8,000 of those commits came in after our first 6.19 merge-window summary was written. The second part of the merge window was focused on drivers, but brought in a number of other changes as well.

Linus has released 6.19-rc1, perhaps a bit earlier than expected.

So it's Sunday afternoon in the part of the world where I am now, so if somebody was looking at trying to limbo under the merge window timing with one last pull request and is taken by surprise by the slightly unusual timing of the rc1 release, that failed.

Teaching moment, or random capricious acts? You be the judge.

Ariadne Conill is exploring a capability-based approach to privilege escalation on Linux systems.

Inspired by the object-capability model, I've been working on a project named capsudo. Instead of treating privilege escalation as a temporary change of identity, capsudo reframes it as a mediated interaction with a service called capsudod that holds specific authority, which may range from full root privileges to a narrowly scoped set of capabilities depending on how it is deployed.

The ability to write kernel code in Rust was explicitly added as an experiment — if things did not go well, Rust would be removed again. At the 2025 Maintainers Summit, a session was held to evaluate the state of that experiment, and to decide whether the time had come to declare the result to be a success. The (arguably unsurprising) conclusion was that the experiment is indeed a success, but there were some interesting points made along the way.

One of the key components in the kernel's development process is the linux-next repository. Every day, a large number of branches, each containing commits intended for the next kernel development cycle, is pulled into linux-next and integrated. If there are conflicts between branches, the linux-next process will reveal them. In theory, many other types of problems can be found as well. Some developers feel that linux-next does not work as well as it could, though. At the 2025 Maintainers Summit, Mark Brown, who helps to keep linux-next going, led a session on how it could be made to work more effectively.

The first topic of discussion at the 2025 Maintainers Summit has been in the air for a while: what role — if any — should machine-learning-based tools have in the kernel development process? While there has been a fair amount of controversy around these tools, and concerns remain, it seems that the kernel community, or at least its high-level maintainership, is comfortable with these tools becoming a significant part of the development process.

Inside this week's LWN.net Weekly Edition:

• Front: Rust in CPython; Python frozendict; Bazzite; IETF post-quantum disagreement; Distrobox; 6.19 merge window; Leaving the TAB.
• Briefs: Let's Encrypt retrospective; PKI infrastructure; Rust in kernel to stay; CNA series; Alpine 3.23.0; cmocka 2.0; Firefox 146; 2024 Free Software Awards; Quotes; ...
• Announcements: Newsletters, conferences, security updates, patches, and more.

The topic of the Rust experiment was just discussed at the annual Maintainers Summit. The consensus among the assembled developers is that Rust in the kernel is no longer experimental — it is now a core part of the kernel and is here to stay. So the "experimental" tag will be coming off. Congratulations are in order for all of the Rust for Linux team.

(Stay tuned for details in our Maintainers Summit coverage.)

The Free Software Foundation has announced the recipients of its 2024 (even though 2025 is almost over) Free Software Awards. Andy Wingo won the award for the advancement of free software, Alx Sa is the outstanding new free-software contributor, and Govdirectory takes the award for projects of social benefit.

As has been recently announced, nominations are open for the 2025 Linux Foundation Technical Advisory Board (TAB) elections. I am one of the TAB members whose term is coming to an end, but I have decided that, after 18 years on the board, I will not be seeking re-election; instead, I will step aside and make room for a fresh voice. My time on the TAB has been rewarding, and I will be sad to leave; the TAB has an important role to play in the functioning of the kernel community.

As of this writing, 4,124 non-merge commits have been pulled into the mainline repository for the 6.19 kernel development cycle. That is a relatively small fraction of what can be expected this time around, but it contains quite a bit of significant work, with changes to many core kernel subsystems. Read on for a summary of the first part of the 6.19 merge window.

Version 2025.12 of the Home Assistant home-automation system has been released.

This month, we're unveiling Home Assistant Labs, a brand-new space where you can preview features before they go mainstream. And what better way to kick it off than with Winter mode? ❄️ Enable it and watch snowflakes drift across your dashboard. It's completely unnecessary, utterly delightful, and exactly the kind of thing we love to build. ❄️

But that's just the beginning. We've been working on making automations more intuitive over the past releases, and this release finally delivers purpose-specific triggers and conditions. Instead of thinking in (numeric) states, you can now simply say "When a light turns on" or "If the climate is heating". It's automation building the way our mind works, as it should be.

There are many possible programmer mistakes that are not caught by the minimal checks specified by the C language; among those is passing an array of the wrong size to a function. A recent attempt to add some safety around array parameters within the crypto layer involved the use of some clever tricks, but it turns out that clever tricks are unnecessary in this case. There is an obscure C feature that can cause this checking to happen, and it is already in use in a few places within the kernel.

Linus Torvalds released the 6.18 kernel as expected on November 30, closing the last full development cycle of 2025. It was another busy cycle, featuring a record number of developers. The time has come for a look at where the code came from for this kernel release, but also for the year-long long-term-support cycle which has also reached its conclusion with this release.

Linus has released the 6.18 kernel, as expected.

So I'll have to admit that I'd have been happier with slightly less bugfixing noise in this last week of the release, but while there's a few more fixes than I would hope for, there was nothing that made me feel like this needs more time to cook. So 6.18 is tagged and pushed out.

Headline changes in this release include the ability to manage namespaces with file handles, support for the AccECN congestion-control protocol, initial support for signing of BPF programs, improved memory management with sheaves, the Rust binder driver, better control over transparent huge pages, and a lot more. This release also saw the removal of the bcachefs filesystem.

See the LWN merge-window summaries (part 1, part 2) and the KernelNewbies 6.18 page for more information.

Version 25.11 of the NixOS distribution has been released. "The 25.11 release was made possible due to the efforts of 2742 contributors, who authored 59430 commits since the previous release". Changes include 7,002 new packages, GNOME 49, LLVM 21, a new COSMIC desktop environment beta, firewalld support, and more; see the release notes for details.

The prizrak.me blog is carrying an introduction to the Landlock security module.

Landlock shines when an application has a predictable set of files or directories it needs. For example, a web server could restrict itself to accessing only /var/www/html and /tmp.

Unlike SELinux or AppArmor, Landlock policies don't require administrator involvement or system-wide configuration. Developers can embed policies directly in application code, making sandboxing a natural part of the development process.

Linus has released 6.18-rc7, probably the last -rc before the 6.18 release.

So the rc6 kernel wasn't great: we had a last-minute core VM regression that caused people problems.

That's not a great thing late in the release cycle like that, but it was a fairly trivial fix, and the cause wasn't some horrid bug, just a latent gotcha that happened to then bite a late VM fix. So while not great, it also doesn't make me worry about the state of 6.18. We're still on track for a final release next weekend unless some big new problem rears its ugly head.

The Oracle blog has a lengthy article on enhancements to GCC to help detect overflows of flexible array members (FAMs) in C programs.

We describe here two new GNU extensions which specify size information for FAMs. These are a new attribute, "counted_by" and a new builtin function, "__builtin_counted_by_ref". Both extensions can be used in GNU C applications to specify size information for FAMs, improving the buffer overflow detection for FAMs in general.

This work has been covered on LWN as well.

The call for candidates for the 2025 election for the Linux Foundation Technical Advisory Board has been posted.

The TAB exists to provide advice from the kernel community to the Linux Foundation and holds a seat on the LF's board of directors; it also serves to facilitate interactions both within the community and with outside entities. Over the last year, the TAB has overseen the organization of the Linux Plumbers Conference, advised on the setup of the kernel CVE numbering authority, worked behind the scenes to help resolve a number of contentious community discussions, worked with the Linux Foundation on community conference planning, and more.

Nominations close on December 13.