Linux

Introduction

The team behind MX Linux has just released version 25, carrying the codename “Infinity”, and it brings a significant upgrade by building upon the stable base of Debian 13 “Trixie”. Released on November 9, 2025, this edition doesn’t just refresh the desktop, it introduces modernized tooling, updated kernels, dual init-options, and installer enhancements aimed at both newcomers and long-time users.

In the sections that follow, we’ll walk through the key new features of MX Linux 25, what’s changed for each desktop edition, recommended upgrade or fresh-install paths, and why this release matters in the wider Linux-distribution ecosystem.

What’s New in MX Linux 25 “Infinity”

Here are the headline changes and improvements that define this release:

By moving to Debian 13, Infinity inherits all the stability, security updates, and broader hardware support of the latest Debian stable release. The base system now aligns with Trixie’s libraries, kernels, and architecture support.

• The standard editions ship with the Linux 6.12 LTS kernel series, offering a solid baseline for most hardware.

• For newer hardware or advanced users, the “AHS” (Advanced Hardware Support) variants and the KDE Plasma edition adopt a Liquorix-flavored Linux 6.16 (or 6.15 in some variants) kernel, maximizing performance and compatibility with cutting-edge setups.

Traditionally associated with lighter-weight init options, MX Linux now offers both systemd by default and SysVinit editions (particularly for Xfce and Fluxbox variants). This gives users the freedom to choose their init system preference without losing new features.

• Xfce edition: Ships with Xfce 4.20. Improvements include a revamped Whisker Menu, updated archive management tools (Engrampa replacing File Roller in some editions).

• KDE Plasma edition: Uses KDE Plasma 6.3.6, defaults to Wayland for a modern session experience (with X11 still optionally available), adds root-actions and service menus to Dolphin, and switches TLP out for power-profiles-daemon to resolve power widget issues.

• Fluxbox edition: Offers a more minimal, highly customizable environment: new panel layouts, updated “appfinder” configs for Rofi, toolbar changes and themes refined. Defaults the audio player to Audacious (instead of the older DeaDBeeF).

Arch Linux has shipped its November 2025 ISO snapshot (2025.11.01), and while Arch remains a rolling distribution, these monthly images are a big deal, especially for new installs, labs, and homelab deployments. This time, the ISO lands alongside two important pieces:

• Archinstall 3.0.12 – a more polished, smarter TUI installer

• Pacman 7.1 – a package manager update with stricter security and better tooling

If you’ve been thinking about spinning up a fresh Arch box, or you’re curious what changed under the hood, this release is a very nice jumping-on point.

Why Arch Still Ships Monthly ISOs in a Rolling World

Arch is famous for its “install once, update forever” model. Technically, you could install from a two-year-old image and just run:

sudo pacman -Syu

…but in practice, that’s painful:

• Huge initial update downloads

• Possible breakage jumping across many months of changes

• Outdated installer tooling

That’s why the project publishes a monthly snapshot ISO: it rolls all current packages into a fresh image so you:

• Start with a current kernel and userland

• Spend less time updating right after install

• Get the latest Archinstall baked in (or just a pacman -Sy archinstall away)

The 2025.11.01 ISO is exactly that: Arch as of early November 2025, ready to go.

What’s Inside the November 2025 ISO (2025.11.01)

The November snapshot doesn’t introduce new features by itself, it’s a frozen image of current Arch, but a few details are worth calling out:

• Ships with a Linux 6.17.x kernel, including improved AMD/Intel GPU support and updated Btrfs bits.

• Includes all the usual base packages plus current toolchains, drivers, and desktop stacks from the rolling repos.

• The image is intended only for new installs; existing Arch systems should keep using pacman -Syu for upgrades.

You can download it from the official Arch Linux download page or via BitTorrent mirrors.

One small twist: the ISO itself still ships with Archinstall 3.0.11, but 3.0.12 was released the same day – so we’ll grab the newer version from the repos before running the installer.

Archinstall 3.0.12: What’s Actually New?

Archinstall has evolved from “nice experiment” to “pretty solid way to install Arch” if you don’t want to script everything yourself. Version 3.0.12 is a refinement release focused on stability, storage, and bootloader logic.

