If you’re old enough, you no doubt remember that up until the 2.6.0 release of the Linux kernel, an odd number after the first version number indicated a pre-release, development version of the kernel. Even though this scheme was abandoned with the 2.6.0 release in 2003 and since then every single release has been a stable release, it seems the ghosts of this old versioning scheme still roam the halls, because prominent Linux kernel developer Greg Kroah-Hartman just published an explainer about Linux kernel versions.

Despite having a stable release model and cadence since December 2003, Linux kernel version numbers seem to baffle and confuse those that run across them, causing numerous groups to mistakenly make versioning statements that are flat out false. So let’s go into how this all works in detail.

↫ Greg Kroah-Hartman

I genuinely find it difficult to imagine what could possibly be unclear about Linux kernel version numbers. The Linux kernel uses a very generic major.minor scheme, but that’s not where the problems lie – it’s the actual development process of each of these numbered release that’s a bit more complex. This is where we have to talk about things like the roughly 10-week release cycle, containing a 2-week merge window, as well as Torvalds handing off the stable branch to the stable kernel maintainers.

The other oddity is when the major version number gets incremented – the first number in the version number. There’s no real method to this, as Kroah-Hartman admits Torvalds increments this number whenever the remaining numbers get too high and unwieldy to deal with. Very practical, but it does mean that going from, say, 5.x to 6.x doesn’t really imply there’s any changes in there that are any bigger or more disruptive than when going from 6.8.x to 6.9.x or whatever.

There’s a few more important details in here, of course, like where LTS releases come from, but that’s really it – nothing particularly groundbreaking or confusing.

Cyble researchers have identified new Linux malware that combines Mirai-derived DDoS botnet capabilities with a stealthy fileless cryptominer, enabling both network disruption and financial profit in the same threat campaign. “This campaign represents a sophisticated and financially motivated operation combining botnet propagation with stealthy cryptomining,” Cyble threat intelligence researchers wrote in a blog post today. Stealthy techniques and processes allow the new Mirai variant to conduct its mischief in secret. “The attacker employs multiple advanced techniques—including raw-socket scanning, masqueraded processes, internal localhost IPC, dynamic DNS resolution, and fileless miner configuration—to evade detection and maintain long-term persistence on compromised devices,” the researchers said.

Linux Malware Combines Mirai Botnet with XMRig Cryptominer

Combining Mirai-based DDoS botnet capabilities with XMRig-based cryptomining capabilities reflects a growing trend of “hybrid monetization strategies, where threat actors maximize ROI by leveraging infected devices not only for botnet attacks but also for illicit cryptocurrency mining,” the researchers wrote. Organizations operating Linux servers, cloud workloads, or exposed IoT devices “should prioritize hardening and continuous monitoring to mitigate their risk,” they said. The malware uses a multi-stage infection chain that begins with a downloader delivering architecture-specific V3G4/Mirai binaries across x86_64, ARM, and MIPS systems. The second stage, Mddos.x86_64, is a statically linked and UPX-packed Executable and Linkable Format (ELF) file with stripped symbols, “making static inspection more complicated,” Cyble said. After executing and gathering system information, the Linux malware moves into stealth mode, renaming its process to appear as a system daemon (systemd-logind), detaching from the terminal, and launching parallel worker threads for attack operations, command and control (C2) communication, and inter-process communication (IPC) coordination. “A key characteristic of this botnet variant is its use of raw TCP sockets, allowing precise crafting of SYN packets for high-velocity SSH scanning campaigns,” the researchers said. At the same time, worker threads resolve the C2 domain (baojunwakuang[.]asia) via repeated queries to Google Public DNS (8.8.8.8) to maintain command channels. “This multi-threaded DNS resolution strategy is typical of Mirai-style bots, allowing the malware to maintain connectivity and receive commands while executing attacks in parallel,” the researchers wrote.

Fileless Cryptominer

In the third stage, the malware deploys a covert Monero cryptominer by downloading a UPX-packed XMRig binary from the IP 159.75.47[.]123 and stores it in /tmp/.dbus-daemon to masquerade as a legitimate process. Instead of a local configuration file, the miner obtains its configuration dynamically from the C2 server, “enabling real-time updates to wallet addresses, mining pools, and algorithms while leaving no on-disk artifacts” and hindering forensic analysis. “Unlike typical miner deployments that embed a static configuration file on disk ... this sample requests runtime configuration data directly from the C2 server,” the Cyble researchers said. That technique allows the threat actors to avoid exposing wallet addresses, pool endpoints and algorithms during static analysis while dynamically rotating mining parameters and preventing visibility of miner settings on the infected host. During execution, the miner connects to the C2 server to make a configuration request, and the server responds with a JSON blob containing the pool URL, wallet address, algorithm, and thread count. The full Cyble blog includes recommendations for defenders, MITRE ATT&CK techniques, and indicators of compromise (IoCs).

Landlock is a Linux API that lets applications explicitly declare which resources they are allowed to access. Its philosophy is similar to OpenBSD’s unveil() and (less so) pledge(): programs can make a contract with the kernel stating, “I only need these files or resources — deny me everything else if I’m compromised.”

