The Node.js project has released
a number of security updates to fix, among other vulnerabilities, a
remote-code-execution bug affecting programs that use Brotli compression. And,
in case any programmers who use compiled languages thought they could relax, the musl libc project has also announced a
new vulnerability: an out-of-bounds
write that could potentially lead to remote code execution, although that
has not been demonstrated.
The work to support block sizes larger than the page size on XFS has been
difficult. Many users of XFS run stable kernels, which means that they aren’t testing
new XFS code as it is released. That has made Daniel Gomez wonder whether
adopting Rust for some of the data structures underlying XFS, particularly
XArrays, could reduce the number of bugs lurking in the code. At
Kangrejos 2026, he led a discussion about the potential problems with converting
XArray to Rust. The assembled kernel developers had a number of reasons to be
cautious about replacing the XArray code, but Gomez was determined to experiment
with the possibility, citing both security and performance improvements.
Rust has several ad-hoc mechanisms to allow user code to influence how the
standard library executes. For example, custom panic handlers and custom
allocators both involve registering functions that core standard library code
needs to call. With more similar features planned,
Jana Dönszelmann spotted the developing pattern and put together a
general solution, introducing a safer, checked analogue of C’s weak symbol
linking. At Kangrejos 2026, she explained how this new language feature works,
and proposed using it to clean up the kernel’s handling of integer overflows in
Rust code.
Self-referential structures that can be used without unsafe code
have posed a problem for Rust for years.
There are many cases where a self-referential data structure is the elegant
algorithmic choice, but implementing it in accordance with Rust’s lifetime rules
is all but impossible. At Kangrejos 2026, Gary Guo presented a clever solution
to the problem in the context of the kernel’s
pin_init crate, which helps with the creation of immovable data structures,
typically for interoperability with C. Guo’s changes could help remove most of
the unsafe code related to lifetimes in the
Nova driver and, eventually, other Rust components.
Rust’s system of ownership and borrowed references is convenient when it can
correctly model a program’s needs. The
Rust for Linux project has worked to
provide adapters between Rust’s semantics and the existing C code
in the kernel. At Kangrejos 2026, Andreas Hindborg spoke about a
patch
series implementing the next such adaptor: an Ownable trait for
representing objects that are allocated in C code, but which Rust code is responsible
for cleaning up (if not necessarily deallocating) when it is done with them.
He hoped to finally reach a consensus on the patch series, after months of
discussion on the mailing list.
Tomáš Šedovič is a program manager at the Rust Foundation. He co-leads the
goals team, which helps
organize the Rust project’s
overall goals, including making sure that the people
who have agreed to work on one have the support they need.
At Kangrejos 2026, he provided an overview of the Rust project’s goal processes
aimed at ensuring that the Rust for Linux developers were aware of how the
project organizes, tracks, and amends goals.
The
Rust for Linux project
has inspired several current project goals, so he thought that getting an inside
view of the process might be helpful.
Nadrieril is a long-time Rust contributor, and the maintainer of the rustc
pattern-matching infrastructure. During his involvement with Rust, he has
noticed a problem with the usability of the language: it is difficult to
automatically extract information from a Rust crate for use with other tooling.
The Charon project aims to fix that by providing a stable API for accessing
internal information from the Rust compiler.
Rust has a number of kinds of smart pointers, both in the standard
library and defined by users. Still, some operations that are possible with
built-in references are not possible to perform with user-defined smart
pointers. Tyler Mandry, lead of the Rust project’s
language team, spoke at
RustConf 2026 about the lengthy effort to change that, and make smart pointers
just as flexible as built-in references.
Christian Legnitto is the maintainer of
rust-gpu and
Rust CUDA, two
libraries that make it possible to program a computer’s graphics processing unit
(GPU) from Rust. He isn’t satisfied with the current state of GPU support in
Rust, however. In a talk at
RustConf 2026, he explained his vision for how the
GPU could become an ordinary compiler target for normal Rust code, without the
need for any special libraries or new ecosystem support. That vision is not yet
fully implemented, but he does have a prototype that he is preparing to release.
Many of the transmissions sent over the radio spectrum can
be decoded with a relatively cheap hardware dongle. Thomas Eckert presented at
RustConf 2026 in Montreal about his hobby:
decoding radio transmissions with Rust.
In his presentation, he
covered all of the math necessary to get started with
software-defined radio,
and gave demonstrations of listening to AM and FM radio, as well as decoding
transmissions from
aircraft transponders. His slides and example code are
available on GitHub.
Pierre-Emmanuel Patry and Arthur Cohen gave a talk at
RustConf 2026 on the
status of the Rust frontend for GCC (gccrs), with a particular eye toward the
goal of
compiling the Linux kernel. Patry gave a follow-up talk for a more
kernel-focused audience at
Kangrejos the next week, which Cohen could not attend. The
gccrs project is
making good progress overall, but it will still be some time until the compiler
is usable.
A function’s return type is supposed to indicate the kind of data that it
produces.
Rust’s “never” type, which is
denoted by an exclamation mark (“!“), is the type the language uses to mark
a function that never returns and other places where a value can never occur. For
a long time, the never type was used internally by the compiler, but was
considered an unstable feature. On
August 24, after more than two years of work,
Rust-compiler-contributor “waffle” finally managed to stabilize the type. It
took so long, in part, because it involved a small breaking
change to previous Rust editions, which the compiler maintainers needed to
ensure did not impact much real code.
When a laptop is asleep, its memory is not unreadable. The right
tooling can attach to the computer’s memory bus and read out its contents, and
cold-boot attacks can theoretically read values from memory for a short time
after the computer loses power. That
is really an unavoidable fact about the hardware, but some users would still
like to ensure that, even if this happens, their long-term encryption keys, such as
the key for full-disk encryption, remain unreadable. In June 2026, Ingo
Blechschmidt
discovered that Linux kernel versions after 6.9 (released in
May 2024)
were not erasing disk-encryption keys when a laptop was put to sleep, even
when configured to do so. He quickly identified a potential fix, which has been
merged, but it was not a comprehensive solution.
The null block
driver (null_blk)
is a small driver that is mostly useful for benchmarking block-layer
implementations. It accepts all requests and marks them complete as quickly as
possible, doing as little work as possible. In June 2026, Andreas Hindborg shared
a patch set implementing the same functionality in Rust, in order to show
that a simple block driver is now possible to write using the kernel’s
Rust APIs and to enable comparisons between the C and Rust
implementations.
A minimal version of the “rnull” driver is already present in the mainline
kernel, but Hindborg’s patch set brings it up to feature parity with the C
version.
Practical quantum computers have been ten years away for the last several
decades. Now, however, it’s beginning to look as though they will be
possible in just a few years. Recent
research with obfuscated results demonstrated much lower memory requirements to factor
ECDSA keys on a quantum computer, with
work by other researchers in the open more than halving memory use compared
to the state of the art in 2023.
At the same time, computer
manufacturers are
boasting quantum processors that retain viable superpositions over longer periods.
Given how slowly software updates filter out to stable systems, it’s worth
looking at what configuration changes and protocol updates are needed to be safe
from quantum computers now.
Ihor Solodrai and Shung-Hsi Yu wrapped up the BPF track at the 2026
Linux
Storage, Filesystem, Memory-Management, and BPF Summit with a pair of
sessions related to testing.
Solodrai spoke about what has changed for BPF’s continuous-integration (CI)
testing. Yu spoke about what may be
needed to test BPF updates in stable kernels more thoroughly. The
BPF subsystem’s CI tests are in a good place, they said; even so, Solodrai and Yu have a
handful of possible avenues toward enabling better test coverage in the future.
Christopher Domas has published a proof of concept with a description showing how to use AMD memory controllers’ bank swizzle mode to bypass memory protection and read or write arbitrary data, including CPU microcode definitions and memory belonging to the
platform security processor. Among other things, this allows code running at the kernel level to directly manipulate the meaning of processor instructions, potentially bypassing other security measures such as memory encryption and virtual machine isolation.
This is not, strictly, unexpected behavior: it is
documented in AMD’s manual (on page 113 of that PDF). But the fact that it can be used to access arbitrary memory and thereby rewrite supposedly immutable parts of the computer’s firmware without crashing the host machine seems like an unintentional side-effect of the design. Fortunately, since enabling bank swizzle mode requires kernel-level privileges, the vulnerability is not an immediate problem for most software. Still, it seems likely that this technique will end up being used for nefarious purposes eventually.
Storage code has to cope with hardware that fails in inconvenient
ways, but coaxing a healthy disk into producing those failures on
demand, for testing, is usually not possible. The kernel
provides several ways to inject block-layer I/O errors, but none of those can select the
operation to fail, pick the status code to return, or target a disk
directly without employing a stacked device on top. Use of a stacked device means
the test runs against the mapper device, not the disk it was meant to
exercise. A patch
series from Christoph Hellwig adds a configurable error-injection
interface that does all three things that the current error-injection code
lacks, controlled by a per-disk debugfs
file.
BPF offers useful safety guarantees, but Kumar Kartikeya Dwivedi wants BPF
programs to be even safer. At the 2026
Linux Storage, Filesystem,
Memory-Management, and BPF Summit, he led a session
(slides)
discussing the possibility
of adding domain-specific invariants to BPF programs. It was not a discussion
intended to lead to the implementation of any particular kernel feature, but
rather an overview of why additional formal verification might be needed, and
how it could work with the existing BPF ecosystem.
The collective thoughts of the interwebz
Manage Consent
To provide the best experiences, we use technologies like cookies to store and/or access device information. Consenting to these technologies will allow us to process data such as browsing behavior or unique IDs on this site. Not consenting or withdrawing consent, may adversely affect certain features and functions.
Functional
Always active
The technical storage or access is strictly necessary for the legitimate purpose of enabling the use of a specific service explicitly requested by the subscriber or user, or for the sole purpose of carrying out the transmission of a communication over an electronic communications network.
Preferences
The technical storage or access is necessary for the legitimate purpose of storing preferences that are not requested by the subscriber or user.
Statistics
The technical storage or access that is used exclusively for statistical purposes.The technical storage or access that is used exclusively for anonymous statistical purposes. Without a subpoena, voluntary compliance on the part of your Internet Service Provider, or additional records from a third party, information stored or retrieved for this purpose alone cannot usually be used to identify you.
Marketing
The technical storage or access is required to create user profiles to send advertising, or to track the user on a website or across several websites for similar marketing purposes.