The Project Zero blog has a three-part series describing a working, zero-click exploit for Pixel 9 devices.

Over the past few years, several AI-powered features have been added to mobile phones that allow users to better search and understand their messages. One effect of this change is increased 0-click attack surface, as efficient analysis often requires message media to be decoded before the message is opened by the user. One such feature is audio transcription. Incoming SMS and RCS audio attachments received by Google Messages are now automatically decoded with no user interaction. As a result, audio decoders are now in the 0-click attack surface of most Android phones.

The blog entry does not question the wisdom of directly exposing audio decoders to external attackers, but it does provide a lot of detail showing how it can go wrong. The first part looks at compromising the codec; part two extends the exploit to the kernel, and part three looks at the implications:

It is alarming that it took 139 days for a vulnerability exploitable in a 0-click context to get patched on any Android device, and it took Pixel 54 days longer. The vulnerability was public for 82 days before it was patched by Pixel.

Al Viro does not often stray outside of the core virtual filesystem area; when he does, it is usually worthy of note. Recently, he wandered into memory management with this patch series to the slab allocator and some of its users. Kernel developers will often put considerable effort into small optimizations, but it is still interesting to look at just how much effort has gone toward the purpose of avoiding a single pointer dereference in some memory-allocation hot paths.

The 2026 edition of the Linux Storage, Filesystem, Memory Management, and BPF Summit will be held May 4-6 in Zagreb, Croatia. The call for proposals has gone out for anybody who would like to attend this invitation-only meeting. "We are asking that you please let us know you want to be invited by February 20, 2026".

The 6.18.5, 6.12.65, 6.6.120, and 6.1.160 stable updates have been released. They all contain a small patch set fixing a scheduling regression associated with idle balancing; the 6.6.120 and 6.1.60 updates also contain a large set of other important fixes.

The READ_ONCE() and WRITE_ONCE() macros are heavily used within the kernel; there are nearly 8,000 call sites for READ_ONCE(). They are key to the implementation of many lockless algorithms and can be necessary for some types of device-memory access. So one might think that, as the amount of Rust code in the kernel increases, there would be a place for Rust versions of these macros as well. The truth of the matter, though, is that the Rust community seems to want to take a different approach to concurrent data access.

On December 24 2025, Linus Torvalds posted a strongly worded message celebrating a ruling in the ongoing GPL-compliance lawsuit filed against VIZIO by the Software Freedom Conservancy (SFC). This case and Torvalds's response have put a spotlight on an old debate over the extent to which the source-code requirements of the GNU General Public License (version 2) extend to keys and other data needed to successfully install modified software on a device. It is worth looking at whether this requirement exists, the subtleties in interpretation that cloud the issue, and the extent to which, if any, the SFC is demanding that information.

Inside this week's LWN.net Weekly Edition:

• Front: What to expect in 2026; LAVD scheduler; libpathrs; Questions for the TAB; Graphite; 2025 timeline.
• Briefs: shadow-utils 4.19.0; Android releases; IPFire 2.29-199; Manjaro 26.0; curl strcpy(); GNU ddrescue 1.30; Ruby 4.0; Partial GPL ruling; Quotes; ...
• Announcements: Newsletters, conferences, security updates, patches, and more.

Android Authority reports that Google will be reducing the frequency of releases of code to the Android Open Source Project to only twice per year.

A spokesperson for Google offered some additional context on this decision, stating that it helps simplify development, eliminates the complexity of managing multiple code branches, and allows them to deliver more stable and secure code to Android platform developers. The spokesperson also reiterated that Google's commitment to AOSP is unchanged and that this new release schedule helps the company build a more robust and secure foundation for the Android ecosystem.

The release schedule for security patches is unchanged.

The calendar has flipped over to 2026; a new year has begun. That means the moment we all dread has arrived: it is time for LWN to put out a set of lame predictions for what may happen in the coming year. Needless to say, we do not know any more than anybody else, but that doesn't stop us from making authoritative-sounding pronouncements anyway.

The 6.19-rc4 kernel prepatch is out for testing.

So this rc is still a bit smaller than usual, but it's not _much_ smaller, and I think next week is likely going to be more or less back to normal.

Which is all exactly as expected, and nothing here looks particularly odd. I'll make an rc8 this release just because of the time lost to the holidays, not because it looks like we'd have any particular issues pending (knock wood).

Greg Kroah-Hartman has written an overview of how the kernel's security team works.