AMD has officially confirmed a high-severity security vulnerability in its new Zen 5–based CPUs, and it’s a nasty one because it hits cryptography right at the source: the hardware random number generator.

Here’s a clear breakdown of what’s going on, how bad it really is, and what you should do if you’re running Zen 5.

What AMD Just Confirmed

AMD’s security bulletin AMD-SB-7055, now tracked as CVE-2025-62626, describes a bug in the RDSEED instruction on Zen 5 processors. Under certain conditions, the CPU can:

• Return the value 0 from RDSEED far more often than true randomness would allow

• Still signal “success” (carry flag CF=1), so software thinks it got a good random value

The issue affects the 16-bit and 32-bit forms of RDSEED on Zen 5; the 64-bit form is not affected.

Because RDSEED is used to feed cryptographically secure random number generators (CSPRNGs), a broken RDSEED can poison keys, tokens, and other security-critical values.

AMD classifies the impact as:

Loss of confidentiality and integrity (High severity).

How the Vulnerability Works (In Plain English)

Modern CPUs expose hardware instructions like RDRAND and RDSEED:

• RDRAND: Gives you pseudo-random values from a DRBG that’s already been seeded.

• RDSEED: Gives you raw entropy samples suitable for seeding cryptographic PRNGs (it should be very close to truly random).

Software like TLS libraries, key generators, HSM emulators, and OS RNGs may rely directly or indirectly on RDSEED to bootstrap secure randomness.

On affected Zen 5 CPUs:

• The 16-bit and 32-bit RDSEED variants sometimes return 0 much more often than a true random source should.

• Even worse, they simultaneously report success (CF=1), so software assumes the value is fine rather than retrying.

In cryptographic terms, this means:

• Entropy can be dramatically reduced (many key bits become predictable or even fixed).

• Keys or nonces derived from those values can become partially or fully guessable.

The Linux kernel, foundational for servers, desktops, embedded systems, and cloud infrastructure, has been under heightened scrutiny. Several vulnerabilities have been exploited in real-world attacks, targeting critical subsystems and isolation layers. In this article, we’ll walk through major examples, explain their significance, and offer actionable guidance for defenders.

CVE-2025-21756 – Use-After-Free in the vsock Subsystem

One of the most alarming flaws this year involves a use-after-free vulnerability in the Linux kernel’s vsock implementation (Virtual Socket), which enables communication between virtual machines and their hosts.

How the exploit works: A malicious actor inside a VM (or other privileged context) manipulates reference counters when a vsock transport is reassigned. The code ends up freeing a socket object while it’s still in use, enabling memory corruption and potentially root-level access.

Why it matters: Since vsock is used for VM-to-host and inter-VM communication, this flaw breaks a key isolation barrier. In multi-tenant cloud environments or container hosts that expose vsock endpoints, the impact can be severe.

Mitigation: Kernel maintainers have released patches. If your systems run hosts, hypervisors, or other environments where vsock is present, make sure the kernel is updated and virtualization subsystems are patched.

CVE-2025-38236 – Out-of-Bounds / Sandbox Escape via UNIX Domain Sockets

Another high-impact vulnerability involves the UNIX domain socket interface and the MSG_OOB flag. The bug was publicly detailed in August 2025 and is already in active discussion.

Attack scenario: A process running inside a sandbox (for example a browser renderer) can exploit MSG_OOB operations on a UNIX domain socket to trigger a use-after-free or out-of-bounds read/write. That allows leaking kernel pointers or memory and then chaining to full kernel privilege escalation.

Why it matters: This vulnerability is especially dangerous because it bridges from a low-privilege sandboxed process to kernel-level compromise. Many systems assume sandboxed code is safe; this attack undermines that assumption.

Mitigation: Distributions and vendors (like browser teams) have disabled or restricted MSG_OOB usage for sandboxed contexts. Kernel patches are available. Systems that run browser sandboxes or other sandboxed processes need to apply these updates immediately.

CVE-2025-38352 – TOCTOU Race Condition in POSIX CPU Timers