It provides a simple, developer-friendly way to add defense-in-depth to applications. Compared to traditional Linux security mechanisms, Landlock is vastly easier to understand and integrate.

This post is meant to be an accessible introduction, and hopefully persuade you to give Landlock a try.

↫ prizrak.me blog

I had no idea this existed, even though it seems to plug a hole in the security and sandboxing landscape on Linux by not requiring any privileges and by being relatively simple and straightforward to use. There’s even an additional “supervisor” proposal that would bring Android-like permissions not just to, say, desktop applications (see Flatpak), but to every process trying to access anything for the first time.

I’m not knowledgeable enough to make any statements about Landlock compared to any other options we have for securing desktop Linux in a user-friendly, non-intrusive manner, but I definitely like its simplicity.

From the blog 9to5Linux: Linux kernel 6.18 is now available for download, as announced today by Linus Torvalds himself, featuring enhanced hardware support through new and updated drivers, improvements to file systems and networking, and more. Highlights of Linux 6.18 include the removal of the Bcachefs file system, support for the Rust Binder driver, a new dm-pcache device-mapper target to enable persistent memory as a cache for slower block devices, and a new microcode= command-line option to control the microcode loader's behavior on x86 platforms. Linux kernel 6.18 also extends the support for file handles to kernel namespaces, implements initial 'block size > page size' support for the Btrfs file system, adds PTW feature detection on new hardware for LoongArch KVM, and adds support for running the kernel as a guest on FreeBSD's Bhyve hypervisor.

Read more of this story at Slashdot.

For the past 18 months, the Linux OEM Tuxedo Computers has been working on bringing a Snapdragon X Elite ARM laptop to market, but now they cancelled the project due to complications.

Development turned out to be challenging due to the different architecture, and in the end, the first-generation X1E proved to be less suitable for Linux than expected. In particular, the long battery runtimes—usually one of the strong arguments for ARM devices—were not achieved under Linux. A viable approach for BIOS updates under Linux is also missing at this stage, as is fan control. Virtualization with KVM is not foreseeable on our model, nor are the high USB4 transfer rates. Video hardware decoding is technically possible, but most applications lack the necessary support.

Given these conditions, investing several more months of development time does not seem sensible, as it is not foreseeable that all the features you can rightfully expect would be available in the end. In addition, we would be offering you a device with what would then be a more than two-year-old Snapdragon X Elite (X1E), whose successor, the Snapdragon X2 Elite (X2E), was officially introduced in September 2025 and is expected to become available in the first half of 2026.

↫ Tuxedo’s announcement

Back when Qualcomm was hyping up these processors, the company made big claims about supporting Linux equally to Windows, but those promises have turned out to be absolutely worthless. Tuxedo already highlighted the problems it was dealing with half a year ago, and now it seems these problems have become impossible to overcome – at least for now. This is a shame, bu also not entirely unexpected, since there’s no way a small Linux OEM can do the work that Qualcomm promised it would do for its own chip.

All this sadly means we still don’t really have proper Linux support for modern ARM laptops, which is a crying shame. The problem isn’t so much Linux itself, but the non-standardised world of ARM hardware. Large OEMs are willing to do the work to make Windows work, but despite recent successes, desktop Linux is nowhere near as popular as Windows, so there’s little incentive for OEMs (or Qualcomm) to step up their game.

It is what it is.

You press the power button. A second later a wall of text scrolls by, or a logo fades in, and eventually Linux appears. What happens in between is not magic. It is a careful handshake between tiny programs and a very literal CPU. This part follows that handshake until the very first line of C code inside the Linux kernel runs.

↫ 0xkato’s blog

Exactly what it says on the tin.

What if you have a PC-98 machine, and you want to run Linux on it, as you do? I mean, CP/M, OS/2, or Windows (2000 and older) might not cut it for you, after all. Well, it turns out that yes, you can run Linux on PC-98 hardware, and thanks to a bunch of work by Nina Kalinina – yes, the same person from a few days ago – there’s now more information gathered in a single place to get you started.

Plamo Linux is one of the few Linux distributions to support PC-98 series. Plamo 3.x is the latest distribution that can be installed on PC-9801 and PC-9821 directly. Unfortunately, it is quite old, and is missing lots of useful stuff.

This repo is to share a-ha moments and binaries for Plamo on PC-98.

↫ Plamo98 goodies

The repository details “upgrading” – it’s a bit more involved than plain upgrading, but it’s not hard – Plamo Linux from 3.x to 4, which gives you access to a bunch of things you might want, like GCC 3.3 over 2.95, KDE 3.x, Python 2.3, and more. There’s also custom BusyBox config files, a newer version of make, and a few other goodies and tools you might want to have. Once it’s all set and done, you can Linux like it’s 2003 on your PC-98.

The number of people to whom this is relevant must be extraorinarily small, but at some point, someone is going to want to do this, only to find this repository of existing work. We’ve all been there.

A very exciting set of kernel patches have just been proposed for the Linux kernel, adding multikernel support to Linux.

