Welcome to the LWN.net Weekly Edition for April 9, 2026

This edition contains the following feature content:

• Protecting against TPM interposer attacks: a look into the fiddly world of the TPM and how it can secure systems.
• An API for handling arithmetic overflow: kernel developers make progress toward safer integer operations.
• Ubuntu's GRUBby plans: Canonical's plans to slim down GRUB run into community objections.
• IPC medley: message-queue peeking, io_uring, and bus1: a roundup of recent proposals for interprocess communication (IPC) enhancements in the kernel.
• Ripping CDs and converting audio with fre:ac: building a digital music collection the old-fashioned way.
• Sharing stories on Scuttlebutt: a censorship-resistant, offline-first social-media system.

This week's edition also includes these inner pages:

• Brief items: Brief news items from throughout the community.
• Announcements: Newsletters, conferences, security updates, patches, and more.

Please enjoy this week's edition, and, as always, thank you for supporting LWN.net.

Comments (none posted)

Protecting against TPM interposer attacks

The Trusted Platform Module (TPM) is a widely misunderstood piece of hardware (or firmware) that lives in most x86-based computers. At SCALE 23x in Pasadena, California, James Bottomley gave a presentation on the TPM and the work that he and others have done to enable the Linux kernel to work with it. In particular, he described the problems with interposer attacks, which target the communication between the TPM and the kernel, and what has been added to the kernel to thwart them.

Bottomley introduced himself as a kernel developer and maintainer who worked on containers for around ten years before he joined Microsoft as an open-source evangelist. "I enjoy studying how open-source systems work." That was all just background, he said, because his talk was unrelated to any of that.

The TPM has "suddenly gotten a very bad rap" due to the requirements of Windows 11, "which obviously has nothing to do with me", he said to chuckles around the room. He started looking into TPMs way back in 2011 after the compromise of the kernel-development infrastructure (i.e. kernel.org); part of the early efforts to better protect kernel.org used a hardware authentication device that could only store a single key, which was inconvenient since he had far more keys. He found out that the TPM can be used as a key store; since most laptops already had a TPM, his goal was simply to use the device to store his keys.

So, 16 years later, he came to SCALE to talk about getting the TPM to work with the kernel, but he has also written code for various tools to allow them to use the TPM for their keys. That includes code in the GNU Privacy Guard (GPG) and a provider for OpenSSL to allow them to work with the TPM. He connected the OpenSSL provider to OpenSSH, but the maintainers of that tool rejected the patches because they no longer use OpenSSL in favor of LibreSSL; that library has removed the pieces needed for his patch to work, however.

TPM hardware

The TPM is often a discrete chip that sits on some hardware bus, such as the Low Pin Count (LPC) or I2C bus, in the system. It can also be a firmware TPM, as it is on his Dell XPS laptop, which runs on a separate CPU that is part of the management engine of the system. The firmware TPM communicates with the main CPU using a memory-based mailbox. The US National Security Agency (NSA) has mandated discrete TPMs in order to comply with its standards, so many laptop makers use a discrete chip, he said.

A discrete TPM is often susceptible to simple probing of the bus it sits on, in what is known as an interposer attack. With a small amount of hardware, all of the traffic on the bus can be captured. Since it is an internal bus for the system, and encryption has a cost that seemed like it would be wasted, the traffic is in clear text.

The disclosure of the attack led TPM users to shift their thinking: since the channel to and from the TPM was potentially compromised, sending secrets in clear text did not make sense any longer. The only attack demonstrated so far is a passive interposer, he said, which is easily defeated by encrypting TPM communication. An active interposer could potentially sit in the middle and alter the communication to and from the real TPM; that would allow it to participate in the encryption so it could see the real data. Handling that kind of attack is rather harder.

In order to do encryption, however, a TPM session must be established, which sets up a shared key between the TPM and the user. The encryption mechanism is a complex one, where the session key is "basically a salt where key-derivation functions are applied to nonces that are exchanged on the bus". It is a "really really complicated scheme, but the bottom line is, if you know the session key, you can decrypt the traffic".

TPM sessions were added for all Linux kernel TPM transactions starting with Linux 6.10. That was around two years ago, Bottomley said. He wrote all of that code, which is now a source of complaints because of the overhead introduced by the encryption. TPMs are typically low-powered devices and they are slow to do encryption and decryption, but encryption does protect against a passive interposer.

There is a public key for the TPM that is used in the process of creating the session key; if active interposers are considered, though, there is a problem in obtaining that public key. Most toolkits simply ask the TPM for the key: "How do I know that the public key it gave me is the one I'm supposed to have?"

The TPM-session work that has gone into the kernel is only used when the kernel itself needs to talk to the TPM, so it is the user in that case. If an application, systemd, say, wants to establish an encrypted session, it must do the session startup for itself as the user. In practice, user-space applications use a library known as the trusted software stack (TSS) to talk to the TPM.

There are two main TSS implementations, one by Intel and another by IBM; both simply ask the TPM for its public key. As noted, that would allow an active interposer to present a public key it controls and pass the traffic through to the real TPM, while siphoning off secrets that are being "protected" by the TPM. Application programmers who need to communicate with the TPM are drawn to using a TSS to avoid the "astronomically" difficult TPM programming, but those libraries do not handle this problem correctly—or even alert users that there is a potential problem. There is no verification done to ensure that the public key provided is the right key to use.

There are other interposer problems, as well. "Even a passive interposer just sitting on the LPC bus can actually toggle the TPM's reset line." That can cause problems because one of the jobs of the TPM is to maintain the platform configuration registers (PCRs) that are used to prove that the code that has been run is what is expected, which is important for integrity-checking purposes. The PCRs are meant to be extended with hash values of the code executed, but toggling the reset line sets all of the PCRs back to zero. An attacker who can reset them can then extend them anew by feeding in all of the proper hashes, even though the code in question was not executed, causing an undetectable integrity breach on the system.

Trusting the public key

Developers need to be able to establish trust in a TPM public key, but the established mechanism "is so complicated that no one ever does it", including the TSS libraries. All discrete TPMs ship with a certificate from the manufacturer that validates the Endorsement key (EK), which is resident in the TPM. That X.509 certificate can be validated because it is signed by manufacturer's master certificate authority (CA), so an EK cannot be forged, which provides a TPM key that can be trusted.

Unfortunately, the EK cannot be used to validate any of the other keys in the TPM. Primary keys are generated by the TPM using a key derivation function, which allows it to generate different kinds of keys from its internal seed, but those keys are either encryption or signing keys. The device can only certify objects (e.g. keys) using signing keys, but the EK can only certify encryption keys, so it cannot certify signing keys.

That raises a question: why is there no signing key that can be validated in the way that the EK can be? "Turns out, it's all the FSF's [Free Software Foundation's] fault", Bottomley said. The Trusted Computing Group (TCG), which is the organization behind the TPM standards, "got badly burned by the FSF backlash against something they called 'Treacherous Computing' way back in the early 2000s". The concern was that the TPM would be used to effectively lock users out of being able to do what they want with their computers (e.g. preventing video decryption); "it's all actually untrue, the TPM is too weak [of] an encryption engine to do this, but it was seen as 'the spy in your computer'" by the FSF and others.

The operating system is what governs access to the TPM, he said, "if you own the operating system on your computer, you're the one guarding access to the TPM". There were plans for non-open-source operating systems "to use TPMs for various nefarious purposes", he said, but those plans were rapidly killed by the Treacherous Computing campaign.

To counter the somewhat-misplaced criticism of the TPM as an agent of others in PCs—TPMs cannot communicate at all without operating-system help—the TCG added some privacy-preserving features to the device. One of those was to restrict manufacturers from shipping signing certificates. Because a signing certificate would uniquely identify a particular TPM, thus become a way to track people online via their TPM operations.

Instead, the TCG allows the TPM to create an arbitrary number of signing keys, called Attestation keys (AKs). Each AK can be certified as coming from a particular EK (thus TPM) by way of a new organization called a PrivacyCA. It would be a third-party CA that is trusted by the operating system, user, and whatever entities need to validate objects from the TPM; it would be the only party that is able to make the connections for the tracking, which is why it needs to be trusted.

"The PrivacyCA idea has been around for ten years; none exist today." So it is a system for validating keys on the TPM that is supported by all TPMs but is unusable in practice to thwart the interposer attacks. For his purposes, though, the PrivacyCA would not help; the kernel needs to validate the keys at early boot time and there is no internet available then.

Another possible angle would be for the kernel to use the EK as its encryption key for communicating with the TPM, but it requires the internet to verify the certificate with the manufacturer's CA. If he could collect up all of the root certificates for all of those CAs, they could be used for the verification since the kernel does have code that can validate a chain of X.509 certificates. At the time he was doing the work, there were many possible TPM manufacturers; these days, there are only around three or four, making collecting the root certificates less daunting. But there is still another problem: firmware TPMs, like the one in his laptop, do not have EK certificates at all.

TPM trivia

So, solving the problem for the kernel required a different approach. Describing it required a quick lesson in what Bottomley called "more TPM trivia".

The TPM 2.0 standard has four hierarchies that are aimed at different users of the chip. They are: the platform hierarchy, which is only accessible to the BIOS, the endorsement hierarchy, where the EK is stored but not used otherwise, the owner or storage hierarchy, where TPM-user keys are normally stored, and the NULL hierarchy, which is not normally used. There is an interesting property of the NULL hierarchy, he said, in that its seed is reinitialized every time the TPM is reset. Keys created in that hierarchy are only usable until the next reset, which is fine for short-lived operations like encrypting the TPM traffic during boot. In addition, if an interposer causes a TPM reset during boot, the kernel will detect it because the kernel's encryption to and from the TPM will fail.

The underlying problem of ensuring that the key is legitimate has not gone away, however. There is no straightforward way to ensure that the NULL key is actually from the TPM and not from an interposer. What he has come up with uses the "name" of the NULL key, which is simply a hash of the public portion of the key, so it is a unique ID for the key. That name gets exported in a sysfs file, which can be verified using a more sophisticated mechanism after the kernel boots.

His openssl_tpm2_engine project has a tool, attest_tpm2_primary, that can be used to do that verification. It can create an EK signing key that can then be verified as coming from the EK that corresponds to the certificate that is signed by the manufacturer. The name of that signing key could be stored somewhere read-only as part of the operating-system installation process, because that verification only needs to be done once. Since the owner of the system is the one creating the EK signing key, and it does not matter if they can track themselves, the privacy concerns that the TCG had, thus the need for a PrivacyCA, are not present, Bottomley said.

Threat models

