a little bit about a router and also the big picture around that router". Gingerich is the director of compliance at the Software Freedom Conservancy (SFC), which is the organization behind the OpenWrt One router that LWN looked at back in November. The router is, of course, based on firmware from the OpenWrt project, which got its start because of GPL-enforcement activities and is a member project at the SFC. [Read more](https://lwn.net/Articles/1014998/) ## [$] The first part of the 6.15 merge window **Category:** Linux **Tags:** Linux **Published:** Fri, 28 Mar 2025 15:08:17 +0000 **TL;DR:** Here is a 2-sentence summary: As of this writing, over 6,600 non-merge changesets have been pulled into the mainline kernel repository for the 6.15 release, indicating that the merge window is well underway. A number of significant changes have already been merged, and this article will summarize the key developments from the first half of the 6.15 merge window. As of this writing, 6,653 non-merge changesets have been pulled into the mainline kernel repository for the 6.15 release. This merge window is thus well underway. A number of significant changes have been merged so far; read on for our summary of the first half of the 6.15 merge window. [Read more](https://lwn.net/Articles/1015414/) ## Security updates for Friday **Category:** Linux **Tags:** Linux **Published:** Fri, 28 Mar 2025 13:10:38 +0000 **TL;DR:** Here is a 2-sentence summary: Multiple Linux distributions have released security updates, including Debian (mercurial and opensaml), Fedora (augeas, mingw-libxslt, and nodejs-nodemon), Mageia (chromium-browser-stable), Red Hat (various packages), SUSE (apache-commons-vfs2, python3, and python36), and Ubuntu (ghostscript, linux, and several variants). These updates address various security vulnerabilities, ensuring the continued security and stability of Linux systems. Security updates have been issued by Debian (mercurial and opensaml), Fedora (augeas, mingw-libxslt, and nodejs-nodemon), Mageia (chromium-browser-stable), Red Hat (grafana, kernel, kernel-rt, opentelemetry-collector, and podman), SUSE (apache-commons-vfs2, python3, and python36), and Ubuntu (ghostscript, linux, linux-aws, linux-azure, linux-gcp, linux-gke, linux-gkeop, linux-ibm, linux-intel-iotg, linux-lowlatency, linux-lowlatency-hwe-5.15, linux-nvidia, linux-oracle, linux-oracle-5.15, linux-raspi, linux, linux-aws, linux-azure, linux-gcp, linux-hwe-6.11, linux-oracle, linux-realtime, linux, linux-aws, linux-gcp, linux-gcp-6.8, linux-gke, linux-gkeop, linux-lowlatency, linux-lowlatency-hwe-6.8, linux-nvidia, linux-nvidia-6.8, linux-nvidia-lowlatency, linux-oracle, linux-oracle-6.8, linux-aws-5.15, linux-kvm, linux-azure, linux-ibm, linux-lowlatency, linux-lowlatency-hwe-6.11, linux-oem-6.11, linux-oem-6.8, linux-realtime, smarty, and snakeyaml). [Read more](https://lwn.net/Articles/1015718/) ## Bypassing Ubuntu's user-namespace restrictions **Category:** Linux **Tags:** Linux **Published:** Thu, 27 Mar 2025 20:51:14 +0000 **TL;DR:** Here is a summary of the text in 2 sentences: Ubuntu 23.10 and 24.04 LTS introduced a feature using AppArmor to restrict access to user namespaces, but Qualys has reported three ways to bypass these restrictions, allowing local users to gain full administrative capabilities within a user namespace. However, Ubuntu has clarified that these bypasses do not constitute security vulnerabilities and are simply demonstrating limitations in the existing protections against unknown Linux kernel vulnerabilities.
Ubuntu 23.10 and 24.04 LTS introduced a feature using AppArmor to restrict access to user namespaces. Qualys has reported three ways to bypass AppArmor's restrictions and enable local users to gain full administrative capabilities within a user namespace. Ubuntu has followed up with a post that explains the namespace-restriction feature in detail, and says these bypasses do not constitute security vulnerabilities.
While a superficial observation of the application of user namespaces may indicate privileged (root level) access, this is a fictitious state that is operating as expected, with access control still mapped to the real (root namespace) user's permissions. As such, these bypasses do not enable more access than what the default Linux kernel unprivileged user namespace feature allows in most Linux distributions. They do, however, demonstrate limitations that we are looking to address in order to strengthen existing protections against as-of-yet-unknown Linux kernel vulnerabilities.
LWN covered Ubuntu 24.04 LTS last May.
[Read more](https://lwn.net/Articles/1015649/) ## Rust adopting Ferrocene Language Specification **Category:** Linux **Tags:** General **Published:** Thu, 27 Mar 2025 19:38:51 +0000 **TL;DR:** Here is a 2-sentence summary: The Rust project has announced that it will adopt the Ferrocene Language Specification (FLS) as part of its ongoing specification efforts. This move aims to remove a barrier to using Rust in safety-critical systems, particularly in organizations that require official language specifications before adoption.One recurring criticism of Rust has been that the language has no official specification. This is a barrier to adoption in some safety-conscious organizations, as well as to writing alternate language implementations. Now, the Rust project has announced that it will be adopting the Ferrocene Language Specification (FLS) developed by Ferrous Systems and maintaining it as part of the core project. While this may not satisfy die-hard standardization-process enthusiasts, it's a step toward removing another barrier to using Rust in safety-critical systems.
It's in that light that we're pleased to announce that we'll be adopting the FLS into the Rust Project as part of our ongoing specification efforts. This adoption is being made possible by the gracious donation of the FLS by Ferrous Systems. We're grateful to them for the work they've done in assembling the FLS, in making it fit for qualification purposes, in promoting its use and the use of Rust generally in safety-critical industries, and now, for working with us to take the next step and to bring the FLS into the Project.[Read more](https://lwn.net/Articles/1015636/)