Welcome to the LWN.net Weekly Edition for September 3, 2026

This edition contains the following feature content:

• A pause for the Python JIT: work has been paused on the JIT since June, after the steering council asked for a PEP to define the work.
• The "rnull" Rust block driver: a blueprint for adding new block devices using Rust.
• Using steal time to moderate CPU demands: a patch set to allow virtual machines to give up vCPUs when contention is high.
• Governing GNOMEs: how the project's technical decision-making is evolving: a look at GNOME's evolving RFC process and other technical-governance progress.
• The rest of the 7.3 merge window: noteworthy changes coming to the next kernel release.
• Securely suspending LUKS-encrypted disks: fixing a regression that allowed disk-encryption keys to remain in memory when a system was put to sleep.
• A note on subscription prices from LWN: LWN's subscription prices are changing for the first time since 2022.

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)

A pause for the Python JIT

In 2024 the Python 3.13 release added an experimental just-in-time (JIT) compiler to optimize the way that CPython executes Python code. Since then, work has proceeded on the JIT, albeit perhaps less formally than some might like. In June, Python's steering council (SC) put out an announcement that no new development on the JIT land (with the exception of bug and security fixes) in Python's main branch, until it accepts a Python Enhancement Proposal (PEP) that would make the case for the JIT as a supported part of CPython. That has led to the creation of PEP 836 ("JIT Go Brrr: The Path to a Supported JIT Compiler for CPython"), which is currently under discussion. As it stands, it seems likely that work on JIT will continue, but when that will happen is less certain.

PEP it up

The Python community uses PEPs to propose new features, serve as a focus for discussion, collect community input, and to serve as a record of decisions. There are three types of PEP: standards track, process, and informational. The standards-track PEPs are for major new features or changes for Python, where the community needs to discuss and decide before (say) removing the global interpreter lock (GIL). Process PEPs are similar but are related to Python governance and development practices around the code base. If accepted by the steering council, these become binding, and (if applicable) work is to commence on implementing the proposal.

Informational PEPs are, as the name suggests, to provide guidelines or other information to the Python community; these PEPs do not represent formal consensus and are non-binding. As such, they generally would not be considered suitable as a basis of major new features landing in CPython's main branch, but work has proceeded on Python's JIT on the basis of PEP 744 ("JIT Compilation"), which is an informational PEP.

That PEP was only introduced several months after CPython core developer Brandt Bucher had already merged the pull request (PR) to add a JIT compiler in January 2024, ahead of the Python 3.13 release.

Thomas Wouters, a steering council member who was serving as the release manager for Python 3.13, stepped in a few days later and asked why the feature had been submitted before a PEP had been submitted or accepted. Ultimately, Wouters persuaded Bucher that a PEP was warranted, and he agreed to start work on one. PEP 744 was announced in April 2024. LWN covered some of that discussion at the time, and Bucher's PyCon US 2024 and PyCon US 2025 talks on the JIT compiler.

There is a "JIT Planning for 3.15 and 3.16" tracking issue on GitHub, created in September 2025, to track goals and work the JIT developers believe was needed to enable the JIT by default by the Python 3.16 release in 2027. But the work was continuing without a standards-track PEP that indicated larger community agreement and awareness.

Hit pause

In its announcement, the council took pains to note that it was not criticizing the JIT effort or those behind the work: "This has been hard, deeply technical work that has been done with great care, and the recent performance improvements are real and encouraging." However, because the project had been underway and undergone a few re-architectures, the council decided, "now is a good time to re-evaluate the JIT's informal status in the project".

The council set a window of six months for a new PEP to be submitted and resolved; it said that the JIT code is to be removed from the main branch and any development would need to continue outside that repository if a PEP is not accepted within that time frame.

We know this asks something of the people who have invested years in this work, and we don't take that lightly. We see this not as winding the project down but as giving it, and the community, the clarity and the explicit commitment that a change of this magnitude to CPython's runtime deserves.

The council asked that the PEP address several points; first, it should cover "how the JIT will be sustained and maintained over the long term". It would also need to explain how the JIT would keep compatibility with other CPython features and tooling, if the JIT would be compatible (or incompatible) with third-party JIT implementations, as well as whether the JIT architecture is considered stable or would change further. The council also asked for "clear, measurable success metrics and timelines"

Why now?

Naturally, there were questions about the announcement. Antoine Pitrou said that the council's decision seemed reasonable but wondered if there was "any further background" that prompted it. Wouters replied that there had not been "a single triggering request" for the PEP, but the announcement was released after the 3.15 beta to indicate the council was "okay with the status quo for 3.15". The JIT is still included as an experimental feature in 3.15 and includes major updates such as a new tracing frontend, a basic form of register allocation, and several optimizations.

Peter Bierma asked for clarification on the council's deadline: he thought that it was unlikely that it would be possible to meet the deadline when some PEPs, such as PEP 703 ("Making the Global Interpreter Lock Optional in CPython"), have taken five months to be accepted by the council after being formally submitted. Pablo Galindo Salgado indicated that the council would be flexible if the PEP was stuck in discussion or in its queue for consideration. Wouters added that the council was trying to drive a "clear decision from the community", because the JIT is a significant change that deserves serious attention. "That doesn't necessarily mean the JIT immediately gets ripped out when that six month deadline is hit – we're not unreasonable – but we do want this to be taken seriously."

The decision to stop development until a PEP is accepted, Mark Shannon said, put JIT contributors in an awkward position. He asked if work to improve the JIT could continue for a month or two "to give time for the PEP to be discussed properly". Council member and JIT contributor Savannah Ostrowski replied that she didn't think that the grace period Shannon asked for was necessary. "We understand the work is ongoing and the current state isn't the final state (as is true of most things in open source)."

Shannon clarified that he was worried about losing momentum and contributors. "There is other work I personally can do, on memory allocation and such, but PRs will bitrot and other contributors may lose interest." Jiahao Li, who had made contributions to the JIT, asked if there were "clear and minor optimizations" that might be acceptable to continue. Alyssa Coghlan suggested that a grace period might be warranted for any in-flight pull requests, especially those from new contributors. "Saying 'no new PRs on this topic until a PEP is approved' is one thing, shifting the goal posts for already in progress changes is something else".

Council member Donghee Na was not convinced that exceptions were a good idea. Even if the policy was adjusted to allow PRs that were already open, "I still think our main focus should be on writing the PEP. Involving those contributors in the PEP process would also be a good experience for them as part of CPython's development process."

On June 8, Diego Russo, a CPython core developer and JIT contributor, replied that he had discussed next steps with Shannon and they were working on a draft. The "JIT Go Brrr" draft PEP was announced on July 3 by Ken Jin. The PEP name may be a nod to the "doesjitgobrrr" web site that tracks the performance of the JIT versus the standard CPython interpreter. "Go Brrr" is a reference to a meme about the US Federal reserve printing money with a caption including the phrase "money printer go brrr".

New PEP

The PEP, authored by Bucher, Jin, and Ostrowski, lays out the current status for the JIT, as well providing a two-and-a-half year timeline with the milestones and goals for the JIT to become a non-experimental feature. The PEP leaves the decision of whether to enable the JIT by default to the Python release manager, rather than setting a condition for that to occur. Currently the JIT is included in the Python binaries for Windows and macOS, but it is disabled by default; some Linux distributions (the PEP cites Fedora and Gentoo) also include the JIT but leave it disabled by default. Interested users can turn on the JIT by setting PYTHON_JIT=1 as an environment variable.

The first year would be focused on developer-experience improvements, making the JIT compatible with free-threaded (no-GIL) Python, avoiding regressions, as well as adding further testing for native Python profilers and debuggers. The second year target, which is scheduled for the first beta of Python 3.17, is "at least 20% performance geometric mean improvement" measured by the Python Performance Benchmark Suite (pyperformance) when using the JIT and free-threaded Python versus free-threaded Python alone.

The last milestone, to be completed by the first 3.17 release candidate, is compatibility review: running the test suites of the top PyPI packages (exactly how many is not specified) to assess JIT compatibility with existing code.

The PEP also calls for adding support for multiple versions of the LLVM compiler; currently, building Python with the JIT enabled requires a specific version of LLVM. Building the JIT for Python 3.14 requires LLVM 19 and Python 3.15 requires LLVM 21; both versions of LLVM have reached end of life. LLVM is required because it is used to create templates called "stencils" (example) for the JIT.

There is a separate standards-track proposal, PEP 774 ("Removing the LLVM requirement for JIT builds"), that would remove the LLVM requirement entirely, but it has not yet been accepted. The current situation is a problem for Linux distributors that support versions of Python in long-term-support releases, as discussed in this thread on the Python forum.

The PEP also proposes some changes to the JIT's frontend infrastructure. Specifically, it calls for replacing the current trace-recording frontend of the JIT compiler with a method-based frontend to make the JIT easier to maintain and make it "more traditional and teachable", which is not the case now. "The current tracing frontend can produce head-scratching results even for very simple benchmarking programs." The trace-recording frontend is explained in detail in a blog post by Jin from May 2026.

Discussion

Cesare Di Mauro noted that the PEP mentioned that the JIT might use more memory, but it made no clear statement about the goals for memory consumption. Jin said that was a good point and planned to take it up with the co-authors of the PEP to include an upper limit on additional memory use.

Wouters, who clarified he was speaking as himself and not as a council member, thought that the PEP really felt like it was two PEPs: one that was showing the criteria for acceptance, and one that explained how the proposers expected to meet the criteria. "Fundamentally, the discussion about the minimum expectations for a supported JIT is distinct from how to get there, especially as we have different proposals for how to get there." He also questioned the firm timeline that was included in the PEP. "It's just not how development works in an open-source project, especially one that cares about backward compatibility."

He wanted to see an explicit discussion in the PEP about the JIT's startup time, warmup time, and memory overhead. These, he said, did not need to be "particularly strict numbers", but if those metrics were not tracked, it would not be possible to understand the cost paid when the JIT is enabled.

The other requirement he voiced was about maintainability of the JIT and its support among the core CPython team members. "We should focus on making whatever design we end up with understandable, and understood by the Core team. We need to make sure enough people work on it and spend time with it". Shannon agreed that "this seems like two PEPs", and implementation details in the current PEP seemed out of place.

Bucher replied the PEP was "providing what the SC asked for" and that the authors had put a lot of effort into creating a cohesive PEP. "A separate PEP seems like it makes the process more complicated and opaque, not less. Here, we have a way to present a complete story". He also thought that the current JIT "can be understood and is accessible to other members [of the community] outside the core team". Ostrowski added that it would make her uncomfortable to have the PEP include goals for the JIT without "everything we've thought through alongside it". Goals without plans, she said, aren't really goals at all.

Wouters responded that he understood where Bucher was coming from now. He added that his understanding of the council's request, though, was meant to be for the current JIT and not a future one. "If the plans in this PEP for the future JIT were rejected, that still leaves the fate of the current JIT unclear." Jin replied that the PEP was not proposing a new or future JIT, though it might seem that way for those unfamiliar with the recent JIT progress. "The design we described might seem like a radical change, but most of it is already in the current CPython main branch! Again, the only change is growing support for methods."

CinderX is an extension for improving the performance of the Python runtime that includes a JIT. Kevin Newton, one of the contributors to CinderX, also thought the proposal should be two PEPs. More importantly, he believed that the PEP "very much understates the sizeable difference between a tracing JIT and a method-at-a-time JIT" and was glossing over some important details. He said that CinderX had already run into some of the problems that the JIT developers would face in replacing the current frontend. He also worried about the focus on simplicity:

JITs and dynamic language runtimes are some of the more complex pieces of software out there. I promise I'm sympathetic to having too little energy and contributors, and it makes sense that you would want the things you mention. But I worry that eschewing complexity in favor of making a JIT compiler "fit" in someone's head ultimately results in a JIT compiler not worth having.

Jin said that he appreciated Newton's expertise with CinderX and other JITs, but he disagreed that it would require a lot of changes to support methods for the current state of the JIT in CPython. The developers had not yet implemented "the usual complex things" yet, which meant that it would not be highly complex to switch between the two at this time. He also disagreed that there was a mandate to produce two PEPs from the steering council, and wanted to avoid putting the burden of doing so on the JIT developers.

The "this should be two PEPs" theme continued with a lengthy comment from CPython core developer Jeremy Hylton. He called for separate PEPs describing the design of the JIT, how various parts of the interpreter runtime interact, as well as one that would describe metrics, timelines, and maintenance plans.

Eric Snow, also a CPython core developer, pushed back against the "ongoing pressure" and expressed support for the JIT. He thought documenting the design and addressing concerns was worth doing but disagreed with blocking further development in the main repository. There was a risk, he cautioned, that making extended demands that seemed like busy work would drive away contributors and turn Python into a project "in which mostly only enterprise teams participate".

Russo said he had worked on the JIT almost since its inception and felt the work should continue; he did, however, support splitting the document into two PEPs. He thought that trying to cover everything in one PEP broadened the discussion and made it harder to reach consensus. "The Steering Council's requests can be addressed through multiple focused PEPs rather than trying to fit everything into one document. Once we have an agreed baseline, follow-up PEPs can evolve individual parts of the JIT independently."

Status

The discussion seems to have lost momentum, without any official statement from the council about whether it also feels there should be multiple PEPs or if it is satisfied with the current draft. There has been no commitment from any of the PEP's authors to split up the current document or produce new PEPs.

On August 17, Wouters posted a summary of the council's meeting from August 6. The summary noted that the council "had office hours" with the authors "discussing the state of the PEP and whether it answered the questions the SC asked in its request for a PEP", but did not elaborate on the results of that discussion. PEP 836 was listed as an agenda item for the council's next meeting, but minutes from that meeting have not yet been posted.

For now, the development of the JIT seems to be largely on hold. No one seems to be voicing direct opposition to the JIT work, just a fair number of people who are asking for more information and debating the details.

Comments (19 posted)

The "rnull" Rust block driver

