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.
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.
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.
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.
A pull request that touches over 8,000 files, changing over 20,000 lines of
code in the process, is (fortunately) not something that happens every day.
It did happen at the end of the 7.0 merge window, though, when Linus
Torvalds merged
an extensive set of changes by Kees Cook to the venerable kmalloc() API (and
its users). As a result of that work, though, the kernel has a new set of
type-safe memory-allocation functions, with a last-minute bonus change to
make the API a little easier to use.
The collective thoughts of the interwebz
Manage Consent
To provide the best experiences, we use technologies like cookies to store and/or access device information. Consenting to these technologies will allow us to process data such as browsing behavior or unique IDs on this site. Not consenting or withdrawing consent, may adversely affect certain features and functions.
Functional
Always active
The technical storage or access is strictly necessary for the legitimate purpose of enabling the use of a specific service explicitly requested by the subscriber or user, or for the sole purpose of carrying out the transmission of a communication over an electronic communications network.
Preferences
The technical storage or access is necessary for the legitimate purpose of storing preferences that are not requested by the subscriber or user.
Statistics
The technical storage or access that is used exclusively for statistical purposes.The technical storage or access that is used exclusively for anonymous statistical purposes. Without a subpoena, voluntary compliance on the part of your Internet Service Provider, or additional records from a third party, information stored or retrieved for this purpose alone cannot usually be used to identify you.
Marketing
The technical storage or access is required to create user profiles to send advertising, or to track the user on a website or across several websites for similar marketing purposes.