In order for the tool to be trustworthy, the operating system has to be trusted. "The TPM people will tell you that the TPM is the only way of trusting your operating system, but that's not true" as secure boot can provide that validation; he noted that developers from the TPM and secure-boot communities often do not work together well. With unified kernel images (UKIs), secure boot can validate the initrd, as well. Full-disk encryption completes the picture, because the decryption password validates the contents of the filesystem.

So an attack on an unattended laptop (a so-called "evil maid" attack) that installs an interposer can be detected unless the interposer device, "which is a fairly weak thing", can also compromise the kernel enough to impact the TPM validation, he said. The operating system must be trusted in order to validate the TPM. "If somebody steals your laptop and turns off secure boot, substitutes their own kernel that defeats all of this, and manages to get your disk encryption key, it's game over." In addition, unlocking the TPM and its keys based solely on the measured state in the PCRs is dangerous; a second factor (e.g. a PIN) should be required to ensure that the system has not been compromised by operating-system replacement.

Bottomley then demonstrated a virtual machine (VM) that was talking to the IBM software TPM, which is useful for testing, he said. He also started up an active interposer written in Python that sat between the VM and the TPM. The VM was set up to unlock the TPM keys based on the PCR values; he was able to log into the system and see the value for the NULL hierarchy key name. The software TPM has a mechanism to generate a EK certificate, so he could create the EK signing key and its name would have been stored in a file on the encrypted disk at install time. He was able to use attest_tpm2_primary to show that the EK signing key could be validated with the EK certificate and that the NULL hierarchy key name was correct, which validated the boot.

During all of that, the interposer was simply passing the data back and forth, without being able to inspect or modify it because the kernel and TPM were encrypting it. He then changed the disk encryption password using systemd, which uses the storage hierarchy key that it cannot validate using the kernel's mechanism. That allows the interposer to use its own key so that it can see all of the traffic between systemd and the TPM. That means it could display (or modify) the new disk password systemd was using.

There was more to the demo, which was rather complicated as one might expect. The YouTube livestream for the talk starts a few minutes late, but the demo comes nearly 30 minutes in, so interested readers can have a look.

He concluded the talk by noting that the NULL hierarchy provides a means to fully protect the kernel from TPM-reset attacks, and the after-boot verification can prove that the keys from the TPM can be trusted—as long as the kernel and user space are trusted (via secure boot, for example). Any TPM-using tool could use the NULL mechanism and compare the key that the kernel exports to ensure that it is talking to the real TPM, which would provide protection against interposers and reset attacks. Doing that work in each application would be burdensome, Bottomley told me later, so it would make sense to do it in the TSS libraries, though it is not clear if that is on the horizon.

It was an interesting look into the rather fiddly world of the TPM and how it can be used to secure our systems. One guesses that the interposer attack is fairly rare, except possibly against seriously high-value targets, but it is important to be able to defend against it. The kernel can do so, at least on systems with secure boot and UKIs, but user-space tools will want to catch up and Bottomley has shown a possible path to get there.

