Linux

The systemd project has officially released systemd 262, delivering another substantial update to the system and service manager used by most major Linux distributions. The final release was tagged on September 22, 2026, following three release candidates earlier in the month.

Systemd 262 introduces improvements across service management, containers, virtualization, encrypted storage, TPM security, networking, journal recovery, system updates, and unattended installations. Among the most interesting additions are the ability to build systemd as a single statically linked PID 1 binary, Intel TDX support in systemd-vmspawn, Live Update Orchestrator integration, improved TPM-backed encryption, and new fallback unit files embedded directly into the systemd manager.

The release also contains a rather unusual development safeguard: an AI/LLM canary intended to help identify code contributions generated by AI that haven't been properly reviewed by a human before submission.

systemd 262 Is Officially Available

The final systemd 262 source was tagged by systemd developer Luca Boccassi on September 22.

The upstream tag identifies commit 8cc40e0c5e9234bf45084751ac53b1fbfe70b492 as systemd v262, following release candidates published throughout September.

The release has already begun reaching Linux distribution development repositories.

Debian accepted systemd 262-1 into Debian Unstable on September 22, while Fedora has prepared systemd 262 packages for Fedora 45.

As usual, the speed at which systemd 262 reaches ordinary users will depend on each distribution's update policy.

systemd Can Now Become a Single Static PID 1 Binary

One of the most interesting changes in systemd 262 is support for building systemd as a single statically linked PID 1 and executor binary.

The feature is primarily intended for extremely small container environments.

Normally, systemd depends on a collection of dynamically linked libraries and supporting components. That architecture makes sense for a complete Linux distribution, but containers sometimes need a much smaller runtime environment.

The new static configuration makes it possible to create a more self-contained systemd executable suitable for minimal container images.

These builds avoid dynamically loading optional libraries and use simplified mechanisms for resolving users and groups rather than relying on the complete Name Service Switch infrastructure.

This doesn't mean normal Linux distributions will suddenly replace their standard systemd packages with a giant static executable. The capability is specifically useful for specialized container and minimal-system deployments.

Ubuntu administrators running containerized workloads have a new Linux kernel security problem to watch closely. Public exploit code is now available for CVE-2026-80521, a Linux kernel use-after-free vulnerability that can allow an unprivileged process inside a container to escape and obtain root privileges on the underlying host.

Security firm DepthFirst published its research and exploit on September 22, 2026, demonstrating the attack against Ubuntu 26.04 LTS. The underlying Linux kernel vulnerability had already been fixed upstream on August 6, but as of September 23, Ubuntu's security tracker still lists the main kernel package in Ubuntu 26.04 LTS as "Vulnerable, work in progress," while Ubuntu 24.04 LTS is also listed as vulnerable.

The situation is particularly important for Docker, Kubernetes, cloud infrastructure, and other environments that run potentially untrusted workloads because the vulnerable kernel functionality can be reached through ordinary operations available inside standard containers.

There is currently no confirmed evidence that CVE-2026-80521 is being actively exploited in real-world attacks, and the vulnerability isn't listed in CISA's Known Exploited Vulnerabilities catalog. The availability of working public exploit code nevertheless makes the patch gap considerably more important.

CVE-2026-80521 Is a Linux Kernel Vulnerability

Although Ubuntu is receiving much of the attention because the newly published exploit specifically targets it, CVE-2026-80521 is fundamentally a Linux kernel vulnerability.

The problem exists in the kernel's AF_UNIX socket subsystem, specifically within its garbage collection mechanism.

AF_UNIX sockets, commonly called Unix-domain sockets, provide local inter-process communication between applications running on the same system.

Unlike conventional network sockets, they don't need to communicate across a network. They are widely used by Linux applications and services for fast communication between local processes.

They also support passing file descriptors between processes through SCM_RIGHTS messages, and it is the kernel's management of these references that creates the conditions for CVE-2026-80521.

A Race Condition Leads to Use-After-Free