The null block driver (null_blk) is a small driver that is mostly useful for benchmarking block-layer implementations. It accepts all requests and marks them complete as quickly as possible, doing as little work as possible. In June 2026, Andreas Hindborg shared a patch set implementing the same functionality in Rust, in order to show that a simple block driver is now possible to write using the kernel's Rust APIs and to enable comparisons between the C and Rust implementations. A minimal version of the "rnull" driver is already present in the mainline kernel, but Hindborg's patch set brings it up to feature parity with the C version.

The rnull driver

Most of Hindborg's patch set is dedicated to adding the last few Rust abstractions required to build a block driver at all. The implementation follows the same general pattern as the last Rust driver that LWN looked at, for the AX88796B networking device. It starts by declaring a new kernel module using the module!() macro, and then creates a new Rust type to represent the module. Unlike the Rust AX88796B driver, Hindborg's driver uses pinning to store a reference to the configfs interface, which complicates the module's initialization function.

The bulk of the function is wrapped in a call to pin_init_scope(), which takes a block of code describing how to initialize a piece of memory and uses that to construct a pinned (immovable) object in-place, without exposing raw uninitialized memory to the Rust code. Other than that one complication, the initialization function is straightforward: it reads module parameters, creates the requested number of disk-device objects, and then stores the configfs interface and list of disks in the module's pinned data:

    pin_init::pin_init_scope(move || -> Result<_, Error> {
        // Read module parameters:
        let blocking = module_parameters::blocking.value();
        // Other parameters elided
        ...

        // Build a tag set (part of how requests are mapped to hardware queues)
        // for the module-wide configfs settings to use
        let shared_tag_set = NullBlkDevice::build_tag_set(...);

        // Create disks
        let mut disks = KVec::new();
        for i in 0..module_parameters::nr_devices.value() {
            // Some local variables elided
            ... 
            let disk = NullBlkDevice::new(...)?;
            disks.push(disk, GFP_KERNEL)?;
        }

        // Store pointers in pinned module data
        Ok(try_pin_init!(Self {
            configfs_subsystem <- configfs::subsystem(shared_tag_set),
            param_disks <- new_mutex!(disks),
        }))
    })

Each block device is represented by a NullBlkDevice structure, which includes various configuration parameters to implement support for bad blocks, bandwidth limits, device zones, and the other testing options that null_blk supports. The structure implements the Operations trait, which describes how disk operations for the device should be performed. The #[vtable] macro is used to package the functions of the trait into a vtable (a structure full of function pointers) that looks indistinguishable from the C implementation to the rest of the kernel. The block I/O subsystem structures used to track the known block devices on the system store a pointer to that vtable. The actual implementations of the functions themselves accept arbitrary requests and immediately mark them as complete.

The core function for this is queue_rq_internal(), which takes (among other things) a pointer to a Request structure that wraps struct request from the kernel's C code. The code is slightly complicated by the need to handle fault injection, but when that is turned off the core logic to handle a request (with editorialized comments) looks like this:

    // Acquire the lock on the request
    let mut rq = rq.start();

    if rq.command() == mq::Command::Flush {
        // If the rnull device has been configured to save writes in memory,
        // flush that storage.
        if this.memory_backed {
            this.storage.flush(&hw_data);
        }

        // Regardless, mark the request as handled and return.
        this.complete_request(rq);
        return Ok(());
    }

    if rq.is_poll() {
        // If the request is trying to poll for completion of something,
        // put it in the poll queue so that a later poll will complete it.
        hw_data.lock().poll_queue.push_head(rq)
        // ... discarding the potential error about a full queue because it is
        // sized such that it should never be overfilled.
            .expect("Buffer is sized to hold all in-flight requests")
    } else {
        // Otherwise, just mark it as complete
        this.complete_request(rq);
    }

    return Ok(());

The more interesting part, for other people wishing to write block drivers, will be the scaffolding around that core logic, which shows how to make a driver configurable and register it as a provider of block devices. The initialization code to read module parameters and expose configfs settings, especially, should be similar between different drivers.

The configfs code exposes the same settings that the null_blk driver does, controlling the size of the emulated block device, whether it reports itself to be a rotational or solid-state drive, and so on. The configfs interface also uses #[vtable], but in a slightly more confusing way: rather than constructing a single vtable that encapsulates the definition of a Rust trait, the code generates multiple vtables, one for each defined configfs attribute, distinguished via const generics. Some of the simpler settings instead use macros such as configfs_simple_bool_field!() to reduce the amount of boilerplate necessary.

One of the configfs attributes that cannot be simplified with those macros is the "badblocks" setting, which controls which sectors report errors when using error injection. The code for that attribute shows how to use the Rust configfs interface. The show() function controls how the setting is displayed to the user; the store() function is used to update the configuration when the user writes to the appropriate configfs file. The "12" in the impl line associates this implementation with the twelfth configfs attribute, and the #[vtable] macro packages it all up as a vtable in the format that configfs's C code expects:

    #[vtable]
    impl configfs::AttributeOperations<12> for DeviceConfig {
        type Data = DeviceConfig;

        fn show(this: &DeviceConfig, page: &mut [u8; PAGE_SIZE]) -> Result<usize> {
            let ret = this.data.lock().bad_blocks.show(page, false);
            if ret < 0 {
                Err(Error::from_errno(ret as c_int))
            } else {
                Ok(ret as usize)
            }
        }

        fn store(this: &DeviceConfig, page: &[u8]) -> Result {
            for line in core::str::from_utf8(page)?.lines() {
                // Parse each line and set the appropriate settings in the
                // DeviceConfig.
                ...
            }

            Ok(())
        }
    }

When the kernel module is loaded, the Rust configfs wrapper automatically registers the configfs::Subsystem structure containing those vtables with configfs. When the user invokes the proper incantations:

    # mount -t configfs none /config
    # mkdir /config/rnull/<block_device_name>
    # echo 1 > /config/rnull/<block_device_name>/power

The configfs code creates a new GenDisk structure, which corresponds to struct gendisk on the C side of the kernel. That structure stores a pointer to the NullBlkDevice vtable.

Future block drivers

Given that the main purpose of null_blk is benchmarking, a natural question is how its performance stacks up against the C implementation. Exactly how much overhead do the Rust bindings introduce? The Rust for Linux project's documentation on the driver shows a benchmark comparing performance between the two drivers on the 6.19-rc5 kernel. As is frequently the case in benchmarking, the comparison is not straightforward. Single-threaded performance is a little worse, as is the performance at higher queue depths, but performance is actually better for some sizes of request, and most tested setups have no statistically distinguishable difference.

Of course, the real point of Hindborg's patch set is not to supplant the C-based null block driver; it is to demonstrate that it is now possible to write new, more interesting block drivers in Rust. Currently, device drivers in Rust can be divided into two general categories: big projects, which have developers willing to implement all of the new Rust abstractions required for them, and little drivers that someone has contributed for a specific device. The former category, which includes Android's Rust binder, Nova, and Tyr, receives a lot of the attention, but given that there are a long tail of tiny, obscure, neglected drivers for niche devices in the kernel, it is arguably the latter category that has more to gain from adopting Rust.

As of August 2026, the kernel has Rust drivers in the latter category for two families of networking devices (the AX88796B and QT2025), TH1520 pulse-width modulation controllers, and CPU-frequency management. That is not much, but these small drivers provide a blueprint for users who want to add support for their own niche devices and who may not be confident in their ability to write correct kernel C. Hindborg's rnull driver provides the same kind of blueprint for adding new block devices to the kernel. Perhaps we will soon see drivers for niche block devices coming to the mailing lists.

Comments (25 posted)

Using steal time to moderate CPU demands

Virtualization can increase CPU utilization by allowing a large number of virtual CPUs to share a smaller number of physical CPUs. The amount of CPU time that is actually available does not change, though, so heavy activity on too many virtual CPUs can lead to contention and significant performance loss. The steal governor patch series from Shrikanth Hegde is an attempt to address that problem with a mechanism that allows virtual machines to voluntarily reduce the number of virtual CPUs they use when contention is high.

From a virtual machine's point of view, contention for a physical CPU is clearly an undesirable thing. When contention occurs, the physical CPU will be unavailable at times when the virtual machine is trying to make use of it; that slows the execution of the workload. The situation can be worse than that, though, if a virtual CPU is preempted while holding locks needed elsewhere in the same virtual machine. At that point, threads that do still have access to a physical CPU may waste their execution time spinning on locks that the preempted CPU is no longer able to free, with possibly severe effects on performance. That is the sort of situation that causes customers to reconsider shared hosting.

Hegde's solution calls for virtual machines to take notice of when contention for physical CPUs is high and to reduce their demands to alleviate that contention.

Steal time and preferred CPUs

The amount of time that a virtual CPU spends waiting for access to a physical CPU is known as "steal time" — execution time that was "stolen" from the virtual machine by somebody else. On a Linux system, the amount of steal time experienced in a virtual machine can be read from /proc/stat, or seen with utilities like top or vmstat. The level of steal time seen by a virtual CPU can be used as a measure of how much contention for the physical CPU is being experienced.

Hegde's patch set uses steal time to help maintain (in ways that will be described shortly) a "preferred CPU" set. The preferred CPUs are a subset of the active virtual CPUs available to the virtual machine; as much as possible, the kernel on that virtual machine will try to schedule its tasks only on the preferred CPUs, leaving the others idle. When the virtual machine starts, the preferred set contains all of the active CPUs. Should the level of steal time experienced become too high, one or more CPUs will be removed from the preferred set. When steal time goes below a lower threshold, CPUs can be restored to the preferred set.

The scheduler makes use of the preferred set in few small but significant ways:

• Whenever the time comes to wake a sleeping task, that task will be placed on one of the preferred CPUs if possible.
• At each regular scheduler tick, the kernel checks whether the current CPU is in the preferred set. If not, the running task, if any, will be pushed out of the current CPU to run on one of the preferred CPUs instead.
• Load balancing will avoid moving tasks onto CPUs that are not in the preferred set.

One important exception to these rules is that a task's CPU affinities will be honored. If a task is only eligible to run on non-preferred CPUs, it will be placed on one of those CPUs. Other than that, though, this machinery will cause any CPUs that are removed from the preferred set to go mostly idle, concentrating the virtual machine's tasks on the preferred set and reducing the number of physical CPUs that the virtual machine is contending for.

One might argue that the result is simply to move the problem around. Contention arises because there is more load on the system than its physical CPUs are able to handle; that load will not go away just because the set of virtual CPUs available to a virtual machine has been reduced. What does happen, though, is that the preemption decisions are moved into the virtual machine, which has more information about the workload and which tasks should be allowed to run first. That can allow the virtual machine to run high-priority tasks, or tasks holding contended locks, before others, leading to better decisions overall.

Policy

The policy part of this system is encapsulated in a "driver" called the steal_governor. It is not actually implemented as a driver, though; it runs as a workqueue item that continually resubmits itself. It is controlled by three parameters: interval_ms regulates how often it checks the experienced steal time, while low_threshold and high_threshold set (as percentages) the amount of steal time that should lead to an increase or decrease in the number of preferred CPUs, respectively. Interestingly, these parameters do not appear in sysfs; instead, they are implemented as module parameters, a configuration method that has been discouraged in recent years. Changing any of these parameters requires unloading and reloading the steal_governor module. The default value for interval_ms is 1000ms; the low and high thresholds default to 2% and 5%, respectively.

On each iteration, the governor compares the amount of steal time to the high threshold. If that threshold is exceeded, the governor will look for a core that contains no housekeeping CPUs; all CPUs in that core will be removed from the preferred set (subject to the obvious restriction that at least one CPU must remain in the preferred set). No other immediate action is taken; the scheduler tweaks described above will eventually cause tasks to move away from the non-preferred CPUs. If, instead, the steal time drops below the low threshold, one core's worth of CPUs will be added back to the preferred set (until the point where all CPUs are preferred).

The policy implementation may be enough for a proof of concept, but it may end up falling short for real deployments. At a minimum, the ability to change the governor's parameters without unloading and reloading a module would be a clear improvement. There does not seem to be a reason why these values could not be changed directly using sysfs or sysctl knobs. Even then, though, it seems inevitable that somebody will want the ability to control the preferred CPU set from user space, or, even more inevitably, with a BPF program.

Another potential problem, of course, is the entirely voluntary nature of this mechanism; it is nice that each virtual machine can react independently, and that there is no need for an overall control or communication mechanism, but the result is a system that is dependent on universal cooperation. If only some virtual machines reduce their preferred CPU count, they will be penalized relative to those that do not. That may limit the applicability of this mechanism on multi-tenant systems where some users may not feel inclined (or may be unable) to cooperate.

On systems where cooperation can be expected, though, the results would appear to be good. The cover letter includes data from a number of benchmark runs showing improvements from about 2% for schbench to over 44% for some hackbench runs. Hegde summarizes the results as: "Many improvement across archs especially with real life workloads".

This patch series has been circulating since the first RFC version in May 2025. It has been through 11 revisions — after several RFC versions — and has evolved considerably over that time. It has not, as yet, acquired the Acked-by or Reviewed-by tags that might indicate readiness for merging into the mainline, but Hegde nonetheless said that "I believe the series has now converged and is ready for merge consideration". Whether the scheduler maintainers agree will likely become clear sometime after the close of the merge window.

This work was discussed at the 2026 Power Management and Scheduling in the Linux Kernel Summit; the video from that session is available.

Comments (2 posted)

Governing GNOMEs: how the project's technical decision-making is evolving

Emmanuele Bassi kicked off a project to improve GNOME's technical governance with a presentation about his ideas (video) at GUADEC 2025. His nudging has led the project to, slowly, work on creating more formal structures for technical governance. It is adopting a teams structure and looking toward creating a steering committee, as well as bootstrapping a Request for Comments (RFC) process. If adopted, GNOME would require RFCs for design, user experience, architectural, and other changes that carry a major impact on the project.

GNOME and governance