In September 2025, the U.S. Cybersecurity & Infrastructure Security Agency (CISA) added this vulnerability to its Known Exploited Vulnerabilities (KEV) catalog.

The speculation around a successor to the Steam Deck has stirred renewed excitement, not just for a new handheld, but for what it signals in Linux-based gaming. With whispers of next-gen specs, deeper integration of SteamOS, and an evolving handheld PC ecosystem, these rumors are fueling broader hopes that Linux gaming is entering a more mature age. In this article we look at the existing rumors, how they tie into the Linux gaming landscape, why this matters, and what to watch.

What the Rumours Suggest

Although Valve has kept things quiet, multiple credible outlets report about the Steam Deck 2 being in development and potentially arriving well after 2026. Some of the key tid-bits:

• Editorials note that Valve isn’t planning a mere spec refresh; it wants a “generational leap in compute without sacrificing battery life”.

• A leaked hardware slide pointed to an AMD “Magnus”-class APU built on Zen 6 architecture being tied to next-gen handhelds, including speculation about the Steam Deck 2.

• One hardware leaker (KeplerL2) cited a possible 2028 launch window for the Steam Deck 2, which would make it roughly 6 years after the original.

• Valve’s own design leads have publicly stated that a refresh with only 20-30% more performance is “not meaningful enough”, implying they’re waiting for a more substantial upgrade.

In short: while nothing is official yet, there’s strong evidence that Valve is working on the next iteration and wants it to be a noteworthy jump, not just a minor update.

Why This Matters for Linux Gaming

The rumoured arrival of the Steam Deck 2 isn’t just about hardware, it reflects and could accelerate key inflection points for Linux & gaming:

The original Steam Deck, running SteamOS (a Linux-based OS), helped prove that PC gaming doesn’t always require Windows. A well-received successor would further validate Linux as a first-class gaming platform, not a niche alternative but a mainstream choice.

Since the first Deck, many Windows-based handhelds have entered the market (such as the ROG Ally, Lenovo Legion Go). Rumours of the Deck 2 keep spotlight on the form factor and raise expectations for Linux-native handhelds. This momentum helps encourage driver, compatibility and OS investments from the broader community.

Introduction

The popular penetration-testing distribution Kali Linux has dropped its latest quarterly snapshot: version 2025.3. This release continues the tradition of the rolling-release model used by the project, offering users and security professionals a refreshed toolkit, broader hardware support (especially wireless), and infrastructure enhancements under the hood. With this update, the distribution aims to streamline lab setups, bolster wireless hacking capabilities (particularly on Raspberry Pi devices), and integrate modern workflows including automated VMs and LLM-based tooling.

In this article, we’ll walk through the key highlights of Kali Linux 2025.3, how the changes affect users (both old and new), the upgrade path, and what to keep in mind for real-world deployment.

What’s New in Kali Linux 2025.3

This snapshot from the Kali team brings several categories of improvements: tooling, wireless/hardware support, architecture changes, virtualization/image workflows, UI and plugin tweaks. Below is a breakdown of the major updates.

One of the headline items is the addition of ten new security tools to the Kali repositories. These tools reflect shifts in the field, toward AI-augmented recon, advanced wireless simulation and pivoting, and updated attack surface coverage. Among the additions are:

• Caido and Caido-cli – a client-server web-security auditing toolkit (graphical client + backend).

• Detect It Easy (DiE) – a utility for identifying file types, a useful tool in reverse engineering workflows.

• Gemini CLI – an open-source AI agent that integrates Google’s Gemini (or similar LLM) capabilities into the terminal environment.

• krbrelayx – a toolkit focused on Kerberos relaying/unconstrained delegation attacks.

• ligolo-mp – a multiplayer pivoting solution for network-lateral movement.

• llm-tools-nmap – allows large-language-model workflows to drive Nmap scans (automated/discovery).

• mcp-kali-server – configuration tooling to connect an AI agent to Kali infrastructure.

• patchleaks – a tool that detects security-fix patches and provides detailed descriptions (useful both for defenders and auditors).

• vwifi-dkms – enables creation of “dummy” Wi-Fi networks (virtual wireless interfaces) for advanced wireless testing and hacking exercises.

