We cannot fix email delivery, but we can sidestep it entirely. Public-inbox archives like lore.kernel.org store all mailing list traffic in git repositories. In its simplest configuration, korgalore can shallow-clone these repositories directly and upload any new messages straight to your mailbox using the provider's API.
The telnetd server invokes /usr/bin/login (normally running as root) passing the value of the USER environment variable received from the client as the last parameter.If the client supplies a carefully crafted USER environment value being the string "-f root", and passes the telnet(1) -a or --login parameter to send this USER environment to the server, the client will be automatically logged in as root bypassing normal authentication processes.
This brought to a close the Ozlabs association with IBM". Thus ends a quarter-century of development history.
(Thanks to Jon Masters).
So we finally ended up with a slightly bigger rc than usual for this stage in the release cycle, but it's not _that_ big, and things still seem quite stable and civilized."
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.
We are asking that you please let us know you want to be invited by February 20, 2026".
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.
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).
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.
Connexion