[Thanks to LWN's travel sponsor, the Linux Foundation, for its travel funding to attend SCALE in Pasadena.]

Comments (4 posted)

An API for handling arithmetic overflow

On March 31, Kees Cook shared a patch set that represents the culmination of more than a year of work toward eliminating the possibility of silent, unintentional integer overflow in the kernel. Linus Torvalds was not pleased with the approach, leading to a detailed discussion about the meaning of "safe" integer operations and the design of APIs for handling integer overflows. Eventually, the developers involved reached a consensus for a different API that should make handling overflow errors in the kernel much less of a hassle.

This work was initially proposed in 2024 as part of Cook's continuing efforts to harden the kernel against various sources of error. In that proposal, he emphasized that the problem with integer overflow in the kernel is not related to undefined behavior — the kernel is compiled with -fno-strict-overflow, which causes integer overflow and underflow to wrap around without error. The problem is with the unexpected code paths that can be taken when a number is suddenly much larger or much smaller than the developer expected. For example, adding an offset to a base address can result in a pointer to a location below the base address, a fact that is easy to overlook when writing buffer-handling code.

Cook's proposed solution to this problem is a system of annotations that separate integers into types depending on whether wrapping is expected or not. Justin Stitt added experimental support for the feature to Clang, in the form of a pair of annotations:

    int __attribute__((overflow_behavior(wrap))) example1;
    int __attribute__((overflow_behavior(trap))) example2;

    // Alternate keyword form:
    int __ob_wrap example1;
    int __ob_trap example2;

The wrap attribute indicates that wrapping is expected (and should, for example, not be remarked upon by linting programs); the trap attribute indicates that it is unexpected (and should cause a crash). In the kernel, it appears that an operation that would cause an overflow of a trapping integer will produce an oops by default. The attributes override compiler flags, so wrapping integers will wrap and trapping integers will trap on overflow, regardless of how the compiler is invoked. Type promotion works in the normal C way; operations involving a normal integer and an annotated integer produce an annotated integer. Operations combining a wrapping integer and a trapping integer produce a trapping integer.

Vincent Mailhol asked about the possibility of adding saturating integers as well. Saturating integers stay at the top or bottom of their range, instead of wrapping, such that MAX_INT + 1 == MAX_INT. Cook agreed that was possible. The overflow_behavior() mechanism should extend to handling other behaviors, although that would result in a proliferation of integer types. Cook's patch set adds a set of typedefs for easily referring to the new types of integer, including "u8t" for trapping unsigned 8-bit integers, "s64w" for wrapping signed 64-bit integers, etc.

Torvalds strongly objected to the way the documentation accompanying the patch set described trapping operations as "safe":

Stop thinking that trapping is "safe".

It damn well isn't. A dead machine is not a safe machine.

Any patches that call trapping behavior safe will be NAK'ed by me.

A later message also objected to the names Cook chose for the typedefs, noting that they were visually similar, which is not a good fit for "VERY subtle semantic changes." He suggested "wrapping_u32" or a similarly explicit name. Miguel Ojeda noted that the Rust syntax for this concept is "Wrapping<u32>", which mirrors Torvald's suggestion. But in practice, Rust code in the Kernel uses explicit function calls (e.g. wrapping_add()) rather than operator overloading, because it prevents confusing copy-paste errors where operators mean different things in context, Ojeda said.

Torvalds thought that it would make sense to use explicit operations like that for arithmetic on trapping integers — which he continued to insist needed some way to make the error recoverable — but thought that it would be overly laborious for wrapping types. He suggested that trapping and wrapping operations should really have completely different syntax, because although they are often discussed together, they're actually quite different: wrapping types are an acknowledgment that a particular behavior is correct and expected, whereas trapping types are a mechanism that deliberately signals an error when something might be going wrong. "Anything that says 'these are two faces of the same coin and are just different attributes on the type' is simply broken by design."

In another follow-up message, he suggested that the interface for trapping integers could use macros to take an error label to jump to, in order to make their use less obnoxious than the kernel's existing overflow-checking functions:

    res = add_overflow(a, b, label);
    ...
    label: // Handle overflow errors
    ...

Cook explained that he had considered an approach like that, but people were so universally against introducing function-based math primitives that they wouldn't accept using them. "Everyone absolutely hates it." Torvalds disagreed, saying that he thought a simple-enough interface would be used when people have a good reason to do so. He gave an example of how the approach he described previously could be extended with a default "overflow" label to further streamline the code. "Now will people ENJOY using 'addo()' and things like that? No." But he still thought that interface was better than randomly killing the kernel when an overflow occurs.

This line of reasoning misses the point, Cook said. All of the places where people would use trapping integers are already supposed to be places where no overflow is possible. So, operations on trapping integers aren't intended to replace existing overflow checks — they're just supposed to make it obvious when a developer has missed an overflow check, because people keep making related mistakes.

If the code was written perfectly, then there's no problem. If there was a bug that allows for overflow then you get a crash instead of totally insane behavior that is almost always exploitable in a way that the system gets compromised. That is a net benefit, even if crashes are still bad.

He did agree that he shouldn't have called trapping a "safe" behavior in the documentation, and promised to fix that. Torvalds replied that using the equivalent of BUG_ON() still wasn't the right way to address the problem.

Cook proposed adding an attribute to the language for specifying a label in a given function where trapping operations should jump; using trapping integer operations outside of an appropriately annotated function would be an error. Torvalds approved of that approach, and spent a while working out precise details of what such an interface would look like with Cook. "So with this kind of interface, all my reservations about it go away."

    int __overflow_label(boom)
    something(...)
    {
        u8 __attribute__((overflow_behavior(trap))) count;
        ...
        // Jumps to 'boom' if the count overflows.
        while (thing()) count++;
        ...
        return 0;
    boom:
        // Cleanup code
        return -EINVAL;
    }

Peter Zijlstra pointed out that, although it worked well for simple examples like the above, this design would cause problems with the __cleanup() macro. It is not permitted to jump into the scope of a stack-allocated object annotated with __cleanup(); the only permitted way to enter that code should be through the assignment to that variable. Having trapping operations jump to a locally defined label makes it easy to invisibly break that rule and accidentally jump into such a scope.

Clang does catch this particular error, Cook demonstrated. GCC doesn't have a similar error message, so that's something that may need to be fixed. Cook did agree that the behavior was "a bit fragile".

With the proposed changes to the API and the documentation, Cook's patch set will have to be more or less rewritten. Stitt's compiler code may need changes as well, and GCC will need to implement a version of whatever Clang settles on. Despite that, having an agreement about the form that the API for trapping integers should take is important progress. It may not be long before the work becomes available, which will provide the opportunity to simplify existing overflow-checking code and to eliminate existing unnoticed overflow bugs.

Comments (none posted)

Ubuntu's GRUBby plans

GNU GRUB 2, mostly just referred to as GRUB these days, is the most widely used boot loader for x86_64 Linux systems. It supports reading from a vast selection of filesystems, handles booting modern systems with UEFI or legacy systems with a BIOS, and even allows users to customize the "splash" image displayed when a system boots. Alas, all of those features come with a price; GRUB has had a parade of security vulnerabilities over the years. To mitigate some of those problems, Ubuntu core developer and Canonical employee Julian Andres Klode has proposed removing a number of features from GRUB in Ubuntu 26.10 to improve GRUB's security profile. His proposal has not been met with universal acclaim; many of the features Klode would like to remove have vocal proponents.

Ubuntu provides two versions of GRUB: one for UEFI systems that enables Secure Boot (referred to as the "signed" builds), and another for systems with legacy BIOS or systems that otherwise don't support Secure Boot (the "unsigned" builds). The unsigned GRUB builds from Ubuntu would continue to have the existing set of features, but Klode is looking to strip quite a bit out of signed GRUB builds; he proposes removing support for reading /boot partitions that use Btrfs, HFS+, XFS, or ZFS filesystems. That would leave ext4, FAT, ISO 9660, and SquashFS. He also wants to disable features to use custom PNG and JPEG splash images, and strip out support for "complex partition setups such as LVM, md-raid (except raid1), and LUKS-encrypted /boot" because those were not tested nor used by the Ubuntu installer.

As for encryption in particular, encryption of /boot only provided security by obscurity, but not actual security. You want to ensure the integrity of those pieces. Our TPM [full-disk encryption (FDE)] solution correctly implements integrity in the early boot stage, and we are committed to keep iterating and improve it.

None of these changes would affect Ubuntu's support for the filesystems in general; users could still have (for example) a Btrfs partition for user data. They simply could not use Btrfs for /boot. The changes are not scheduled for the upcoming long-term-support (LTS) release, 26.04, which is due in April. Thus, he said, affected users (those who want the features being removed) would have the option of staying on an LTS release with the GRUB features for up to ten years.

Klode isn't the first person to decide that GRUB has too much complexity and too many features that pose security problems. For example, GRUB maintainer Marta Lewandowska has advocated getting rid of bootloaders altogether in favor of Unified Kernel Images (UKIs).

Pushback

Dropping features from an upstream application is rarely popular, as Klode no doubt discovered when turning off optional KeePassXC features in the Debian package he maintains. The tactic has proven no more popular with GRUB. Neal Gompa was first in line to object to Klode's plans; specifically, he complained about dropping Btrfs support. He argued that the support was necessary for those who want to use boot-to-snapshot setups. User "haroldw" pointed out that it is unnecessary, and perhaps undesirable, for /boot to be Btrfs-formatted for snapshot support to work: "Grub doesn't respect the default btrfs subvolume settings leading to easy breakage and requiring to modify kernel parameters in grub.cfg." Gompa did not seem to be persuaded, and still wanted to be able to use Btrfs features to resize /boot if desired.

Quite a few people wanted to preserve support for JPEGs and PNGs. Gompa, for example, argued against removing support since some of the Ubuntu flavors use images as part of their branding. Sebastian Schneeland not only objected to removing image support, but wished for an easier way to make a graphical boot menu with friendly labels for each entry. Paddy Landau said that he would be disappointed if Ubuntu removed image support. "I've been seeing my welcoming Ubuntu background when I boot for many years!"

Some suggested ditching GRUB entirely. Andreas Schildbach (and others) asked about switching Ubuntu to systemd-boot instead. "It's the minimal bootloader you're looking for, and it integrates into systemd-based systems well anyway." However, Tobiyo Kuujikai pointed out that systemd-boot only supports UEFI systems. That would likely be a non-starter, since Ubuntu would then need to support not just two different builds of GRUB, but two entirely different boot loaders, which would no doubt require changes in its installer, how it handles kernel updates, and more.

Robie Basak asked for Klode to cite specific security issues that could have been avoided if the change had happened earlier "given that these security issues of the past are the sole motivation for this change". Thomas Ward, a member of Ubuntu's Community Council and its Technical Board, said that Klode's proposal needed further discussion as well as "a deeper explanation of how this is going to improve security for each dropped item". He said that Ubuntu would be alienating the majority of its users and requiring organizations with specific requirements to forgo the use of Secure Boot.

I want to hear the Foundation team's reason for each removal. If you are unable to provide an ample justification for each removal, then the Foundations team needs to not abandon existing feature sets on the basis that "it makes GRUB Signed more bare and thus more secure because there's less open holes for risks".

While Klode did not reply with specific examples, Tobias Heider supplied a list of 11 recent CVEs "that would have been avoided by not shipping drivers that Ubuntu doesn't actually use", including CVE-2024-45774, which affected GRUB's JPEG parser. The flaw could allow an attacker to supply a "specially crafted JPEG" that would cause GRUB to perform an out-of-bounds write, that in turn might allow a Secure Boot bypass.

If you go through the list of CVE search results you will find that there are plenty and often in parts that Ubuntu doesn't actually use or support in any way.

Keep in mind the grub drivers are only ever needed to get to the kernel and initrd files which are on the /boot partition, after that we use the kernel drivers for LUKS and file systems.

Signed, sealed, delivered

Users were also concerned about not having LUKS encryption for the /boot partition, and the impact on full-disk encryption (FDE). There was a fair bit of discussion and disagreement about the need for /boot encryption. Klode's position is that encrypting the partition did little to enhance security; that stance found a number of supporters. Peter White argued that it was more important to validate everything used in the boot process against cryptographic signatures. "The chain of trust doesn't hinge on everything being encrypted, but on everything being validated against cryptographic signatures; it's about integrity/verity rather than confidentiality." Mate Kukri agreed: "The only solution to this issue is the bootloader to actually enforce initrd signing, /boot encryption and even optional initrd signing is a completely inadequate defense."

Klode replied that Canonical had been working to address FDE integrity concerns by making its TPM-backed FDE boot flow available for Ubuntu Desktop in the 26.04 release, though it is not yet available for Ubuntu Server.

Our TPM FDE solution ensures that the initrd is verified at boot time (it is part of a [unified kernel image (UKI)] for now), and more importantly measured, and the unlocking of the root partition is sealed to that measurement, meaning you cannot even replace the initrd with another validly signed one.

Steven Maddox said that Klode's proposal was the opposite of what he was hoping for. GRUB 2.14, which will be included in 26.04, had just added support for the default encryption used with LUKS2; now it would be removed in Ubuntu 26.10. He complained that users would be stuck with unencrypted /boot partitions of a fixed size "where we have to try and forever judge how big they should be for future kernels and such". He also worried about bad actors being able to modify GRUB's configuration files in the unencrypted partition. White replied that bad actors would not get very far "because they can't coerce GRUB2 into opening an initrd that's not the sealed one". Encryption of the /boot partition, he said, was never a sufficient security measure.

Discussion of the proposal continues. Klode's last appearance in the thread, so far, was on March 27, when he replied about the TPM-backed FDE boot flow. It is not clear whether there is any deadline for feedback or whether any of the objections might alter the plans for stripping features out of GRUB signed builds. It will be interesting to see if any other Linux distributions consider following suit, or if Ubuntu will be alone in trying to streamline GRUB for security reasons.

Comments (75 posted)

IPC medley: message-queue peeking, io_uring, and bus1

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.

Peeking at message queues

The POSIX message-queue API is not heavily used, but there are users out there who care about how well it works. Message queues are named objects that, by default, all share a global namespace, though IPC namespaces can be used to separate them. There is a whole set of system calls for the creation, configuration, use, and destruction of message queues; see the mq_overview man page for an introduction to this subsystem.

Of interest here is mq_timedreceive(), which can be used to receive messages from a message queue:

    ssize_t mq_timedreceive(size_t msg_len;
                            mqd_t mqdes, char  msg_ptr[msg_len],
                            size_t msg_len, unsigned int *msg_prio,
                            const struct timespec  abs_timeout);

This call will receive the highest-priority message pending in the queue described by mqdes (which is a file descriptor on Linux systems) into the buffer pointed to by msg_ptr, which must be at least msg_len bytes in length. If abs_timeout is not null, it specifies how long the call should block before returning a timeout error. On successful receipt of a message, the location pointed to by msg_prio (if non-null) will be set to the priority of the received message.

That system call has a fair number of parameters, but Mathura Kumar would like to add some more. Since mq_timedreceive() was not designed for extensibility, that means adding a new system call. Thus, Kumar's patch set adding mq_timedreceive2(). But there is an additional constraint here: there are architecture-imposed limits on the number of arguments that can be passed to system calls, and Kumar's plans would exceed those limits. As a result, the new system call is defined as:

    struct mq_timedreceive2_args {
        size_t         msg_len;
        unsigned int  *msg_prio;
        char          *msg_ptr;
    };

    ssize_t mq_timedreceive2(mqd_t mqdes,
                             struct mq_timedreceive2_args *uargs,
                             unsigned int flags,
                             unsigned long index,
                             const struct timespec *abs_timeout);

The msg_len, msg_prio, and msg_ptr arguments have been moved into the new mq_timedreceive2_args structure, freeing up two slots for new parameters to the system call. That structure is passed by pointer, without using the common pattern of passing its length, which would make future additions easier; that may change if this patch series moves forward.

The new arguments are flags and index. In this series, only one flag (MQ_PEEK) is defined; if it is present, the message will be returned as usual, but without removing it from the queue, meaning that it will still be there the next time a receive operation is performed. The index argument indicates which message is of interest; a value of zero will return the highest-priority message, and higher values will return messages further back in the queue.

There are a few use cases for these features described in the patch cover letter. One would be monitoring tools, which may want to look at the message traffic without interfering with it. Another one is Checkpoint/Restore in Userspace, which can read a series of messages out of a queue, then restore them with the rest of the process at a future time.

The series as a whole has not received much attention so far, which is perhaps unsurprising given that few developers have much interest in POSIX message queues. If this work is to proceed, it will need to attract some reviews, and probably go through some more rounds to address the problems that are found.

IPC in io_uring

Since its inception, the io_uring subsystem has steadily gained functionality. After having started as the asynchronous I/O mechanism that Linux has long lacked, it has evolved into a separate system-call interface providing access to increasing amounts of kernel functionality. While io_uring can be used for interprocess communication (by way of Unix-domain sockets, for example), it has not yet acquired its own IPC scheme. This patch series from Daniel Hodges seeks to change that situation, but it probably needs a fair amount of work to get there.

Hodges's goal is to provide a high-bandwidth IPC mechanism, similar to D-Bus, that will perform well on large systems. By using shared ring buffers, processes should be able to communicate with minimal copying of data. It is worth noting that other developers have attempted to solve this problem over the years, generally without success; see, for example, the sad story of kdbus. Hope springs eternal, though, and perhaps io_uring is the platform upon which a successful solution can be built.

There are facilities for direct and broadcast messages. Communication is done through "channels"; it all starts when one process issues at least one IORING_REGISTER_IPC_CHANNEL_CREATE operation to establish an open channel. Other processes can attach to existing channels if the permissions allow. Two basic operations, IORING_OP_IPC_SEND and IORING_OP_IPC_RECV, are used to send and receive messages, respectively. There is no documentation, naturally, but interested readers can look at this patch containing a set of self-tests that exercise the new features.

The io_uring maintainer, Jens Axboe, quickly noticed that the patch showed signs of LLM-assisted creation, something that Hodges owned up to. He also noted that the series falls short of being a complete D-Bus replacement, lacking features like credential management. Still Axboe agreed that an IPC feature for io_uring "makes sense to do" and seemed happy with the overall design of the code. Some questions he asked though, went unanswered. For this work to proceed, Hodges will need to return and do the hard work to bring a proof-of-concept patch up to the level needed for integration into a core subsystem like io_uring.

Bus1 returns

Back in 2016, David Herrmann Rheinsberg proposed a new kernel subsystem called "bus1", which would provide kernel-mediated interprocess communication along the lines of D-Bus. It allowed the passing of messages, but also of capabilities, represented by bus1 handles and open file descriptors. The proposal attracted some attention, and brought some interesting ideas (see the above-linked article for details), but stalled fairly quickly and was never seriously considered for merging into the mainline kernel.

Ten years later, bus1 is back, posted this time by David Rheinsberg. The code has seen a few changes in the intervening decade:

The biggest change is that we stripped everything down to the basics and reimplemented the module in Rust. It is a delight not having to worry about refcount ownership and object lifetimes, but at the cost of a C<->Rust bridge that brings some challenges.

The core features of bus1 remain similar to what was proposed in 2016. For the time being, Rheinsberg is focusing on the Rust aspects of the work and requesting help from the Rust for Linux community to get that integration into better shape.

At some future time, presumably, the new bus1 implementation will be more widely exposed within the kernel community, at which point we will see if there is an appetite for this kind of in-kernel IPC mechanism or not. For those who would like an early look, this patch contains documentation on how the bus1 API will work, though with a number of details left unspecified.

[Editor's note: we originally missed that David had changed his name. Apologies for the error.]

Comments (20 posted)

Ripping CDs and converting audio with fre:ac

It has been a little while since LWN last surveyed tools for managing a digital music collection. In the intervening decades, many Linux users have moved on to music streaming services, found them wanting, and are looking to curate their own collection once again. There are plenty of choices when it comes to ripping, managing, and playing digital audio; so many, in fact, that it can be a bit daunting. After years of tinkering, I've found a few tools that work well for managing my digital library: the first I'd like to cover is the fre:ac free audio encoder for ripping music from CDs and converting between audio formats.

Building a music library starts with acquiring music rather than renting it; when I decided to ditch my Spotify subscription a few years ago, I already had a sizable CD collection that I'd started accumulating in the late 1980s. Unfortunately, I had been haphazard about converting to digital formats; some of it was ripped to MP3, some to FLAC, and I had not yet gotten around to digitizing hundreds of CDs. The metadata for what I had converted was a mess. It was time to standardize things and get serious about archiving everything in a digital format.

Step one was to pick the format or formats of choice; I settled on FLAC as the lossless format of choice for long-term archiving, and MP3 as a lossy-but-acceptable format to be stored on my laptop and copied over to my media player. I have a hardware player that reads from Micro SD cards rather than keeping my collection on my phone; it's quite impressive how compact storage has become over the years, and it's nice to have 128GB cards to work with rather than the paltry 6GB of storage my first MP3 player (a Creative Nomad 2) had.

No doubt some folks will wonder "why not Ogg?" That is a fair question. The primary reason is that I often share music files with family members who do not have Ogg-compatible devices. Standardizing on MP3 means that I could buy a dirt-cheap music player for my daughter and populate a few Micro SD cards with playlists without worrying about compatibility. MP3, despite its warts, is universally supported but Ogg support is not guaranteed.

fre:ac

Step two is, of course, ripping the CDs. There are countless Linux applications for extracting audio from CDs. After sampling many of these I've settled on fre:ac because it serves as a one-stop shop for ripping CDs and converting audio. None of its features are unique to fre:ac, of course, but it's rare to find them all collected in a single tool that offers (for me, anyway) the right mix of features, customization, and ease of use. For example, many rippers will convert audio from a CD to Flac, MP3, Ogg, or other formats; fewer have the ability, as fre:ac offers, to convert to multiple formats in a single run, and write the appropriate metadata for each.

Fre:ac is a multi-platform application; builds are available for Linux, FreeBSD, Haiku, macOS, and Windows. The project offers official Flatpak and Snap builds, in addition to AppImage builds for x86_64, 32-bit x86, as well as 32-bit and 64-bit Arm. It is licensed under the GPLv2, and uses a custom component framework to provide an interface to the encoders, decoders, taggers, and other applications fre:ac uses, such as LAME for MP3 encoding, libcdio to decode CDs, and many others. Fre:ac smoothes over the complexity of using the various libraries and command-line tools while stitching together the chain of utilities that extract audio, convert it to the desired format, and so forth.

The project began in the early 2000s under the name "BonkEnc", and was renamed in 2010. Fre:ac is mostly a one-person operation; its maintainer, Robert Kausch, is responsible for the vast majority of commits to its repository. There are 16 other contributors, all of whom have made fewer than 30 commits. He is actively developing fre:ac, but formal releases are few and far between: the most recent, 1.1.7, was announced in March 2023. However, the project also provides a set of continuous builds that track current development. In September 2025, Kausch said that a 1.1.8 release is in the works, but he couldn't say when it would be finished. At least for my purposes, this is fine—fre:ac is a mature program that does not really need much in the way of new features. It only needs to be maintained so that it continues to work as various libraries and helper programs are updated.

Settings

Using fre:ac is straightforward; the first order of business is to set the encoder to be used when converting a set of files or ripping from CD. The available encoders vary by platform; Linux versions of fre:ac include FFmpeg, LAME, Xiph's FLAC encoder, and quite a few others. The multi-encoder hub (meh!) component allows users to select two or more encoders to be used in the same processing run; so, for example, meh! can be used for converting a CD to FLAC and MP3 in one go. Fre:ac has sensible defaults for encoders, but it's also possible to set encoder options, such as the bit rate for MP3s, manually.

In addition to the encoder, users can choose from an assortment of filters for signal processing, such as the volume adjustment component to raise or lower the default volume of an encoded file. This might be useful, for example, when converting CDs that are victims of the loudness war. I've noticed a distinct difference in the loudness of CDs purchased in the 1980s and early 1990s versus more recent releases, but don't take my word for it; there is a Dynamic Range Database online with information about more than 190,000 releases. Each entry has a rating on its dynamic range; CDs with a higher score are more likely to sound better, at least as a representation of the recorded music. Reducing the volume won't improve the dynamic range of an album, but it can help to ensure that tracks from different albums play at the same relative volume; it can be annoying when creating a playlist and some tracks are markedly quieter or louder than the rest.

ReplayGain is a standard that is designed to normalize loudness for audio formats. Unfortunately, fre:ac does not have support for adding ReplayGain tags at this time. Kausch has said that he plans to add support at some point, but he couldn't commit to when it would be available.

Users will also want to pay a visit to fre:ac's settings (Options -> General Settings) to configure its other CD-ripping options, such as the output filename pattern, the CDDB source for album metadata (Gnudb by default), and the metadata tag formats. Assuming fre:ac finds CDDB data for a CD, it uses the metadata to populate the output filename; for example, I use the following structure when creating new files:

    The Cure/(2024) Songs of a Lost World/01-Alone.mp3

That is, the artist or band name, the year the album was released (in parentheses) and its title, the track number, title of the song, and the extension for the audio format (e.g. mp3). If fre:ac does not find metadata for a CD in Gnudb, which is extremely rare in my experience, it can be added manually before converting audio or added later with a tag editor such as Kid3 or MusicBrainz Picard.

Fre:ac also supports saving multiple configurations, so it's possible to have a configuration for ripping CDs, another for converting FLAC to MP3, and yet another for adjusting the loudness of audio from badly mastered CDs.

Ripping and converting

After configuring fre:ac, it's time to put it to the test. Users can add a CD and/or audio files with the File menu or toolbar icons; fre:ac even allows adding all files by filename pattern (e.g., "*flac") throughout a set of folders. This makes it quite convenient for converting an existing collection in one format to another. In addition to handling the format conversion, fre:ac will translate the metadata from one format to another so the collection does not need to be re-tagged.

After tracks are added to be processed, they will show up in the "Joblist" tab. The tags that will be added to the files are shown in the "Tags" tab; these can be edited before conversion if any of the metadata is wrong or missing. When ripping CDs, I find that a lot of the metadata pulled from Gnudb is mostly accurate, but I often disagree with the genre and the artist metadata often needs tweaking as well. This is not helped by bands that variously style the "and" in their name across releases as "and", "&" and "'N". Once all is well with the metadata, it's time to start the encoding process.

When converting CDs, fre:ac will attempt to verify the checksums of the ripped audio against the AccurateRip database, which houses checksum values for millions of CDs. If there is a mismatch, fre:ac will throw an error with a list of tracks that have a bad checksum. Note that it is possible that the conversion is fine and that the checksums do not match because it's a different version of the same album. Fre:ac also has a "Logs" tab where, as the name implies, it writes out the log of its operations, which displays the file checksums, if they were successfully verified, and how long each operation took.

Overall, I've found fre:ac to be a reliable workhorse for digitizing CDs and converting audio files. The only real downside I've encountered with fre:ac is its documentation. The basics of its operation are self-explanatory or easily uncovered with a bit of poking around. However, there are features that would benefit from documentation, such as what each filter does and suggestions for best results, but fre:ac's documentation is sparse and dated. The project does have a GitHub discussion forum, though a number of questions remain unanswered after quite some time. Trial and error is, currently, the best way to learn its ins and outs.

Comments (36 posted)

Sharing stories on Scuttlebutt

Not many people live on sailboats. Things may be better these days, but back in 2014 sailboat dwellers had to contend with lag-prone, intermittent, low-bandwidth internet connections. Dominic Tarr decided to fix the problem of keeping up with his friends by developing a delay-tolerant, fully distributed social-media protocol called Scuttlebutt. Nearly twelve years later, the protocol has gained a number of users who have their own, non-sailboat-related reasons to prefer a censorship-resistant, offline-first social-media system.

In Scuttlebutt, each person has an append-only log of information where each entry is signed with their private key; this log contains both data (such as social-media posts) and metadata (such as information on who is following whom). Since each entry in the log is signed, it doesn't matter by what route those entries reach interested recipients. When two computers running software that supports Scuttlebutt connect to each other, they exchange a list of which feeds they are interested in, and then share any entries that one has that the other doesn't. This is a straightforward example of a gossip protocol, and it provides a simple foundation for higher-level social-media applications.

Since each person's logs are separate, there is no need for a global consensus algorithm — it is normal and expected for each participant in the network to have a different view of what is going on. In fact, there is no central registry of protocol participants. Instead, people add their friends' feeds directly, and then organically discover other people by seeing who their friends interact with. By default, many Scuttlebutt clients will replicate the feeds of anyone within two degrees of separation: direct friends, and friends of friends. If a friend interacts with the post of someone more distant than that (replying to it, or just reacting to it with an emoji), most clients will display the unknown post as a button that adds the unknown post's feed to the set of feeds to follow.

Connections between computers can be made locally (typically announced over local WiFi via mDNS), or via relay servers on the internet called "rooms". This ensures that two people can keep in touch as long as they have some regular contact — meeting up in person, being online at the same time, or just having a mutual friend who meets those criteria. There is also a related project, tinySSB, that operates over LoRa radio with much smaller packet sizes and longer range. Either way, it's difficult to say how many people are using Scuttlebutt on a regular basis since the connections are formed opportunistically and the replication distance of feeds is limited. There is no such thing as a message that will propagate to the network as a whole.

The underlying network communication behind Scuttlebutt is relatively simple; it's an agreed set of binary formats for establishing connections, exchanging information on what feeds each participant is interested in, and then exchanging signed log entries. Since the underlying protocol is so simple, there are a number of implementations for users to choose from. Several of these also agree on the storage format for data at rest, allowing users to seamlessly switch between them. In addition to the expected social-media applications, there are also programs that use Scuttlebutt as a transport layer for Git, for sharing JavaScript packages, for sharing recipes, and for playing chess.

Below is a screenshot of one of the more popular clients, Manyverse, showing the friends-of-friends feed. The feed can be filtered and searched in various ways, but defaults to showing all posts the client is aware of in reverse chronological order. The other tabs on the left show private (encrypted) messages, interactions with one's own posts, and what other Scuttlebutt clients are currently connected (directly or via a relay), respectively.

Since getting connected to Scuttlebutt requires starting with a friend's feed, it can be difficult to join in. The historical solution to this has been "pubs" — automated servers that do nothing but automatically follow your feed if you ask them to. There are a handful of public ones available. Following a pub's feed lets people new to the network see what is going on generally, and lets their own posts be visible to other people. In that sense, a pub can serve much the same role as a local Mastodon server by allowing people to connect to a specific existing community with a general theme. But, due to the nature of the internet, that also puts the burden of moderation on a pub's operator, to some extent. More generally, pubs run somewhat counter to the idea of a decentralized network to begin with, by creating a point of failure for people trying to join the network.

Over time, the Scuttlebutt community has recommended moving away from pubs and toward rooms, which just act as a traffic relay and not a part of the social graph. Rooms do allow people to see who else is online simultaneously (identified by public key, since without replicating their feed there is no metadata such as username available). So, one approach to joining the network is connecting to a chosen public room, looking at the posts of the random people who happen to be online, and deciding to follow some subset of them. Getting one's own posts out there still requires using a pub, contacting someone out-of-band, or being randomly chanced upon in a room. Another approach is to meet people in person and exchange Scuttlebutt feeds. Because users are free to curate their own lists of interesting people and ignore everyone else, spam is not too much of a problem.

The internet being what it is, however, the system does need some safeguards. In a centralized system, there can be a specific team responsible for moderation. In a distributed setting, that becomes a lot harder. For one thing, not all users of the protocol will agree on what content needs moderation. For another, the lack of a global consensus algorithm means that even if there were some group that agreed on moderation, there is no way that they could apply that decision to the whole network — by design.

The system that the Scuttlebutt ecosystem has settled on is based on blocking specific people and propagating those blocks. Anyone can simply decline to replicate a specific feed that they don't want to share, and by recording that decision in their own feed in a machine-readable way, it can propagate out to their friends who trust their judgment. That way a particular friend group only needs to block a troublesome source of spam or abuse once, instead of once per person. This isn't perfect — it essentially requires everyone to do a little moderation work for their friends — but it's the best solution available at the moment. The Scuttlebutt community has done some research into alternate approaches, such as distributed reputation systems, but none are in wide use.

If the experience of using Scuttlebutt were to be summarized in one word, that word would be "slow". Not in the sense that the applications are unresponsive, but in the sense that getting set up as part of the community takes a certain amount of time and attention. Following a new friend means synchronizing their feed and any new friends-of-friends, which in turn requires fetching their entire history of posts. Media, such as photos and videos, is stored and shared out-of-band, so this isn't as much data as it could be, but it still takes minutes to hours, depending on volume and internet connection quality.

When new posts are made, they also don't propagate instantly. It's entirely possible, and reasonably common, for someone to read their friends' posts, write lengthy replies, share a picture of some isolated location, all offline. When they reconnect, it results in a sudden flurry of activity. That style of interaction tends to encourage asynchronous, long-form exchanges — although of course there are still plenty of people who post short, microblogging-style messages as well.

There are many federated social-media platforms; fully distributed systems are much rarer because of the real challenges introduced by not having a global consensus or feed. On the other hand, given the toxicity of modern social media, maybe having software that focuses on individual relationships and eschews the idea of requiring people to stay constantly connected to participate in online discussions is a good thing. Interested readers should refer to Scuttlebutt's documentation on getting started.

Comments (43 posted)

Hackers breached the European Commission (The Next Web)

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.

Comments (6 posted)

Nix privilege escalation security advisory

The NixOS project has announced a critical vulnerability in many versions of the Nix package manager's daemon. The flaw was introduced as part of a fix for a prior vulnerability in 2024. According to the advisory, all default configurations of NixOS and systems building untrusted derivations are impacted.

A bug in the fix for CVE-2024-27297 allowed for arbitrary overwrites of files writable by the Nix process orchestrating the builds (typically the Nix daemon running as root in multi-user installations) by following symlinks during fixed-output derivation output registration. This affects sandboxed Linux builds - sandboxed macOS builds are unaffected. The location of the temporary output used for the output copy was located inside the build chroot. A symlink, pointing to an arbitrary location in the filesystem, could be created by the derivation builder at that path. During output registration, the Nix process (running in the host mount namespace) would follow that symlink and overwrite the destination with the derivation's output contents.

In multi-user installations, this allows all users able to submit builds to the Nix daemon (allowed-users - defaulting to all users) to gain root privileges by modifying sensitive files.

Comments (2 posted)

OpenSSH 10.3 released

OpenSSH 10.3 has been released. Among the many changes in this release are a security fix to address late validation of metacharacters in user names, removal of bug compatibility for SSH implementations that do not support rekeying, and a fix to ensure that scp clears setuid/setgid bits from downloaded files when operating as root in legacy (-O) mode. See the release announcement for a full list of new features, bug fixes, and potentially incompatible changes.

Comments (none posted)

Security quote of the week

It is sad to me that zero trust can be put in people as my only objective is to create useful things with code but it seems like the world is strongly against that with someone trying to steal / exploit something at every corner. my countries philosphy is "Ubuntu" - "I am because we are" or "humanity towards others" i hope that more can embrace that in the future.

— Jason Saayman (maintainer of Axios).

Imagine that every week for twenty years, people message you asking you to comment on the latest wolf sighting, and every week you have to tell them: I haven’t seen a wolf, I haven’t heard a wolf, I believe wolves exist but I don’t yet see evidence of them anywhere near our town.

Then one evening, you hear a howl in the distance, and sure enough, on a hill overlooking the town is the clear silhouette of a large wolf. So you point to it — and all the same people laugh and accuse you of “crying wolf.”

Now you know how it’s been for me with cryptographically relevant quantum computing.

— Scott Aaronson (quantum computing researcher)

Comments (none posted)

Kernel release status

The current development kernel is 7.0-rc7, released on April 5. Linus proclaimed: "Things look set for a final release next weekend, but please keep testing. The Easter bunny is watching".

As of -rc7, the 7.0 development cycle has brought in exactly 14,000 non-merge changesets from a record-breaking 2,314 developers. The release history looks like:

RC	Date	Commits
v7.0-rc1	2026-02-22	12468	12468
v7.0-rc2	2026-03-01	434	434
v7.0-rc3	2026-03-08	537	537
v7.0-rc4	2026-03-15	544	544
v7.0-rc5	2026-03-22	391	391
v7.0-rc6	2026-03-29	517	517
v7.0-rc7	2026-04-05	417	417

See the (subscriber-only) KSDB 7.0 page for lots more information.

Stable updates: the 6.19.11, 6.18.21, 6.12.80, and 6.6.131 updates were released on April 2, followed a few milliseconds later by 6.6.132 containing a build fix. 6.6.133 came out on April 6 with another regression fix.

Comments (none posted)

Exelbierd: What's actually in a Sashiko review?

Brian "bex" Exelbierd has published a blog post exploring follow-up questions raised by the recent debate about the use of the LLM-based review tool Sashiko in the memory-management subsystem. His main finding is that Sashiko reviews are bi-modal with regards to whether they contain reports about code not directly changed by the patch set — most do not, but the ones that do often have several such comments.

Hypothesis 1: Reviewers are getting told about bugs they didn't create. Sashiko's review protocol explicitly instructs the LLM to read surrounding code, not just the diff. That's good review practice — but it means the tool might flag pre-existing bugs in code the patch author merely touched, putting those problems in their inbox.

Hypothesis 2: The same pre-existing bugs surface repeatedly. If a known issue in a subsystem doesn't get fixed between review runs, every patch touching nearby code could trigger the same finding. That would create a steady drip of duplicate noise across the mailing list.

I pulled data from Sashiko's public API and tested both.

Comments (4 posted)

Introducing the FreeBSD laptop integration testing project

Recently, the FreeBSD Foundation has been making progress on improving the operating system's support for modern laptop hardware. The foundation is now looking to expand testing to encompass a wider range of hardware; it has announced a laptop integration testing project to allow the community to easily test FreeBSD's compatibility with laptops and submit the results.

With limited access to testing systems, there's only so much we can do! We hope to work together with volunteers from the community who want FreeBSD to work well on their laptops.

While we expect device hardware and software enumeration to be a fully automated process, we feel that manually-submitted comments about personal experience with FreeBSD are equally valuable. We plan to highlight this commentary on our "matrix of compatibility" webpage for each tested laptop.

We are striving to make it as easy as possible to submit your results. You won't have to worry about environment setup, submission formatting, or any repo-specific details!

See the project repository and testing instructions for more.

Comments (none posted)

No kidding: Gentoo GNU/Hurd

On April 1, the Gentoo Linux project published a blog post announcing that it was switching to GNU Hurd as its primary kernel as an April Fool's joke. While that is not true, the project has followed up with an announcement of a new Gentoo port to the Hurd:

Our crack team has been working hard to port Gentoo to the Hurd and can now share that they've succeeded, though it remains still in a heavily experimental stage. You can try Gentoo GNU/Hurd using a pre-prepared disk image. The easiest way to do this is with QEMU [...]

We have developed scripts to build this image locally and conveniently work on further development of the Hurd port. Release media like stages and automated image builds are future goals, as is feature parity on x86-64. Further contributions are welcome, encouraged, and needed. Be patient, expect to get your hands dirty, anticipate breakage, and have fun!

Oh, and Gentoo GNU/Hurd also works on real hardware!

Text for the April Fool's post is available at the bottom of the real announcement.

Comments (28 posted)

SFC: What the FCC router ban means for FOSS

Denver Gingerich of the Software Freedom Conservancy (SFC) has published an article on the impact of the ban on the sale of all new home routers not made in the United States issued by the Federal Communications Commission (FCC). The SFC, of course, is the organization behind the OpenWrt One router.

Since software updates to already-FCC-approved devices do not require a new FCC approval, it appears the FCC is trying to move beyond its usual authorization procedures to restrict what manufacturers are allowed to push to existing routers. However, the FCC notably does not restrict software changes made by owners of routers in the U.S. In particular, there is no indication that updates people make to their own routers, using software they have sourced themselves, would run afoul of any past or present FCC rule.

As a result, we do not believe that this new FCC decision affects whether and how people can run OpenWrt or other user-selected firmware updates on routers they have already purchased. Not only is this an important right in relation to our ownership and control of our own devices, it also ensures that people can keep their routers secure for far longer than the manufacturer may choose to provide security updates, by allowing them to install up-to-date community software that supports routers for 10, 15, or even more years after their initial release date, as OpenWrt does for many devices.

He also notes that, as the OpenWrt One is already FCC-approved, there should be no impact on its availability in the US. The SFC has asked the FCC for clarification and plans to provide updates when they receive a reply.

Comments (none posted)

Development quote of the week

All I'm actually saying here is that (waves broadly) a lot more people who have never opened a PR or maintained a project being in a position to either open a PR or maintaining a project is going to result in them not behaving within the social norms we've developed as a group that is, to be fair, far less insular than in the 90s but is still somewhat insular compared to society as a whole and yes we are going to have to get used to the equivalent of HTML mail and top posting

— Matthew Garrett

Comments (none posted)

CFP Deadlines: April 9, 2026 to June 8, 2026

The following listing of CFP deadlines is taken from the LWN.net CFP Calendar.

Deadline	Event Dates	Event	Location
April 15	May 4 May 11	MiniDebConf Hamburg 2026	Hamburg, Germany
April 20	July 13 July 19	DebCamp 26	Santa Fe, Argentina
April 23	October 5 October 7	Linux Plumbers Conference 2026	Prague, Czechia
April 30	September 29 September 30	devopsdays Berlin 2026	Berlin, Germany
May 25	July 20 July 25	DebConf 26	Santa Fe, Argentina
May 31	October 1	Open Tech Day | Software-defined Storage	Nuremberg, Germany

If the CFP deadline for your event does not appear here, please tell us about it.

Events: April 9, 2026 to June 8, 2026

The following event listing is taken from the LWN.net Calendar.

Date(s)	Event	Location
April 10 April 11	Grazer Linuxtage	Graz, Austria
April 20 April 21	SambaXP	Göttingen, Germany
April 23	OpenSUSE Open Developers Summit	Prague, Czech Republic
April 25 April 26	Sesja Linuksowa (Linux Session)	Wrocław, Poland
April 27 April 28	foss-north	Gothenburg, Sweden
April 28 April 29	stackconf 2026	Munich, Germany
April 29 May 1	Linaro Connect Madrid 2026	Madrid, Spain
May 2	22nd Linux Infotag Augsburg	Augsburg, Germany
May 4 May 6	Linux Storage, Filesystem, Memory Management and BPF Summit	Zagreb, Croatia
May 4 May 11	MiniDebConf Hamburg 2026	Hamburg, Germany
May 15 May 17	PyCon US	Long Beach, California, US
May 16 May 17	Lomiri Tech Meeting	Tilburg, The Netherlands
May 18 May 20	Open Source Summit North America	Minneapolis, Minnesota, US
May 18 May 23	RustWeek 2026	Utrecht, Netherlands
May 21 May 22	Linux Security Summit North America	Minneapolis, Minnesota, US
May 23 May 24	Curl up	Prague, Czechia
May 26	Media Summit	Nice, France
May 27 May 28	Embedded Recipes	Nice, France
May 29	Yocto Project Developer Day	Nice, France
May 29	libcamera workshop	Nice, France
May 30 May 31	Journées du Logiciel Libre 2026	Lyon, France
June 6	Hong Kong Open Source Conference	Hong Kong

If your event does not appear here, please tell us about it.

Alert summary April 2, 2026 to April 8, 2026

Dist.	ID	Release	Package	Date
AlmaLinux	ALSA-2026:6622	10	crun	2026-04-06
AlmaLinux	ALSA-2026:6621	9	crun	2026-04-06
AlmaLinux	ALSA-2026:6005	8	freerdp	2026-04-03
AlmaLinux	ALSA-2026:6340	9	freerdp	2026-04-02
AlmaLinux	ALSA-2026:6344	10	grafana	2026-04-03
AlmaLinux	ALSA-2026:6382	9	grafana	2026-04-02
AlmaLinux	ALSA-2026:6388	10	grafana-pcp	2026-04-03
AlmaLinux	ALSA-2026:6259	10	gstreamer1-plugins-bad-free, gstreamer1-plugins-base, gstreamer1-plugins-good, and gstreamer1-plugins-ugly-free	2026-04-03
AlmaLinux	ALSA-2026:6300	9	gstreamer1-plugins-bad-free, gstreamer1-plugins-base, gstreamer1-plugins-good, and gstreamer1-plugins-ugly-free	2026-04-03
AlmaLinux	ALSA-2026:6053	10	kernel	2026-04-03
AlmaLinux	ALSA-2026:6571	8	kernel	2026-04-06
AlmaLinux	ALSA-2026:6153	9	kernel	2026-04-02
AlmaLinux	ALSA-2026:6572	8	kernel-rt	2026-04-06
AlmaLinux	ALSA-2026:6445	8	libpng12	2026-04-03
AlmaLinux	ALSA-2026:6439	8	libpng15	2026-04-03
AlmaLinux	ALSA-2026:6470	8	perl-YAML-Syck	2026-04-03
AlmaLinux	ALSA-2026:6473	8	python3	2026-04-03
AlmaLinux	ALSA-2026:6286	9	python3.11	2026-04-01
AlmaLinux	ALSA-2026:6256	10	python3.12	2026-04-01
AlmaLinux	ALSA-2026:6436	8	rsync	2026-04-03
AlmaLinux	ALSA-2026:6390	9	rsync	2026-04-02
AlmaLinux	ALSA-2026:6301	9	squid	2026-04-01
AlmaLinux	ALSA-2026:6342	10	thunderbird	2026-04-01
AlmaLinux	ALSA-2026:6188	9	thunderbird	2026-04-02
Debian	DSA-6192-1	stable	chromium	2026-04-03
Debian	DSA-6197-1	stable	dovecot	2026-04-05
Debian	DSA-6197-2	stable	dovecot	2026-04-06
Debian	DSA-6190-1	stable	gst-plugins-bad1.0	2026-04-01
Debian	DSA-6191-1	stable	gst-plugins-ugly1.0	2026-04-01
Debian	DSA-6193-1	stable	inetutils	2026-04-03
Debian	DLA-4521-1	LTS	libpng1.6	2026-04-02
Debian	DLA-4522-1	LTS	libxml-parser-perl	2026-04-04
Debian	DSA-6201-1	stable	openssl	2026-04-07
Debian	DSA-6194-1	stable	pyasn1	2026-04-03
Debian	DSA-6195-1	stable	python-tornado	2026-04-03
Debian	DSA-6196-1	stable	roundcube	2026-04-04
Debian	DSA-6200-1	stable	tor	2026-04-05
Debian	DSA-6199-1	stable	trafficserver	2026-04-05
Debian	DSA-6198-1	stable	valkey	2026-04-05
Fedora	FEDORA-2026-bcc66a29da	F42	bind9-next	2026-04-03
Fedora	FEDORA-2026-a6efefa854	F43	bind9-next	2026-04-03
Fedora	FEDORA-2026-b4d393799a	F42	bpfman	2026-04-02
Fedora	FEDORA-2026-d62d7fe77e	F43	bpfman	2026-04-02
Fedora	FEDORA-2026-9cc418c23e	F43	calibre	2026-04-07
Fedora	FEDORA-2026-bdd01d79ba	F43	chromium	2026-04-04
Fedora	FEDORA-2026-31c619152e	F42	cmake	2026-04-03
Fedora	FEDORA-2026-ee4ff58256	F43	corosync	2026-04-08
Fedora	FEDORA-2026-4747ff73a3	F43	crun	2026-04-02
Fedora	FEDORA-2026-627f2db2b7	F42	domoticz	2026-04-04
Fedora	FEDORA-2026-45d8852ca3	F43	domoticz	2026-04-04
Fedora	FEDORA-2026-07418a381f	F42	freerdp	2026-04-03
Fedora	FEDORA-2026-6ea5f04bb9	F42	giflib	2026-04-06
Fedora	FEDORA-2026-409856189a	F43	gnome-remote-desktop	2026-04-02
Fedora	FEDORA-2026-a45f438402	F43	goose	2026-04-08
Fedora	FEDORA-2026-5e16254ca6	F42	gst-devtools	2026-04-03
Fedora	FEDORA-2026-5e16254ca6	F42	gst-editing-services	2026-04-03
Fedora	FEDORA-2026-5e16254ca6	F42	gstreamer1	2026-04-03
Fedora	FEDORA-2026-5e16254ca6	F42	gstreamer1-doc	2026-04-03
Fedora	FEDORA-2026-5e16254ca6	F42	gstreamer1-plugin-libav	2026-04-03
Fedora	FEDORA-2026-5e16254ca6	F42	gstreamer1-plugins-bad-free	2026-04-03
Fedora	FEDORA-2026-5e16254ca6	F42	gstreamer1-plugins-base	2026-04-03
Fedora	FEDORA-2026-5e16254ca6	F42	gstreamer1-plugins-good	2026-04-03
Fedora	FEDORA-2026-5e16254ca6	F42	gstreamer1-plugins-ugly-free	2026-04-03
Fedora	FEDORA-2026-5e16254ca6	F42	gstreamer1-rtsp-server	2026-04-03
Fedora	FEDORA-2026-5e16254ca6	F42	gstreamer1-vaapi	2026-04-03
Fedora	FEDORA-2026-66f19b11e0	F42	kea	2026-04-08
Fedora	FEDORA-2026-04263e2a5b	F43	kea	2026-04-08
Fedora	FEDORA-2026-a8d6c7c064	F42	libgsasl	2026-04-04
Fedora	FEDORA-2026-5317df36be	F43	libgsasl	2026-04-04
Fedora	FEDORA-2026-5aafda8cd8	F43	libinput	2026-04-05
Fedora	FEDORA-2026-e2621c29b2	F42	libopenmpt	2026-04-03
Fedora	FEDORA-2026-178c482e71	F42	mapserver	2026-04-05
Fedora	FEDORA-2026-6d7e0a8b45	F43	mapserver	2026-04-05
Fedora	FEDORA-2026-fe96f3532b	F42	mingw-binutils	2026-04-05
Fedora	FEDORA-2026-9174e6ea37	F43	mingw-binutils	2026-04-05
Fedora	FEDORA-2026-3cc99e7d09	F42	mingw-gstreamer1	2026-04-05
Fedora	FEDORA-2026-e6d8e9fd49	F43	mingw-gstreamer1	2026-04-05
Fedora	FEDORA-2026-3cc99e7d09	F42	mingw-gstreamer1-plugins-bad-free	2026-04-05
Fedora	FEDORA-2026-e6d8e9fd49	F43	mingw-gstreamer1-plugins-bad-free	2026-04-05
Fedora	FEDORA-2026-3cc99e7d09	F42	mingw-gstreamer1-plugins-base	2026-04-05
Fedora	FEDORA-2026-e6d8e9fd49	F43	mingw-gstreamer1-plugins-base	2026-04-05
Fedora	FEDORA-2026-3cc99e7d09	F42	mingw-gstreamer1-plugins-good	2026-04-05
Fedora	FEDORA-2026-e6d8e9fd49	F43	mingw-gstreamer1-plugins-good	2026-04-05
Fedora	FEDORA-2026-f911c124c2	F42	mingw-libpng	2026-04-05
Fedora	FEDORA-2026-7576b56379	F43	mingw-libpng	2026-04-05
Fedora	FEDORA-2026-ff5da930eb	F42	mingw-python3	2026-04-05
Fedora	FEDORA-2026-22d8c9f967	F43	mingw-python3	2026-04-05
Fedora	FEDORA-2026-ca43aa006f	F42	nextcloud	2026-04-07
Fedora	FEDORA-2026-05152ff554	F42	nginx-mod-modsecurity	2026-04-03
Fedora	FEDORA-2026-6d5dce1a0d	F43	nginx-mod-modsecurity	2026-04-03
Fedora	FEDORA-2026-fba501f889	F42	openbao	2026-04-03
Fedora	FEDORA-2026-a9c2a486a6	F43	openbao	2026-04-03
Fedora	FEDORA-2026-387a47c82b	F43	polkit	2026-04-02
Fedora	FEDORA-2026-7b2964fc42	F43	pspp	2026-04-08
Fedora	FEDORA-2026-5e16254ca6	F42	python-gstreamer1	2026-04-03
Fedora	FEDORA-2026-e8c06584a9	F42	python3.12	2026-04-04
Fedora	FEDORA-2026-49aedae50d	F42	python3.13	2026-04-03
Fedora	FEDORA-2026-ba6745d242	F42	python3.14	2026-04-04
Fedora	FEDORA-2026-013fb3d1bc	F43	python3.14	2026-04-02
Fedora	FEDORA-2026-0ff49872ae	F42	python3.9	2026-04-04
Fedora	FEDORA-2026-1e87d53608	F43	python3.9	2026-04-04
Fedora	FEDORA-2026-f0293b845e	F43	rauc	2026-04-08
Fedora	FEDORA-2026-f47b1861e4	F42	rust	2026-04-05
Fedora	FEDORA-2026-334414b5e8	F42	rust-rustls-webpki	2026-04-02
Fedora	FEDORA-2026-efe3ef6f55	F43	rust-rustls-webpki	2026-04-02
Fedora	FEDORA-2026-57fce98ef9	F42	rust-sccache	2026-04-02
Fedora	FEDORA-2026-3c1918cbd5	F43	rust-sccache	2026-04-05
Fedora	FEDORA-2026-6227013c47	F42	rust-scx_layered	2026-04-02
Fedora	FEDORA-2026-9aa04df1ea	F43	rust-scx_layered	2026-04-02
Fedora	FEDORA-2026-3e4a2ef21b	F42	rust-scx_rustland	2026-04-02
Fedora	FEDORA-2026-51d92325e2	F43	rust-scx_rustland	2026-04-02
Fedora	FEDORA-2026-66bd2898f2	F42	rust-scx_rusty	2026-04-02
Fedora	FEDORA-2026-6ff037cd05	F43	rust-scx_rusty	2026-04-02
Fedora	FEDORA-2026-0b85273940	F42	scap-security-guide	2026-04-02
Fedora	FEDORA-2026-e99428e749	F43	scap-security-guide	2026-04-02
Fedora	FEDORA-2026-2f6fa1b6a1	F42	tcpflow	2026-04-04
Fedora	FEDORA-2026-4398680e1a	F43	tcpflow	2026-04-04
Fedora	FEDORA-2026-5f9e9fea3c	F43	vim	2026-04-04
Mageia	MGASA-2026-0080	9	firefox, nss	2026-04-02
Mageia	MGASA-2026-0086	9	freerdp	2026-04-06
Mageia	MGASA-2026-0085	9	polkit-122	2026-04-06
Mageia	MGASA-2026-0082	9	python-nltk	2026-04-06
Mageia	MGASA-2026-0087	9	python-pyasn1	2026-04-06
Mageia	MGASA-2026-0090	9	python-pygments	2026-04-08
Mageia	MGASA-2026-0089	9	roundcubemail	2026-04-07
Mageia	MGASA-2026-0081	9	thunderbird	2026-04-02
Mageia	MGASA-2026-0088	9	tigervnc	2026-04-07
Mageia	MGASA-2026-0083	9	vim	2026-04-06
Mageia	MGASA-2026-0084	9	xz	2026-04-06
Oracle	ELSA-2026-6340	OL9	freerdp	2026-04-01
Oracle	ELSA-2026-6259	OL10	gstreamer1-plugins-bad-free, gstreamer1-plugins-base, gstreamer1-plugins-good, and gstreamer1-plugins-ugly-free	2026-04-01
Oracle	ELSA-2026-6037	OL8	kernel	2026-04-01
Oracle	ELSA-2026-6153	OL9	kernel	2026-04-01
Oracle	ELSA-2026-6266	OL9	libxslt	2026-04-01
Oracle	ELSA-2026-6281	OL8	python3.11	2026-04-01
Oracle	ELSA-2026-6286	OL9	python3.11	2026-04-01
Oracle	ELSA-2026-6256	OL10	python3.12	2026-04-01
Oracle	ELSA-2026-6283	OL8	python3.12	2026-04-01
Oracle	ELSA-2026-6285	OL9	python3.12	2026-04-01
Oracle	ELSA-2026-6301	OL9	squid	2026-04-01
Oracle	ELSA-2026-6342	OL10	thunderbird	2026-04-01
Red Hat	RHSA-2026:6191-01	EL8.8	container-tools:rhel8	2026-04-03
Red Hat	RHSA-2026:3164-01	EL9	edk2	2026-04-07
Red Hat	RHSA-2026:2776-01	EL9	edk2	2026-04-07
Red Hat	RHSA-2026:2771-01	EL9.6	edk2	2026-04-07
Red Hat	RHSA-2026:5913-01	EL10	ncurses	2026-04-06
Red Hat	RHSA-2026:1720-01	EL7	openssl	2026-04-07
Red Hat	RHSA-2026:1475-01	EL8.4	openssl	2026-04-07
Red Hat	RHSA-2026:1349-01	EL9.0	openssl	2026-04-07
Slackware	SSA:2026-093-01		infozip	2026-04-03
Slackware	SSA:2026-093-02		krita	2026-04-03
SUSE	SUSE-SU-2026:20927-1	SLE BCI 16	389-ds	2026-04-01
SUSE	SUSE-SU-2026:20917-1	SLE BCI 16	ImageMagick	2026-04-01
SUSE	SUSE-SU-2026:1201-1	SLE12	ImageMagick	2026-04-07
SUSE	SUSE-SU-2026:1202-1	SLE15	ImageMagick	2026-04-07
SUSE	SUSE-SU-2026:1203-1	SLE15 oS15.6	ImageMagick	2026-04-07
SUSE	openSUSE-SU-2026:10465-1	TW	ImageMagick	2026-04-01
SUSE	SUSE-SU-2026:1174-1	SLE12	LibVNCServer	2026-04-02
SUSE	SUSE-SU-2026:1173-1	SLE15 oS15.6	LibVNCServer	2026-04-02
SUSE	SUSE-SU-2026:1191-1	SLE-m5.2	avahi	2026-04-06
SUSE	SUSE-SU-2026:1209-1	SLE-m5.0 SLE-m5.1 SLE-m5.2 SLE-m5.3 SLE-m5.4 SLE-m5.5	bind	2026-04-08
SUSE	SUSE-SU-2026:20905-1	SLE BCI 16	busybox	2026-04-01
SUSE	openSUSE-SU-2026:20460-1	oS16.0	chromium	2026-04-04
SUSE	openSUSE-SU-2026:0113-1	osB15	chromium	2026-04-02
SUSE	openSUSE-SU-2026:0112-1	osB15	chromium	2026-04-02
SUSE	SUSE-SU-2026:20950-1	SLE-m6.0 SLE-m6.1	cockpit	2026-04-07
SUSE	openSUSE-SU-2026:10472-1	TW	conftest	2026-04-02
SUSE	openSUSE-SU-2026:10488-1	TW	corosync	2026-04-05
SUSE	SUSE-SU-2026:20904-1	SLE BCI 16	cosign	2026-04-01
SUSE	SUSE-SU-2026:20918-1	SLE BCI 16	curl	2026-04-01
SUSE	openSUSE-SU-2026:10473-1	TW	dnsdist	2026-04-02
SUSE	SUSE-SU-2026:20949-1	SLE-m6.2	docker-compose	2026-04-01
SUSE	SUSE-SU-2026:20923-1	SLE BCI 16	exiv2	2026-04-01
SUSE	SUSE-SU-2026:1166-1	SLE15 SLE-m5.3 SLE-m5.4 SLE-m5.5 oS15.4 oS15.6	expat	2026-04-02
SUSE	openSUSE-SU-2026:10466-1	TW	expat	2026-04-01
SUSE	openSUSE-SU-2026:20448-1	oS16.0	expat	2026-04-02
SUSE	openSUSE-SU-2026:10458-1	TW	firefox	2026-04-01
SUSE	SUSE-SU-2026:1165-1	SLE12	freerdp	2026-04-01
SUSE	SUSE-SU-2026:1164-1	SLE15	freerdp2	2026-04-01
SUSE	openSUSE-SU-2026:10459-1	TW	freerdp2	2026-04-01
SUSE	SUSE-SU-2026:1193-1	SLE15 oS15.4 oS15.6	gimp	2026-04-07
SUSE	SUSE-SU-2026:1194-1	MP4.3 SLE15 oS15.6	google-cloud-sap-agent	2026-04-07
SUSE	SUSE-SU-2026:1195-1	SLE12	google-cloud-sap-agent	2026-04-07
SUSE	SUSE-SU-2026:1205-1	oS15.6	govulncheck-vulndb	2026-04-07
SUSE	SUSE-SU-2026:20915-1	SLE BCI 16	gstreamer-plugins-ugly	2026-04-01
SUSE	SUSE-SU-2026:20922-1	SLE BCI 16	harfbuzz	2026-04-01
SUSE	openSUSE-SU-2026:10462-1	TW	heroic-games-launcher	2026-04-01
SUSE	SUSE-SU-2026:1198-1	SLE-m5.2	ignition	2026-04-07
SUSE	SUSE-SU-2026:1197-1	SLE-m5.3	ignition	2026-04-07
SUSE	SUSE-SU-2026:1208-1	SLE-m5.4	ignition	2026-04-08
SUSE	SUSE-SU-2026:1200-1	SLE-m5.5	ignition	2026-04-07
SUSE	openSUSE-SU-2026:10474-1	TW	ignition	2026-04-02
SUSE	openSUSE-SU-2026:20452-1	oS16.0	kea	2026-04-02
SUSE	openSUSE-SU-2026:0117-1	osB15	keybase-client	2026-04-03
SUSE	SUSE-SU-2026:20912-1	SLE BCI 16	keylime	2026-04-01
SUSE	openSUSE-SU-2026:10470-1	TW	libXvnc-devel	2026-04-02
SUSE	openSUSE-SU-2026:10489-1	TW	libinput-devel	2026-04-05
SUSE	SUSE-SU-2026:20903-1	SLE BCI 16	libjxl	2026-04-01
SUSE	SUSE-SU-2026:20910-1	SLE BCI 16	librsvg	2026-04-01
SUSE	SUSE-SU-2026:20913-1	SLE BCI 16	libsodium	2026-04-01
SUSE	SUSE-SU-2026:20902-1	SLE BCI 16	libsoup	2026-04-01
SUSE	SUSE-SU-2026:1178-1	oS15.4	libsoup	2026-04-02
SUSE	SUSE-SU-2026:1179-1	SLE-m5.3 SLE-m5.4 SLE-m5.5 oS15.4	libsoup2	2026-04-02
SUSE	SUSE-SU-2026:20901-1	SLE BCI 16	net-snmp	2026-04-01
SUSE	SUSE-SU-2026:20948-1	SLE-m6.2	net-tools	2026-04-01
SUSE	openSUSE-SU-2026:20437-1	oS16.0	net-tools	2026-04-02
SUSE	openSUSE-SU-2026:10463-1	TW	netty	2026-04-01
SUSE	SUSE-SU-2026:20925-1	SLE BCI 16	nghttp2	2026-04-01
SUSE	openSUSE-SU-2026:10475-1	TW	opensc	2026-04-02
SUSE	openSUSE-SU-2026:10482-1	TW	osslsigncode	2026-04-03
SUSE	openSUSE-SU-2026:0116-1	osB15	osslsigncode	2026-04-03
SUSE	openSUSE-SU-2026:0115-1	osB15	osslsigncode	2026-04-03
SUSE	openSUSE-SU-2026:10467-1	TW	ovmf-202602	2026-04-02
SUSE	SUSE-SU-2026:1170-1	SLE12	perl-Crypt-URandom	2026-04-02
SUSE	SUSE-SU-2026:20911-1	SLE BCI 16	poppler	2026-04-01
SUSE	openSUSE-SU-2026:20449-1	oS16.0	postgresql13	2026-04-02
SUSE	openSUSE-SU-2026:20447-1	oS16.0	postgresql16	2026-04-02
SUSE	SUSE-SU-2026:20906-1	SLE BCI 16	postgresql17	2026-04-01
SUSE	SUSE-SU-2026:20921-1	SLE BCI 16	postgresql18	2026-04-01
SUSE	SUSE-SU-2026:20907-1	SLE BCI 16	protobuf	2026-04-01
SUSE	SUSE-SU-2026:1199-1	SLE12	python-PyJWT	2026-04-07
SUSE	SUSE-SU-2026:1206-1	SLE15 oS15.6	python	2026-04-07
SUSE	SUSE-SU-2026:20928-1	SLE BCI 16	python-black	2026-04-01
SUSE	SUSE-SU-2026:20920-1	SLE BCI 16	python-orjson	2026-04-01
SUSE	openSUSE-SU-2026:20458-1	oS16.0	python-pillow	2026-04-04
SUSE	SUSE-SU-2026:1192-1	MP4.3 SLE15 oS15.4 oS15.6	python-pyOpenSSL	2026-04-07
SUSE	SUSE-SU-2026:20930-1	SLE BCI 16	python-pyOpenSSL	2026-04-01
SUSE	SUSE-SU-2026:20960-1	SLE-m6.0	python-pyOpenSSL	2026-04-07
SUSE	SUSE-SU-2026:20954-1	SLE-m6.1	python-pyOpenSSL	2026-04-07
SUSE	SUSE-SU-2026:20929-1	SLE BCI 16	python-pyasn1	2026-04-01
SUSE	SUSE-SU-2026:1162-1	SLE12	python-tornado	2026-04-01
SUSE	SUSE-SU-2026:1171-1	SLE15 SLE-m5.2 SLE-m5.3 SLE-m5.4 SLE-m5.5	python-tornado	2026-04-02
SUSE	SUSE-SU-2026:20919-1	SLE BCI 16	python-tornado6	2026-04-01
SUSE	openSUSE-SU-2026:10485-1	TW	python311-Flask-Cors	2026-04-04
SUSE	openSUSE-SU-2026:10476-1	TW	python311-Pygments	2026-04-02
SUSE	SUSE-SU-2026:20956-1	SLE-m6.0	python311	2026-04-07
SUSE	SUSE-SU-2026:20951-1	SLE-m6.1	python311	2026-04-07
SUSE	openSUSE-SU-2026:10468-1	TW	python311-ecdsa	2026-04-02
SUSE	openSUSE-SU-2026:10461-1	TW	python311-nltk	2026-04-01
SUSE	openSUSE-SU-2026:10480-1	TW	python313	2026-04-03
SUSE	openSUSE-SU-2026:10481-1	TW	python314	2026-04-03
SUSE	openSUSE-SU-2026:10469-1	TW	python315	2026-04-02
SUSE	SUSE-SU-2026:20959-1	SLE-m6.0	tar	2026-04-07
SUSE	SUSE-SU-2026:20955-1	SLE-m6.1	tar	2026-04-07
SUSE	SUSE-SU-2026:1177-1	SLE15 SLE-m5.2 SLE-m5.3 SLE-m5.4 SLE-m5.5 oS15.6	tar	2026-04-02
SUSE	SUSE-SU-2026:1163-1	SLE15 oS15.6	thunderbird	2026-04-01
SUSE	openSUSE-SU-2026:20444-1	oS16.0	tomcat10	2026-04-02
SUSE	SUSE-SU-2026:20926-1	SLE BCI 16	tomcat11	2026-04-01
SUSE	SUSE-SU-2026:20916-1	SLE BCI 16	vim	2026-04-01
SUSE	SUSE-SU-2026:1169-1	SLE15	wireshark	2026-04-02
SUSE	openSUSE-SU-2026:10457-1	TW	xen	2026-04-01
Ubuntu	USN-8089-3	16.04 18.04 20.04	adsys, juju-core, lxd	2026-04-07
Ubuntu	USN-8140-1	16.04 18.04 20.04 22.04	cairo	2026-04-02
Ubuntu	USN-8146-1	25.10	jpeg-xl	2026-04-02
Ubuntu	USN-8142-1	14.04	kernel	2026-04-01
Ubuntu	USN-8151-1	22.04 24.04	lambdaisland-uri-clojure	2026-04-06
Ubuntu	USN-8147-1	14.04 16.04 18.04 20.04 22.04 24.04 25.10	libarchive	2026-04-06
Ubuntu	USN-8149-1	24.04 25.10	linux, linux-aws, linux-aws-6.17, linux-gcp, linux-gcp-6.17, linux-hwe-6.17, linux-realtime	2026-04-02
Ubuntu	USN-8145-1	16.04 18.04	linux, linux-aws, linux-aws-hwe, linux-kvm, linux-oracle	2026-04-02
Ubuntu	USN-8148-1	24.04	linux, linux-aws, linux-gcp, linux-gke, linux-gkeop, linux-ibm, linux-lowlatency, linux-nvidia, linux-raspi	2026-04-02
Ubuntu	USN-8143-1	14.04 16.04	linux, linux-aws, linux-kvm, linux-lts-xenial	2026-04-01
Ubuntu	USN-8148-2	24.04	linux-fips, linux-aws-fips, linux-gcp-fips	2026-04-02
Ubuntu	USN-8145-2	18.04	linux-fips, linux-aws-fips	2026-04-02
Ubuntu	USN-8143-2	16.04	linux-fips	2026-04-02
Ubuntu	USN-8145-3	16.04 18.04	linux-gcp, linux-gcp-4.15, linux-gcp-fips	2026-04-06
Ubuntu	USN-8152-1	24.04	linux-oem-6.17	2026-04-06
Ubuntu	USN-8095-5	24.04	linux-raspi, linux-raspi-realtime	2026-04-01
Ubuntu	USN-8141-1	22.04	linux-raspi	2026-04-01
Ubuntu	USN-8094-5	25.10	linux-raspi	2026-04-01
Ubuntu	USN-8148-3	22.04 24.04	linux-realtime, linux-realtime-6.8, linux-raspi-realtime	2026-04-02
Ubuntu	USN-8148-4	24.04	linux-realtime-6.17	2026-04-06
Ubuntu	USN-8154-1	18.04 20.04 22.04 24.04 25.10	python-django	2026-04-07
Ubuntu	USN-8139-1	25.10	rust-cargo-c	2026-04-01
Ubuntu	USN-8138-1	22.04 24.04 25.10	rust-tar	2026-04-01
Ubuntu	USN-8153-1	14.04	salt	2026-04-07
Ubuntu	USN-8150-1	16.04	spip	2026-04-06
Ubuntu	USN-8144-1	16.04 18.04 20.04 22.04 24.04	undertow	2026-04-02

Full Story (comments: none)