GNOME was founded in 1997; its non-profit foundation followed in 2001 to provide support for the project by managing funds, overseeing legal assets such as trademarks, maintaining development infrastructure, and running events. The original charter for the foundation, however, made it clear that there was no taste for rigid structure around technical governance:

GNOME sits on the frontier of the Linux application market, and is likely to continue to face growing pains as we try to meet the needs of ISVs (Independent Software Vendors) and others who are joining the movement.

It would be impossible to impose a high degree of bureaucratic structure onto a heretofore amorphous and somewhat anarchic community. And it shouldn't be done, anyway.

Bassi makes the case in the write-up of his governance talk, that the "over-reliance on personal projects and taste" has resulted in GNOME being "a loosey-goosey collection of cats, herded together by whoever shows up with 'a vision'". He writes that GNOME's software quality has improved over the years, but only because the project has a few people maintaining a lot of components—thus things are consistent, but also means that maintainers are in danger of burnout.

Bassi argued for doing away with the individual maintainer model in favor of shared responsibility. In the discussion on GNOME's Discourse forum in August 2025, he detailed the formal technical-governance system that he envisioned. It includes a change-proposal process, teams for parts of the project, such as a platform team for the application-development layer, a core apps team for GNOME applications, a tooling team for development tools, and so forth. He also proposed a steering committee formed from representatives of the teams. Changes that impact multiple teams would be discussed and documented in public, then published for posterity.

The proposal to get rid of individual maintainers was a sticking point for some GNOME contributors. Adrian Vovk thought that GNOME had too few people for "this bureaucratic process", and expected there would still be de facto maintainers who had the institutional knowledge over "their corner of the stack". Michael Catanzaro said it was unrealistic to do away with maintainers entirely, since "GNOME is a big collection of small projects, and teams with a large scope and perspective are just not a better way of working on small projects". He did allow that it would be fine to give teams the power to overrule individual maintainers.

Allan Day worried that the proposal was trying to do too much at once:

Formalized teams plus steering committee plus RFC process is a lot. Out of those three elements the development teams is the most high-risk and complex. I can't help but wonder whether that part of the plan should be decoupled and given more time/space to evolve.

A year later...

The governance work has been evolving slowly, or more slowly than Bassi had hoped, at any rate. On July 17, at GUADEC 2026, he provided an update on GNOME's governance work, in his "Some more governance" talk (video). "I toyed with the idea of calling the talk 'governance will continue until morale improves', but that was a little bit too on the nose, to be honest."

He said that he had expected his proposal to be contentious, but he received valuable feedback instead. "Everyone agreed that technical governance had to be improved in the project". Unfortunately, there were few people actually working on the governance improvements, "which means that people were looking at other people to unblock the issue, and they were waiting for somebody to come along and tell them what to do". He thought that GNOME would adopt new technical governance quickly, but people "really don't know where to start".

Progress has been made, though; he said there are now rules defining what a team is and what constitutes an active or inactive team. There is an entire chapter in the GNOME Project Handbook that defines what a team is, how teams should collaborate, and spaces on GNOME's GitLab instance for each team. He said that there is currently a bindings team and that he had been "collecting people like Pokémon" who work on "any platform library" to create a platform team.

So the goal of the platform team is whenever somebody is contributing to the core library, a new feature, a new setting, a new widget, a new API, it doesn't matter what, it doesn't matter how big, you come to the platform team and you talk to us. If you're inside already at the platform team, you know what to do. If you're outside because you're a new contributor or you are interested in something for your application, you come to the platform team.

The governance process effort has also identified inactive teams, such as the documentation team; Bassi said that it needed reviving or to be shut down, since there hasn't been any activity except his own in refreshing the GNOME Help web site.

Anyone who wanted to start their own team, he said, should follow the rules in the handbook or come to him for a template. "The important thing is [they] all have regular meetings and publish their agenda so that people are aware of it; people can jump in and help you out. And use the GNOME infrastructure because it's there for a reason".

The steering committee, however, has not yet been created. Bassi said there were still open questions: for example, who gets to be on the committee and for how long? Should it be a decision-making or an arbitration body? How can GNOME avoid the committee becoming a "small subset of people steering the project in a direction that the rest of the community doesn't care about"? All of those questions are still unanswered.

RFC process

The path to answering some of those questions may lie in the RFC process, which Bassi is emphatically not leading. Bassi said that he did not want to be involved in the development of the RFC process, "because there is nothing that trips a bunch of nerds like rule lawyering" and there is nothing that nerds hate more than bureaucracy, "except the one they come up with". Instead, Sofie Herold is leading the charge for the RFC process. She began the discussion on July 27, with a draft RFC proposal and suggested that it should be the first test of the process as RFC-0001. Unfortunately, the first draft seems to have been erased at some point, but a more recent draft is available.

Even though Bassi's governance proposal included a RFC-like change process, and adopting bits of it would involve an RFC process, RFC-0001 presents itself as an alternative to Bassi's proposal. It has a smaller scope in the hopes of avoiding being "stuck with a proposal that covers too many aspects and details of the project's governance to be realistically discussed in one package".

Under the proposal, RFCs will be created in a GNOME/rfcs repository on GNOME's GitLab instance, and it calls for a thread to be created on GNOME's forum for discussion of RFCs. Any member of the GNOME Foundation can create an RFC as a merge request (MR), and the MRs can be locked so that only foundation members can comment. There are examples of situations that call for an RFC to be created, such as resolving stalled discussions or handling major design decisions. The proposal states that an RFC "cannot override the competencies and powers given to certain groups or people by the GNOME Foundation" (whatever those powers might be—they are left unspecified).

When an RFC is created, it is driven by one or more editors ("the author as well as additionally specified editors"), and can be amended during discussion by editors or stakeholders. The definition of "stakeholder" is "is anyone whose work or projects in GNOME are meaningfully affected by the proposed change", which could be a person, a team, or a group as large as all GNOME Foundation members. An RFC should list stakeholders when it is created, but additional stakeholders "must be added" if two members of a team believe their team is a stakeholder.

If someone objects to all or part of an RFC, they can raise a "concern" which may be accepted by any stakeholder (excepting the person who raised the concern in the first place). It is unclear how it would be handled if stakeholders disagree about concerns and their resolution. The RFC specification is a bit vague about expected discussion length; it states that there is a 14-day final comment period to raise new concerns before an RFC is accepted or rejected "once discussion has died down", but it does not dictate any requirement that a discussion take at least a certain amount of time.

According to the draft, after the final comment period ends then any stakeholder can choose to either accept (merge) the RFC or reject (close the MR) it.

Lucas Baudin asked for examples of changes that would go through the RFC process. Bassi provided a few changes that he thought would need RFCs, such as switching documentation formats and changing GNOME's recommended image-loader library. Matthias Clasen agreed; he also thought that the examples emphasized the need for the RFC process to be lightweight and focused on raising awareness of changes. He said he was pretty sure that none of the changes Bassi shared as examples would have been completed "if there had been a prolonged, concern-heavy discussion of all the eventualities and unlikely failures before any code was written."

On August 31, Sam Thursfield said that he had been holding off on a comment while he digested the RFC text, "but nothing new has come from that, so I think the best thing to do is adopt the process and start using it". Herold said that comments had died down and "we are slowly moving towards final comment period". If no new concerns have been raised before September 4, she planned to announce a final comment period via a blog post, This Week in GNOME, and an announcement on GNOME's Discourse forum. "In general, I think it might be best if we just start using the RFC process and then implement the lessons learned later."

Change is afoot

Next year, GNOME will have its 30th anniversary. The project has made it this far without a formal technical-governance process, but a case can be made (and has been made) that it's past time for the project to adopt one and shed its "amorphous and somewhat anarchic" ways. Assuming the RFC process is adopted, it will be interesting to see what the first proposals are and how well the process works once it's put to the test.

Comments (5 posted)

The rest of the 7.3 merge window

By the time Linus Torvalds released 7.3-rc1 and closed the merge window for this release, 15,267 non-merge changesets had been pulled into the mainline repository. That is the second-highest commit count for an -rc1 release in the kernel's history; only the 6.7-rc1 release, which included nearly 3,000 commits of bcachefs history, had more. About 13,000 of those commits entered the mainline after the first 7.3 merge-window summary was written so, needless to say, there are a lot of changes to cover.

The most interesting changes made in the latter part of the 7.3 merge window include:

Architecture-specific

• The s390 architecture has a new cpuidle subsystem based on the kernel's generic cpuidle infrastructure. Also new for s390 is kernel control-flow-integrity support using the Clang compiler's software-integrity features.

BPF

• BPF kfuncs can now be marked with the KF_SPINLOCK_SAFE flag, indicating that they can safely be called with a spinlock held.
• It is easier to pass arena pointers into BPF kfuncs; a kfunc parameter that is declared with a magic suffix (__arena) to its name will automatically be offset into the arena's space and cast to the appropriate type. There is also an __arena__nullable variant for pointers that might be passed as NULL. See this commit for more information. This feature also works for struct_ops arguments.
• BPF programs can now have access to global per-CPU data; see this merge message for more information.
• The BPF verifier now provides more information on verification errors, making it easier to debug the source of the problem. See this merge message (scroll past the version information at the top) for more information.

Core kernel

• The remaining pieces of the sub-scheduler feature for sched_ext have been merged; the feature has been declared complete and working. From the merge message: "a root BPF scheduler can now hand a cgroup subtree over to a nested sub-scheduler together with revocable CPU grants, and the sub-scheduler owns all scheduling decisions for its tasks on those CPUs."
• Dynamic probes (kprobes, uprobes, and fprobes) are able to perform some simple type casting using the kernel's BTF data; in 7.3, that capability has been extended significantly. Support for boot-time probes has also been improved. See this merge message for an overview.
• The kernel has gained better working-set tracking for virtual machines; see this article for an overview of this work, which is arguably the largest chunk of LLM-assisted core code merged to date.
• The DAMON subsystem now supports data-attributes-only monitoring, for users who are more interested in the types of memory being accessed than the specifics of which memory is being accessed. See this changelog for an overview.
• The kexec handover mechanism has gained improved handling of huge pages allocated at boot time; those pages are now marked and preserved over a live update to a new kernel.

Filesystems and block I/O

• The ntfs3 filesystem has gained basic support for alternative data streams, which are accessed with a colon in the file name. So, for example, "cat file:query_streams" will list the streams associated with a file. See this changelog for some more information.
• The competing ntfs filesystem now has read-only support for Windows overlay filter (WOF) compression.
• The NFS server has gained CB_NOTIFY support for directory delegations. In short, this means that the server can report specific changes within a directory to the other side, allowing caches to be retained in many cases.
• Support for version 1 of the Btrfs free-space cache has been deprecated since the 6.11 release; in 7.3, it is being removed altogether. Older filesystems will still work, though perhaps a bit more slowly. The btrfstune tool can be used to convert a filesystem to use the newer (version 2) free-space cache. See this commit for some more information.
• The long-deprecated (since 5.9) usebackuproot Btrfs mount option has been removed; rescue=usebackuproot should be used instead.
• Buffered I/O to block devices can now use the RWF_DONTCACHE flag to avoid keeping data in the page cache.
• The ksmbd in-kernel SMB filesystem server has gained a number of new features, including Apple Time Machine support, per-share SMB3 encryption support, SMB Direct RDMA encryption, and more; see this merge message for the full list.
• The Filesystem in Userspace (FUSE) subsystem now has better support for buffer pools and zero-copy I/O when used with io_uring. See this documentation commit for some more information.
• The F2FS filesystem has gained the ability to dynamically remove partitions from a filesystem's pool, and to put them back at a later time. This commit contains some documentation on this feature.

Hardware support

• Clock: R-Car X5H clocks, Amlogic A9 SoC clock controllers, Rockchip RV1106 clock controllers, Qualcomm Glymur EVA and camera clock controllers, Hawi video clock controllers, Qualcomm Shikra global and audio core clock controllers, Qualcomm Nord display and graphics clock controllers, Maili video clock controllers, ESWIN EIC7700 HSP clock controllers, UltraRISC DP1000 clock controllers, Cixtech Sky1 audio subsystem clock controllers, and MediaTek MT8173 mfgtop clock controllers.
• GPIO and pin control: Realtek DHC RTD1625 GPIO controllers, MediaTek MT6858 pin controllers, Airoha en7523 and an7563 SoC pin controllers, and Qualcomm Maili pin controllers.
• Graphics: Anbernic TD4310 LCD panels, Chipone ICNA35XX panels, Ilitek ILI9488-based panels, Ilitek ILI7807S-based panels, Renesas R63419 dual-DSI video mode panels, and Novatek NT36536 panels.
• Hardware monitoring: Silergy SQ24860 regulators, ROHM BD12780 and BD12790 hot-swap controllers, PolarFire SoC (MPFS) temperature and voltage sensors, ESWIN EIC7700 voltage and temperature sensors, MPS MPQ82D00 step-down controllers, Kandou KB9002 PCIe retimers, Analog Devices MAX16545, MAX16550, and Volterra VT7505 PMBus controllers, MPS MPQ8646 buck converters, Altera SoC FPGA temperature and voltage sensors, and Qualcomm SPMI PMIC MBG temperature monitors.
• Industrial I/O: Analog Devices ADF41513 PLL frequency synthesizers, QST QMC5883L and QMC6308 3-axis magnetic sensors, NXP MCF54415 digital-to-analog converters, MediaTek MT6323 PMIC auxiliary analog-to-digital converters, AMD Versal system monitors, Texas Instruments ADS112C14/ADS122C14 analog-to-digital converters, InvenSense ICM-42607 motion trackers, Analog Devices LTC2378 analog-to-digital converters, Sensirion SLF3S liquid flow sensors, and Microchip MCP47A1 digital-to-analog converters.
• Input: Imagis ISA1200 haptic feedback units, MSI Claw game pads, HyperX microphone mute buttons, and AMD SFH tablet-mode switches.
• Media: Sony IMX471 and IMX678 sensors.
• Miscellaneous: R-Car X5H power-domain controllers, Spreadtrum SC2730 power regulators, Nuvoton MA35D1 QSPI controllers, Lenovo SE30 Gen 2 and SE60 watchdog timers, Nuvoton MA35D1 watchdog timers, LeapIO RAID adapters, TI BQ25630 battery chargers, SG Micro SGM41542 chargers, AMD AXI I3C master controllers, Axiado mailboxes, AMD Halo Box RGB LED controllers, SpacemiT K3 USB3/PCIe PHYs, Qualcomm QMP PCIe PHYs, Airoha SMC eFuses, Intel silicon security engine interfaces, Qualcomm MAILI interconnects, AMD MicroBlaze/V BRAM-based remote processors, ESWIN EIC7700 HSP reset controllers, Cix Sky1 audio subsystem reset controllers, Analog Devices LTC3220 18-channel LED controllers, and Silergy SY7758 backlight controllers.
• Networking: Analog Devices ADIN1140 10BASE-T1S PHYs and MAC-PHYs, Morse Micro mm81x WiFi interfaces, NXP IW61x WiFi chipsets, Realtek 8922DE/8922DE-VS PCI WiFi adapters, DAPU Telecom DAP8211R(I) gigabit Ethernet PHYs, Intel E2100 control-plane functions, and MediaTek MT7628 Embedded Ethernet switches.
• Sound: AWINIC AW88399 codecs, Qualcomm WSA885X codecs, and Realtek RT766 SDCA codecs.

