Linus has released 6.18-rc6 for testing. "So we have a slightly larger rc6 than usual, but I think it's just the random noise and a result of pull request timings rather than due to any issues with the release. But I guess we have a couple of weeks remaining to find out."

One of the many objectives of the Linux Kernel Self-Protection Project (KSPP), which just completed ten years of work, is to ensure that all array references can be bounds-checked, even in the case of flexible array members, the size of which is not known at compile time. One of the most challenging flexible array members in the kernel is not even declared as such. Almost exactly one year ago, LWN looked at the effort to increase safety around the networking subsystem's heavily used sockaddr structure. One year later, Kees Cook is still looking for a way to bring this work to a close.

The Google Security Blog has a new post on just how well the use of Rust is working out for the Android project.

We adopted Rust for its security and are seeing a 1000x reduction in memory safety vulnerability density compared to Android's C and C++ code. But the biggest surprise was Rust's impact on software delivery. With Rust changes having a 4x lower rollback rate and spending 25% less time in code review, the safer path is now also the faster one.

Longtime LWN readers will have encountered the concept of "stable pages" before; it was first covered here nearly 15 years ago. For the most part, the problem that stable pages were meant to solve — preventing errors when user space modifies a buffer that is under I/O — has been dealt with. But recent discussions show that there is one area where problems remain: direct I/O. There is some disagreement, though, over whether those problems are the result of user-space bugs and how much of a performance price should be paid to address them.

Version 2.0.0 of public-inbox, the mail archiving system behind lore.kernel.org and LWN's email archive, has been released. "This release includes several new features and fixes; mostly around improved integration between inboxes and coderepos for solver. Portability and reliability is also improved, especially in the internal process management of lei."

The 6.18-rc5 kernel prepatch is out for testing. "In other words: it all looks just the way I like it at this point: small and boring."

The kernel community is currently reviewing a proposed policy for contributors who are using large language models to assist in the creation of their patches; the primary focus is on disclosure of the use of those tools. "The goal here is to clarify community expectations around tools. This lets everyone become more productive while also maintaining high degrees of trust between submitters and reviewers."

The future of the Filesystem Hierarchy Standard (FHS) has been under discussion for some time; now, Neal Gompa has announced that the FHS is "hosted and stewarded" by Freedesktop.org.

For those who are unaware, the Filesystem Hierarchy Standard (FHS) is the definition for POSIX operating systems to organize system and user data. It is broadly adopted by Linux, BSD, and other operating systems that follow POSIX-like conventions.

See this page for the specification's new home.

Filesystems are complex and performance-sensitive beasts. They can also present security concerns. Microkernel-based systems have long pushed filesystems into separate processes in order to contain any vulnerabilities that may be found there. Linux can do the same with the Filesystem in Userspace (FUSE) subsystem, but using FUSE brings a significant performance penalty. Darrick Wong is working on ways to eliminate that penalty, and he has a massive patch set showing how ext4 filesystems can be safely implemented in user space by unprivileged processes with good performance. This work has the potential to radically change how filesystems are managed on Linux systems.

Inside this week's LWN.net Weekly Edition:

• Front: Python thread safety; Namespace reference counting; Merigraf; Speeding up short reads; Julia 1.12; systemd security.
• Briefs: CHERIoT 1.0; Chromium XSLT; Arm KASLR; Bazzite; Devuan 6.0; Incus 6.18; LXQt 2.3.0; Rust 1.91.0; Quotes; ...
• Announcements: Newsletters, conferences, security updates, patches, and more.

The Project Zero blog explains that, on 64-bit Arm systems, the kernel's direct map is always placed at the same virtual location, regardless of whether kernel address-space layout randomization (KASLR) is enabled.

While it remains true that KASLR should not be trusted to prevent exploitation, particularly in local contexts, it is regrettable that the attitude around Linux KASLR is so fatalistic that putting in the engineering effort to preserve its remaining integrity is not considered to be worthwhile. The joint effect of these two issues dramatically simplified what might otherwise have been a more complicated and likely less reliable exploit.

Version 6.0 ("Excalibur") of the systemd-averse Devuan distribution has been released. It is based on Debian 13 ("trixie"), and includes some of the significant changes from that release, including the merged /usr hierarchy. See the release notes for details.

The kernel's namespaces feature is, among other things, a key part of the implementation of containers. Like much in the kernel, though, the namespace API evolved over time; there was no design at the outset. As a result, this API has some rough edges and missing features. Christian Brauner is working to straighten out the namespace situation somewhat with this daunting 72-part patch series that, among other things, adds a new system call to allow user space to query the namespaces present on the system.

Joel Severin has announced the availability of his port of the Linux kernel to WebAssembly; one can go to this page and watch it boot in a browser.

Wasm is similar to every other arch in Linux, but also different. One important difference is that there is no way to suspend execution of a task. There is a way around this though: Linux supports up to 8k CPUs (or possibly more...). We can just spin up a new CPU dedicated to each user task (process/thread) and never preempt it

Linus has released 6.18-rc4 for testing. "Last week in fact felt *so* calm that I was surprised to notice that rc4 isn't really smaller than usual: all the stats look very normal, both in number of changes and where the changes are."

The relatively small 6.17.7, 6.12.57, and 6.6.116 stable kernels have been released; each contains another set of important fixes.

Julian Andres Klode has announced that the Debian APT package-management tool will acquire "hard Rust dependencies sometime after May 2026. "If you maintain a port without a working Rust toolchain, please ensure it has one within the next 6 months, or sunset the port."

Version 1.91.0 of the Rust language has been released. Changes include promoting aarch64-pc-windows-msvc to a tier-1 platform, a new lint rule to catch dangling raw pointers from local variables, and a fair number of newly stabilized APIs.

The kernel's file-I/O subsystems have been highly optimized over the years in the hope of providing the best performance for a wide variety of workloads. There is, however, one workload type that suffers with current kernels: applications that perform many short reads, in multiple processes, from the same file. Kiryl Shutsemau has been working on a patch to try to optimize this case, but the task is turning out to be harder than one might expect.

The Python Software Foundation, earlier this year, successfully obtained a $1.5 million grant from the US National Science Foundation "to address structural vulnerabilities in Python and PyPI". The actual grant came with some strings attached though, in the form of a requirement not to pursue diversity, equity, and inclusion programs. So the Foundation has withdrawn the proposal rather than agree to terms that run counter to its own mission.

We're disappointed to have been put in the position where we had to make this decision, because we believe our proposed project would offer invaluable advances to the Python and greater open source community, protecting millions of PyPI users from attempted supply-chain attacks. The proposed project would create new tools for automated proactive review of all packages uploaded to PyPI, rather than the current process of reactive-only review.