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.

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.

Linus has released 7.0-rc4 for testing.

Then Thursday hit with the networking pull. And then on Friday everybody else decided to send in their work for the week, with a few more trickling in over the weekend. End result: what had for a short few days looked like a nice calm week turned into another "bigger than usual" release candidate.

To be fair, that "almost everything comes in at the end of the week" is 100% normal, and none of this is surprising. I was admittedly hoping that things would start to calm down, but that was not to be.

I no longer really believe that it was the one extra week we had last release cycle: I'm starting to suspect it's the psychological result of "hey, new major number", and people are just being a bit more active as a result.

Reddit user "Ok_Lingonberry3296" has posted the results of an extensive investigation into the companies that are pushing US state legislatures to enact age-verification bills.

I've been pulling public records on the wave of "age verification" bills moving through US state legislatures. IRS 990 filings, Senate lobbying disclosures, state ethics databases, campaign finance records, corporate registries, WHOIS lookups, Wayback Machine archives. What started as curiosity about who was pushing these bills turned into documenting a coordinated influence operation that, from a privacy standpoint, is building surveillance infrastructure at the operating system level while the company behind it faces zero new requirements for its own platforms.

(See also this article for a look at the California law.)

Qualys has sent out a somewhat breathless advisory describing a number of vulnerabilities in the AppArmor security module, which is used in a number of Debian-based distributions (among others).

This "CrackArmor" advisory exposes a confused-deputy flaw allowing unprivileged users to manipulate security profiles via pseudo-files, bypass user-namespace restrictions, and execute arbitrary code within the kernel. These flaws facilitate local privilege escalation to root through complex interactions with tools like Sudo and Postfix, alongside denial-of-service attacks via stack exhaustion and Kernel Address Space Layout Randomization (KASLR) bypasses via out-of-bounds reads.

One of the first changes merged for the upcoming 7.0 release was nullfs, an empty filesystem that cannot actually contain any files. One might logically wonder why the kernel would need such a thing. It turns out, though, that there are places where a null filesystem can come in handy. For 7.0, nullfs will be used to make life a bit easier for init programs; future releases will likely use nullfs to increase the isolation of kernel threads from the init process.

Linus has released 7.0-rc3 for testing. "So it's still pretty early in the release cycle, and it just feels a bit busier than I'd like. But nothing particularly stands out or looks bad."

Geoff Huston looks at the network time protocol, and efforts to secure it, in detail.

NTP operates in the clear, and it is often the case that the servers used by a client are not local. This provides an opportunity for an adversary to disrupt an NTP session, by masquerading as a NTP server, or altering NTP payloads in an effort to disrupt a client's time-of-day clock. Many application-level protocols are time sensitive, including TLS, HTTPS, DNSSEC and NFS. Most Cloud applications rely on a coordinated time to determine the most recent version of a data object. Disrupting time can cause significant chaos in distributed network environments.

While it can be relatively straightforward to secure a TCP-based protocol by adding an initial TLS handshake and operating a TLS shim between TCP and the application traffic, it's not so straightforward to use TLS in place of a UDP-based protocol for NTP. TLS can add significant jitter to the packet exchange. Where the privacy of the UDP payload is essential, then DTLS might conceivably be considered, but in the case of NTP the privacy of the timestamps is not essential, but the veracity and authenticity of the server is important.

NTS, a secured version of NTP, is designed to address this requirement relating to the veracity and authenticity of packets passed from a NTS server to an NTS client. The protocol adds a NTS Key Establishment protocol (NTS-KE) in additional to a conventional NTPv4 UDP packet exchange (RFC 8915).

Version 25.12.0 of the OpenWrt router distribution is available; this release has been dedicated to the memory of Dave Täht. Changes include a switch to the apk package manager, the integration of the attended sysupgrade method, and support for a long list of new targets.

Version 1.94.0 of the Rust language has been released. Changes include array windows (an iterator for slices), some Cargo enhancements, and a number of newly stabilized APIs.

The grith.ai blog reports on an LLM prompt-injection vulnerability that led to 4,000 installations of a compromised version of the Cline utility.

For the next eight hours, every developer who installed or updated Cline got OpenClaw - a separate AI agent with full system access - installed globally on their machine without consent. Approximately 4,000 downloads occurred before the package was pulled.

The interesting part is not the payload. It is how the attacker got the npm token in the first place: by injecting a prompt into a GitHub issue title, which an AI triage bot read, interpreted as an instruction, and executed.