Introduction

In the world of modern CPUs, speculative execution, where a processor guesses ahead on branches and executes instructions before the actual code path is confirmed, has long been recognized as a performance booster. However, it has also given rise to a class of vulnerabilities collectively known as “Spectre” attacks, where microarchitectural side states (such as the branch target buffer, caches, or predictor state) are mis-exploited to leak sensitive data.

Now, a new attack variant, dubbed VMScape, exposes a previously under-appreciated weakness: the isolation between a guest virtual machine and its host (or hypervisor) in the branch predictor domain. In simpler terms: a malicious VM can influence the CPU’s branch predictor in such a way that when control returns to the host, secrets in the host or hypervisor can be exposed. This has major implications for cloud security, virtualization environments, and kernel/hypervisor protections.

In this article we’ll walk through how VMScape works, the CPUs and environments it affects, how the Linux kernel and hypervisors are mitigating it, and what users, cloud operators and admins should know (and do).

What VMScape Is & Why It Matters

Speculative execution vulnerabilities like Spectre exploit the gap between architectural state (what the software sees as completed instructions) and microarchitectural state (what the CPU has done internally, such as cache loads, branch predictor updates, etc). Even when speculative paths are rolled back architecturally, side-effects in the microarchitecture can remain and be probed by attackers.

One of the original variants, Spectre-BTI (Branch Target Injection, also called Spectre v2) leveraged the Branch Target Buffer (BTB) / predictor to redirect speculative execution along attacker-controlled paths. Over time, hardware and software mitigations (IBRS, eIBRS, IBPB, STIBP) have been introduced. But VMScape shows that when virtualization enters the picture, the isolation assumptions break down.

VMScape (tracked as CVE‑2025‑40300) is described by researchers from ETH Zürich as “the first Spectre-based end-to-end exploit in which a malicious guest VM can leak arbitrary sensitive information from the host domain/hypervisor, without requiring host code modifications and in default configuration.”

Here are the key elements making VMScape significant:

• The attack is cross-virtualization: a guest VM influences the host’s branch predictor state (not just within the guest).

Introduction

Modern computing systems rely heavily on operating-system schedulers to allocate CPU time fairly and efficiently. Yet many of these schedulers operate blindly with respect to the meaning of workloads: they cannot distinguish, for example, whether a task is latency-sensitive or batch-oriented. This mismatch, between application semantics and scheduler heuristics, is often referred to as the semantic gap.

A recent research framework called SchedCP aims to close that gap. By using autonomous LLM‐based agents, the system analyzes workload characteristics, selects or synthesizes custom scheduling policies, and safely deploys them into the kernel, without human intervention. This represents a meaningful step toward self-optimizing, application-aware kernels.

In this article we will explore what SchedCP is, how it works under the hood, the evidence of its effectiveness, real-world implications, and what caveats remain.

Why the Problem Matters

At the heart of the issue is that general-purpose schedulers (for example the Linux kernel’s default policy) assume broad fairness, rather than tailoring scheduling to what your application cares about. For instance:

• A video-streaming service may care most about minimal tail latency.

• A CI/CD build system may care most about throughput and job completion time.

• A cloud analytics job may prefer maximum utilisation of cores with less concern for interactive responsiveness.

Traditional schedulers treat all tasks mostly the same, tuning knobs generically. As a result, systems often sacrifice optimisation opportunities. Some prior efforts have used reinforcement-learning techniques to tune scheduler parameters, but these approaches have limitations: slow convergence, limited generalisation, and weak reasoning about why a workload behaves as it does.

SchedCP starts from the observation that large language models can reason semantically about workloads (expressed in plain language or structured summaries), propose new scheduling strategies, and generate code via eBPF that is loaded into the kernel via the sched_ext interface. Thus, a custom scheduler (or modified policy) can be developed specifically for a given workload scenario, and in a self-service, automated way.

Architecture & Key Components

SchedCP comprises two primary subsystems: a control-plane framework and an agent loop that interacts with it. The framework decouples “what to optimise” (reasoning) from “how to act” (execution) in order to preserve kernel stability while enabling powerful optimisations.

Here are the major components: