The 6.19.12, 6.18.22, 6.12.81, 6.6.134, and 6.1.168 stable kernel updates have been released; each contains another set of important fixes.

Things do not always go the way kernel developers think they will. When the kernel gained support for the creation of read-only transparent huge pages for the page cache in 2019, the developer of that feature, Song Liu, added a Kconfig file entry promising that support for writable huge pages would arrive "in the next few release cycles". Over six years later, that promise is still present, but it will never be fulfilled. Instead, the read-only option will soon be removed, reflecting how the core of the memory-subsystem has changed underneath this particular feature.

Linus has released 7.0-rc7 for testing. "Things look set for a final release next weekend, but please keep testing. The Easter bunny is watching".

LWN recently reported on the Trivy compromise that led, in turn, to the compromise of the LiteLLM system; that article made the point that the extent of the problem was likely rather larger than was known. The Next Web now reports that the Trivy attack was used to compromise a wide range of European Commission systems.

The European Union's computer emergency response team said on Thursday that a supply chain attack on an open-source security scanner gave hackers the keys to the European Commission's cloud infrastructure, resulting in the theft and public leak of approximately 92 gigabytes of compressed data including the personal information and email contents of staff across dozens of EU institutions.

The kernel provides a number of ways for processes to communicate with each other, but they never quite seem to fit the bill for many users. There are currently a few proposals for interprocess communication (IPC) enhancements circulating on the mailing lists. The most straightforward one adds a new system call for POSIX message queues that enables the addition of new features. For those wanting an entirely new way to do interprocess communication, there is a proposal to add a new subsystem for that purpose to io_uring. Finally, the bus1 proposal has made a return after ten years.

Michael Meeks has posted an angry missive about changes at The Document Foundation. What has really happened is not entirely clear, but it seems to involve, at a minimum, the forced removal of all Collabora staff from the foundation. There has been a set of "thank you" notes to the people involved posted in the foundation's forums. The Document Foundation's decision to restart LibreOffice Online almost certainly plays into this as well.

Details are fuzzy at best; we will be working at providing a clearer picture, but that will take some time.

There is a blog post on sockpuppet.org arguing that we are not prepared for the upcoming flood of high-quality, LLM-generated vulnerability reports and exploits.

Now consider the poor open source developers who, for the last 18 months, have complained about a torrent of slop vulnerability reports. I'd had mixed sympathies, but the complaints were at least empirically correct. That could change real fast. The new models find real stuff. Forget the slop; will projects be able to keep up with a steady feed of verified, reproducible, reliably-exploitable sev:hi vulnerabilities? That's what's coming down the pipe.

Everything is up in the air. The industry is sold on memory-safe software, but the shift is slow going. We've bought time with sandboxing and attack surface restriction. How well will these countermeasures hold up? A 4 layer system of sandboxes, kernels, hypervisors, and IPC schemes are, to an agent, an iterated version of the same problem. Agents will generate full-chain exploits, and they will do so soon.

Meanwhile, no defense looks flimsier now than closed source code. Reversing was already mostly a speed-bump even for entry-level teams, who lift binaries into IR or decompile them all the way back to source. Agents can do this too, but they can also reason directly from assembly. If you want a problem better suited to LLMs than bug hunting, program translation is a good place to start.

The 7.0-rc6 kernel prepatch is out for testing.

Anyway, exactly because it's just "more than usual" rather than feeling *worse* than usual, I don't currently feel this merits extending the release, and I still hope that next weekend will be the last rc. But it's just a bit unnerving how this release doesn't want to calm down, so no promises.

LiteLLM is a gateway library providing access to a number of large language models (LLMs); it is popular and widely used. On March 24, the word went out that the version of LiteLLM found in the Python Package Index (PyPI) repository had been compromised with information-stealing malware and downloaded thousands of times, sparking concern across the net. This may look like just another supply-chain attack — and it is — but the way it came about reveals just how many weak links there are in the software supply chains that we all depend on.

The SafeDep blog reports that compromised versions of the telnyx package have been found in the PyPI repository:

Two versions of telnyx (4.87.1 and 4.87.2) published to PyPI on March 27, 2026 contain malicious code injected into telnyx/_client.py. The telnyx package averages over 1 million downloads per month (~30,000/day), making this a high-impact supply chain compromise. The payload downloads a second-stage binary hidden inside WAV audio files from a remote server, then either drops a persistent executable on Windows or harvests credentials on Linux/macOS.

A number of projects have been struggling with the question of which submissions created by large language models (LLMs), if any, should be accepted into their code base. This discussion has been further muddied by efforts to use LLM-driven reimplemention as a way to remove copyleft restrictions from a body of existing code, as recently happened with the Python chardet module. In this context, an attempt to introduce an LLM-generated implementation of the Linux ext4 filesystem into OpenBSD was always going to create some fireworks, but that project has its own, clearly defined reasons for looking askance at such submissions.

The kernel's direct map provides code running in kernel mode with direct access to all physical memory installed in the system — on 64-bit systems, at least. It obviously makes life easier for kernel developers, but the direct map also brings some problems of its own, most of which are security-related. Interest in removing at least some pages from the direct map has been simmering for years; a couple of patch sets under discussion show some use cases for memory that has been removed from the direct map, and how such memory might be efficiently managed.

This issue report describes a credential-stealing attack buried within LiteLLM 1.82.8 in the PyPI repository. It collects and exfiltrates a wide variety of information, including SSH keys, credentials for a number of cloud services, crypto wallets, and so on. Anybody who has installed this package has likely been compromised and needs to respond accordingly.

Update: see this futuresearch article for some more information. "The release contains a malicious .pth file (litellm_init.pth) that executes automatically on every Python process startup when litellm is installed in the environment."

Chris Down has posted a detailed look at how the kernel's zswap and zram subsystems work — and how they differ.

Most people think of zswap and zram simply as two different flavours of the same thing: compressed swap. At a surface level, that's correct – both compress pages that would otherwise end up on disk – but they make fundamentally different bets about how the kernel should handle memory pressure, and picking the wrong one for your situation can actively make things worse than having no swap at all

Linus has released 7.0-rc5 for testing. "It looks like things are starting to calm down - rc5 is smaller than the previous rc's this merge window, although it still tracks a bit larger than rc5s historically do."

Version 0.15.0 of the b4 patch-management tool is out. Highlights in this release include the b4 review workflow manager for maintainers (covered briefly in this article), b4 dig, which can find the original mailing-list submission behind a commit, three-way-merge support in b4 shazam, and more. See the release notes for details.

Ars Technica describes the ritual that will be required before a future Android device will deign to install apps from somewhere other than the Play Store. It is not for the impatient.

Here are the steps:

• Enable developer options by tapping the software build number in About Phone seven times
• In Settings > System, open Developer Options and scroll down to "Allow Unverified Packages."
• Flip the toggle and tap to confirm you are not being coerced
• Enter device unlock code
• Restart your device
• Wait 24 hours
• Return to the unverified packages menu at the end of the security delay
• Scroll past additional warnings and select either "Allow temporarily" (seven days) or "Allow indefinitely."
• Check the box confirming you understand the risks.
• You can now install unverified packages on the device by tapping the "Install anyway" option in the package manager.

The kernel project has a unique approach to tooling that avoids many commonly used development systems that do not fit the community's scale and ways of working. Another way of looking at the situation is that the kernel project has often under-invested in tooling, and sometimes seems bent on doing things the hard way. In recent times, though, the amount of effort that has gone into development tools for the kernel has increased, with some interesting results. Recent developments in this area include the Sashiko code-review system, a patch-review manager built into b4, and a new attempt at a framework for the specification and verification of kernel APIs.

Version 4.24.0 of the Samba SMB filesystem implementation has been released. There are a number of significant changes, including audit support for authentication information, remote password management, a number of Kerberos improvements, asynchronous-I/O rate limiting, and more.

Roman Gushchin has announced the existence of an LLM-driven patch-review system named Sashiko. It automatically creates reviews for all patches sent to the linux-kernel mailing list (and some others).

In my measurement, Sashiko was able to find 53% of bugs based on a completely unfiltered set of 1,000 recent upstream issues using "Fixes:" tags (using Gemini 3.1 Pro). Some might say that 53% is not that impressive, but 100% of these issues were missed by human reviewers.

Sashiko is built on Chris Mason's review prompts (covered here in October 2025), but the implementation has evolved considerably.