This patch series introduces multikernel architecture support, enabling multiple independent kernel instances to coexist and communicate on a single physical machine. Each kernel instance can run on dedicated CPU cores while sharing the underlying hardware resources.

↫ Cong Wang on the LKML

The idea is that you can run multiple instances of the Linux kernel on different CPU cores using kexec, with a dedicated IPI framework taking care of communication between these kernels. The benefits for fault isolation and security is obvious, and it supposedly uses less resources than running virtual machines through kvm and similar technologies.

The main feature I’m interested in is that this would potentially allow for “kernel handover”, in which the system goes from using one kernel to the other. I wonder if this would make it possible to implement a system similar to what Android currently uses for updates, where new versions are installed alongside the one you’re running right now, with the system switching over to the new version upon reboot. If you could do something similar with this technology without even having to reboot, that would be quite amazing and a massive improvement to the update experience.

It’s obviously just a proposal for now, and there will be much, much discussion to follow I’m sure, but the possibilities are definitely exciting.

As if Francesco P. Lovergine heard my prayers, he wrote an article detailing his experiences with using Guix. Considering he’s a longtime Debian developer, we’re looking at someone who knows a thing or two about Linux.

In the last few months, I have installed and upgraded my second preferred GNU/Linux system, GNU Guix, on multiple boxes. Regarding that system, I have already written a few introductory posts in the recent past. This is an update about my experiences as a user and developer. I still think Guix is a giant step forward in packaging and management, in comparison with Debian and other distributions, for elegance and inner coherence.

↫ Francesco P. Lovergine

Lovergine found some problems with Guix, most notably those stemming from a lack of manpower. It’s not a hugely popular package management system and associated distribution, so the team of developers behind it is relatively small, and this leads to issues like outdated packages, problems arising from updates, and possible security issues. There’s no specific security team, for instance, but at least it’s easy to roll back updates due to the nature of Guix.

Another problem, partially related to the lack of manpower, stems from the fact that the GNU Guix System uses some unusual systems, most notably GNU Shepard. This init system is an alternative to the widely-used systemd, alongside other alternatives like runit (which I use through Void Linux), but due to its relative lack of popularity, it can take some time for more complex packages to be made compatible with it. Especially some packages – like GNOME – that depend more and more on systemd are going to lag behind on Guix.

For anyone with decent Linux experience and a willingness to tinker, I don’t think any of these issues – and the others Lovergine mentions – are dealbreakers. Sure, you might not want to deploy the GNU Guix System on a production system or anything that requires solid, strong security, but for personal and enthusiast use it seems like an interesting and somewhat unorthodox Linux distribution.

DistroWatch’s Jesse Smith is bringing some attention to an issue I have never encountered and had never heard of, and it has to do with antivirus software on Windows. It seems it’s not uncommon for antivirus software on Windows to mark Linux ISOs as malware or otherwise dangerous, and it seems people are reporting these findings to DistroWatch, for some reason. DistroWatch makes it clear they don’t host any of the ISOs, and that close to all of these warnings from antivirus software are false positives.

So why do multiple Windows virus scanners report that they find malware in Linux downloads? Putting aside the obvious conspiracy theories about anti-virus vendors not wanting to lose customers, what is probably happening is the scanners are detecting an archive file (the ISO) which contains executable code, and flagging it as suspicious. Some of the code is even able to change the disk layout, which is something that looks nasty from a security point of view. It’s entirely understandable that a malware scanner which sees an archive full of executable code that could change the way the system boots would flag it as dangerous.

↫ Jesse Smith at DistroWatch

I wonder how many people curious about Linux downloaded an ISO, only to delete is after their Windows antivirus marked it as dangerous. I can’t imagine the number to be particularly high – if you’re downloading a Linux ISO, you’re probably knowledgeable enough to figure out it’s a false positive – but apparently it’s a big enough issue that DistroWatch needs to inform its readers about it, which is absolutely wild to me.

I stumbled upon an LWN.net article from 2023, in which Lars Wirzenius, a long-time Debian developer and friend of Linus Torvalds, recalls the very early days of Linux – in fact, before it was even called Linux. There’s so many fun little stories in here, like how the Linux kernel started out as a multitasking demo written in x86 assembly, which did nothing more than write As and Bs on the screen, or the fact Linux was originally called Freax before Ari Lemmke, one of the administrators of ftp.funet.fi, opted for the name “Linux” when uploading the first release.

However, my favourite story is about what installing Linux was like during those early days.

During this time, people were interested in trying out this new thing, so Linus needed to provide an installation method and instructions. Since he only had one PC, he came to visit to install it on mine. Since his computer had been used to develop Linux, which had simply grown on top of his Minix installation, it had never actually been installed before. Thus, mine was the first PC where Linux was ever installed. While this was happening, I was taking a nap, and I recommend this method of installing Linux: napping, while Linus does the hard work.

↫ Lars Wirzenius at LWN.net

The entire article is a joy to read, and since it’s from 2023, I’m sure I’m late to the party and none of it is news to many of you. On a more topical note, Wirzenius published a short article today detailing why he still uses Debian, after all these decades.