At the technical level, CVE-2026-80521 involves a race condition inside the AF_UNIX garbage collector.

The kernel needs to track references between Unix sockets when file descriptors are passed between processes. Circular references can develop, where one socket effectively references another while that socket references something else in the same group.

Linux represents these relationships internally and periodically determines which references can safely be removed.

The Fedora Project has officially released Fedora Linux 45 Beta, giving users an early look at the technologies expected to form the foundation of the final Fedora 45 release. The beta became available on September 15, 2026, after Fedora's Quality team approved Release Candidate 1.3 for publication.

Fedora 45 Beta brings significant changes throughout the operating system, including Python 3.15, GCC 16.2, glibc 2.44, GNU Binutils 2.47, Go 1.27, LLVM 23, Podman 6, stricter RPM signature verification, improved DNF5 protections, a new userspace virtual console, standardized desktop secret storage, and substantial installer improvements.

The release is available across Fedora Workstation, KDE Plasma Desktop, Server, Cloud, IoT, Atomic Desktops, Spins, and Labs, although a few prerelease images are excluded.

Fedora 45 Beta Is Now Available

Fedora Linux 45 Beta represents the final major public testing milestone before Fedora 45 reaches stable status.

Fedora describes its beta releases as code-complete previews that closely represent what users should expect from the final version. Development isn't finished, however, and bugs or incomplete migrations can still be discovered during real-world testing.

Fedora 45 Beta is currently available in several major editions:

• Fedora Workstation 45 Beta
• Fedora KDE Plasma Desktop 45 Beta
• Fedora Server 45 Beta
• Fedora Cloud 45 Beta
• Fedora IoT 45 Beta
• Fedora Atomic Desktops
• Fedora Spins
• Fedora Labs

Existing Fedora installations can also be upgraded to the beta using Fedora's DNF system-upgrade process.

Fedora's official Workstation download page confirms Beta 1.3 images for both x86_64 and AArch64 systems.

A New Virtual Console with kmscon

One of Fedora 45's more unusual system-level changes is the replacement of the traditional in-kernel console with kmscon.

Fedora describes kmscon as a modern userspace virtual terminal implementation that provides smoother rendering, better internationalization and font handling, improved visual integration, and security improvements compared with the older console infrastructure.

This affects the virtual terminals users encounter outside their normal graphical desktop session.

Most desktop users spend relatively little time interacting directly with these consoles, but they remain important for troubleshooting, system administration, servers, recovery operations, and systems running without a graphical environment.

Moving that functionality into userspace also gives Fedora more flexibility for future development instead of relying entirely on the legacy kernel console implementation.

The Thunderbird team has officially released Thunderbird 156, bringing another round of new features, security improvements, authentication enhancements, and reliability fixes to the popular open-source email client. Released on September 15, 2026, the update is available for Linux alongside Windows and macOS.

Thunderbird 156 is not a dramatic redesign of the desktop mail client. Instead, it concentrates on improving areas that matter to everyday users and system administrators, including OAuth authentication, OpenPGP, POP3, IMAP, Exchange Web Services, SMTP, attachments, calendars, enterprise policies, and security.

For Linux users in particular, the release delivers several fixes affecting common mail protocols and account configurations while retaining support for Linux environments using GTK+ 3.14 or newer.

Thunderbird 156 Arrives on Linux

Thunderbird 156 follows version 154, which arrived in August with features including optional system tray operation and Microsoft Graph support for Microsoft 365.

Version 156 continues the project's monthly release cycle with a more targeted collection of authentication, security, compatibility, and reliability improvements.

According to Thunderbird's official release notes, version 156 requires:

• Linux: GTK+ 3.14 or newer
• Windows: Windows 10 or newer
• macOS: macOS 10.15 or newer

Thunderbird 156 was officially released on September 15.

Linux distribution availability will vary because distributions can package Thunderbird according to their own schedules. Users receiving Thunderbird through another packaging channel may therefore see version 156 at a different time.

Custom OAuth Support Expands

One of the most significant areas of development in Thunderbird 156 is OAuth authentication.

Thunderbird now supports custom OAuth configurations containing an issuer ID and client secret for IMAP and POP3 accounts. Custom OAuth support has also been extended specifically to POP3.

OAuth has become increasingly important as email providers move away from conventional username-and-password authentication toward token-based authentication.

For Thunderbird, broader custom OAuth support means users and organizations have greater flexibility when connecting the client to mail services that don't fit Thunderbird's predefined provider configurations.

This can be particularly useful in enterprise environments, self-hosted infrastructure, and organizations operating their own identity systems.

Exchange Custom OAuth Setup Fixed

Exchange users receive an important related correction.

The KDE Project has officially released KDE Plasma 6.7.5, delivering another round of bug fixes and stability improvements for the Plasma 6.7 desktop series. Released on September 8, 2026, the update contains roughly a month of fixes and updated translations contributed since Plasma 6.7.4 arrived in early August.

Unlike a major Plasma release, version 6.7.5 doesn't introduce a large collection of new desktop features. Instead, KDE has focused on fixing problems affecting Discover, KWin, Wayland, networking, System Monitor, Plasma Desktop, RPM-OSTree systems, Snap updates, HDR rendering, and several other components.

For users already running Plasma 6.7, this makes version 6.7.5 primarily a maintenance upgrade intended to make the desktop more dependable ahead of the next major Plasma series.

KDE Plasma 6.7.5 Arrives as the September Bugfix Release

KDE describes Plasma 6.7.5 as its September bugfix release for the Plasma 6 desktop.

The broader Plasma 6.7 series originally arrived in June 2026, followed by a succession of maintenance releases:

• Plasma 6.7.1 on June 23
• Plasma 6.7.2 on June 30
• Plasma 6.7.3 on July 14
• Plasma 6.7.4 on August 4
• Plasma 6.7.5 on September 8

KDE's official download infrastructure confirms that the Plasma 6.7.5 source packages became available on September 8.

This slower maintenance cadence later in a Plasma series is normal. Once the most urgent post-release problems have been addressed, KDE generally shifts more development attention toward the next feature release while continuing to provide important fixes for the current branch.

Discover Receives Several Important Fixes

KDE's Discover software center receives some of the most noticeable improvements in Plasma 6.7.5.

One particularly annoying problem could cause Discover to become stuck while checking for updates when its Snap backend was installed but no Snap applications actually had updates available.

That problem has now been corrected.

Discover also behaves more reliably when fwupd, the Linux firmware update service, is unavailable. Previously, a broken or intentionally masked fwupd service could interfere with Discover's normal operation. Plasma 6.7.5 allows the rest of the application to continue functioning correctly in that situation.

This is useful for systems where firmware updating isn't supported, where administrators intentionally disable the service, or where fwupd encounters a configuration problem.

Firmware Updates No Longer Incorrectly Require Reboots

Another Discover correction addresses a regression involving firmware updates.

One of Linux's oldest surviving distributions is moving closer to its next major release. Slackware 16 Alpha 1 became available on September 5, 2026, marking the first formal alpha milestone on the road toward Slackware Linux 16. The release follows a major rebuild of Slackware-current using a substantially newer GNU toolchain and brings together several upgrades that have accumulated since Slackware 15.0 arrived more than four years ago.

The alpha combines Linux 6.18 LTS, GCC 16.2.0, glibc 2.44, GNU Binutils 2.47, KDE Plasma 6, and numerous updated user-space packages while retaining much of the deliberately traditional architecture that has distinguished Slackware for decades.

For longtime Slackware users, Alpha 1 is particularly significant because it provides the clearest indication yet that the lengthy Slackware 16 development cycle is moving toward an eventual stable release.

Slackware 16 Finally Reaches Alpha

Slackware doesn't operate according to the predictable six-month or annual release schedules used by many other Linux distributions.

Instead, development takes place continuously through the Slackware-current branch. Patrick Volkerding and other contributors update that development tree until it reaches a state considered suitable for a stable release.

The previous major version, Slackware 15.0, was released in February 2022. More than four and a half years later, Slackware-current has now officially reached the first alpha milestone for version 16.

Volkerding marked the milestone following a complete rebuild of the distribution with its newly upgraded compiler, C library, and binary utilities.

The short changelog announcement even suggested there might finally be "a light at the end of the tunnel," a promising indication for Slackware users waiting for version 16.

The Entire Distribution Was Rebuilt

One of the most consequential changes behind Alpha 1 is a complete package rebuild.

Slackware's development toolchain has moved to:

• GCC 16.2.0
• glibc 2.44
• GNU Binutils 2.47

After introducing those components, Slackware rebuilt the distribution's packages against the updated environment.

A full rebuild is much more significant than simply replacing three packages.

GCC is responsible for compiling much of the software distributed with Slackware, glibc provides fundamental C library functionality used throughout Linux user space, and Binutils supplies essential development utilities including the GNU assembler and linker.

Rebuilding the distribution against these versions gives Slackware 16 a considerably newer foundation than its predecessor.

These platforms help teams monitor how technical content appears in AI-generated answers, from brand mentions and citations to accuracy and referral traffic.

Search is splitting into two experiences: one built around ranked pages and another around generated answers. As AI platforms summarize Linux tutorials, open-source project documentation, API references and technical guidance, teams need ways to measure whether their content is mentioned, cited and accurately represented.

An AEO platform provides that visibility. They help writers, maintainers, developers, and content teams examine how pages appear in generated answers, which sources receive citations, and whether AI platforms send traffic to the intended documentation.

Top AEO Tools for Technical Content

AEO and AI visibility platforms vary greatly. Some are mostly about tracking mentions, while others combine AI visibility with citations, referral traffic, competitor data or content recommendations. Below is a selection of tools, both popular and niche, that can be used by technical and content teams responsible for developer portals, Linux resources and open-source projects.

Best for: Measuring AI visibility, citations and resulting website traffic in one platform.

Similarweb AI Search Intelligence gives teams a broad view of how brands and websites appear across AI-generated search experiences. It can be used to monitor brand mentions, citation frequency, prompt-level visibility and share of voice while comparing results with competitors. Similarweb also connects those measurements with its wider web and traffic intelligence, helping teams examine whether visibility and citations are producing visits to particular pages.

For technical content teams, this combination can make it easier to trace the path from an AI answer to its cited source and then to referral traffic. Teams can identify prompts where documentation is absent, determine which domains are being cited instead, and investigate whether AI-referred visitors reach the intended technical

pages. For example, an open-source project could examine whether prompts about installation on Ubuntu, package dependencies or command-line configuration lead users to its current documentation rather than an outdated forum post.

Standout feature: Similarweb combines AI visibility, citation analysis and traffic intelligence, reducing the need to examine those signals in separate platforms.

Best for: Tracking technical content across a wide selection of AI engines.

AI security means hardening everything around the model, not just the model itself.

AI workloads have moved out of the research sandbox and into production, which means they now carry the same operational weight as any other critical service. If you want to understand what is AI security in practical terms, start here. It's not a 

separate discipline bolted onto your existing stack. It's an extension of it. The systems around a model matter as much as the model itself, and for teams running Linux and open-source infrastructure, that means applying familiar discipline to some new risks.

AI Security Is Becoming Part of the Linux Infrastructure

Treat AI workloads like production infrastructure, not side projects. A model doesn't run in isolation. It depends on an operating system, a container runtime, storage, APIs, identity systems, and a pile of dependencies. If any of those layers are weak, prompt filtering or output moderation won’t be enough.

Security teams that only look at the model may miss much of the actual attack surface. The work starts with the same questions you'd ask about any service. What's exposed? Who can reach it? What happens if it's compromised? 

The AI Attack Surface Extends Beyond the Model 

Model-serving APIs, embeddings, retrieval systems, vector databases, plugins, and CI/CD pipelines all now sit inside the perimeter. A vector database that holds proprietary documents is a data store like any other and needs the same access controls. An inference endpoint that accepts arbitrary text input is a public-facing service, and it needs rate limits and authentication like any other. Plugins and tool integrations expand what a model can touch, which also expands what an attacker can touch. It’s the same threat modeling you’d apply to a web application. 

Why security buyers are rethinking what matters most.

Security teams typically don’t struggle to find vulnerabilities as much as they have in the past. The harder part usually begins after the report arrives, once dozens of findings land in front of engineering teams already juggling patch schedules, production deadlines, and internal disagreements about urgency. Platforms like XBOW, OffSec, and Cobalt have entered that environment as organizations started rethinking what they actually need from pentesting vendors beyond annual compliance exercises.

A vulnerability may look severe inside a dashboard, while no one internally agrees whether it creates meaningful exposure or simply adds another item to an already crowded queue. Infrastructure also changes too quickly for static testing cycles to answer every operational question.

APIs update mid-quarter, contractors receive temporary access that lingers longer than expected, and cloud permissions change quietly during routine development work. Buyers evaluating vendors now spend more time asking whether testing accurately reflects the systems employees use every day.

Pentesting Vendors Now Face Different Expectations

Long reports stopped carrying the same weight years ago. Security teams already know modern environments contain weaknesses. What many organizations want now is clearer evidence showing which findings deserve immediate attention and which ones can wait without creating major operational exposure. That distinction became harder to ignore as remediation timelines stretched across larger environments.

Linux kernel developers are considering a new “steal governor” designed to improve performance when multiple virtual machines compete for limited physical CPU resources. The proposal uses the amount of CPU steal time observed inside a guest to dynamically reduce or expand the number of virtual CPUs on which that VM prefers to schedule work.

The feature is primarily aimed at heavily virtualized servers where administrators deliberately assign more virtual CPUs than the host can physically execute at once. Under heavy load, that overcommitment can lead to frequent vCPU preemption, lock-holder delays, cache disruption, and ultimately lower overall throughput.

The latest v11 patch series was posted on August 25, 2026, and its developer has proposed consideration during the Linux 7.3 development cycle, potentially targeting Linux 7.4 for inclusion. This means the feature is still under review and is not part of a stable Linux kernel yet.

What Is CPU Steal Time?

CPU steal time is a concept specific to virtualization.

Imagine a virtual machine has eight vCPUs. From inside that VM, the operating system behaves as though those eight CPUs are available. But those virtual CPUs ultimately need to run on the host's physical processors.

If several VMs are competing for the same physical CPU resources, the hypervisor may temporarily prevent one VM's vCPU from running so another VM can use the processor.

The time during which the guest wanted to execute but couldn't because the hypervisor was using the underlying CPU elsewhere is known as steal time.

High steal time is therefore a useful indication that the physical host is experiencing CPU contention.

The “Noisy Neighbor” Problem

The steal governor is designed primarily to address what virtualization engineers commonly call the noisy neighbor problem.

Consider a server hosting several VMs:

• VM A has 32 vCPUs.
• VM B has 32 vCPUs.
• VM C has 32 vCPUs.
• The physical server has only 64 CPU threads available to those workloads.

That configuration can work perfectly well when the VMs aren't simultaneously busy.

If all three suddenly become heavily loaded, however, they may collectively request more CPU time than the physical machine can provide.

The hypervisor then has to constantly switch between vCPUs.

Those interruptions can become particularly expensive if a vCPU is preempted while holding a lock or executing another latency-sensitive section of code. Other threads may then wait for a vCPU that isn't currently being allowed to run.

The result can be counterintuitive: giving the VMs more virtual CPUs can sometimes make the combined workloads slower.