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.

The Rust Foundation has posted the recordings from RustConf 2026 in Montreal, Canada. Photos of the event are also available. LWN covered four talks from RustConf this year.

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.