Miscellaneous

• Changes to the user-space perf tool include a new function view for perf c2c; see this merge message for the full list of changes.

Networking

• It is now possible to use big TCP packets in UDP tunnels managed with VXLAN and GENEVE.

Security-related

• There is a new sysctl knob, crypto/af_alg_restrict, that regulates access to the AF_ALG cryptographic API from user space. The default is to partly restrict access to this feature (which may well be removed entirely in the future). See this changelog for an overview of the new knob, and this article for some context.
• The verification of signed BPF programs has been tightened by having the kernel verify the integrity of a program's metadata prior to loading it. See this merge message and this documentation commit for more information, and this article for some context.
• The landlock_restrict_self() system call now accepts a new flag, LANDLOCK_RESTRICT_SELF_NO_NEW_PRIVS, that sets the "no new privileges" flag for the calling process, but only after the setup of the new rule set passed to the call succeeds. This commit contains some documentation for this feature.
• The AppArmor security module now supports loading of compressed policies.

Internal kernel changes

• Rust-support additions include I/O types and projection, the fwctl API, and sleepable read-copy-update (SRCU).
• The new rv wakeup monitor can report situations where a low-priority task is waking a realtime task — often an indication of priority inversion.
• An expedited read-copy-update (RCU) grace period will now cause ordinary callbacks to be called along with the expedited ones.
• There is a new ioctl() command for the memory-allocation profiling feature. It allows the kernel to filter out unwanted information before passing the allocation data to user space, significantly improving performance. See this changelog for the (limited) documentation that exists.
• The low-level internals of the swap subsystem have been reworked around a new swap_ops structure, cleaning up the code and facilitating future improvements.
• With regard to exported symbols, 153 were removed, but an impressive 523 were added. There were also three kfuncs removed and 32 added. See this page for a full list of the changes to exported symbols and kfuncs.

The changes in 7.3-rc1 were contributed by 2,450 developers, of whom 520 were first-time contributors. There are Assisted-by tags in 1,264 of those commits — that is just over 8% of the total, but is also surely a significant undercount of LLM-assisted commits in the kernel.

Now comes the stabilization period, when bugs are found and fixed before the 7.3 release, which is most likely to happen on October 18. The 7.2 release saw over 3,000 commits applied after 7.2-rc1; if, as seems probable, that pattern repeats itself in the coming weeks, 7.3 will end up with the most commits of any kernel release — so far.

Comments (2 posted)

Securely suspending LUKS-encrypted disks

When a laptop is asleep, its memory is not unreadable. The right tooling can attach to the computer's memory bus and read out its contents, and cold-boot attacks can theoretically read values from memory for a short time after the computer loses power. That is really an unavoidable fact about the hardware, but some users would still like to ensure that, even if this happens, their long-term encryption keys, such as the key for full-disk encryption, remain unreadable. In June 2026, Ingo Blechschmidt discovered that Linux kernel versions after 6.9 (released in May 2024) were not erasing disk-encryption keys when a laptop was put to sleep, even when configured to do so. He quickly identified a potential fix, which has been merged, but it was not a comprehensive solution.

Sleeping with encrypted disks

Wiping the running system's disk-encryption keys poses a bit of a chicken-and-egg problem: without the keys present, any attempt to read something from the disk will block. Suspending access to the root disk by wiping the encryption key and then putting the computer to sleep nearly guarantees that when it is woken, the system will attempt to read files required by the screen-locker executable from disk, causing the whole system to deadlock.

Therefore, most distributions do not actually wipe the disk-encryption keys when putting a system to sleep. Instead, they keep the keys resident in memory to provide a more seamless experience, since cold-boot attacks are rare and difficult. Despite that, users who want more thorough protections can enable them. Debian was the first distribution to allow it, and uses a slightly involved mechanism to do so. When the computer is preparing to sleep, it creates a RAM disk holding all of the programs and configuration files required to prompt the user for their disk-encryption passphrase before wiping the encryption keys. When the computer is woken from sleep, the prompting program on that RAM disk runs first, unlocking the disk again and adding its key to the kernel's keyring. Subsequently, future accesses to the disk will succeed, so the rest of the user-space programs can awaken normally.

Debian packages this setup as cryptsetup-suspend, which has been ported to several other distributions. When Blechschmidt attempted to port cryptsetup-suspend to NixOS, he noticed that the encryption key remained in the memory of the virtual machine on which he was testing. Additional testing showed that the problem was in the kernel. "There is something uniquely unsettling about trusting a security mechanism for years and learning it was never doing the thing."

The bug

In 2024, Christian Brauner worked to clean up some device-mapper code to use the block-device file-descriptor-based interface rather than the older handle-based interface. As part of that refactoring, this line:

    bdev_handle = bdev_open_by_dev(dev, mode, _dm_claim_ptr, NULL);

Became:

    bdev_file = bdev_file_open_by_dev(dev, mode, _dm_claim_ptr, NULL);

It is not immediately obvious why this would cause a problem. The actual bug concerns how the thread keyring of the process that requested the block device operation is handled. When a user-space process acquires a reference to the device-mapper device for an encrypted disk, including when, for example, cryptsetup asks to relock a disk by wiping the disk-encryption key, the created bdev_file holds a reference to the thread keyring. The older handle-based interface did not do that, which is why the behavior changed.

Normally, it makes sense for a struct file in the kernel to cache the relevant credentials associated with it. In this case, however, the kernel keeps a reference to the file after the corresponding user-space process has exited, keeping the thread keyring (which contains a copy of the disk-encryption key) alive. So, even when the kernel wipes its own copies of the key from memory, as requested, the copy in the thread keyring remains behind.

The fix, which was merged in July 2026 for the 7.2 kernel, is to instruct the kernel to use its own credentials for the created file, rather than the thread's keyring:

    scoped_with_kernel_creds()
        bdev_file = bdev_file_open_by_dev(dev, mode, _dm_claim_ptr, NULL);

(That code uses the kernel's scoped cleanup helper macros to temporarily override credentials in the security context of a task with the kernel's own credentials.)

With that change, the thread keyring is freed as soon as cryptsetup exits, and the kernel's copy of the disk-encryption key is wiped on request, so the key does not remain resident in memory. However, that does little for people who have to run kernels earlier than 7.2. In response to Blechschmidt's discovery of the bug, cryptsetup maintainer Ondrej Kozina added a workaround to the tool that creates an extra intermediary keyring that can be explicitly revoked when cryptsetup exits. That way, even if a buggy kernel pins the key from the thread's keyring, that key will no longer be usable to access the disk's main encryption key. That change is included in the project's 2.8.7 release, from late July 2026.

Explicitly freeing the keyring is an important precaution in any case, Kozina said, because there are other kernel subsystems that can pin keyrings. Ensuring that none of them have been invoked incorrectly is a much less robust solution than modifying cryptsetup to work around the problem. Blechschmidt's fix only applies to encrypted block devices backed by physical devices; block devices backed by loopback interfaces or other less-common configurations may still encounter the bug.

NixOS's new suspend code

Ultimately, Blechschmidt's porting attempt was successful. He has since released an experimental program that takes a similar approach to securely suspending with full-disk encryption on NixOS. He has also added an integration test to NixOS that verifies that the keys are correctly wiped on suspend, so that the bug cannot be inadvertently reintroduced.

Debian's cryptsetup-suspend has a somewhat benign race condition: since the program first wipes the disk-encryption keys and then asks the kernel to put the computer to sleep, there is a brief window where a kernel task attempting to access the disk could lock up waiting for the key to be available. When this happens, the computer fails to go to sleep, which is annoying at best and can lead to overheating at worst. Blechschmidt's NixOS version uses a kernel patch to wipe the keys and trigger sleep mode at the same time, eliminating the potential race. It still needs to use a RAM disk to allow the user to enter the disk-encryption passphrase after the computer wakes.

Considering that cryptsetup-suspend is not enabled by default on any distribution, it's unclear exactly how many users would really have been bothered by this bug. By default, disk encryption keys remain in memory when a computer is put to sleep, and this does not seem to cause much concern. But it's nice to know that, when explicitly configured to, Linux systems will now follow through on wiping the encryption keys on sleep.

Comments (28 posted)

A note on subscription prices from LWN

The online publication industry, as a whole, is struggling, with challenges coming from multiple directions. Thanks to the support of all of you, our readers, LWN would appear to be doing better than most. But the world has changed around us and, in particular, prices have changed considerably. By now, you probably know where this is going: subscription prices at LWN will be increasing as of September 15.

We adopted the subscription model in late 2002; it was one of the best decisions we have ever made. This model makes us independent of the volatile (and surveillance-driven) advertising market and aligns our interests with those of our readers. But it does depend on support from those readers; if you have not yet subscribed to LWN, please consider doing so now — our subscribers are the only reason we continue to exist.

We have only increased prices twice in the 24 years since adopting this model; the last increase was in early 2022, nearly five years ago. That increase helped to keep us on a stable footing, and a lot more besides. We were able to hire Daroc Alden and Joe Brockmeier, and they have greatly increased the depth and range of our coverage. The LWN site has been improved in a number of ways, with features like articles in EPUB format, markdown formatting for comments, the kernel source database, full-text email and RSS feeds, dark-mode support, the public topic list, and more. A lot of effort has also gone into keeping the site alive, responsive, and reader-friendly in the face of escalating scraper attacks.

Since the 2022 price change, according to the undoubtedly reliable numbers from the US government, consumer-price inflation has added up to almost exactly 20%. Some costs (health insurance, naturally) have gone up rather more than that. We will be matching the inflation number, though, and increase prices by approximately 20%; the new monthly prices will be:

Level	Price
Starving hacker	$6.00
Professional hacker	$11.00
Project leader	$19.00
Maniacal supporter	$55.00

Prices for group subscriptions will be increased by the same amount.

All subscriptions purchased ahead of the change will remain valid through the original expiration date. The policy for individual monthly subscriptions is a little different this time; all monthly subscriptions that were active before this announcement went out will be charged at the old rate for the following six months. Reminders will be sent out to monthly subscribers before the new rates take effect.

There are few things we like less than raising prices, which is why we have done it so rarely. It would be far better to keep LWN as inexpensive as possible and make it up in volume. Subscriber growth has stalled, though, in recent years, making that strategy unworkable for now. We are working on schemes to bring in more subscribers again, but that is a long-term process; getting there requires some short-term help.

In January, LWN will begin its 30th year of publication. There is really only one reason why we are still here and vital after all that time: it is because our readers have always supported us. There are not many people who have had the good fortune to write for such a loyal community, and we are deeply grateful for it. Thank you, as always, for supporting LWN.

Comments (72 posted)

Security quote of the week

It's hard to evaluate the security of open source projects when security bug reports remain private forever. Users deserve to see security bug reports, so please remember to unset issue report confidentiality when you're done handling an issue. There are very few good reasons to keep an issue report confidential forever. If you're not planning to disclose the issue report within the next few months, it should probably already already be public.

For GNOME, I disclose issues whenever a merge request has been created or a fix lands in the git repo, or 30 days after the issue was reported, whichever comes first. Your project might prefer to wait until the fix is released before disclosing, especially if you fear that a vulnerability might actually be exploited during the window between the fix and release. Whatever you choose, please don't forget about it and leave the issue report confidential forever. That's not fair to your project's users. Even if not many people will take the time to look, users should at least have a chance to see reported issues.

— Michael Catanzaro

Comments (none posted)

Kernel release status

The current development kernel is 7.3-rc1, released on August 30. "Nothing really stands out - except for the fact that it's big. It's not the biggest rc1 we've ever had, but it's certainly up there, at least in number of commits."

This release has seen 15,267 non-merge changesets from 2,450 developers, 520 of whom were first-time kernel contributors. The release history looks like:

RC	Date	Commits
v7.3-rc1	2026-08-30	16267	16267

See the LWN KSDB v7.3 page for a lot more details.

Stable updates: 7.2.1, 7.1.11, 6.18.47, 6.12.106, 6.6.154, 6.1.185, 5.15.218, and 5.10.267 were released on August 27. The single-fix 7.2.2, 7.1.12, 6.18.48, 6.12.107, 6.6.155, 6.1.186, 5.15.219, and 5.10.268 updates followed on the 28th, and 7.2.3, 7.1.13, 6.18.49, 6.12.108, 6.6.156, 6.1.187, 5.15.220, and 5.10.269 were released on September 2. Note that 7.1.13 is the final 7.1 update.