The members of the security team contain a handful of core kernel developers that have experience dealing with security bugs, and represent different major subsystems of the kernel. They do this work as individuals, and specifically can NOT tell their employer, or anyone else, anything that is discussed on the security alias before it is resolved. This arrangement has allowed the kernel security team to remain independent and continue to operate across the different governments that the members operate in, and it looks to become the normal way project security teams work with the advent of the European Union's new CRA law coming into effect.

Nate Graham looks back at how 2025 went for the KDE project.

Today Plasma is the default desktop environment in a bunch of the hottest new gaming-focused distros, including Bazzite, CachyOS, Garuda, Nobara, and of course SteamOS on Valve's gaming devices. Fedora's Plasma edition was also promoted to co-equal status with the GNOME edition, and Asahi Linux — the single practical option for Linux on newer Macs — only supports KDE Plasma. Parrot Linux recently switched to Plasma by default, too. And Plasma remains the default on old standbys like EndeavourOS, Manjaro, NixOS, OpenMandriva, Slackware and TuxedoOS — which ships on all devices sold by Tuxedo Computers!

Linus has released 6.19-rc3 for testing. "Another week, another -rc release. Except the past week has obviously been the holiday week, and this rc release is pretty small as a result. Very much as expected."

The judge in the Vizio GPL-compliance lawsuit has ruled, in a summary judgment, that the GNU General Public License, version 2, does not require the provision of signing keys needed to install modified software on a device.

Read as a whole, the Agreements require Vizio to make the source code available in such a manner that the source code can be readily obtained and modified by Plaintiff or other third parties. While source code is defined to include "the scripts used to control compilation and installation," this does not mean that Vizio must allow users to reinstall the software, modified or otherwise, back onto its smart TVs in a manner that preserves all features of the original program and/or ensures the smart TVs continue to function properly. Rather, in the context of the Agreements, the disputed language means that Vizio must provide the source code in a manner that allows the source code to be obtained and revised by Plaintiff or others for use in other applications.

As the Software Freedom Conservancy, the plaintiff in the case, has pointed out, the judge has ruled against a claim that was never actually made.

SFC has never held the position, nor do we today hold the position, that any version of the GPL (even including GPLv3!) require "that the device continues to function properly" after a user installs their modified version of the copyleft components.

Linus Torvalds, meanwhile, has posted his own take on the ruling that has, as one might imagine, sparked an extended discussion as well.

Another year has reached its conclusion. That can only mean one thing: the time has come to take a look back at the predictions we made in January and evaluate just how badly they turned out. Much to our surprise, not all of our predictions were entirely accurate. It has been a wild year in the Linux community and beyond, to say the least.

Arnd Bergmann began his 2025 Linux Plumbers Conference session on the future of 32-bit support in the Linux kernel by saying that it was to be a followup to his September talk on the same topic. The focus this time, though, was on the kernel's "high memory" abstraction, and when it could be removed. It seems that the kernel community will need to support 32-bit systems for some time yet, even if it might be possible to remove some functionality, including support for large amounts of memory on those systems, more quickly.

Version 17.1 of the GDB debugger is out. Changes include shadow-stack support, info threads improvements, a number of Python API improvements, and more, including: "Warnings and error messages now start with an emoji (warning sign, or cross mark) if supported by the host charset. Configurable." See the NEWS file for more information.

Version 4.3.0 of the security-oriented Qubes OS distribution has been released. Changes include more recent distribution templates, preloaded disposable virtual machines, and the reintroduction of the Qubes Windows Tools set. See the release notes for more information.

Ian Jackson (along with Sean Whitton) has posted a manifesto and status update to the effect that, since Git repositories have become the preferred method to distribute source, that is how Debian should be distributing its source packages.

Everyone who interacts with Debian source code should be able to do so entirely in git.

That means, more specifically:

1. All examination and edits to the source should be performed via normal git operations.
2. Source code should be transferred and exchanged as git data, not tarballs. git should be the canonical form everywhere.
3. Upstream git histories should be re-published, traceably, as part of formal git releases published by Debian.
4. No-one should have to learn about Debian Source Packages, which are bizarre, and have been obsoleted by modern version control.

This is very ambitious, but we have come a long way!

The 6.19-rc2 kernel prepatch is out for testing. "I obviously expect next week to be even quieter, with people being distracted by the holidays. So let's all enjoy taking a little break, but maybe break the boredom with some early rc testing?"