All posts by corbet

A 0-click exploit chain for the Pixel 9 (Project Zero)

Post Syndicated from corbet original https://lwn.net/Articles/1054547/

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.

[$] Removing a pointer dereference from slab allocations

Post Syndicated from corbet original https://lwn.net/Articles/1053870/

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.

[$] READ_ONCE(), WRITE_ONCE(), but not for Rust

Post Syndicated from corbet original https://lwn.net/Articles/1053142/

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.

[$] GPLv2 and installation requirements

Post Syndicated from corbet original https://lwn.net/Articles/1052842/

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.

[$] LWN.net Weekly Edition for January 8, 2026

Post Syndicated from corbet original https://lwn.net/Articles/1051994/

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.

Google will now only release Android source code twice a year (Android Authority)

Post Syndicated from corbet original https://lwn.net/Articles/1053061/

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.

[$] Predictions for the new year

Post Syndicated from corbet original https://lwn.net/Articles/1052269/

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.

Kernel prepatch 6.19-rc4

Post Syndicated from corbet original https://lwn.net/Articles/1052732/

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).

Kroah-Hartman: Linux kernel security work

Post Syndicated from corbet original https://lwn.net/Articles/1052607/

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.

Graham: [KDE] Highlights from 2025

Post Syndicated from corbet original https://lwn.net/Articles/1052241/

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!

A partial ruling in the Vizio GPL suit

Post Syndicated from corbet original https://lwn.net/Articles/1051984/

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.

[$] A high-memory elimination timeline for the kernel

Post Syndicated from corbet original https://lwn.net/Articles/1051010/

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.

GDB 17.1 released

Post Syndicated from corbet original https://lwn.net/Articles/1051653/

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.

Jackson: Debian’s git transition

Post Syndicated from corbet original https://lwn.net/Articles/1051580/

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!