Comments (none posted)

Ryabitsev: Creepy crawlies

Konstantin Ryabitsev has written a blog post with hard numbers about the impact of AI crawlers on the Linux kernel repositories at git.kernel.org:

Today, git.kernel.org receives about 6M daily requests demanding to see random commits. Of these, 66% are still immediately batted away with the Anubis challenge, but 33% are now solving the math and getting through to the main site — because apparently what we have to offer is worth spending a ton of cycles to calculate the Anubis challenge.

It's impossible to tell with certainty which of these are bots and which are real humans — but chances are, if it's asking for an old commit in a random old fork, it's probably not a real developer trying to do their work.

With a bunch of generous assumptions, legitimate requests are only about 2% of git.kernel.org traffic — everything else are scrapers.

Comments (101 posted)

Quote of the week

If we really have lost sparse maintenance again, and nobody is willing to step up, I can try to do a minimal job at it.

But I'll be honest: I think it's been exactly two decades since I really worked on sparse, because I think I stopped Sept 2006, and Josh Triplett took over, and then we've had Chris Li and Luc Van Oostenryck doing maintenance.

So I'd treat it like I treat my microemacs "maintainance" - sporadic, and probably with an LLM. Because I'm not really willing to put in a lot of effort.

This is partly me fishing for some poor soul who actually *wants* to maintain this. Because if somebody sees that "I'll use an LLM" as a threat: that's exactly how it's meant.

— Linus Torvalds

Comments (1 posted)

Debian votes to allow "responsible use of generative AI"

The results of the Debian general-resolution vote on the use of large language models have been posted; the winner is choice 5: Responsible Use of Generative AI.

Debian neither endorses nor prohibits the use of generative AI tools in the development, maintenance, or documentation of software, packaging, documentation, and other media published within the Debian Project. We recognize that such tools can substantially improve the productivity of contributors when used responsibly, allowing volunteers to spend more of their limited time on work that requires technical expertise, judgment, review, and collaboration.

The Debian Project nevertheless expects that all contributions submitted to Debian, regardless of how and with which tools they were produced, satisfy the same standards of quality, correctness, maintainability, and legal compliance. The use of a generative AI tool does not diminish the contributor's responsibility for the work they submit. Contributors are expected to understand, review, test, and, where appropriate, modify AI-assisted output before incorporating it into Debian.

Comments (169 posted)

Car: Dolphin 26.08 and KIO performance improvements

Méven Car has written a pair of interesting blog posts (part 1, part 2). The first post is largely about some of the recent new features and performance work that have gone into the Dolphin file manager 26.08 release, as well as the KIO framework. The second looks at the performance improvements and benchmarks for previous, current, and upcoming releases.

Copying many small files is more than twice as fast as it was in April. The gain falls off as files get larger, which is what you would expect: the fix is to the per-file overhead, and once each file carries a megabyte of actual I/O the overhead stops being what you are waiting for.

There is still a gap with cp, discussed at length in the July post. KIO is doing more than cp does, but not five times more, and the batching work that closes most of the rest of that gap is still in progress.

Comments (4 posted)

Firefox 155 released

Version 155 of the Firefox web browser has been released. Notable changes include a count in the address bar of how many ad trackers Firefox has blocked, container reordering, and ensuring that mailto: links are only opened by explicit user actions. There is also a change of the domain used for "captive portals" (such as the ones used to sign into hotel WiFI): Firefox now uses "firefox-portal-detection.com" instead of "detectportal.firefox.com", which may require a change in network allow lists.

The release also includes a number of changes that may impact web developers, as well as a number of bug fixes and security fixes.

Comments (none posted)

Incus 7.4 released

Version 7.4 of the Incus container and virtual-machine management system has been released. Notable changes in this release include UEFI Secure Boot key management, "near-live" migration of containers between Incus instances, as well as burst I/O limits for disk and network devices.

Comments (none posted)

Netdev 0x1A videos and slides are now live

The Netdev 0x1A conference was held in Rome, Italy from July 13 through July 16. Conference organizer Jami Hadi Salim has let us know that the videos and slides for all sessions are now available. Topics include Linux QUIC, shared memory socket transport, eBPF-based DDoS protection, and more.

Comments (none posted)

OpenShot 4.0 released

Version 4.0 of the OpenShot video editor has been released.

OpenShot 4.0 has arrived, bringing some of the biggest creative workflow upgrades in our history. You can now record your screen, webcam, microphone, and system audio directly into a project. You can correct and grade footage with color wheels, curves, LUTs, and professional video scopes. You can also isolate subjects with locally run machine learning models and create everything from animated audio visualizations to cinematic film looks.

See the release notes for a full list of changes.

Comments (3 posted)

Development quote of the week

Another dimension to consider is that while almost all patent litigation involves only patent-holding corporations, outside the direct experience of most users and developers, every single contributor to every single project is a copyright holder. That means any clauses could potentially impact a far larger number of people, possibly personally. In addition, the availability of such a far-reaching tool would inevitably be tempting to corporations as a vehicle for other objectives, such as to chill complaints about their poor behaviour by individuals.

So by allowing open source licenses to use copyright claims as a trigger for penalties, we open up the prospect of dark patterns impacting the whole open source community. As a license-review community we should be super cautious of this dramatic expansion of scope with its consequent significant expansion in games playable.

— Simon Phipps

Comments (none posted)

CFP Deadlines: September 3, 2026 to November 2, 2026

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

Deadline	Event Dates	Event	Location
September 6	October 6	Real-time Linux User Forum	Prague, Czechia
September 6	January 20 January 22	Everything Open	Brisbane, Australia
September 18	September 19	Software Freedom Day NJ	Montclair, NJ, US
September 21	October 10 October 11	GStreamer Conference 2026	Prague, Czech Republic
September 28	November 3 November 4	Open vSwitch and OVN 2026 Fall Conference	Heilbronn, Germany
October 1	November 7 November 8	OpenFest 2026	Sofia, Bulgaria
October 1	November 12 November 13	Ubuntu Summit 26.10	Online
October 4	November 7 November 8	OpenALT	Brno, Czechia
October 9	November 20 November 21	OLF Conference	Columbus, Ohio, US
November 1	April 1 April 4	Southern California Linux Expo	Pasadena, CA, US

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

Events: September 3, 2026 to November 2, 2026

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

Date(s)	Event	Location
August 30 September 5	FOSS4G Hiroshima 2026	Hiroshima, Japan
September 8 September 10	RustConf 2026	Montreal, Canada
September 17 September 18	Git Merge	Lisbon, Portugal
September 19 September 24	Akademy 2026	Graz, Austria
September 19	Software Freedom Day NJ	Montclair, NJ, US
September 19 September 20	Nextcloud Community Conference 2026	Berlin, Germany
September 21 September 23	Kernel Recipes	Paris, France
September 22 September 24	Reproducible Builds Summit	Gothenburg, Sweden
September 25 September 27	PostmarketOS and Alpine Linux Conference	Aachen, Germany
September 28 October 1	Alpine Linux Persistence and Storage Summit	Lizumerhütte, Tyrol, Austria
September 28 September 30	X.Org Developers Conference	Toronto, Canada
September 30 October 1	All Systems Go! 2026	Berlin, Germany
October 1	Open Tech Day | Software-defined Storage	Nuremberg, Germany
October 1 October 2	embedded Linux for Safe and Secure Applications	Göttingen, Germany
October 2 October 4	GNU Tools Cauldron	Prague, Czechia
October 3 October 4	openSUSE.Asia Summit 2026	Yogyakarta, Indonesia
October 3 October 4	Linux Days 2026	Prague, Czechia
October 5 October 7	Linux Plumbers Conference 2026	Prague, Czechia
October 6	Real-time Linux User Forum	Prague, Czechia
October 6	Yocto Project Developer Day 2026	Prague, Czechia
October 7 October 9	Embedded Linux Conference Europe	Prague, Czech Republic
October 7 October 9	Open Source Summit Europe	Prague, Czech Republic
October 8	Linux Security Summit Europe	Prague, Czechia
October 10 October 11	GStreamer Conference 2026	Prague, Czech Republic
October 13 October 15	OpenSSL Conference	Prague, Czech Republic
October 14 October 17	PyCon South Africa	Cape Town, South Africa
October 16 October 18	VideoLAN Developers' Days	Rome, Italy
October 18 October 20	All Things Open	Raleigh, NC, US
October 20 October 23	The Matrix Conference	Malmö, Sweden
October 20 October 23	PostgreSQL Conference Europe	Valencia, Spain
October 30 November 1	Qubes OS Summit	Berlin, Germany

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

Alert summary August 27, 2026 to September 2, 2026

Dist.	ID	Release	Package	Date
AlmaLinux	ALSA-2026:59372	10	assertj-core	2026-08-28
AlmaLinux	ALSA-2026:60215	9	assertj-core	2026-08-27
AlmaLinux	ALSA-2026:59380	10	attr	2026-08-26
AlmaLinux	ALSA-2026:60226	9	attr	2026-08-27
AlmaLinux	ALSA-2026:61340	10	dbus-broker	2026-09-01
AlmaLinux	ALSA-2026:61355	9	dbus-broker	2026-09-01
AlmaLinux	ALSA-2026:58899	10	firefox	2026-08-26
AlmaLinux	ALSA-2026:58897	9	firefox	2026-08-26
AlmaLinux	ALSA-2026:61379	9	freerdp	2026-09-02
AlmaLinux	ALSA-2026:62425	8	gegl	2026-09-02
AlmaLinux	ALSA-2026:62420	8	gegl04	2026-09-02
AlmaLinux	ALSA-2026:61587	9	gimp	2026-09-02
AlmaLinux	ALSA-2026:62507	8	gimp:2.8	2026-09-02
AlmaLinux	ALSA-2026:61766	8	glib2	2026-09-01
AlmaLinux	ALSA-2026:60305	8	go-toolset:rhel8	2026-08-27
AlmaLinux	ALSA-2026:60306	10	golang	2026-08-28
AlmaLinux	ALSA-2026:60304	9	golang	2026-08-27
AlmaLinux	ALSA-2026:62407	8	grafana	2026-09-02
AlmaLinux	ALSA-2026:58982	9	grafana	2026-08-26
AlmaLinux	ALSA-2026:59133	10	gstreamer1-plugins-good	2026-08-26
AlmaLinux	ALSA-2026:59972	10	gstreamer1-plugins-good	2026-08-26
AlmaLinux	ALSA-2026:59152	9	gstreamer1-plugins-good	2026-08-26
AlmaLinux	ALSA-2026:61625	10	gzip	2026-09-01
AlmaLinux	ALSA-2026:61623	9	gzip	2026-09-01
AlmaLinux	ALSA-2026:60004	10	httpd	2026-08-28
AlmaLinux	ALSA-2026:59347	9	httpd	2026-08-26
AlmaLinux	ALSA-2026:61680	10	iperf3	2026-09-01
AlmaLinux	ALSA-2026:61257	8	iperf3	2026-08-31
AlmaLinux	ALSA-2026:61389	9	iperf3	2026-09-01
AlmaLinux	ALSA-2026:57252	9	kernel	2026-08-26
AlmaLinux	ALSA-2026:59723	9	kernel	2026-08-28
AlmaLinux	ALSA-2026:62218	8	libssh	2026-09-02
AlmaLinux	ALSA-2026:60394	10	libxml2	2026-08-28
AlmaLinux	ALSA-2026:61248	8	libxml2	2026-08-31
AlmaLinux	ALSA-2026:61247	9	libxml2	2026-08-31
AlmaLinux	ALSA-2026:60329	8	mingw-openssl	2026-08-26
AlmaLinux	ALSA-2026:61242	8	mingw-sqlite	2026-08-31
AlmaLinux	ALSA-2026:59387	9	mod_http2	2026-08-26
AlmaLinux	ALSA-2026:56973	9	mysql:8.4	2026-09-01
AlmaLinux	ALSA-2026:59362	9	nginx	2026-08-26
AlmaLinux	ALSA-2026:59490	9	nginx:1.24	2026-08-26
AlmaLinux	ALSA-2026:59496	9	nginx:1.26	2026-09-01
AlmaLinux	ALSA-2026:61376	10	nodejs22	2026-09-01
AlmaLinux	ALSA-2026:61377	10	nodejs24	2026-09-01
AlmaLinux	ALSA-2026:61383	9	nodejs:22	2026-09-01
AlmaLinux	ALSA-2026:61386	9	nodejs:24	2026-09-01
AlmaLinux	ALSA-2026:55603	9	nodejs:24	2026-09-01
AlmaLinux	ALSA-2026:59379	10	pam	2026-08-26
AlmaLinux	ALSA-2026:61259	9	php	2026-09-01
AlmaLinux	ALSA-2026:62334	8	php:7.4	2026-09-02
AlmaLinux	ALSA-2026:61903	9	php:8.2	2026-09-01
AlmaLinux	ALSA-2026:61240	9	pipewire	2026-09-02
AlmaLinux	ALSA-2026:59997	10	polkit	2026-08-26
AlmaLinux	ALSA-2026:50828	9	ruby:3.3	2026-09-01
AlmaLinux	ALSA-2026:50827	9	ruby:4.0	2026-09-01
AlmaLinux	ALSA-2026:58927	10	sqlite	2026-08-26
AlmaLinux	ALSA-2026:58936	9	sqlite	2026-08-26
AlmaLinux	ALSA-2026:61586	10	tar	2026-09-02
AlmaLinux	ALSA-2026:61581	9	tar	2026-09-01
AlmaLinux	ALSA-2026:62142	10	wget	2026-09-02
AlmaLinux	ALSA-2026:62144	8	wget	2026-09-02
AlmaLinux	ALSA-2026:62143	9	wget	2026-09-02
AlmaLinux	ALSA-2026:61316	9	xmlrpc-c	2026-09-02
Debian	DSA-6472-1	stable	bubblewrap	2026-08-27
Debian	DLA-4758-1	LTS	chromium	2026-08-27
Debian	DSA-6476-1	stable	chromium	2026-08-27
Debian	DSA-6474-1	stable	cockpit	2026-08-27
Debian	DLA-4766-1	LTS	cyrus-imapd	2026-09-01
Debian	DSA-6468-1	stable	emacs	2026-08-26
Debian	DLA-4765-1	LTS	expat	2026-08-31
Debian	DSA-6470-1	stable	gimp	2026-08-27
Debian	DSA-6477-1	stable	kernel	2026-08-29
Debian	DLA-4767-1	LTS	keystone	2026-09-02
Debian	DSA-6480-1	stable	keystone	2026-09-01
Debian	DLA-4734-1	LTS	lemonldap-ng	2026-09-01
Debian	DLA-4762-1	LTS	libarchive	2026-08-31
Debian	DLA-4764-2	LTS	libdbd-csv-perl	2026-08-31
Debian	DLA-4764-1	LTS	libdbi-perl	2026-08-31
Debian	DSA-6473-1	stable	libdbi-perl	2026-08-27
Debian	DLA-4761-1	LTS	libnet-dns-perl	2026-08-30
Debian	DLA-4763-1	LTS	librabbitmq	2026-08-31
Debian	DLA-4756-1	LTS	openjdk-11	2026-08-26
Debian	DLA-4757-1	LTS	openjdk-17	2026-08-26
Debian	DLA-4760-1	LTS	roundcube	2026-08-29
Debian	DSA-6479-1	stable	roundcube	2026-08-30
Debian	DSA-6478-1	stable	starlette	2026-08-30
Debian	DSA-6475-1	stable	suricata-update	2026-08-27
Debian	DSA-6471-1	stable	wireshark	2026-08-27
Debian	DLA-4759-1	LTS	xrdp	2026-08-29
Debian	DSA-6469-1	stable	xrdp	2026-08-27
Fedora	FEDORA-2026-32054fb87a	F44	GitPython	2026-08-31
Fedora	FEDORA-2026-d0535bed52	F43	apache-ivy	2026-08-31
Fedora	FEDORA-2026-c02768c662	F44	apache-ivy	2026-08-31
Fedora	FEDORA-2026-875d2a5154	F43	bind	2026-08-31
Fedora	FEDORA-2026-d87e7f498a	F44	bind	2026-08-31
Fedora	FEDORA-2026-a1cdcc1604	F43	bluez	2026-08-27
Fedora	FEDORA-2026-d4eec45564	F43	bluez	2026-08-31
Fedora	FEDORA-2026-1fba3f22c9	F44	bluez	2026-08-28
Fedora	FEDORA-2026-96e0765328	F43	bubblewrap	2026-09-02
Fedora	FEDORA-2026-3d9bd126ce	F44	bubblewrap	2026-08-31
Fedora	FEDORA-2026-4ca90cfeb9	F44	cockpit	2026-09-02
Fedora	FEDORA-2026-f903f9ff11	F43	curl	2026-08-31
Fedora	FEDORA-2026-2f88b83676	F44	curl	2026-08-27
Fedora	FEDORA-2026-8894da1406	F43	emacs	2026-08-31
Fedora	FEDORA-2026-60eff202e7	F44	emacs	2026-08-27
Fedora	FEDORA-2026-e47f5a0b84	F44	emacs	2026-09-02
Fedora	FEDORA-2026-e205f21e0d	F43	epiphany	2026-08-31
Fedora	FEDORA-2026-b4cd43a7dc	F44	expat	2026-08-31
Fedora	FEDORA-2026-470bf100e4	F44	freerdp	2026-08-31
Fedora	FEDORA-2026-461d7d7380	F44	gdk-pixbuf2	2026-08-31
Fedora	FEDORA-2026-001de57d4f	F44	gdk-pixbuf2	2026-09-02
Fedora	FEDORA-2026-c3b358dc93	F44	golang	2026-08-27
Fedora	FEDORA-2026-b661d1a235	F43	hcloud	2026-08-31
Fedora	FEDORA-2026-dd9ec8b0c2	F44	hcloud	2026-08-31
Fedora	FEDORA-2026-71a5fbb962	F44	kbd	2026-08-31
Fedora	FEDORA-2026-f04e0d4d9d	F43	kernel	2026-08-31
Fedora	FEDORA-2026-92c9a5d8bc	F44	kernel	2026-08-31
Fedora	FEDORA-2026-4857ca6db8	F43	knot	2026-08-27
Fedora	FEDORA-2026-85369e2e3a	F44	knot	2026-08-27
Fedora	FEDORA-2026-3dea695305	F43	lego	2026-08-31
Fedora	FEDORA-2026-801a29e61d	F44	lego	2026-08-31
Fedora	FEDORA-2026-a547768693	F43	libopenmpt	2026-08-31
Fedora	FEDORA-2026-a6d074ea9c	F44	libopenmpt	2026-08-27
Fedora	FEDORA-2026-f3ca65c0c9	F43	libsoup3	2026-08-27
Fedora	FEDORA-2026-e5726efb1a	F43	mqttcli	2026-08-31
Fedora	FEDORA-2026-08fe186b29	F44	nebula	2026-08-31
Fedora	FEDORA-2026-ba51600ab3	F43	openbao	2026-08-27
Fedora	FEDORA-2026-73f5dc988f	F44	openbao	2026-08-27
Fedora	FEDORA-2026-535a408db5	F43	openssh	2026-08-27
Fedora	FEDORA-2026-51251b4657	F44	openssl	2026-09-02
Fedora	FEDORA-2026-9f32915b09	F44	openvkl	2026-09-02
Fedora	FEDORA-2026-8d9ba295e0	F43	opkssh	2026-08-31
Fedora	FEDORA-2026-f5a5073561	F44	opkssh	2026-08-31
Fedora	FEDORA-2026-1b05b6dad1	F44	postgresql16-anonymizer	2026-08-28
Fedora	FEDORA-2026-9f07e6bc2b	F44	pyOpenSSL	2026-08-28
Fedora	FEDORA-2026-9f07e6bc2b	F44	python-cryptography	2026-08-28
Fedora	FEDORA-2026-7c23b06d74	F44	python-linkify-it-py	2026-09-02
Fedora	FEDORA-2026-4f3301f569	F44	python-llm	2026-09-02
Fedora	FEDORA-2026-c10d41473a	F44	python-mkdocs-git-revision-date-localized-plugin	2026-08-31
Fedora	FEDORA-2026-397c391da2	F44	python-pip	2026-08-31
Fedora	FEDORA-2026-9f07e6bc2b	F44	python-pynitrokey	2026-08-28
Fedora	FEDORA-2026-9f32915b09	F44	rkcommon	2026-09-02
Fedora	FEDORA-2026-52e9ee2c4d	F43	rpki-client	2026-08-31
Fedora	FEDORA-2026-fb17adc9de	F44	rpki-client	2026-08-31
Fedora	FEDORA-2026-d6763b4c84	F43	rsync	2026-08-27
Fedora	FEDORA-2026-9d6aa20cbf	F43	rubygem-mechanize	2026-08-31
Fedora	FEDORA-2026-e165aa7e17	F44	rubygem-mechanize	2026-08-31
Fedora	FEDORA-2026-ce685f40fe	F43	rust-anstyle-hyperlink	2026-08-27
Fedora	FEDORA-2026-77528477c2	F44	rust-anstyle-hyperlink	2026-08-27
Fedora	FEDORA-2026-ce685f40fe	F43	rust-anstyle-progress	2026-08-27
Fedora	FEDORA-2026-77528477c2	F44	rust-anstyle-progress	2026-08-27
Fedora	FEDORA-2026-ce685f40fe	F43	rust-cargo	2026-08-27
Fedora	FEDORA-2026-77528477c2	F44	rust-cargo	2026-08-27
Fedora	FEDORA-2026-ce685f40fe	F43	rust-cargo-c	2026-08-27
Fedora	FEDORA-2026-77528477c2	F44	rust-cargo-c	2026-08-27
Fedora	FEDORA-2026-ce685f40fe	F43	rust-cargo-credential-libsecret	2026-08-27
Fedora	FEDORA-2026-77528477c2	F44	rust-cargo-credential-libsecret	2026-08-27
Fedora	FEDORA-2026-ce685f40fe	F43	rust-cargo-util	2026-08-27
Fedora	FEDORA-2026-77528477c2	F44	rust-cargo-util	2026-08-27
Fedora	FEDORA-2026-ce685f40fe	F43	rust-cargo-util-schemas	2026-08-27
Fedora	FEDORA-2026-77528477c2	F44	rust-cargo-util-schemas	2026-08-27
Fedora	FEDORA-2026-ce685f40fe	F43	rust-cargo-util-terminal	2026-08-27
Fedora	FEDORA-2026-77528477c2	F44	rust-cargo-util-terminal	2026-08-27
Fedora	FEDORA-2026-ce685f40fe	F43	rust-crates-io	2026-08-27
Fedora	FEDORA-2026-77528477c2	F44	rust-crates-io	2026-08-27
Fedora	FEDORA-2026-c3233bfa3f	F43	rust-h2	2026-08-28
Fedora	FEDORA-2026-4757e7a415	F44	rust-h2	2026-08-28
Fedora	FEDORA-2026-ce685f40fe	F43	rust-rustfix	2026-08-27
Fedora	FEDORA-2026-77528477c2	F44	rust-rustfix	2026-08-27
Fedora	FEDORA-2026-b182827934	F44	srt	2026-08-31
Fedora	FEDORA-2026-6f9cef7bfe	F44	subfinder	2026-08-31
Gentoo	202608-31		Chromium, Google Chrome, Microsoft Edge, Opera, Vivaldi	2026-08-27
Gentoo	202609-01		Chromium, Google Chrome, Microsoft Edge, Opera, Vivaldi	2026-09-01
Gentoo	202608-29		Chromium, Google Chrome, Microsoft Edge, Opera	2026-08-27
Gentoo	202608-34		Chromium, Google Chrome, Microsoft Edge, Opera	2026-08-31
Gentoo	202608-28		Chromium, Google Chrome, Microsoft Edge. Opera	2026-08-27
Gentoo	202608-33		Freenet	2026-08-29
Gentoo	202608-30		OpenRGB	2026-08-27
Gentoo	202608-32		Tor	2026-08-29
Mageia	MGASA-2026-0338	10, 9	avahi	2026-08-27
Mageia	MGASA-2026-0343	10	c-ares	2026-08-31
Mageia	MGASA-2026-0348	10	clamav	2026-08-31
Mageia	MGASA-2026-0352	10	expat, mingq-expat	2026-08-31
Mageia	MGASA-2026-0345	10, 9	firefox, nspr, nss	2026-08-31
Mageia	MGASA-2026-0342	10	flatpak	2026-08-31
Mageia	MGASA-2026-0341	10, 9	golang	2026-08-30
Mageia	MGASA-2026-0363	9	hplip	2026-09-01
Mageia	MGASA-2026-0344	10, 9	jbig2dec	2026-08-31
Mageia	MGASA-2026-0359	10, 9	nodejs	2026-09-01
Mageia	MGASA-2026-0353	10, 9	openssl	2026-08-31
Mageia	MGASA-2026-0351	10, 9	perl-Catalyst-Plugin-Authentication	2026-08-31
Mageia	MGASA-2026-0361	10, 9	perl-Date-Manip	2026-09-01
Mageia	MGASA-2026-0360	10, 9	perl-HTML-FormHandler	2026-09-01
Mageia	MGASA-2026-0362	10, 9	perl-HTTP-Date	2026-09-01
Mageia	MGASA-2026-0356	10, 9	perl-Mojolicious	2026-09-01
Mageia	MGASA-2026-0350	10, 9	perl-Plack	2026-08-31
Mageia	MGASA-2026-0347	10, 9	postgresql15, postgresql18	2026-08-31
Mageia	MGASA-2026-0339	10	python-django	2026-08-27
Mageia	MGASA-2026-0349	10	python-hpack	2026-08-31
Mageia	MGASA-2026-0340	10, 9	python-nltk	2026-08-29
Mageia	MGASA-2026-0354	10, 9	redis	2026-08-31
Mageia	MGASA-2026-0358	9	roundcubemail	2026-09-01
Mageia	MGASA-2026-0346	10, 9	thunderbird	2026-08-31
Mageia	MGASA-2026-0357	10, 9	varnish	2026-09-01
Mageia	MGASA-2026-0355	10, 9	vim	2026-09-01
Oracle	ELSA-2026-54272	OL8	abrt	2026-08-27
Oracle	ELSA-2026-59372	OL10	assertj-core	2026-08-27
Oracle	ELSA-2026-60215-0	OL9	assertj-core	2026-08-27
Oracle	ELSA-2026-60226-0	OL9	attr	2026-08-27
Oracle	ELSA-2026-61766-0	OL8	glib2	2026-09-01
Oracle	ELSA-2026-60306-0	OL10	golang	2026-09-01
Oracle	ELSA-2026-59487	OL8	gstreamer1-plugins-base	2026-08-27
Oracle	ELSA-2026-59972	OL10	gstreamer1-plugins-good	2026-08-27
Oracle	ELSA-2026-61623-0	OL9	gzip	2026-09-01
Oracle	ELSA-2026-60004-0	OL10	httpd	2026-08-27
Oracle	ELSA-2026-59821	OL8	kernel	2026-08-28
Oracle	ELSA-2026-59723	OL9	kernel	2026-08-28
Oracle	ELSA-2026-60394-0	OL10	libxml2	2026-09-01
Oracle	ELSA-2026-60329-0	OL8	mingw-openssl	2026-08-28
Oracle	ELSA-2026-61242-0	OL8	mingw-sqlite	2026-09-01
Oracle	ELSA-2026-59216	OL8	nginx:1.24	2026-08-27
Oracle	ELSA-2026-59496	OL9	nginx:1.26	2026-08-27
Oracle	ELSA-2026-61376-0	OL10	nodejs22	2026-09-01
Oracle	ELSA-2026-58819	OL10	nodejs24	2026-08-27
Oracle	ELSA-2026-59997	OL10	polkit	2026-08-27
Oracle	ELSA-2026-38487	OL8	xorg-x11-server	2026-09-01
Oracle	ELSA-2026-38489	OL10	xorg-x11-server-Xwayland	2026-09-01
Red Hat	RHSA-2026:55437-01	EL10	bind	2026-09-01
Red Hat	RHSA-2026:60383-01	EL7	bind	2026-09-01
Red Hat	RHSA-2026:54654-01	EL8	bind	2026-09-01
Red Hat	RHSA-2026:57189-01	EL9.4	bind	2026-09-01
Red Hat	RHSA-2026:55441-01	EL9.6	bind	2026-09-01
Red Hat	RHSA-2026:55442-01	EL9	bind9.18	2026-09-01
Red Hat	RHSA-2026:54576-01	EL10	dracut	2026-09-01
Red Hat	RHSA-2026:57580-01	EL10.0	dracut	2026-09-01
Red Hat	RHSA-2026:54575-01	EL8	dracut	2026-09-01
Red Hat	RHSA-2026:61252-01	EL8.8	dracut	2026-09-01
Red Hat	RHSA-2026:54571-01	EL9	dracut	2026-09-01
Red Hat	RHSA-2026:57775-01	EL9.2	dracut	2026-09-01
Red Hat	RHSA-2026:57785-01	EL9.4	dracut	2026-09-01
Red Hat	RHSA-2026:57772-01	EL9.6	dracut	2026-09-01
Red Hat	RHSA-2026:57015-01	EL10	glib2	2026-09-01
Red Hat	RHSA-2026:61766-01	EL8	glib2	2026-09-01
Red Hat	RHSA-2026:55440-01	EL9	glib2	2026-09-01
Red Hat	RHSA-2026:60305-01	EL8	go-toolset:rhel8	2026-09-02
Red Hat	RHSA-2026:60306-01	EL10	golang	2026-09-02
Red Hat	RHSA-2026:61882-01	EL10.0	golang	2026-09-02
Red Hat	RHSA-2026:60304-01	EL9	golang	2026-09-02
Red Hat	RHSA-2026:61253-01	EL9.2	golang	2026-09-01
Red Hat	RHSA-2026:57649-01	EL9.4	golang	2026-09-01
Red Hat	RHSA-2026:62405-01	EL9.4	golang	2026-09-02
Red Hat	RHSA-2026:62404-01	EL9.6	golang	2026-09-02
Red Hat	RHSA-2026:62407-01	EL8	grafana	2026-09-02
Red Hat	RHSA-2026:62406-01	EL9	grafana	2026-09-02
Red Hat	RHSA-2026:61625-01	EL10	gzip	2026-09-01
Red Hat	RHSA-2026:61623-01	EL9	gzip	2026-09-01
Red Hat	RHSA-2026:59723-01	EL9	kernel	2026-09-01
Red Hat	RHSA-2026:59662-01	EL9.2	kernel	2026-09-01
Red Hat	RHSA-2026:59663-01	EL9.2	kernel-rt	2026-09-01
Red Hat	RHSA-2026:35842-01	EL10	nodejs22	2026-08-31
Red Hat	RHSA-2026:39246-01	EL10.0	nodejs22	2026-08-31
Red Hat	RHSA-2026:35841-01	EL10	nodejs24	2026-08-31
Red Hat	RHSA-2026:41947-01	EL8	nodejs:22	2026-08-31
Red Hat	RHSA-2026:35892-01	EL9	nodejs:22	2026-08-31
Red Hat	RHSA-2026:39868-01	EL8	nodejs:24	2026-08-31
Red Hat	RHSA-2026:35891-01	EL9	nodejs:24	2026-08-31
Red Hat	RHSA-2026:58563-01	EL7	openssl	2026-09-01
Red Hat	RHSA-2026:61585-01	EL9.2	osbuild-composer	2026-09-01
Red Hat	RHSA-2026:61245-01	EL9.2	osbuild-composer	2026-09-01
Red Hat	RHSA-2026:59562-01	EL9.4	osbuild-composer	2026-09-01
Red Hat	RHSA-2026:59560-01	EL9.6	osbuild-composer	2026-09-01
Red Hat	RHSA-2026:61581-01	EL9	tar	2026-09-01
Red Hat	RHSA-2026:55892-01	EL10	unbound	2026-09-01
Red Hat	RHSA-2026:55784-01	EL8	unbound	2026-09-01
Red Hat	RHSA-2026:55841-01	EL9	unbound	2026-09-01
Slackware	SSA:2026-244-01		pcre2	2026-09-01
SUSE	SUSE-SU-2026:3869-1	SLE15 oS15.4	7zip	2026-08-31
SUSE	SUSE-SU-2026:23317-1	SLE16.0	7zip	2026-08-31
SUSE	SUSE-SU-2026:23312-1	SLE16.0	ImageMagick	2026-08-31
SUSE	SUSE-SU-2026:3803-1	SLE15	LibVNCServer	2026-08-26
SUSE	openSUSE-SU-2026:11602-1	TW	OpenRGB	2026-08-28
SUSE	SUSE-SU-2026:3915-1	SLE12	apache2-mod_auth_openidc	2026-09-01
SUSE	openSUSE-SU-2026:11582-1	TW	apache2-mod_auth_openidc	2026-08-26
SUSE	SUSE-SU-2026:3863-1	SLE15 oS15.6	apptainer	2026-08-28
SUSE	openSUSE-SU-2026:21675-1	oS16.0	broot	2026-08-29
SUSE	SUSE-SU-2026:3817-1	SLE15 oS15.4	buildah	2026-08-26
SUSE	SUSE-SU-2026:3900-1	SLE12	busybox	2026-08-31
SUSE	SUSE-SU-2026:3908-1	oS15.4	busybox	2026-09-01
SUSE	openSUSE-SU-2026:11627-1	TW	bzip2	2026-08-31
SUSE	SUSE-SU-2026:23364-1	SLE-m6.0	c-ares	2026-08-31
SUSE	openSUSE-SU-2026:11593-1	TW	c-ares-devel	2026-08-27
SUSE	openSUSE-SU-2026:11606-1	TW	cadvisor	2026-08-29
SUSE	openSUSE-SU-2026:11628-1	TW	chromedriver	2026-08-31
SUSE	openSUSE-SU-2026:0318-1	osB15	chromium	2026-08-31
SUSE	openSUSE-SU-2026:21674-1	oS16.0	coredns	2026-08-29
SUSE	openSUSE-SU-2026:11617-1	TW	coturn	2026-08-30
SUSE	SUSE-SU-2026:23355-1	SLE-m6.1	cpio	2026-08-31
SUSE	SUSE-SU-2026:3918-1	SLE12	cups-filters	2026-09-01
SUSE	SUSE-SU-2026:23361-1	SLE-m6.0	curl	2026-08-31
SUSE	SUSE-SU-2026:23350-1	SLE-m6.1	curl	2026-08-31
SUSE	SUSE-SU-2026:3814-1	SLE12	curl	2026-08-26
SUSE	openSUSE-SU-2026:21692-1	oS16.0	dhcpcd	2026-08-31
SUSE	openSUSE-SU-2026:11609-1	TW	distribution-registry	2026-08-29
SUSE	SUSE-SU-2026:3818-1	SLE15 SLE5.3 SLE5.4 SLE5.5 SLE-m5.3 SLE-m5.4 SLE-m5.5	docker	2026-08-26
SUSE	openSUSE-SU-2026:11629-1	TW	dovecot24	2026-08-31
SUSE	SUSE-SU-2026:23276-1	SLE-m6.2	dracut	2026-08-26
SUSE	SUSE-SU-2026:23314-1	SLE16.0	dracut	2026-08-31
SUSE	openSUSE-SU-2026:21639-1	oS16.0	dracut	2026-08-27
SUSE	SUSE-SU-2026:3831-1	oS15.4	evince	2026-08-27
SUSE	SUSE-SU-2026:23304-1	SLE16.0	firefox	2026-08-31
SUSE	openSUSE-SU-2026:21663-1	oS16.0	gh	2026-08-27
SUSE	openSUSE-SU-2026:0309-1	osB15	gh	2026-08-30
SUSE	openSUSE-SU-2026:0305-1	osB15	git-lfs	2026-08-30
SUSE	SUSE-SU-2026:23300-1	SLE16.0	go1.25	2026-08-31
SUSE	SUSE-SU-2026:3815-1	SLE15 oS15.6	go1.25-openssl	2026-08-26
SUSE	SUSE-SU-2026:23301-1	SLE16.0	go1.26	2026-08-31
SUSE	SUSE-SU-2026:3816-1	SLE15 oS15.6	go1.26-openssl	2026-08-26
SUSE	openSUSE-SU-2026:21705-1	oS16.0	go1.26-openssl	2026-08-31
SUSE	SUSE-SU-2026:3830-1	SLE15	go1.27	2026-08-26
SUSE	SUSE-SU-2026:3883-1	SLE12	google-cloud-sap-agent	2026-08-31
SUSE	openSUSE-SU-2026:11619-1	TW	grafana	2026-08-30
SUSE	SUSE-SU-2026:23274-1	SLE-m6.2	gstreamer-plugins-bad	2026-08-26
SUSE	SUSE-SU-2026:23308-1	SLE16.0	gstreamer-plugins-bad	2026-08-31
SUSE	openSUSE-SU-2026:21629-1	oS16.0	gstreamer-plugins-bad	2026-08-27
SUSE	SUSE-SU-2026:23363-1	SLE-m6.0	gzip	2026-08-31
SUSE	SUSE-SU-2026:23356-1	SLE-m6.1	gzip	2026-08-31
SUSE	openSUSE-SU-2026:21666-1	oS16.0	gzip	2026-08-28
SUSE	SUSE-SU-2026:3882-1	SLE15 SLE5.5 SLE-m5.5	helm	2026-08-31
SUSE	openSUSE-SU-2026:11630-1	TW	istioctl	2026-08-31
SUSE	openSUSE-SU-2026:11594-1	TW	java-11-openjdk	2026-08-27
SUSE	openSUSE-SU-2026:11640-1	TW	java-17-openj9	2026-09-01
SUSE	openSUSE-SU-2026:11641-1	TW	java-1_8_0-openj9	2026-09-01
SUSE	openSUSE-SU-2026:11621-1	TW	java-25-openjdk	2026-08-30
SUSE	openSUSE-SU-2026:11631-1	TW	jfrog-cli	2026-08-31
SUSE	openSUSE-SU-2026:11634-1	TW	jupyter-jupyterlab	2026-08-31
SUSE	SUSE-SU-2026:3809-1	SLE11	kernel	2026-08-26
SUSE	SUSE-SU-2026:3810-1	SLE15	kernel	2026-08-26
SUSE	SUSE-SU-2026:3824-1	SLE15 oS15.6	kubernetes	2026-08-26
SUSE	SUSE-SU-2026:3823-1	SLE15 oS15.6	kubernetes-old	2026-08-26
SUSE	SUSE-SU-2026:3905-1	SLE12	libapr-util1	2026-09-01
SUSE	SUSE-SU-2026:23275-1	SLE-m6.2	libarchive	2026-08-26
SUSE	SUSE-SU-2026:23309-1	SLE16.0	libarchive	2026-08-31
SUSE	SUSE-SU-2026:3872-1	SLE12	libcares2	2026-08-31
SUSE	SUSE-SU-2026:3921-1	SLE5.3 SLE5.4 SLE-m5.3 SLE-m5.4 oS15.4	libgcrypt	2026-09-02
SUSE	SUSE-SU-2026:23320-1	SLE16.0	libheif	2026-08-31
SUSE	openSUSE-SU-2026:11623-1	TW	libopenssl-3-devel	2026-08-30
SUSE	SUSE-SU-2026:23313-1	SLE16.0	liboqs	2026-08-31
SUSE	openSUSE-SU-2026:21634-1	oS16.0	liboqs	2026-08-27
SUSE	openSUSE-SU-2026:21694-1	oS16.0	librest	2026-08-31
SUSE	SUSE-SU-2026:3834-1	SLE15 oS15.6	librest0_7	2026-08-27
SUSE	openSUSE-SU-2026:11596-1	TW	libsoup-3_0-0	2026-08-28
SUSE	openSUSE-SU-2026:11579-1	TW	libwireshark19	2026-08-26
SUSE	openSUSE-SU-2026:0315-1	osB15	mozjs102	2026-08-30
SUSE	SUSE-SU-2026:3835-1	SLE15	openssl, openssl-3	2026-08-27
SUSE	SUSE-SU-2026:3877-1	SLE15 SLE5.5 SLE-m5.5 oS15.5	openssl-1_1	2026-08-31
SUSE	SUSE-SU-2026:3878-1	SLE15 oS15.6	openssl-1_1	2026-08-31
SUSE	SUSE-SU-2026:3876-1	SLE15 oS15.5	openssl-3	2026-08-31
SUSE	SUSE-SU-2026:3866-1	SLE15 oS15.6	openssl-3	2026-08-31
SUSE	SUSE-SU-2026:3871-1	oS15.4	openvpn	2026-08-31
SUSE	openSUSE-SU-2026:11632-1	TW	owasp-modsecurity-crs	2026-08-31
SUSE	SUSE-SU-2026:23277-1	SLE-m6.2	pcp	2026-08-26
SUSE	SUSE-SU-2026:23316-1	SLE16.0	pcp	2026-08-31
SUSE	openSUSE-SU-2026:21636-1	oS16.0	pcp	2026-08-27
SUSE	openSUSE-SU-2026:11633-1	TW	php-composer2	2026-08-31
SUSE	SUSE-SU-2026:3854-1	SLE15 SES7.1 oS15.3	podman	2026-08-28
SUSE	SUSE-SU-2026:3853-1	SLE15 SLE5.3 SLE5.4 SLE-m5.3 SLE-m5.4 oS15.4	podman	2026-08-28
SUSE	openSUSE-SU-2026:21699-1	oS16.0	postgresql14	2026-08-31
SUSE	openSUSE-SU-2026:21700-1	oS16.0	postgresql15	2026-08-31
SUSE	openSUSE-SU-2026:21702-1	oS16.0	postgresql17	2026-08-31
SUSE	openSUSE-SU-2026:21703-1	oS16.0	postgresql18	2026-08-31
SUSE	openSUSE-SU-2026:11613-1	TW	pyenv	2026-08-29
SUSE	openSUSE-SU-2026:0311-1	osB15	pyenv	2026-08-30
SUSE	openSUSE-SU-2026:0314-1	osB15	python-PyPDF2	2026-08-30
SUSE	SUSE-SU-2026:3862-1	SLE12	python	2026-08-28
SUSE	openSUSE-SU-2026:21685-1	oS16.0	python-cryptography	2026-08-31
SUSE	SUSE-SU-2026:3898-1	MP4.3 SLE15 oS15.4	python-httplib2	2026-08-31
SUSE	SUSE-SU-2026:23319-1	SLE16.0	python-pip	2026-08-31
SUSE	SUSE-SU-2026:3910-1	MP4.3 SLE15 oS15.4	python-sqlparse	2026-09-01
SUSE	SUSE-SU-2026:3907-1	SLE15 oS15.6	python-sqlparse	2026-09-01
SUSE	SUSE-SU-2026:3906-1	SLE15 oS15.3	python3-sqlparse	2026-09-01
SUSE	SUSE-SU-2026:3851-1	SLE15 oS15.4	python310	2026-08-28
SUSE	SUSE-SU-2026:3832-1	oS15.4	python310-pip	2026-08-27
SUSE	SUSE-SU-2026:3870-1	SLE15 oS15.6	python312	2026-08-31
SUSE	openSUSE-SU-2026:11614-1	TW	python313-Authlib	2026-08-29
SUSE	SUSE-SU-2026:23303-1	SLE16.0	python313	2026-08-31
SUSE	openSUSE-SU-2026:11625-1	TW	python313-djangorestframework	2026-08-31
SUSE	openSUSE-SU-2026:11585-1	TW	python313-mistune	2026-08-27
SUSE	openSUSE-SU-2026:11626-1	TW	python313-starlette	2026-08-31
SUSE	openSUSE-SU-2026:11635-1	TW	python313-uv	2026-09-01
SUSE	SUSE-SU-2026:3855-1	SLE12	python36	2026-08-28
SUSE	SUSE-SU-2026:3846-1	SLE12	python36-pip	2026-08-27
SUSE	SUSE-SU-2026:23362-1	SLE-m6.0	qemu	2026-08-31
SUSE	SUSE-SU-2026:23351-1	SLE-m6.1	qemu	2026-08-31
SUSE	SUSE-SU-2026:3806-1	SLE15 oS15.6	qemu	2026-08-26
SUSE	SUSE-SU-2026:23305-1	SLE16.0	qt6-svg	2026-08-31
SUSE	openSUSE-SU-2026:21626-1	oS16.0	qt6-svg	2026-08-27
SUSE	SUSE-SU-2026:3868-1	SLE12	quagga	2026-08-31
SUSE	openSUSE-SU-2026:21681-1	oS16.0	rav1e	2026-08-31
SUSE	SUSE-SU-2026:3852-1	SLE15 oS15.4	rekor	2026-08-28
SUSE	SUSE-SU-2026:23321-1	SLE16.0	rmt-server	2026-08-31
SUSE	openSUSE-SU-2026:21640-1	oS16.0	rmt-server	2026-08-27
SUSE	SUSE-SU-2026:3822-1	SLE15	rootlesskit	2026-08-26
SUSE	SUSE-SU-2026:23254-1	SLE-m6.1	rsync	2026-08-26
SUSE	SUSE-SU-2026:23289-1	SLE-m6.2	rsync	2026-08-28
SUSE	SUSE-SU-2026:23323-1	SLE16.0	rsync	2026-08-31
SUSE	openSUSE-SU-2026:21650-1	oS16.0	rsync	2026-08-27
SUSE	SUSE-SU-2026:3867-1	SLE12	rsyslog	2026-08-31
SUSE	SUSE-SU-2026:3861-1	SLE15	rsyslog	2026-08-28
SUSE	SUSE-SU-2026:3859-1	SLE15 oS15.4	rsyslog	2026-08-28
SUSE	SUSE-SU-2026:3860-1	SLE15 oS15.6	rsyslog	2026-08-28
SUSE	SUSE-SU-2026:23236-1	SLE16.0	snpguest	2026-08-25
SUSE	SUSE-SU-2026:23327-1	SLE16.0	snphost	2026-08-31
SUSE	SUSE-SU-2026:23347-1	SLE-m6.1	sssd	2026-08-31
SUSE	SUSE-SU-2026:3899-1	SLE15	sssd	2026-08-31
SUSE	SUSE-SU-2026:3843-1	SLE5.3 SLE5.4 SLE-m5.3 SLE-m5.4 oS15.4	suseconnect-ng	2026-08-27
SUSE	SUSE-SU-2026:3916-1	MP4.3 SLE15	terraform-provider-aws, terraform-provider-azurerm, terraform-provider-external, terraform-provider-google, terraform-provider-helm, terraform-provider-kubernetes, terraform-provid	2026-09-01
SUSE	SUSE-SU-2026:3847-1	oS15.4	texlive	2026-08-27
SUSE	SUSE-SU-2026:3897-1	SLE15	thunderbird	2026-08-31
SUSE	openSUSE-SU-2026:11590-1	TW	tor	2026-08-27
SUSE	openSUSE-SU-2026:0306-1	osB15	tor	2026-08-30
SUSE	openSUSE-SU-2026:0312-1	osB15	trivy	2026-08-30
SUSE	SUSE-SU-2026:3917-1	SLE12	ucode-intel	2026-09-01
SUSE	SUSE-SU-2026:23360-1	SLE-m6.0	unbound	2026-08-31
SUSE	SUSE-SU-2026:23349-1	SLE-m6.1	unbound	2026-08-31
SUSE	SUSE-SU-2026:3884-1	SLE15 SLE5.5 SLE-m5.5	unbound	2026-08-31
SUSE	SUSE-SU-2026:3885-1	SLE15 oS15.6	unbound	2026-08-31
SUSE	SUSE-SU-2026:23255-1	SLE-m6.1	util-linux	2026-08-26
SUSE	SUSE-SU-2026:3812-1	SLE15 SLE5.3 SLE5.4 SLE-m5.3 SLE-m5.4 oS15.4	util-linux	2026-08-26
SUSE	SUSE-SU-2026:3813-1	SLE15 SLE5.5 SLE-m5.5 oS15.5	util-linux	2026-08-26
SUSE	openSUSE-SU-2026:0307-1	osB15	v2ray-core	2026-08-30
SUSE	SUSE-SU-2026:23346-1	SLE-m6.0	vim	2026-08-31
SUSE	SUSE-SU-2026:23365-1	SLE-m6.0	vim	2026-08-31
SUSE	openSUSE-SU-2026:21671-1	oS16.0	vim	2026-08-29
SUSE	SUSE-SU-2026:23297-1	SLE-m6.2	wget	2026-08-28
SUSE	SUSE-SU-2026:23326-1	SLE16.0	wget	2026-08-31
SUSE	openSUSE-SU-2026:21665-1	oS16.0	wget	2026-08-28
SUSE	SUSE-SU-2026:3837-1	SLE12	wicked	2026-08-27
SUSE	SUSE-SU-2026:3841-1	SLE15	wicked	2026-08-27
SUSE	SUSE-SU-2026:3842-1	SLE15 SLE5.3 SLE5.4 SLE-m5.3 SLE-m5.4 oS15.4	wicked	2026-08-27
SUSE	SUSE-SU-2026:3839-1	SLE15 SLE5.5 SLE-m5.5 oS15.5	wicked	2026-08-27
SUSE	SUSE-SU-2026:3840-1	SLE15 oS15.6	wicked	2026-08-27
SUSE	openSUSE-SU-2026:11636-1	TW	wicked	2026-09-01
SUSE	openSUSE-SU-2026:21669-1	oS16.0	wicked	2026-08-28
SUSE	SUSE-SU-2026:23311-1	SLE16.0	xmlrpc-c	2026-08-31
SUSE	openSUSE-SU-2026:21633-1	oS16.0	xmlrpc-c	2026-08-27
SUSE	SUSE-SU-2026:3893-1	SLE12	yast2-auth-client	2026-08-31
SUSE	SUSE-SU-2026:3914-1	SLE15	yast2-auth-client	2026-09-01
SUSE	SUSE-SU-2026:3894-1	SLE15 oS15.4	yast2-auth-client	2026-08-31
SUSE	SUSE-SU-2026:3895-1	SLE15 oS15.5	yast2-auth-client	2026-08-31
SUSE	SUSE-SU-2026:3901-1	SLE15 oS15.6	yast2-auth-client	2026-08-31
SUSE	SUSE-SU-2026:3890-1	SLE12	yast2-samba-client	2026-08-31
SUSE	SUSE-SU-2026:3886-1	SLE15	yast2-samba-client	2026-08-31
SUSE	SUSE-SU-2026:3889-1	SLE15 oS15.4	yast2-samba-client	2026-08-31
SUSE	SUSE-SU-2026:3888-1	SLE15 oS15.5	yast2-samba-client	2026-08-31
SUSE	SUSE-SU-2026:3887-1	SLE15 oS15.6	yast2-samba-client	2026-08-31
Ubuntu	USN-8691-1	14.04 16.04 18.04 20.04 22.04 24.04 26.04	attr	2026-08-31
Ubuntu	USN-8682-1	14.04 16.04 18.04 20.04	bind9	2026-08-26
Ubuntu	USN-8696-1	22.04 24.04 26.04	bind9	2026-08-31
Ubuntu	USN-8685-1	14.04 16.04 18.04 20.04 22.04 24.04 26.04	bzip2	2026-08-31
Ubuntu	USN-8697-1	22.04 24.04 26.04	coreutils	2026-08-31
Ubuntu	USN-8704-1	14.04 16.04 18.04 20.04 22.04 24.04 26.04	cpio	2026-08-31
Ubuntu	USN-8692-1	14.04 16.04 18.04 20.04 22.04 24.04 26.04	diffutils	2026-08-31
Ubuntu	USN-8698-1	24.04 26.04	freerdp3	2026-08-31
Ubuntu	USN-8710-1	14.04 16.04 18.04 20.04 22.04 24.04 26.04	libevent	2026-09-01
Ubuntu	USN-8711-1	22.04 24.04 26.04	libgcrypt20	2026-09-01
Ubuntu	USN-8683-1	18.04 20.04 22.04 24.04	libheif	2026-08-26
Ubuntu	USN-8699-1	22.04 24.04 26.04	libssh	2026-08-31
Ubuntu	USN-8644-3	14.04 16.04 18.04	linux-azure, linux-azure-4.15, linux-azure-fips	2026-08-27
Ubuntu	USN-8643-5	22.04 24.04	linux-azure-6.8, linux-ibm, linux-ibm-6.8, linux-oracle-6.8, linux-raspi, linux-raspi-realtime	2026-08-27
Ubuntu	USN-8658-4	20.04	linux-azure-fde-5.15	2026-08-27
Ubuntu	USN-8661-3	22.04	linux-fips, linux-gke	2026-08-27
Ubuntu	USN-8666-3	20.04	linux-gcp-fips	2026-08-27
Ubuntu	USN-8700-1	22.04 24.04 26.04	mysql-8.0, mysql-8.4	2026-08-31
Ubuntu	USN-8709-1	14.04 16.04 18.04 20.04 22.04 24.04	ncurses	2026-09-01
Ubuntu	USN-8686-1	22.04 24.04	opencryptoki	2026-08-27
Ubuntu	USN-8707-1	26.04	opencryptoki	2026-09-01
Ubuntu	USN-8693-1	26.04	openjdk-17-crac	2026-08-31
Ubuntu	USN-8694-1	26.04	openjdk-21-crac	2026-08-31
Ubuntu	USN-8695-1	26.04	openjdk-25-crac	2026-08-31
Ubuntu	USN-8689-1	26.04	openjdk-26	2026-08-31
Ubuntu	USN-8678-2	14.04 16.04 18.04 20.04	openssl, openssl1.0	2026-08-26
Ubuntu	USN-8678-3	26.04	openssl	2026-08-31
Ubuntu	USN-8687-1	18.04 20.04 22.04 24.04	p11-kit	2026-08-31
Ubuntu	USN-8688-1	18.04 20.04 22.04 24.04	pam	2026-08-27
Ubuntu	USN-8688-2	26.04	pam	2026-09-01
Ubuntu	USN-8684-1	24.04	perl	2026-08-31
Ubuntu	USN-8690-1	20.04 22.04 24.04 26.04	pillow	2026-09-01
Ubuntu	USN-8712-1	22.04 24.04 26.04	pyasn1	2026-09-01
Ubuntu	USN-8708-1	26.04	rust-sudo-rs	2026-09-01
Ubuntu	USN-8555-2	14.04	ubuntu-advantage-tools	2026-09-01
Ubuntu	USN-8701-1	24.04 26.04	udisks2	2026-08-31
Ubuntu	USN-8702-1	22.04 24.04 26.04	util-linux	2026-08-31
Ubuntu	USN-8703-1	24.04 26.04	webkit2gtk	2026-08-31
Ubuntu	USN-8705-2	18.04 20.04	zfs-linux	2026-09-01
Ubuntu	USN-8705-1	22.04 24.04 26.04	zfs-linux	2026-08-31
Ubuntu	USN-8706-1	24.04 26.04	zlib	2026-09-01

Full Story (comments: none)