Welcome to the LWN.net Weekly Edition for July 30, 2026

This edition contains the following feature content:

• Hazard pointers for the kernel: an alternative approach to lockless data updates that may offer better performance.
• A report from Debian's new DFSG team: how the ftpmaster team split is working out for the project so far.
• An operations structure for swap devices: different approaches to an abstraction layer for swap storage.
• Additional coverage from the 2026 Linux Storage, Filesystem, Memory Management, and BPF Summit:
• An update on netkit and the use of BPF in user space: the work to allow zero-copy networking within virtual machines continues.
• Debugging information for inlined functions: adding information about inlined functions to BTF.
• Fedora approves a smaller GRUB: FESCo gives the go-ahead to a slimmed-down GRUB package for confidential computing and other use cases.
• Progress toward compiling Linux with gccrs: a look at how the Rust frontend for GCC is progressing.

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)

Hazard pointers for the kernel

The kernel's read-copy-update (RCU) subsystem ensures that data will not be deleted until it is known that there are no threads holding references to it. RCU works well and is widely used throughout the kernel, but it can increase memory use and add significant delays before unused kernel objects are cleaned up. Hazard pointers are an alternative approach to lockless data updates that offers better performance, for some situations at least. The kernel community is currently considering a hazard-pointer implementation by Mathieu Desnoyers and Paul McKenney.

Like RCU, hazard pointers are meant to be a way to hold a short-lived reference to an immutable object that may disappear once all references are gone. Code holding references to RCU-protected data must disable preemption; hazard pointers, instead, appear to be designed to allow preemption, though such use may not be entirely optimal.

The hazard-pointer API

At the API level, code using hazard pointers must allocate a context (struct hazptr_ctx) for each pointer that will be in use at the same time; this structure is normally placed on the stack. If there is a pointer (we'll call it resource) to an object to be protected by a hazard pointer, and code needs to access that object, the pointer must first be acquired with a call to:

    void *hazptr_acquire(struct hazptr_ctx *ctx, void * const *address);

Where ctx is the above-described context, and address, in this case, would be the address of resource. This call will return the current value of resource (the address of the protected object) and ensure that this object will not be changed or deleted for as long as the reference remains. When work with the protected object is complete, the code must call:

    void hazptr_release(struct hazptr_ctx *ctx, void *address);

Where address is the address of the old copy of the resource; after this call, the previously protected object can no longer be used.

Normally, a hazard pointer must be released in the same execution context in which it was obtained — in the same thread or interrupt handler, in other words. There may be times when it is necessary to release the pointer in a different setting, though. That can be done, but only if the hazard-pointer context is passed to this function:

    void hazptr_detach(struct hazptr_ctx *ctx);

This call must, clearly, be made before the pointer is actually released.

On the producer side, when the time comes to replace the protected object with a new one, code should create and initialize the new object, aim the resource pointer at this new copy, then call:

    void hazptr_synchronize(void *address);

This call, which must be made in a preemptible context, will wait until there are no more hazard-pointer references to the given address, then return to the caller. At that point, the object at that address can be freed.

The implementation

The core idea behind hazard pointers is relatively simple: a call to hazptr_acquire() adds the pointer to a special list, while hazptr_release() removes it from that list. When a call to hazptr_synchronize() is made, that list is scanned for the address in question; if the address is found there, the function will wait until it is removed. This algorithm could be implemented with a simple linked list protected by a lock, but the whole purpose is to maximize performance, so the actual implementation is somewhat more complicated.

The hazard-pointer code maintains a global per-CPU array, with four slots on each CPU. The oversimplified explanation of the algorithm is that, on a call to hazptr_acquire(), an empty slot is found, and the relevant address is stored there. Calls to hazptr_synchronize() can then simply scan those slots (on each CPU) and wait until none of them contain the protected address. But, once again, there are complications.

One of those is an ordering problem. hazptr_acquire() must read the pointer to acquire, then store it into the slot. On the synchronize side, that pointer must be changed, then the slots searched for the previous value. If the synchronization code runs between the two acquire operations — after the pointer is read, but before it is stored into a slot — it will conclude that there are no references and release an object that is still in use. That is not the sort of hazard the authors of this code care to face.

To address this problem, the slots are maintained in three different states. If the address stored there is NULL, the slot is free and not protecting a pointer. If it contains a non-NULL pointer value, the slot is occupied protecting that pointer. But there is a third value, HAZPTR_WILDCARD (which happens to have the value 0x1UL) to indicate that the slot is in the process of being assigned. hazptr_acquire() starts by finding a free slot and setting its value to HAZPTR_WILDCARD; only then does it read the address value and, subsequently, store it in the slot. hazptr_synchronize() treats any slot containing HAZPTR_WILDCARD as if it contained the pointer it is looking for, so it will wait until the real pointer value appears in that slot before returning. That extra check prevents the race described above.

The other complication is: what happens if there is a need for more than four slots? Any given function may not need so many slots, but there is no knowing how many will be used by functions further down the call chain. The hazard-pointer API could just return an error in that case, but that seems like a sure way to create hard-to-find bugs. Instead, handling this case is what the hazptr_ctx structure is for.

That structure contains a spare slot that can be used to hold the hazard pointer if none of the per-CPU slots are available. In that case, the code uses the slot in the context structure, then links that structure into a per-CPU list. When a hazptr_synchronize() call happens, it must search those per-CPU lists as well as the per-CPU slots to ensure that the address is not under protection. As an added twist, there are actually two per-CPU linked lists; one is available for adding to while the other is available for searching, again to prevent race conditions. The list traversal risks slowing everything down, but those lists should almost always be empty.

The overflow slot has a couple of uses beyond extending the four per-CPU slots. The hazptr_detach() call described above will immediately move the given pointer into the overflow slot (if it is not already there), freeing the per-CPU slot for other uses. There is also a special callback added to the scheduler that is called on context switches; that one moves all of the per-CPU slots to their corresponding overflow slots. In this way, if a thread is preempted while using hazard-pointer slots, it will free the faster per-CPU slots for whoever runs next.

This code is still in a relatively early state, and could yet evolve somewhat before finding its way into the mainline. Importantly, the patch series does not include any users of the API, which is normally a requirement for a new subsystem like this. The creation of those users may well reveal API shortcomings that can be resolved before merging upstream. So it is hard to hazard a guess as to when hazard pointers will be available for use by kernel developers.

Comments (9 posted)

A report from Debian's new DFSG team

The DFSG, Licensing & New Packages Team (usually shortened to "DFSG team") was created in October 2025 as part of the ftpmaster team split. Its job is to review packages in the new queue for compliance with the Debian Free Software Guidelines (DFSG), among other things, before the packages are allowed to enter the Debian archive. The change was long in coming, and some questions remained after the split whether it was the right move. Andrew McMillan provided an overview of the team's activities and its current status during DebConf26. While it may be too early to say with certainty, his report suggests that the new division of duties is working out well.

I did not attend DebConf26, but I did watch the recording of McMillan's talk, which is available in WebM format (HD quality, low-resolution video). Slides from the presentation have not yet been made available.

Ftpmaster split

For more than two decades, Debian's ftpmaster team was responsible for allowing new packages to enter Debian, removing old packages, and otherwise maintaining Debian's archive. At times, packages languished in the new queue longer than Debian developers thought that they should, and the team was seen by some as a bottleneck that was in need of attention.

The idea of refactoring the team was brought up in the "meet the ftpteam" BoF (notes) at DebConf24. On October 3, 2025, Debian Project Leader (DPL) Andreas Tille announced his plan to split the ftpmaster team into two parts: the Archive Operations Team, which handles the infrastructure supporting the Debian archives, and the DFSG team. Tille pulled the trigger on the change on October 26, 2025; he created delegations for the new teams and revoked the delegation for the ftpmaster team, thereby dissolving it.

The first delegation for the DFSG team was composed entirely of former members of the ftpmaster team: Thorsten Alteholz, Ansgar Burchardt, Joerg Jaspert, and Luke Faraone, all of whom were also appointed to the new Archive team. On January 19, 2026, Tille appointed a new delegation to the DFSG team consisting of McMillan, Emmanuel Arias, Nicolas Mora, Mechtilde Stehmann, and Reinhard Tartler.

Team introduction

McMillan said that the talk was supposed to be delivered jointly with Arias and Tartler; however, Tartler had needed to fly back to New York, and Arias was in attendance but not presenting as he is "famously a very shy person", though he would be happy to field questions in Spanish if there were any. "In English, I'll do the talking, I guess." Mora and Stehmann were going to join remotely, he said later, but the network-connectivity problems in the presentation room made that impossible.

The team name was quite a mouthful, he acknowledged, but while "DFSG team" is easier to say it also misses some of the team's responsibilities. He thought it was important to point out that the team reviews packages for compliance with packaging standards and so forth, in addition to ensuring that the packaged software meets the Debian Free Software Guidelines.

The DFSG team does not replace the ftpmaster team, he said: "We just do a very specific task, which was largely done by Thorsten Alteholz in the past." Alteholz had done a great job, "but it was more than one person can handle". The DFSG team does things much more in parallel, and tries not to get blocked on any particular package. "And if somebody's not available, then we can work around that." McMillan also talked about what the DFSG team does not do: it does not fully replace the ftpmaster team. Processing of packages into Debian's stable release, the security and backports repositories, and other archives are handled by the Archive team.

He displayed a slide with the text: "Thesis: a package isn't free until someone checks". McMillan said that the DFSG team has to check that a package is free software before it can enter the archive; the team also reviews packages headed for Debian's contrib and non-free repositories. "We review those as well with less-stringent requirements, as is appropriate for non-free."

There are two types of packages that pass through the hands of the DFSG team: genuinely new source packages that have never been or are not currently in Debian. There are also "binary new" packages which, he explained, which have new names due to a version increment or similar changes. "We tend to review the binary new packages much more leniently, but we still find packages that have been around in Debian for 15 years that have issues with their licensing".

In those cases, the team often accepts the package with a note asking the packager to make the needed changes. "We would rather accept a package which has some minor changes needed, and we'll just ask you to make the minor changes after it's entered the archive." That saves a lot of round-tripping, he added.

McMillan detailed some of the things that the DFSG team looks for during a review; licensing in the debian/copyright file that differs from the headers in the package's source files, non-free assets bundled into the package, or other problems. Sometimes, he said, "people put something into the Debian copyright [file] that seems to be a license, but it actually is just verbiage about the license that's put on a web page or something". In those cases, the team has to ask the packager to include the actual license in debian/copyright.

Most packages come through using the copyright format 1.0 specification, which defines a standard, machine-interpretable format for the debian/copyright file. The format is better known as DEP-5, as it was proposed as a Debian Enhancement Proposal (DEP) in 2007: "DEP-5: Machine-readable debian/copyright". It was published as an optional format in 2012. McMillan hoped that everyone in the audience was familiar with the DEP-5 format; after the audience seemed to indicate that it was, he said, "good, we want to make it mandatory for new packages to be DEP-5".

He said that the DEP-5 requirement was likely to be introduced before the end of this year. "We might actually make it actually apply retroactively that it is a bug for a package not to have the copyright in DEP-5 format." That would help people who are managing large sets of computers who want to know the licensing that's being used in an organization. "Software bill of materials people, and that sort of thing." It's unclear how many packages are not using DEP-5 format or might not be fully compliant.

Dashboard

Developers who are interested in the progress of their packages, or everyone's packages, through the new queue can follow along using the DFSG team's Dashboard. McMillan said that the dashboard is a simple web presentation of the queue with an iceberg's worth of complexity underneath it.

The Archive team uses the Debian Archive Kit (dak) collection of scripts to manage the archive. The DFSG team discussed using those tools as well, he said, but decided that it would be better to have its own software with a separate interface. "So we interact with dak, our software interacts with dak, but we don't have to learn how dak works. That can be somebody else's problem."

Instead of using the dak tools, he said that the DFSG team uses software that is focused on its process. He displayed a slide with some example uses of dnq, the command-line client the team has developed to process new packages. For instance dnq list displays packages that are ready to be reviewed, dnq fetch is used to grab the package, dnq assign packagename will assign a package to the reviewer, etc. The dnq complete accept command finalizes the review and turns it over to dak, which sends out the final email to the packager. "Or, now and again, somebody might get a reject [email]. Hopefully nobody in this room."

The team is still learning from one another, he said: "We kind of all have slightly different workflows because we're a new team and we're evolving." Members of the team have different kinds of skills, he said: Stehmann, for example, has a strong legal background and is good at reading through licenses to assess what is, or is not, compatible with the DFSG.

Priorities and results

Each team member chooses which packages to look at, McMillan said: "The ones that come to the top of my list tend to be languages that I'm more familiar with, like Go. And the ones that go to the bottom of my list tend to be languages that I'm less familiar with, like Python." Conversely, Arias is more familiar with Python, so he is more likely to review those packages. A package can also be designated for team review if it happens to be tricky in some way, such as big package that has been around since the 1990s with "a very hairy set of authors and copyrights".

There were more than 750 packages in the queue when the new DFSG team took over, he said; now there are normally fewer than 30. The team started by prioritizing the oldest packages first, "but also with a balance to get important packages". New binary packages, for example, are given a higher priority than new source packages. Packages with high popularity contest (popcon) scores are also prioritized.

The team normally processes packages within two or three days, McMillan said, "if it takes more than a week for your package to get through, you've hopefully had some communication with the reviewer in that process". He encouraged packagers to email the team if it seemed that a review was taking too long.

Even though the team is processing the new queue more quickly, McMillan said that the team could use more hands and invited people to talk to the team if they were interested in joining. He said he would ultimately like to have a system that put more of the workload of accepting new packages onto Debian developers in general. He envisioned "some kind of quorum sort of structure" that would allow anyone with upload rights to the Debian archive to endorse a package as being good. If it received enough votes, it would just be accepted.

There was a lot of discussion last year at DebConf, McMillan said, "about the difficulty with getting [new] packages accepted into Debian, and I think this year we're not talking about that". He opened the floor for questions, but the audience did not offer any, so he ended the session a bit early.

Comments (9 posted)

An operations structure for swap devices

One of the ideas raised at the 2026 Linux Storage, Filesystem, Memory Management, and BPF Summit (LSFMM+BPF) was the creation of an operations structure for the swap subsystem. Like many parts of the kernel, the swap layer evolved over time, with pieces being added as needed; the end result of this evolution is rarely what one would expect had the subsystem been designed today. The interface between the swap layer and the devices it uses is just one example. It appears that one result of the swap subsystem's evolution — the lack of an abstraction layer to interface with underlying storage — will soon be addressed, but in a different way than was initially envisioned.

In the early days, the kernel was only able to swap to a dedicated partition on a local disk drive. If that partition turned out to be too small — and it always turned out that way in the end — the only way to fix it was, normally, to repartition the entire disk. The eventual addition of the ability to use a file within a filesystem as swap space made life easier for system administrators; later still, the kernel gained the ability to swap to networked filesystems. Within the swap layer, each of these possible swap backends is coded as a set of special cases where their behavior differs. This lack of abstraction at that level makes the swap subsystem harder to maintain and improve.

A a patch series meant to improve this situation, created by Baoquan He, had been in the works for some time. The interface between the swap layer and the backend would be defined by this structure:

    struct swap_ops {
	void (*read_folio)(struct swap_info_struct *sis, struct folio *folio,
			   struct swap_iocb **plug);
	void (*write_folio)(struct swap_info_struct *sis, struct folio *folio,
			    struct swap_iocb **plug);
	void (*unplug)(struct swap_iocb *sio);
    };

The purpose of the read_folio() and write_folio() functions is fairly obvious: they are called to move one or more pages between memory and the underlying swap device. The unplug() function existed to start a batch of accumulated I/O operations. Together, this set of operations was able to hide the differences between swap backends from the rest of the swap subsystem.

In He's series, there were three swap_ops structures defined, for three different backend cases:

• bdev_async_swap_ops is for the normal case of swapping to a block device. Operations happen asynchronously, since block devices can take some time to carry them out. It is worth noting that the case of swapping to a file within a local filesystem is also normally handled by these operations. When a swap file is added, the kernel asks the filesystem to specify where the file's blocks have been placed, then bypasses the filesystem for I/O thereafter.
• bdev_sync_swap_ops is also for a local block device, but the operations are synchronous; the functions will not return until the requested operations are complete. This is the "swap bypass" case, which was described in this article; in short, for fast, memory-based devices, the operations come down to memory copies, so there is no point in performing them asynchronously.
• bdev_fs_swap_ops is a set of operations that call into a filesystem to perform the actual I/O. As noted above, this case is not for local filesystems. It is needed, though, for swapping to files on network filesystems.

This series had been through seven revisions and appeared to be on track for merging into the mainline. After LSFMM+BPF, though, Christoph Hellwig showed up with a somewhat different approach to the problem. His series is focused on increasing the batching of swap-I/O operations for better performance. As part of that effort, it adds an operations structure that is inspired by He's work, but which takes a different approach:

    struct swap_ops {
	unsigned int flags;
	bool (*can_merge)(struct folio *folio, struct folio *prev_folio,
			size_t prev_folio_size, int rw);
	void (*submit_write)(struct swap_io_ctx *ctx);
	void (*submit_read)(struct swap_io_ctx *ctx);
    };

The can_merge() function determines whether the I/O operations for two folios can be merged into a single, larger operation. It has to determine whether the storage for the two folios is logically adjacent on the backing store, so the calculation must be different for different backing devices. submit_write() and submit_read() are for initiating I/O, with the details of the operation gathered together into the ctx argument. There is only one possible flags value, SWAP_OPS_F_REQUIRE_NOFS, which indicates that any reclaim operations must not call into the filesystem, since that could generate a recursive call into the filesystem hosting the swap file.

In Hellwig's patch set, there are only two operations structures defined: swap_bdev_ops for block-device backends, and swap_fs_ops for filesystem-backed backends. The synchronous swap-bypass case is handled with tests in the block-device implementation, as with current kernels.

This series is on its fifth revision, and seems to be mostly ready, though it may not come together in time for the 7.3 merge window. This work, it seems, has run into a problem that is showing up with increasing frequency in the kernel community: the Sashiko review tool has few complaints about the patches themselves, but finds a couple of pre-existing problems in the code that the patches change. There is a natural desire to see those problems fixed, but delaying new work to fix them is not always a popular decision. Whether that will happen in this case is yet to be determined.

Comments (2 posted)

An update on netkit and the use of BPF in user space

Daniel Borkmann led a session at the 2026 Linux Filesystem, Memory-Management, and BPF Summit about the progress that has been made with netkit, the subsystem that allows virtual machines (VMs) running on Linux to perform networking efficiently. When that did not fill the full time, he went on to discuss his idea for using BPF to live-patch user-space applications. While netkit is making progress, and can now support zero-copy receipt of packets into a VM in a network namespace, the idea of using BPF for patching user-space programs remains entirely speculative.

There have long been ways for VMs to accelerate their networking or access physical networking devices. Those approaches, however, have not been compatible with the use of network namespaces. That combination is needed by KubeVirt, a Kubernetes setup that uses virtual machines for isolation and network namespaces to set networking policies. Eventually, Borkmann would like to let virtual machines do true zero-copy networking. A critical step toward that is the recently merged support for queue leasing.

Queue leasing enables zero-copy networking by allowing the virtual machine manager (VMM) to create a queue on the VM's virtual networking device, and then bind it to a real queue on a host device. Right now, that is only working for receive queues — meaning that when a packet arrives to the physical network interface card (NIC), the driver can place it directly in the memory that corresponds to the virtual NIC's queue, and therefore have it be accessible to the VM directly.

The support for receive-queue leasing is fairly robust; it already works with other performance optimizations such as huge pages or BIG TCP, provided that the physical NIC supports them. There is a need for some self-tests to ensure that these things keep working, Borkmann said. On the transmit side, there are some additional complications that will be more work to address.

The underlying design for transmit-queue leasing is nearly identical: allowing the VM to place outgoing packets directly in memory accessible to the physical NIC. John Fastabend asked whether the transmit side would need a BPF program to enforce policy. Borkmann replied that, for netkit, there would be such a BPF program installed even in the absence of queue leasing. The thing is, not all physical devices support the kind of direct memory access that would be needed for transmit-queue leasing. There was a patch from Bobby Eshleman (merged on May 18), Borkmann said, that would extend the device memory transmit configuration property to indicate whether the physical device supports this kind of access; then netkit just needs to be extended to pass through that property from the underlying physical device.

Allowing VMs to pass data directly to devices like this would not allow them to circumvent network namespace policies because the packet header still goes through the normal process, including any BPF programs that have been set up to filter or redirect packets. It is only the data part of the packet — the part that is expensive to copy — that is provided directly. Once transmit-queue leasing can be made to work, it should be suitable to most use cases.

One audience member asked about which component was supposed to be able to set up receive-queue leasing, and what was preventing a VM from abusing the ability to exhaust the host device's number of supported queues. For his use case, Borkmann said, it is Cillium that sets up the queue leases. The correspondence is always set up by some software running on the VMM; the VM can't simply decide that it gets to have a queue. The same person also asked why it was necessary to have a separate transmit queue per VM; for the receive-queue side, it's needed because incoming packets may need to be steered to different VMs, but he did not think that it was necessary for transmit queues.

It might be possible to use a shared transmit queue, Borkmann said, but he had previously seen bugs where, when express data path (XDP) assigned a queue mapping, it caused problems with the state of queues on the physical NIC. Keeping things separate prevents interference of that kind from occurring. The audience member then had some additional suggestions for how the transmit side could be improved which Borkmann promised to look into.

BPF for user-space live patching

The other topic that Borkmann wanted to discuss with the assembled kernel contributors was the possibility of using BPF to live-patch user-space programs. He got the idea from Fastabend's earlier talk, noting that sometimes there are user-space applications that are just as hard to patch against security vulnerabilities in a timely manner as the kernel. What if the kernel could generate trampolines or just-in-time compiled code that runs directly in user-space? That could allow the same kind of function-argument validation or return-value alteration. Such a facility could also be used to optimize the performance of uprobes.

Of course, it is already possible to patch user-space programs by directly modifying the text pages in memory. That is risky, however, because a misplaced patch can wreak havoc on a program. BPF might be useful here for the same reason it is in the kernel, Borkmann thought: BPF programs can be verified to ensure that they do not cause a crash. There are plenty of critical user-space applications where a form of live-patching that was guaranteed not to cause a crash would be welcome.

Borkmann envisioned a system where the kernel would verify a BPF program, compile it to position-independent code, and then inject it into the executable memory of a running user-space application. The user-space process would run the compiled BPF program directly. One complication would be that the BPF program would not have access to kernel-only interfaces, such as the majority of BPF maps, but for simple patches access to BPF arenas should be sufficient.

Song Liu thought that many important application properties could not be verified, and that therefore BPF programs in user-space might still crash user-space applications. Borkmann didn't think that small programs similar to Fastabend's "shields" would cause problems. In the kernel, the verifier has a clearly defined set of things that programs are and aren't allowed to do, Liu said, which is not true in user-space, so it's not clear that the verifier would be sufficient, or even helpful.

Jakub Sitnicki asked what advantage a BPF-patching mechanism would have over uprobes. Borkmann said that, because BPF would run directly in user space, it would avoid the overhead of a trap into the kernel. Andrii Nakryiko agreed, noting that uprobes have limited performance. Liu suggested that some of uprobe's functionality could be moved into user-space without involving BPF.

There is also the question of how to hook the generated code into the user-space executable, Nakryiko pointed out. Uprobes use a small breakpoint instruction, and then the kernel emulates the overwritten instruction. But patching in a longer jump to a BPF trampoline would be more complicated: "this rewriting of generic instructions is very hard". I asked about the possibility of including special target locations in user-space binaries that would be simpler to patch, but Nakryiko said that the benefit of uprobes was that they could run on any function.

At that point, the session was running out of time, but not before one more audience member asked for the verifier to be pulled out into a separate library. A lot of the benefit of the verifier, especially type-system-related checks, carries over between contexts, he said; having the verifier as a separate library would let user-space applications add in their own rules on top of that.

Overall, the assembled developers seemed to feel that using BPF for user-space patching would be difficult for several reasons, although none were opposed to the idea in principle, if it could be made to work. Whether anyone judges the ability to patch user-space programs in this way to be worth the hassle remains to be seen.

Comments (1 posted)

Debugging information for inlined functions

BPF programs use BPF type format (BTF) debugging information in order to determine how to interact with functions in the kernel. Specifically, tracing a kernel function involves finding its address in the kernel's BTF section — but that doesn't work for functions that have been inlined, and therefore don't have a single, specific address. Alan Maguire wants to add information about inlined functions to BTF in order to allow them to be traced, and led a session on that topic at the 2026 Linux Storage, Filesystem, Memory-Management, and BPF Summit.

There are more than 100,000 inlined functions in the kernel, Maguire said, spread across five times as many locations. Worse, some of them are partially inlined: called normally in some places and inlined in others. That can lead to cases today where it appears that a function was traced successfully, but some invocations were not seen.

The good news is that the rest of the infrastructure for tracing inlined functions is already in place to enable kprobes, which can be attached to arbitrary locations. It is just a matter of getting the data about where functions have been inlined into a usable format, Maguire stated. "The story is actually pretty complete."

So, what is needed to store this information in BTF? The DWARF debugging format already has a way to indicate inlining information, but DWARF is also difficult to work with, and doesn't have a simple way to represent the common cases. A solution for BTF should be compact, and permit deduplication, to keep the memory overhead low, Maguire said. Ideally, inlining information could be stored in a separate section of the kernel binary, or even be distributed as a separate kernel module, so that it is not loaded until it is needed.

Concretely, Maguire proposed three new pieces of information be added to BTF. The first was inline-site-specific information about which function was inlined at each call site and how it would have been called if it had not been inlined, called the "location section". That data can't be easily deduplicated because it's specific to a given call site, so as much as possible the information should consist of pointers to data that can be deduplicated.

The second and third pieces of information he wants to add would be the pointed-to data: a "location prototype" and "location parameter". The location prototype specifies how the inlined function's arguments are represented at the call site, as a list of pointers to location parameters, which each store how to access a single function argument. In theory, the compiler could store a given function parameter at a different location for every inlined call site (of which there are 538,090); in practice, there are a limited number of ways that the compiler will transform parameters, and many functions have compatible signatures that result in the compiler making the same choices. In the current kernel, deduplicating location prototypes results in just 57,141 distinct entries referencing only 17,535 location parameter entries in total.

This means that the location sections take up most of the added data. Overall, the additions to BTF that Maguire proposes would come to approximately 11MB of additional data, or about 21 bytes per inlined call site. When pulled out into a separate kernel module and compressed, the total amount of data goes down to 3.5MB.

Maguire then went through an example of how information about a specific function would be stored. Consider this function:

    int foo(int a, void *b, bool c);

If the compiler chose to inline foo() in a way that eliminates a as unused, promotes b to be passed in a register, and determines that c is a constant, the BTF representation would be a single location section entry storing the BTF type ID of foo(), the offset of the call site from the kernel's base address in memory, and a pointer to the location-prototype entry. That entry becomes a length-tagged array of references to location-parameter entries. The first entry is null, indicating that a cannot be recovered. The second points to a location parameter entry with a flag that indicates the value is contained in a register, and then the specific register number of b. The last location-parameter entry has a different flag specifying that it is a constant, and then the value of the constant.

Alexei Starovoitov asked what order the location-section entries would be stored in, since the kernel will have to search through them to find the right entry when setting up tracing. At first, Maguire thought that sorting by the address of the call site would be best, but after looking at how the data would be used, he decided to sort the entries by function name, instead. That way, tracers that are looking for information on a particular function can find it quickly with a binary search.

There were two prerequisite problems with adding inlining information to BTF that Maguire covered. For one thing, the number of location-section entries required increasing the size of the length field of the containing structure to 24 bits. More seriously, some of the existing tooling for processing BTF did not cope well with the presence of new tags that it doesn't know how to read. That is a problem that comes up any time BTF is extended with new kinds of information, and part of how DWARF ended up becoming so brittle. To address that, Maguire added information on how to parse BTF into BTF itself. Now, any tool that can read that meta-information can correctly skip past any new tags that it does not understand.

Maguire also had to update the poke-a-hole (pahole) utility to handle properly sorting the new kinds of BTF tags. That ended up being a bit complicated, but it should be working for normal kernel builds. Andrii Nakryiko asked about how it would handle out-of-tree modules. Those modules would need resilient module BTF that could be explicitly relocated when loaded into a running kernel, Maguire explained. His design allows that, but it complicates the build somewhat. There was a bit of back-and-forth about the changes that would be needed to support out-of-tree modules elegantly, but ultimately no changes were agreed upon.

At the time of writing, Maguire's patch set has not been merged. It is clearly useful to be able to trace inlined and partially inlined functions; the question is whether it is worth the complexity and memory overhead. Time will tell.

Comments (8 posted)

Fedora approves a smaller GRUB

Leo Sandoval and Marta Lewandowska have put forward a change proposal for Fedora 45, which is expected in October, to provide a separate, slimmed-down version of GRUB for a niche use case. The new package would be in addition to the main GRUB package and would not replace it for the majority of Fedora users. The idea met with some resistance from Fedora contributors who thought that it would be better to use systemd-boot, or another modern bootloader, rather than trying to wrangle GRUB into a suitable state for the use case. The Fedora Engineering Steering Council (FESCo), however, voted to accept the change on July 7.

Signed, sealed, booted

The change proposal specifies the creation of a UEFI-only build of GRUB with a minimal set of modules for booting unified kernel images (UKIs) using boot loader specification (BLS) files. The target use case is for booting "sealed bootable container" images in virtual environments (e.g., running virtual machines in public clouds) for confidential computing.

LWN has covered bootable containers (bootc) in the past, but sealed bootc images are relatively new. A sealed image is one with all of the components for a fully verified boot chain: that includes firmware, the UKI, and a composefs repository, with fs-verity enabled, for the filesystem rather than OSTree, which has traditionally been used for bootc. A sealed image relies on Secure Boot and currently is only supported on x86_64 and aarch64 systems with UEFI.

The main users of the new GRUB package, according to the proposal, will be the Fedora CoreOS developers. Since CoreOS is meant to be a minimal, automatically updated operating system, the hope is that a stripped-down GRUB with fewer built-in modules will have a smaller attack surface and require less-frequent updates. CoreOS may be the first user of the new GRUB build, but the proposal envisions "a minimal UEFI bootloader for virtual environments that can be further tailored for use in those environments".

It is interesting to see Lewandowska, who is a Red Hat quality engineer, now endorsing GRUB for this use case after arguing that it should be replaced not long ago. She gave a a talk at DevConf.cz, in 2024, about a project called nmbl (for "no more bootloader", pronounced "nimble") that would replace GRUB for use with UKIs. Instead of using a separate bootloader, nmbl would use the Linux kernel as its own bootloader. Her blog post that was published to coincide with the talk gives a good overview of nmbl, as well as its anticipated advantages over GRUB.

She pointed out at the time that Red Hat was carrying "hundreds of downstream patches" for the project and had argued that GRUB was too complex. Lewandowska also pointed out the large number of vulnerabilities it had been subject to over time, as well as all of the filesystem, storage, and memory-allocation bugs that she said GRUB's developers did not have the time to fix.

During the proposal discussion, Lewandowska explained her change of heart regarding GRUB, at least in part: "This year GRUB upstream moved to GitLab, has much better [continuous integration], become more accessible and much more lively." It would appear that work on nmbl has stalled as GRUB has had a revival: the repository that seems to have the most up-to-date work on the project, a dracut plugin for working with nmbl, was last updated in August 2025. The proposal does not mention nmbl at all.

Why not systemd-boot?

The original vision for sealed bootable containers called for using systemd-boot rather than GRUB. The proposal mentions that systemd-boot was considered, but was rejected for several reasons. It argued that systemd-boot "has not been widely tested or fuzzed, like GRUB has been", and that long-term maintenance of more than one bootloader would add technical debt. An early version of the proposal claimed that the systemd team would "view any additional features [for systemd-boot] as a no-go".

Fedora change discussions are still conducted on both its discussion forum and the Fedora development mailing list, though a proposal to change that and move discussions solely to the mailing list is currently being entertained. This meant that the discussion was, naturally, a bit fragmented. On the forum, Zbigniew Jędrzejewski-Szmek said that the arguments against systemd-boot were "divorced from reality". He said that the project was "fairly widely used", its code was being fuzzed through OSS-Fuzz (albeit "not as extensively as it should be"), and added that systemd-boot received new features regularly.

On the mailing list, Lennart Poettering commented that he was "really irritated" by the comment that systemd developers were not adding features. "We are adding new stuff to systemd-boot/systemd-stub all the time, including stuff contributed by Red Hat's [confidential computing] folks". On the forum, Lewandowska said that proposal sponsors were told by "RHEL/Fedora systemd maintainers" that new features were not being added to systemd-boot. The bullet point about new features has since been removed from the proposal by Kashyap Chamarthy.

Michael Gruber said that he was not against the proposal, per se, but complained that it was "giving up on the idea of systemd-boot (or something else) as a new and lean boot loader". GRUB does too many things, he said, and he was not convinced that "chopping off parts" of the software would be the right way to go. Alberto Ruiz also thought that the reasons given for rejecting systemd-boot were faulty: "the burden of maintaining a GRUB variant is likely higher than the burden of supporting systemd-boot in an additional use case that is very limited in scope".

If GRUB were not so widely used, Lewandowska said, "I would agree adopting it for this use case does not make sense". But, given the amount of investment it has already received, she believed that it made sense to use GRUB rather than to adopt something new.

The proposal provided instructions and links to packages for early testing. Gerd Hoffman observed that the test GRUB package "does not look very stripped down to me", and provided output comparing the size of the standard GRUB binary against the test version. The smaller GRUB package was only about 64KB smaller than the standard binary, which is a bit larger than 4MB. Sandoval acknowledged that it needed more work and linked to the tracking ticket for the work of removing non-essential modules from GRUB.

Neal Gompa said he was generally in favor of the proposal, though he wanted to see support for other common filesystems such as Btrfs, ext4, and XFS. Currently the slimmed-down build only includes the FAT filesystem module. Timothée Ravier replied that adding more supported filesystems would contradict the goal of including as few modules as possible to reduce the attack surface and reduce the need for updates. That led to an extended debate about other cloud use cases and the problems with UEFI.

Gompa also said that he had been "exploring and engaging with upstream" GRUB developers on the topic of providing additional security features around data integrity. "With the revived upstream and our patches getting merged at a rapid clip now, I'm very optimistic about the future of the GRUB project." Poettering, however, was less enthusiastic about expanding GRUB's filesystem features. "It's hard enough for the Linux storage people to maintain that as part of the Linux kernel, and now you expect the handful of Grub maintainers to keep up with this in their own codebase?"

Oron Peled suggested another strategy, highly reminiscent of nmbl, for dealing with the various filesystems that bootable components might live on. Specifically, he thought the project should consider using an intermediate kernel to boot another kernel, thereby reusing the Linux kernel's filesystem drivers. Jędrzejewski-Szmek pointed out that Peled's suggested approach "has been discussed extensively in the past" but had a number of downsides. For example, he said that the kernel's "'embrace all CVEs' approach" that has resulted in a constant stream of CVEs meant "we'd be updating that smaller kernel all the time".

Accepted

In considering the change, FESCo member Simon de Vlieger said that he found it difficult to vote on; he did not see the value in having the stripped-down GRUB in virtual environments, but thought it might be useful in other situations that were not being considered or targeted. "This stripped down version is at odds though with what I've seen people expect this to turn into (having filesystem drivers, that sort of stuff)." But, since it was only the introduction of a new package, he cast a "weak-ish +1" in favor of the proposal. He said that he expected any deliverables, such as CoreOS, that might use the new package by default would need to go through the change process for approval.

Ravier said that he was wearing multiple hats in the discussion since he was involved with CoreOS, Fedora's Atomic desktops, Red Hat Enterprise Linux (RHEL) CoreOS, as well as being a member of FESCo. He was in favor of the change since it would be used in RHEL and CentOS CoreOS for confidential-computing setups. But, from the FESCo perspective "I don't think this change brings a lot of value to Fedora and we should focus on using systemd-boot instead". He said he was working on using systemd-boot for the Atomic desktops, but: "In the end, I'm +1 as this is an additive change that is useful for some groups of Fedora and does not prevent us from doing something else in the future."

In the end, none of the FESCo members expressed much enthusiasm for the proposal, but none of the members seemed inclined to oppose it. It passed with five votes in favor (out of nine possible) and none against. Assuming all goes well, the new package should appear in Fedora 45. It will be interesting to see how the experiment goes, and whether there is a change proposal in time for Fedora 46 to make this the default bootloader for Fedora CoreOS.

Comments (8 posted)

Progress toward compiling Linux with gccrs

The gccrs project, which is creating a Rust frontend for the GCC compiler, has spent the first half of 2026 focusing on compiling the Linux kernel. By testing the compiler against the kernel crates, the development team has made significant progress toward generating correct code for other Rust programs. As detailed in the project's weekly and monthly reports, this effort has uncovered and resolved problems in areas such as attribute handling (described in the report for February), name resolution, and resource management (both detailed in the May report). Currently, the compiler can only handle simple standalone programs, but that situation could change rapidly in the coming months.

The drive to compile the Rust components of the Linux kernel stems from the new toolchain requirements brought by Rust's introduction into the kernel. Currently, developers must use the LLVM-based rustc compiler (although rustc does have experimental, in-progress support for using GCC as a backend via rust_codegen_gcc). While LLVM is supported by the kernel, a GCC-based alternative is necessary to support architectures not targeted by LLVM and to integrate with GCC's existing plugin ecosystem. As the kernel's Rust integration matures, toolchain flexibility and the availability of a GCC-based compiler have become priorities for Linux distributions.

Reorganizing milestones

Compiler frontend projects often track their progress against the release cycle of their target backend. In its March 2026 report, the gccrs team announced a change in project management, opting to organize its work into three capability-based milestones rather than targeting specific GCC versions.

The first milestone is an "embedded Rust compiler" capable of compiling no_std programs that depend only on the core crate. The second is a "Rust for Linux compiler" that supports the alloc crate alongside focused on supporting the specific crates used by the kernel. The final milestone is a "general purpose compiler" aimed at handling broader Rust applications beyond the kernel environment.

The first milestone is not completely implemented, but it is close. Progress toward the Rust for Linux milestone is underway. In March, the team added support for compiler_builtins, a key low-level crate required by kernel builds, and focused on resolving problems within the kernel's ffi crate the kernel's custom, minimal implementations of the compiler_builtins and ffi crates. To support this effort, Zhi Heng joined the project in May 2026 for an Open Source Security internship. His work is dedicated to fixing bugs encountered when gccrs compiles kernel crates and establishing continuous-integration testing to prevent regressions.

However, simply testing to ensure the compiler can process Rust code without crashing is only part of the task. The generated code must also be correct. The implementation of Rust's destructor semantics is key to the generation of correct code, because idiomatic Rust code uses them more heavily than traditional C code, so that has been another area of focus.

The Drop infrastructure

Rust manages resources using a scope-based model known as resource acquisition is initialization (RAII). When a value goes out of scope, the compiler automatically inserts a call to its destructor, which is defined by the Drop trait.

In Rust, tracking when variables must be cleaned up is complex because a variable's initialization state can change depending on the control flow within a function. If a variable is conditionally moved or only partially initialized, the compiler cannot simply drop it at the end of the enclosing scope. To solve this, the frontend must analyze the control-flow graph and generate dynamic "drop flags"—boolean variables tracked at run time—to record whether a value needs to be destroyed before passing this representation to the GCC backend. That analysis was missing from the initial implementation of Drop in gccrs, causing some Drop::drop() calls to be omitted or incorrect. Prior to the recent work on the compiler, gccrs lacked Drop elaboration entirely.

In the context of the Linux kernel, missing Drop calls lead to severe run-time failures, such as memory leaks or unreleased system resources. A primary example is lock management. When kernel code acquires a lock, the Rust for Linux API returns a MutexGuard. The Drop implementation for this guard is responsible for releasing the lock.

As the team noted in May, without proper Drop calls, the lock is never released. This results in miscompiled code where locks remain held after their guard goes out of scope, which can cause synchronization failures or deadlocks. Google Summer of Code (GSoC) participant Janet Chien joined the project in May to focus specifically on building the gccrs Drop infrastructure.

Name-resolution work

Testing the compiler against the standard library and kernel crates also exposed fundamental bugs in how gccrs handled name resolution.

Rust maintains three four distinct namespaces: the value namespace for functions and static variables, the macro namespace, the type namespace, and a namespace for lifetimes and control-flow labels. When the compiler encounters a "path"—a sequence of identifiers like crate::foo::bar used to refer to an item—it must identify the correct namespace for each segment of the path.

The development team discovered a flaw in its processing pipeline. Previously, when gccrs looked for the definition of an item, it resolved paths within the namespace of the target item type. For instance, when looking for a function, it resolved the path segments in the value namespace. This approach is incorrect because modules and publicly visible imports actually live in the type namespace; the compiler cannot successfully traverse a path to find a function without first resolving the module structure itself in the type namespace.

Fixing this problem required a rewrite of internal data structures and a refactoring of the visitor implementations used throughout the code. By May, these changes allowed the deeply nested imports in the core crate to resolve correctly. Modules and imports are now properly inserted into the types namespace, aligning gccrs more closely with rustc behavior.

Metadata and attribute handling

The shift to compiling kernel crates highlighted further problems in how gccrs processes compiler attributes and crate metadata.

Rust relies on attributes, such as #[cfg()], for conditional compilation. The February 2026 report described how lead developer Pierre-Emmanuel Patry had reworked the attribute-handling pipeline. His work split, into two distinct passes, the compiler pass that removes items excluded by the cfg attribute. This separation was necessary to support unstable features within the kernel; some of these features rely on macro expansion or conditional attributes that must be stripped before the main attribute-validation pass can safely evaluate them without triggering compiler errors.

In March, gccrs added a command-line option equivalent to rustc's -Zcrate-attr, called -frust-crate-attr. This option allows the build system to inject attributes during compiler invocation without modifying the underlying source files. This is particularly useful for passing the #![no_core] attribute, which is necessary to compile code without depending on the standard core library. That feature is relied upon by developers who are fuzzing the compiler to locate edge-case bugs.

Linking the kernel's Rust crates eventually revealed a new bug. Rust crates export metadata, typically bundled in .rlib files, to communicate their public APIs to other crates. When attempting to link kernel code, the developers found that certain modules and exports were simply missing from the emitted metadata. Because the compiler was omitting nested module exports during metadata generation, gccrs was unable to resolve external dependencies.

This problem was not caught by the project's existing metadata test cases, which relied on flatter module structures. Identifying this bug required compiling real-world code. Consequently, the team began a significant rework of the metadata handling system to ensure the GNU toolchain can successfully link the kernel's dependency tree.

Current capabilities and the challenges of upstreaming

So, what is possible for gccrs today? Currently, the compiler can successfully handle standalone no_core programs, and has made significant strides in processing the core crate and implementing compiler builtins. However, fully compiling the kernel's complex Rust abstractions remains a work in progress. gccrs is currently able to parse the kernel's code and the project is focused on correctly implementing the run-time semantics.

Beyond technical hurdles, gccrs has also had to navigate the organization challenges of the GNU toolchain. Historically, the project has faced problems landing its patches in the upstream GCC tree. Integrating an entirely new, rapidly evolving language frontend into GCC is a large undertaking, and the size of the patch sets has occasionally overwhelmed the limited bandwidth of upstream GCC reviewers. While the situation has improved as the frontend's architecture has stabilized, merging sweeping changes—such as the recent name-resolution rewrites and Drop infrastructure—still requires significant coordination and patience to clear the upstream review process the bigger change is the recent elevation of two gccrs developers to the status of GCC maintainers, which allows them to stage updates in their own tree and then push them wholesale..

Next steps

Work continues on the remaining components required to compile the kernel. GSoC participant Enes Çevik, who also joined the project in May, is implementing support for the alloc crate. This crate handles dynamic memory allocation types like Box, Rc, and Vec. Although kernel development avoids many standard library abstractions, several core kernel Rust abstractions rely on allocation types making support for the alloc crate a hard prerequisite for the "Rust for Linux" milestone. While earlier versions of the kernel's Rust integration relied on a fork of the standard alloc crate, the kernel has recently transitioned to using its own custom alloc module. Consequently, compiling the standard alloc crate is no longer a strict prerequisite for the "Rust for Linux" milestone, though it remains an important step for the compiler's broader capabilities.

The broader development community will soon receive a closer look at this progress. Patry and Arthur Cohen plan to present a talk titled "Compiling the Linux kernel with gccrs" at RustConf in Montreal and EuroRust in Barcelona later this year. By systematically addressing the specific requirements of kernel code, the project is steadily building the foundation for using GCC to compile Rust code within the Linux kernel ecosystem.

[ Note: several corrections about the state of the alloc and compiler_builtins libraries have been added to the article. ]

Comments (1 posted)

Security quotes of the week

Again, discernment is everything when it comes to getting useful work out of a chatbot. If you don't know anything about my work and you ask a chatbot to explain it to you, you will likely be badly misled. If you are familiar with my work and you ask a chatbot for the best examples where I explain a given subject, you may get a good answer, and if you get a bad one, you'll know it.

— Cory Doctorow

As a researcher I've also been spending a lot of time with models, talking through various ideas. I don't think I will surprise anyone when I say that they're obviously getting better, even over the course of the past few months. While I don't have Mythos and $100k to spend, I have been able to query at least one new advanced unreleased model, and I also have received some surprising new "results" to questions that I've been interested in for a few years.

Which brings me to the real problem: just because a model spits out an apparent new result, this does not mean the result is real. Even if models are good at producing real results, they're much better at producing results that look real but are misleading. This can be enormously frustrating, and often means that human attention is more necessary than ever.

— Matthew Green comments on the recent cryptographic results from Anthropic

Comments (none posted)

Kernel release status

The current development kernel is 7.2-rc5, released on July 26. Linus said: "So it's a bit too big for my liking, but nothing in there strikes me as particularly strange or scary".

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

RC	Date	Commits
v7.2-rc1	2026-06-28	14395	14395
v7.2-rc2	2026-07-05	433	433
v7.2-rc3	2026-07-12	475	475
v7.2-rc4	2026-07-19	557	557
v7.2-rc5	2026-07-26	611	611

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

Stable updates: the massive 7.1.5, 6.18.40, 6.12.97, 6.6.145, 6.1.178, 5.15.212, and 5.10.261 updates were released on July 24. The single-fix 6.12.98 release came out on July 25; 6.12.99, 6.6.146, and 6.1.179 (also with a single regression fix) followed on July 29.

Comments (none posted)

Mourning Dan Williams

I have just received the shocking news that Dan Williams, a longtime, high-profile kernel developer, has passed away. I knew him primarily through his long service on the Linux Foundation Technical Advisory Board; he was always a strong, thoughtful, and intelligent presence. Dan will be deeply missed.

There is a support effort underway for Dan's family as they come to terms with this loss.

Comments (21 posted)

In remembrance of Dan Williams

On July 21, the kernel community lost Dan Williams, one of its most beloved contributors. Dave Hansen and Thomas Gleixner, both of whom worked with Williams extensively, have written an obituary and allowed LWN to publish it. He will be deeply missed, but he has left us with a lot to remember him by.

Full Story (comments: 9)

Quotes of the week

Patch authors are expected to proactively look into the AI-generated reviews and handle such feedback as any other kind of review: either debate it or address it. In both cases a reply on the mailing list is expected.

Authors are strongly encouraged to run LLM reviews on the posted patches in advance of the actual post. Large series triggering a significant amount of AI-generated feedback will likely get little attention from maintainers and reviewers.

— Paolo Abeni updates policy for the networking subsystem

Back when Linux ran on an abacus, I added __GFP_NOFAIL because four or five sites (file systems) were infinitely looping on alloc_pages until it succeeded. I figured we should move this operation into the page allocator so we could easily find those sites and fix them to Not Do That.

I made it very clear (changelog and code comments) that no new code should use __GFP_NOFAIL. How did that work out?

    hp2:/usr/src/linux-7.2-rc4> grep -r __GFP_NOFAIL | wc -l
    241

So much lameness!

— Andrew Morton

I'll also be up front about the fact that this patchset is based entirely on LLM predicted code. I review it all and correct any errors, issues, concerns, etc immediately as each new hunk of code is predicted by the LLM to prevent errors from compounding and multiplying. Thus the code ends up the way I'd write it manually, not the way an unchecked LLM would vibe code it. Mistakes in the code are mine, not a result of an LLM being used to predict the code I'd write faster than I can write it myself.

— Dave Chinner

Comments (14 posted)

A Debian general resolution on LLM usage

The Debian project is considering a general resolution on the use of large language models in the creation of the distribution. There are three alternatives to consider: a total ban on LLM usage, rejecting LLMs "as far as practical", or explicitly allowing LLM usage subject to a set of conditions. The discussion period has just begun; the beginning of the voting period does not yet appear to have been set. Those who want to look over the discussion ahead of the inevitable LWN article can find it over here.

Comments (150 posted)

De Vlieger: The Fedora 45 sausage factory

Fedora contributor Simon de Vlieger has published a blog post with a walkthrough of how the project turns source code and packages into the final release that users install on their systems.

It follows the a package from a packager's git push to a composed release: ISOs, cloud images, container images, and OSTree deployments.

The walkthrough describes how the Fedora 'sausage' is created as of Fedora 45, things change all the time; I hope to have time to update this document every cycle or every few cycles of Fedora releases so there's both history and people can find up to date information.

Comments (5 posted)

Distributions quote of the week

I have never been known to endorse performance art, sarcasm, or ironic communication that makes a point. I only approve of proposals and specifications that are sincere and well-meaning, like RFC 3514 or RFC 2324.

— Christine Lemmer-Webber

Comments (1 posted)

Codeberg: Protecting our FLOSS commons from LLMs

The Codeberg forge has adopted a pair of new policies, promising not to use hosted projects to train LLMs and, more controversially, banning the hosting of LLM-generated software. The site's blog describes and justifies these policies.

Although often well intentioned, sharing the result of a prompt and calling it "libre software" does not make the world a better place. Codeberg is not and does not want to be a place to dump such generated single-use software that no one else will ever look at. We are a place for people to collaborate and improve software together. Within this context, the recent votes can be understood as a reconfirmation of those principles: As we want to center on human collaboration, we will not actively support or engage in the creation of LLMs and will not put our limited resources to use for storing single-use software that would pollute our FLOSS commons.

Comments (88 posted)

GCC steering committee announces AI policy

The GCC steering committee has announced that it has accepted an AI contributions policy recommended by the GCC AI policy working group.

The policy, in part, states that the project will decline any "legally significant contributions which include LLM-generated content or are derived from LLM-generated content". It uses the definition of "legally significant" from the GNU Project maintainer guidelines, which holds that the threshold is "around 15 lines of code and/or text" to qualify as significant for copyright purposes. GCC maintainers may, however, choose to accept legally significant test cases that are generated by an LLM.

The policy does not forbid use of LLMs for research, analysis, bug discovery and reporting, patch review, etc. as long as the output is not included in contributions. The committee says that it expects the policy will evolve and will be revisited periodically.

Comments (110 posted)

GNU Binutils 2.47 released

Version 2.47 of GNU Binutils has been released. In addition to the usual bug fixes there are some notable new features in this release including added support for a number of RISC-V standard extensions, a command-line option (-M annotate) which displays the symbol for undefined instructions for AArch64, and more. The 32-bit s390 target has been deprecated with this release.

Comments (none posted)

GNU C Library 2.44 released

Version 2.44 of the GNU C Library has been released. Changes include a new /etc/tunables.conf file for the system-wide setting of tunable parameters, a new tunable to control the use of transparent huge pages for read-only executable segments, a number of math-function improvements, a handful of security fixes, and more.

Comments (5 posted)

Home Assistant Device Database public preview

The Open Home Foundation, which governs the Home Assistant home-automation project, has announced the "public preview" of its Device Database:

Providing a public, open way to browse the anonymous, aggregated device data we collect was always part of the plan, and this preview is our first step toward it.

You can already use it to search and filter devices to see aggregated community insights, starting with a deliberately focused set of specifics, such as whether a device requires an internet connection, and which protocols and integrations it works with. We've kept that initial scope narrow on purpose, giving us a solid foundation we can build on together with you, our community, as the database grows.

LWN looked at Home Assistant in May 2025.

Comments (none posted)

Wayfire 0.11 released

Version 0.11 of the wlroots-based Wayfire Wayland compositor has been released. Notable changes include better fractional scaling, per-output ICC profiles, support for additional Wayland protocols, and more.

Comments (none posted)

Linux Plumbers Conference 2026 registration open

Registration is now open for the 2026 Linux Plumbers Conference, to be held October 5 to 7 in Prague, Czechia. Tickets to this event tend to sell out quickly, so interested attendees probably should not procrastinate.

Comments (none posted)

CFP Deadlines: July 30, 2026 to September 28, 2026

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

Deadline	Event Dates	Event	Location
July 31	October 14 October 17	PyCon South Africa	Cape Town, South Africa
July 31	October 1 October 2	embedded Linux for Safe and Secure Applications	Göttingen, Germany
July 31	September 25 September 27	PostmarketOS and Alpine Linux Conference	Aachen, Germany
August 1	September 28 October 1	Alpine Linux Persistence and Storage Summit	Lizumerhütte, Tyrol, Austria
August 1	August 25 August 30	MiniDebConf and MiniDebCamp Winterthur 2026	Winterthur, Switzerland
August 11	October 6	Yocto Project Developer Day 2026	Prague, Czechia
August 31	October 2 October 4	GNU Tools Cauldron	Prague, Czechia
August 31	October 3 October 4	Linux Days 2026	Prague, Czechia
September 6	October 6	Real-time Linux User Forum	Prague, Czechia
September 6	January 20 January 22	Everything Open	Brisbane, Australia

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

Events: July 30, 2026 to September 28, 2026

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

Date(s)	Event	Location
August 6 August 9	FOSSY 2026	Vancouver, Canada
August 8 August 9	UbuCon Asia 2026 @ COSCUP	Taipei, Taiwan
August 11 August 12	Open Source Summit Korea	Seoul, South Korea
August 14 August 16	Hackers on Planet Earth	New York, NY, US
August 25 August 30	MiniDebConf and MiniDebCamp Winterthur 2026	Winterthur, Switzerland
August 30 September 5	FOSS4G Hiroshima 2026	Hiroshima, Japan
September 17 September 18	Git Merge	Lisbon, Portugal
September 19 September 20	Nextcloud Community Conference 2026	Berlin, Germany
September 22 September 24	Kernel Recipes	Paris, France
September 22 September 24	Reproducible Builds Summit	Gothenburg, Sweden
September 25 September 27	PostmarketOS and Alpine Linux Conference	Aachen, Germany

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

Alert summary July 23, 2026 to July 29, 2026

Dist.	ID	Release	Package	Date
AlmaLinux	ALSA-2026:42739	10	acl	2026-07-22
AlmaLinux	ALSA-2026:43420	8	acl	2026-07-22
AlmaLinux	ALSA-2026:42736	9	acl	2026-07-22
AlmaLinux	ALSA-2026:44438	9	compat-openssl11	2026-07-24
AlmaLinux	ALSA-2026:43400	10	dogtag-pki	2026-07-22
AlmaLinux	ALSA-2026:46532	8	dovecot	2026-07-28
AlmaLinux	ALSA-2026:41905	9	dovecot	2026-07-22
AlmaLinux	ALSA-2026:42694	10	glibc	2026-07-22
AlmaLinux	ALSA-2026:42733	8	glibc	2026-07-22
AlmaLinux	ALSA-2026:42952	9	glibc	2026-07-23
AlmaLinux	ALSA-2026:46394	10	go-fdo-client	2026-07-28
AlmaLinux	ALSA-2026:46395	10	go-fdo-server	2026-07-28
AlmaLinux	ALSA-2026:10704	8	go-toolset:rhel8	2026-07-22
AlmaLinux	ALSA-2026:35832	10	golang-github-openprinting-ipp-usb	2026-07-22
AlmaLinux	ALSA-2026:35827	10	grafana	2026-07-22
AlmaLinux	ALSA-2026:11507	8	grafana	2026-07-22
AlmaLinux	ALSA-2026:46391	8	grafana	2026-07-27
AlmaLinux	ALSA-2026:35826	10	grafana-pcp	2026-07-22
AlmaLinux	ALSA-2026:11514	8	grafana-pcp	2026-07-22
AlmaLinux	ALSA-2026:42828	8	httpd:2.4	2026-07-22
AlmaLinux	ALSA-2026:42877	8	java-1.8.0-openjdk	2026-07-24
AlmaLinux	ALSA-2026:42877	9	java-1.8.0-openjdk	2026-07-24
AlmaLinux	ALSA-2026:42887	8	java-17-openjdk	2026-07-24
AlmaLinux	ALSA-2026:42887	9	java-17-openjdk	2026-07-24
AlmaLinux	ALSA-2026:42895	10	java-21-openjdk	2026-07-24
AlmaLinux	ALSA-2026:41948	8	javapackages-tools:201801	2026-07-22
AlmaLinux	ALSA-2026:42919	10	kernel	2026-07-24
AlmaLinux	ALSA-2026:44270	10	kernel	2026-07-25
AlmaLinux	ALSA-2026:45115	8	kernel	2026-07-24
AlmaLinux	ALSA-2026:47011	8	kernel	2026-07-28
AlmaLinux	ALSA-2026:43307	9	kernel	2026-07-24
AlmaLinux	ALSA-2026:45116	8	kernel-rt	2026-07-24
AlmaLinux	ALSA-2026:47010	8	kernel-rt	2026-07-28
AlmaLinux	ALSA-2026:44391	10	libpq	2026-07-23
AlmaLinux	ALSA-2026:44308	9	libpq	2026-07-23
AlmaLinux	ALSA-2026:46398	10	libreswan	2026-07-27
AlmaLinux	ALSA-2026:46396	8	libreswan	2026-07-27
AlmaLinux	ALSA-2026:46397	9	libreswan	2026-07-27
AlmaLinux	ALSA-2026:42668	9	libtiff	2026-07-22
AlmaLinux	ALSA-2026:43505	10	mariadb-connector-c	2026-07-23
AlmaLinux	ALSA-2026:36189	10	perl-HTTP-Daemon	2026-07-22
AlmaLinux	ALSA-2026:43218	8	pki-deps:10.6	2026-07-22
AlmaLinux	ALSA-2026:41937	10	sssd	2026-07-22
AlmaLinux	ALSA-2026:46990	8	sssd	2026-07-28
AlmaLinux	ALSA-2026:42122	9	sssd	2026-07-24
Debian	DSA-6395-1	stable	bind9	2026-07-22
Debian	DLA-4705-1	LTS	calibre	2026-07-29
Debian	DLA-4701-1	LTS	chromium	2026-07-27
Debian	DSA-6396-1	stable	chromium	2026-07-23
Debian	DSA-6400-1	stable	exim4	2026-07-24
Debian	DLA-4695-1	LTS	firefox-esr	2026-07-22
Debian	DSA-6394-1	stable	firefox-esr	2026-07-22
Debian	DLA-4699-1	LTS	hplip	2026-07-26
Debian	DSA-6402-1	stable	hplip	2026-07-28
Debian	DLA-4696-1	LTS	imagemagick	2026-07-24
Debian	DLA-4704-1	LTS	libraw	2026-07-29
Debian	DLA-4700-1	LTS	linux-6.1	2026-07-26
Debian	DLA-4702-1	LTS	openjdk-11	2026-07-28
Debian	DLA-4703-1	LTS	openjdk-17	2026-07-28
Debian	DSA-6397-1	stable	pdns-recursor	2026-07-23
Debian	DSA-6401-1	stable	samba	2026-07-28
Debian	DLA-4698-1	LTS	spice-vdagent	2026-07-24
Debian	DSA-6398-1	stable	webkit2gtk	2026-07-23
Fedora	FEDORA-2026-8e8273f18f	F44	GitPython	2026-07-26
Fedora	FEDORA-2026-1528cb06a7	F43	btrbk	2026-07-29
Fedora	FEDORA-2026-ac712bf651	F43	chromium	2026-07-23
Fedora	FEDORA-2026-acf674bc6a	F43	chromium	2026-07-25
Fedora	FEDORA-2026-8a09a7af63	F43	chromium	2026-07-29
Fedora	FEDORA-2026-310f620a68	F44	chromium	2026-07-23
Fedora	FEDORA-2026-4870f59184	F44	chromium	2026-07-25
Fedora	FEDORA-2026-e48156418f	F44	chromium	2026-07-29
Fedora	FEDORA-2026-e2b3dd1ec0	F43	collectl	2026-07-23
Fedora	FEDORA-2026-71a9784a57	F44	collectl	2026-07-23
Fedora	FEDORA-2026-47575c76a5	F43	cryptlib	2026-07-24
Fedora	FEDORA-2026-e4349a03b1	F44	cryptlib	2026-07-24
Fedora	FEDORA-2026-d9817786d6	F43	dotnet10.0	2026-07-25
Fedora	FEDORA-2026-f738966fc9	F44	dotnet10.0	2026-07-25
Fedora	FEDORA-2026-da44c3870f	F43	dotnet8.0	2026-07-24
Fedora	FEDORA-2026-9aef53fa96	F44	dotnet8.0	2026-07-24
Fedora	FEDORA-2026-3afd9d89f4	F43	dotnet9.0	2026-07-24
Fedora	FEDORA-2026-d6b061ad69	F44	dotnet9.0	2026-07-24
Fedora	FEDORA-2026-6dab7a3eff	F43	firefox	2026-07-26
Fedora	FEDORA-2026-7d71f89d7e	F44	firefox	2026-07-24
Fedora	FEDORA-2026-9630be304f	F43	fractal	2026-07-23
Fedora	FEDORA-2026-600530ae91	F44	fractal	2026-07-23
Fedora	FEDORA-2026-4a2d23b470	F43	google-osconfig-agent	2026-07-26
Fedora	FEDORA-2026-9781489c3a	F44	google-osconfig-agent	2026-07-26
Fedora	FEDORA-2026-d61fcb86ed	F43	gpsd	2026-07-29
Fedora	FEDORA-2026-6503a6a639	F43	kernel	2026-07-23
Fedora	FEDORA-2026-2b94d8d05c	F44	kernel	2026-07-23
Fedora	FEDORA-2026-56568b6fe8	F43	kronosnet	2026-07-29
Fedora	FEDORA-2026-db53330c8f	F44	kronosnet	2026-07-29
Fedora	FEDORA-2026-30e8e9a2b2	F44	lego	2026-07-27
Fedora	FEDORA-2026-9d59721e9b	F44	libgit2	2026-07-27
Fedora	FEDORA-2026-146b86f436	F43	libreswan	2026-07-26
Fedora	FEDORA-2026-063caa9112	F43	libssh	2026-07-23
Fedora	FEDORA-2026-0e46c91ccf	F44	libssh	2026-07-23
Fedora	FEDORA-2026-59fdef3e5f	F43	libwebsockets	2026-07-27
Fedora	FEDORA-2026-9921e0e415	F44	libwebsockets	2026-07-27
Fedora	FEDORA-2026-597e8f9de1	F44	llvm	2026-07-23
Fedora	FEDORA-2026-0bb141710c	F43	mbedtls	2026-07-25
Fedora	FEDORA-2026-64ca3441c3	F43	moby-engine	2026-07-26
Fedora	FEDORA-2026-70a4eeeab8	F44	moby-engine	2026-07-26
Fedora	FEDORA-2026-8870088088	F43	mupdf	2026-07-25
Fedora	FEDORA-2026-d085110cf3	F44	netatalk	2026-07-25
Fedora	FEDORA-2026-60fc198d3b	F44	nginx	2026-07-23
Fedora	FEDORA-2026-60fc198d3b	F44	nginx-mod-brotli	2026-07-23
Fedora	FEDORA-2026-60fc198d3b	F44	nginx-mod-fancyindex	2026-07-23
Fedora	FEDORA-2026-60fc198d3b	F44	nginx-mod-headers-more	2026-07-23
Fedora	FEDORA-2026-60fc198d3b	F44	nginx-mod-js-challenge	2026-07-23
Fedora	FEDORA-2026-60fc198d3b	F44	nginx-mod-modsecurity	2026-07-23
Fedora	FEDORA-2026-60fc198d3b	F44	nginx-mod-naxsi	2026-07-23
Fedora	FEDORA-2026-60fc198d3b	F44	nginx-mod-vts	2026-07-23
Fedora	FEDORA-2026-168280f3c4	F43	opkssh	2026-07-28
Fedora	FEDORA-2026-a0bf40ecfe	F44	opkssh	2026-07-28
Fedora	FEDORA-2026-566791181a	F43	p11-kit	2026-07-26
Fedora	FEDORA-2026-adc8ddbeaa	F43	pam	2026-07-26
Fedora	FEDORA-2026-c0abcba354	F43	perl-DBI	2026-07-23
Fedora	FEDORA-2026-1c5ffc6018	F44	perl-DBI	2026-07-23
Fedora	FEDORA-2026-6f12b08313	F43	perl-Mojolicious	2026-07-28
Fedora	FEDORA-2026-4334fd85bc	F44	perl-Mojolicious	2026-07-28
Fedora	FEDORA-2026-c8484f1afb	F43	perl-YAML-Syck	2026-07-23
Fedora	FEDORA-2026-2139aa7dce	F44	perl-YAML-Syck	2026-07-23
Fedora	FEDORA-2026-3805ba3721	F44	python-black	2026-07-24
Fedora	FEDORA-2026-fbb9501b22	F43	python-django5	2026-07-25
Fedora	FEDORA-2026-6215e65f6c	F43	python-idna	2026-07-26
Fedora	FEDORA-2026-3805ba3721	F44	python-lsp-black	2026-07-24
Fedora	FEDORA-2026-3805ba3721	F44	python-pytokens	2026-07-24
Fedora	FEDORA-2026-a006788209	F43	restic	2026-07-29
Fedora	FEDORA-2026-c87cc5b948	F44	restic	2026-07-29
Fedora	FEDORA-2026-a9f0d5370e	F43	rpm	2026-07-28
Fedora	FEDORA-2026-9985882270	F44	rpm	2026-07-28
Fedora	FEDORA-2026-9d59721e9b	F44	rust-libgit2-sys	2026-07-27
Fedora	FEDORA-2026-4d9a2870e5	F43	skopeo	2026-07-27
Fedora	FEDORA-2026-9b2e56edf5	F44	skopeo	2026-07-25
Fedora	FEDORA-2026-51628b98a8	F43	srt	2026-07-23
Fedora	FEDORA-2026-45ce54d51e	F44	srt	2026-07-23
Fedora	FEDORA-2026-9ab663dcd4	F43	sssd	2026-07-25
Fedora	FEDORA-2026-289c38d6f2	F43	systemd	2026-07-27
Fedora	FEDORA-2026-230ba36543	F44	systemd	2026-07-27
Fedora	FEDORA-2026-ddaabe38ab	F43	trafficserver	2026-07-27
Fedora	FEDORA-2026-bb8dc1e5b6	F44	trafficserver	2026-07-27
Fedora	FEDORA-2026-ec8e535c6e	F43	webkitgtk	2026-07-26
Fedora	FEDORA-2026-7bbb52b49d	F43	wget1	2026-07-25
Fedora	FEDORA-2026-952a486b39	F43	xrdp	2026-07-26
Fedora	FEDORA-2026-9d3c766833	F44	xrdp	2026-07-26
Mageia	MGASA-2026-0289	10, 9	apache	2026-07-23
Mageia	MGASA-2026-0291	10, 9	cifs-utils	2026-07-23
Mageia	MGASA-2026-0288	10, 9	dnsmasq	2026-07-23
Mageia	MGASA-2026-0295	10, 9	giflib	2026-07-25
Mageia	MGASA-2026-0298	10, 9	graphite2	2026-07-25
Mageia	MGASA-2026-0307	10	gstreamer1.0-libav	2026-07-28
Mageia	MGASA-2026-0294	10, 9	libevent	2026-07-24
Mageia	MGASA-2026-0299	10, 9	libnfs	2026-07-25
Mageia	MGASA-2026-0306	10, 9	libslirp	2026-07-28
Mageia	MGASA-2026-0302	10	libyang	2026-07-28
Mageia	MGASA-2026-0292	10	lrzip	2026-07-24
Mageia	MGASA-2026-0304	10, 9	memcached	2026-07-28
Mageia	MGASA-2026-0301	10, 9	nginx	2026-07-28
Mageia	MGASA-2026-0303	10	packages	2026-07-28
Mageia	MGASA-2026-0290	10, 9	socat	2026-07-23
Mageia	MGASA-2026-0305	10, 9	sqlite3	2026-07-28
Mageia	MGASA-2026-0293	10	transmission	2026-07-24
Mageia	MGASA-2026-0297	10, 9	vorbis-tools	2026-07-25
Mageia	MGASA-2026-0300	10, 9	wget	2026-07-25
Mageia	MGASA-2026-0296	10, 9	yelp	2026-07-25
Oracle	ELSA-2026-41897	OL10	.NET 10.0	2026-07-22
Oracle	ELSA-2026-41893	OL10	.NET 8.0	2026-07-22
Oracle	ELSA-2026-21286	OL10	.NET 8.0	2026-07-28
Oracle	ELSA-2026-41895	OL10	.NET 9.0	2026-07-22
Oracle	ELSA-2026-26456	OL10	389-ds-base	2026-07-22
Oracle	ELSA-2026-36196	OL10	389-ds-base	2026-07-22
Oracle	ELSA-2026-19345	OL9	LibRaw	2026-07-28
Oracle	ELSA-2026-36782	OL10	aardvark-dns	2026-07-22
Oracle	ELSA-2026-42739	OL10	acl	2026-07-22
Oracle	ELSA-2026-43420	OL8	acl	2026-07-28
Oracle	ELSA-2026-38494	OL10	buildah	2026-07-22
Oracle	ELSA-2026-29195	OL10	buildah	2026-07-28
Oracle	ELSA-2026-32990	OL10	cifs-utils	2026-07-22
Oracle	ELSA-2026-44438	OL9	compat-openssl11	2026-07-28
Oracle	ELSA-2026-29952	OL7	compat-poppler022	2026-07-28
Oracle	ELSA-2026-39302	OL10	cups	2026-07-22
Oracle	ELSA-2026-43400	OL10	dogtag-pki	2026-07-28
Oracle	ELSA-2026-41988	OL10	dovecot	2026-07-22
Oracle	ELSA-2026-26532	OL10	dracut	2026-07-22
Oracle	ELSA-2026-39297	OL10	edk2	2026-07-22
Oracle	ELSA-2026-19138	OL10	fence-agents	2026-07-22
Oracle	ELSA-2026-21380	OL10	firefox	2026-07-22
Oracle	ELSA-2026-36211	OL10	freeipmi	2026-07-22
Oracle	ELSA-2026-36203	OL10	freerdp	2026-07-22
Oracle	ELSA-2026-33412	OL10	galera and mariadb11.8	2026-07-22
Oracle	ELSA-2026-39272	OL10	git-lfs	2026-07-22
Oracle	ELSA-2026-19133	OL10	git-lfs	2026-07-22
Oracle	ELSA-2026-30855	OL10	git-lfs	2026-07-28
Oracle	ELSA-2026-42063	OL10	glib2	2026-07-22
Oracle	ELSA-2026-18139	OL10	glibc	2026-07-22
Oracle	ELSA-2026-20594	OL10	glibc	2026-07-22
Oracle	ELSA-2026-42952	OL9	glibc	2026-07-28
Oracle	ELSA-2026-20613	OL10	gnutls	2026-07-22
Oracle	ELSA-2026-46394	OL10	go-fdo-client	2026-07-28
Oracle	ELSA-2026-37436	OL10	golang	2026-07-22
Oracle	ELSA-2026-22120	OL10	golang	2026-07-28
Oracle	ELSA-2026-29980	OL10	golang	2026-07-28
Oracle	ELSA-2026-36749	OL10	gstreamer1-plugins-bad-free	2026-07-22
Oracle	ELSA-2026-36675	OL10	gstreamer1-plugins-good	2026-07-22
Oracle	ELSA-2026-36673	OL10	gstreamer1-plugins-ugly-free	2026-07-22
Oracle	ELSA-2026-26228	OL10	hplip	2026-07-22
Oracle	ELSA-2026-39976	OL10	hplip	2026-07-22
Oracle	ELSA-2026-42828	OL8	httpd:2.4	2026-07-28
Oracle	ELSA-2026-40895	OL9	jackson-annotations, jackson-core, jackson-databind, jackson-jaxrs-providers, and jackson-modules-base	2026-07-28
Oracle	ELSA-2026-18134	OL10	kernel	2026-07-22
Oracle	ELSA-2026-19569	OL10	kernel	2026-07-28
Oracle	ELSA-2026-44270	OL10	kernel	2026-07-28
Oracle	ELSA-2026-42919	OL10	kernel	2026-07-28
Oracle	ELSA-2026-42552	OL8	kernel	2026-07-28
Oracle	ELSA-2026-43307	OL9	kernel	2026-07-28
Oracle	ELSA-2026-39296	OL10	libinput	2026-07-22
Oracle	ELSA-2026-44391	OL10	libpq	2026-07-28
Oracle	ELSA-2026-44308	OL9	libpq	2026-07-28
Oracle	ELSA-2026-18326	OL10	libvirt	2026-07-22
Oracle	ELSA-2026-28234	OL10	libxml2	2026-07-22
Oracle	ELSA-2026-39304	OL10	libxml2	2026-07-22
Oracle	ELSA-2026-40841	OL8	maven:3.8	2026-07-28
Oracle	ELSA-2026-27842	OL10	memcached	2026-07-22
Oracle	ELSA-2026-20693	OL10	mysql8.4	2026-07-28
Oracle	ELSA-2026-19159	OL10	nginx	2026-07-22
Oracle	ELSA-2026-36364	OL10	nginx	2026-07-22
Oracle	ELSA-2026-41947	OL8	nodejs:22	2026-07-28
Oracle	ELSA-2026-39868	OL8	nodejs:24	2026-07-28
Oracle	ELSA-2026-19146	OL10	openexr	2026-07-22
Oracle	ELSA-2026-38499	OL10	openexr	2026-07-22
Oracle	ELSA-2026-22314	OL10	openssl	2026-07-28
Oracle	ELSA-2026-38513	OL10	perl-DBI	2026-07-22
Oracle	ELSA-2026-39547	OL10	perl-XML-LibXML	2026-07-22
Oracle	ELSA-2026-23388	OL10	php	2026-07-22
Oracle	ELSA-2026-22649	OL10	php8.4	2026-07-22
Oracle	ELSA-2026-38514	OL10	plexus-utils	2026-07-22
Oracle	ELSA-2026-38495	OL10	podman	2026-07-22
Oracle	ELSA-2026-24386	OL10	podman	2026-07-28
Oracle	ELSA-2026-24470	OL10	podman	2026-07-28
Oracle	ELSA-2026-37072	OL10	podman	2026-07-28
Oracle	ELSA-2026-18289	OL10	podman	2026-07-28
Oracle	ELSA-2026-30044	OL7	poppler	2026-07-28
Oracle	ELSA-2026-27743	OL10	postgresql16	2026-07-22
Oracle	ELSA-2026-27742	OL10	postgresql18	2026-07-22
Oracle	ELSA-2026-39183	OL10	python3.12	2026-07-22
Oracle	ELSA-2026-28581	OL10	python3.14	2026-07-22
Oracle	ELSA-2026-41949	OL9	python3.14	2026-07-28
Oracle	ELSA-2026-19152	OL10	rsync	2026-07-22
Oracle	ELSA-2026-28132	OL7	samba	2026-07-28
Oracle	ELSA-2026-41937	OL10	sssd	2026-07-22
Oracle	ELSA-2026-42122	OL9	sssd	2026-07-28
Oracle	ELSA-2026-19153	OL10	thunderbird	2026-07-22
Oracle	ELSA-2026-36788	OL10	tomcat	2026-07-22
Oracle	ELSA-2026-18537	OL10	tomcat	2026-07-28
Oracle	ELSA-2026-36790	OL10	tomcat9	2026-07-22
Oracle	ELSA-2026-18536	OL10	tomcat9	2026-07-22
Oracle	ELSA-2026-25341	OL10	tomcat9	2026-07-28
Oracle	ELSA-2026-23231	OL10	unbound	2026-07-22
Oracle	ELSA-2026-36320	OL10	unbound	2026-07-22
Oracle	ELSA-2026-38509	OL10	vim	2026-07-22
Oracle	ELSA-2026-22711	OL10	vim	2026-07-22
Oracle	ELSA-2026-28210	OL10	vim	2026-07-28
Oracle	ELSA-2026-19125	OL10	xorg-x11-server-Xwayland	2026-07-22
Oracle	ELSA-2026-24716	OL10	yggdrasil	2026-07-22
Oracle	ELSA-2026-39573	OL10	yggdrasil	2026-07-22
Oracle	ELSA-2026-19126	OL10	yggdrasil	2026-07-28
Oracle	ELSA-2026-19128	OL10	yggdrasil-worker-package-manager	2026-07-22
Red Hat	RHSA-2026:38504-01	EL8	container-tools:rhel8	2026-07-24
Red Hat	RHSA-2026:19160-01	EL10	firefox	2026-07-27
Red Hat	RHSA-2026:24511-01	EL10.0	firefox	2026-07-27
Red Hat	RHSA-2026:24983-01	EL7	firefox	2026-07-27
Red Hat	RHSA-2026:20566-01	EL8	firefox	2026-07-27
Red Hat	RHSA-2026:24516-01	EL8.4	firefox	2026-07-27
Red Hat	RHSA-2026:25015-01	EL8.6	firefox	2026-07-27
Red Hat	RHSA-2026:24755-01	EL8.8	firefox	2026-07-27
Red Hat	RHSA-2026:20574-01	EL9	firefox	2026-07-27
Red Hat	RHSA-2026:24509-01	EL9.2	firefox	2026-07-27
Red Hat	RHSA-2026:24510-01	EL9.4	firefox	2026-07-27
Red Hat	RHSA-2026:24508-01	EL9.6	firefox	2026-07-27
Red Hat	RHSA-2026:39272-01	EL10	git-lfs	2026-07-24
Red Hat	RHSA-2026:30855-01	EL10	git-lfs	2026-07-24
Red Hat	RHSA-2026:39266-01	EL8	git-lfs	2026-07-24
Red Hat	RHSA-2026:30853-01	EL8	git-lfs	2026-07-24
Red Hat	RHSA-2026:39319-01	EL9	git-lfs	2026-07-24
Red Hat	RHSA-2026:30854-01	EL9	git-lfs	2026-07-24
Red Hat	RHSA-2026:38995-01	EL8	go-toolset:rhel8	2026-07-24
Red Hat	RHSA-2026:37436-01	EL10	golang	2026-07-24
Red Hat	RHSA-2026:37435-01	EL9	golang	2026-07-24
Red Hat	RHSA-2026:29981-01	EL9	golang	2026-07-24
Red Hat	RHSA-2026:35832-01	EL10	golang-github-openprinting-ipp-usb	2026-07-24
Red Hat	RHSA-2026:35827-01	EL10	grafana	2026-07-24
Red Hat	RHSA-2026:35830-01	EL8	grafana	2026-07-24
Red Hat	RHSA-2026:35828-01	EL9	grafana	2026-07-24
Red Hat	RHSA-2026:35826-01	EL10	grafana-pcp	2026-07-24
Red Hat	RHSA-2026:35831-01	EL8	grafana-pcp	2026-07-24
Red Hat	RHSA-2026:35829-01	EL9	grafana-pcp	2026-07-24
Red Hat	RHSA-2026:36749-01	EL10	gstreamer1-plugins-bad-free	2026-07-28
Red Hat	RHSA-2026:37130-01	EL8	gstreamer1-plugins-bad-free	2026-07-28
Red Hat	RHSA-2026:47076-01	EL8.4	gstreamer1-plugins-bad-free	2026-07-28
Red Hat	RHSA-2026:36834-01	EL9	gstreamer1-plugins-bad-free	2026-07-28
Red Hat	RHSA-2026:16101-01	EL7	host-metering	2026-07-24
Red Hat	RHSA-2026:42876-01	EL7	java-1.8.0-openjdk	2026-07-24
Red Hat	RHSA-2026:42877-01	EL8	java-1.8.0-openjdk	2026-07-24
Red Hat	RHSA-2026:42880-01	EL7	java-11-openjdk with Extended Lifecycle Support	2026-07-24
Red Hat	RHSA-2026:42887-01	EL8.6	java-17-openjdk	2026-07-24
Red Hat	RHSA-2026:42895-01	EL8	java-21-openjdk	2026-07-24
Red Hat	RHSA-2026:36617-01	EL9	oci-seccomp-bpf-hook	2026-07-24
Red Hat	RHSA-2026:39005-01	EL10	rhc	2026-07-24
Red Hat	RHSA-2026:41930-01	EL8	rhc	2026-07-24
Red Hat	RHSA-2026:36776-01	EL8	rhc	2026-07-24
Red Hat	RHSA-2026:39879-01	EL9	rhc	2026-07-24
Red Hat	RHSA-2026:42946-01	EL10	rhc-worker-playbook	2026-07-24
Red Hat	RHSA-2026:36317-01	EL9	skopeo	2026-07-24
Red Hat	RHSA-2026:26539-01	EL10.0	thunderbird	2026-07-27
Red Hat	RHSA-2026:22643-01	EL8	thunderbird	2026-07-27
Red Hat	RHSA-2026:21381-01	EL9	thunderbird	2026-07-27
Red Hat	RHSA-2026:26269-01	EL9.2	thunderbird	2026-07-27
Red Hat	RHSA-2026:26174-01	EL9.4	thunderbird	2026-07-27
Red Hat	RHSA-2026:42088-01	EL8	webkit2gtk3	2026-07-27
Red Hat	RHSA-2026:42062-01	EL9	webkit2gtk3	2026-07-27
Red Hat	RHSA-2026:38487-01	EL8	xorg-x11-server	2026-07-24
Red Hat	RHSA-2026:38486-01	EL9	xorg-x11-server	2026-07-24
Red Hat	RHSA-2026:38489-01	EL10	xorg-x11-server-Xwayland	2026-07-24
Red Hat	RHSA-2026:38488-01	EL8	xorg-x11-server-Xwayland	2026-07-24
Red Hat	RHSA-2026:38490-01	EL9	xorg-x11-server-Xwayland	2026-07-24
Red Hat	RHSA-2026:39573-01	EL10	yggdrasil	2026-07-24
Slackware	SSA:2026-209-01		libarchive	2026-07-28
Slackware	SSA:2026-204-01		mozilla-thunderbird	2026-07-23
Slackware	SSA:2026-209-03		samba	2026-07-28
Slackware	SSA:2026-209-02		seamonkey	2026-07-28
SUSE	SUSE-SU-2026:3138-1	SLE15	389-ds	2026-07-20
SUSE	openSUSE-SU-2026:11319-1	TW	7zip	2026-07-22
SUSE	SUSE-SU-2026:3201-1	SLE15 oS15.6	GraphicsMagick	2026-07-23
SUSE	SUSE-SU-2026:3395-1	SLE15 oS15.6	GraphicsMagick	2026-07-29
SUSE	SUSE-SU-2026:3192-1	SLE12	ImageMagick	2026-07-22
SUSE	SUSE-SU-2026:3024-1	SLE12	ImageMagick	2026-07-15
SUSE	SUSE-SU-2026:3194-1	SLE15	ImageMagick	2026-07-22
SUSE	SUSE-SU-2026:3193-1	SLE15 oS15.4	ImageMagick	2026-07-22
SUSE	SUSE-SU-2026:3335-1	SLE15 oS15.4	ImageMagick	2026-07-28
SUSE	SUSE-SU-2026:3219-1	SLE15 oS15.6	ImageMagick	2026-07-24
SUSE	SUSE-SU-2026:22620-1	SLE16.0	ImageMagick	2026-07-16
SUSE	SUSE-SU-2026:22829-1	SLE16.0	ImageMagick	2026-07-27
SUSE	SUSE-SU-2026:22861-1	SLE16.0	ImageMagick	2026-07-27
SUSE	SUSE-SU-2026:22860-1	SLE16.0	PackageKit	2026-07-27
SUSE	SUSE-SU-2026:3224-1	SLE15 oS15.6	SVT-AV1, libyuv0, libaom3	2026-07-24
SUSE	SUSE-SU-2026:22917-1	SLE-m6.0	afterburn	2026-07-27
SUSE	SUSE-SU-2026:22787-1	SLE-m6.2	afterburn	2026-07-23
SUSE	SUSE-SU-2026:22827-1	SLE16.0	afterburn	2026-07-27
SUSE	SUSE-SU-2026:2976-1	SLE5.3 SLE-m5.3	afterburn	2026-07-14
SUSE	SUSE-SU-2026:2977-1	SLE5.4 SLE-m5.4	afterburn	2026-07-14
SUSE	SUSE-SU-2026:2975-1	SLE5.5 SLE-m5.5	afterburn	2026-07-14
SUSE	openSUSE-SU-2026:11324-1	TW	afterburn	2026-07-23
SUSE	SUSE-SU-2026:22622-1	SLE16.0	agama	2026-07-16
SUSE	openSUSE-SU-2026:21448-1	oS16.0	agama-web-ui	2026-07-28
SUSE	SUSE-SU-2026:22575-1	SLE16.0	alloy	2026-07-14
SUSE	SUSE-SU-2026:22667-1	SLE-m6.1	alsa	2026-07-20
SUSE	SUSE-SU-2026:3270-1	SLE15 oS15.6	alsa	2026-07-27
SUSE	openSUSE-SU-2026:11345-1	TW	amazon-ecs-init	2026-07-25
SUSE	SUSE-SU-2026:3225-1	SLE15	apache-commons-compress, apache-ivy, brotli-java, zstd-jni	2026-07-24
SUSE	SUSE-SU-2026:22858-1	SLE16.0	apache-ivy	2026-07-27
SUSE	openSUSE-SU-2026:11327-1	TW	apache-sshd	2026-07-23
SUSE	SUSE-SU-2026:22564-1	SLE16.0	apache2	2026-07-14
SUSE	SUSE-SU-2026:3216-1	SLE12	avahi	2026-07-24
SUSE	SUSE-SU-2026:3218-1	SLE15 oS15.6	avahi	2026-07-24
SUSE	SUSE-SU-2026:22853-1	SLE16.0	avahi	2026-07-27
SUSE	SUSE-SU-2026:3217-1	SLE5.3 SLE5.4 SLE5.5 SLE-m5.3 SLE-m5.4 SLE-m5.5 oS15.4	avahi	2026-07-24
SUSE	openSUSE-SU-2026:21417-1	oS16.0	avahi	2026-07-24
SUSE	SUSE-SU-2026:22841-1	SLE16.0	aws-nitro-enclaves-cli	2026-07-27
SUSE	openSUSE-SU-2026:21406-1	oS16.0	aws-nitro-enclaves-cli	2026-07-24
SUSE	openSUSE-SU-2026:11346-1	TW	chromedriver	2026-07-25
SUSE	openSUSE-SU-2026:21453-1	oS16.0	chromium	2026-07-28
SUSE	openSUSE-SU-2026:0257-1	osB15	chromium	2026-07-23
SUSE	openSUSE-SU-2026:0264-1	osB15	chromium	2026-07-27
SUSE	SUSE-SU-2026:22888-1	SLE-m6.1	cifs-utils	2026-07-27
SUSE	SUSE-SU-2026:22574-1	SLE16.0	clamav	2026-07-14
SUSE	SUSE-SU-2026:22770-1	SLE-m6.2	cockpit, cockpit-machines, cockpit-packages, cockpit- podman, cockpit-repos, cockpit-subscriptions	2026-07-22
SUSE	SUSE-SU-2026:22837-1	SLE16.0	cockpit, cockpit-machines, cockpit-packages, cockpit- podman, cockpit-repos, cockpit-subscriptions	2026-07-27
SUSE	SUSE-SU-2026:3048-1	SLE15	container-suseconnect	2026-07-15
SUSE	SUSE-SU-2026:22800-1	SLE-m6.0	containerd	2026-07-27
SUSE	SUSE-SU-2026:22892-1	SLE-m6.1	containerd	2026-07-27
SUSE	SUSE-SU-2026:3052-1	SLE15 SLE5.3 SLE5.4 SLE5.5 SLE-m5.3 SLE-m5.4 SLE-m5.5	containerd	2026-07-15
SUSE	SUSE-SU-2026:22613-1	SLE16.0	cosign	2026-07-16
SUSE	SUSE-SU-2026:22602-1	SLE-m6.2	cryptsetup	2026-07-15
SUSE	SUSE-SU-2026:22645-1	SLE16.0	cryptsetup	2026-07-16
SUSE	SUSE-SU-2026:22709-1	SLE-m6.0	curl	2026-07-22
SUSE	SUSE-SU-2026:22889-1	SLE-m6.1	curl	2026-07-27
SUSE	SUSE-SU-2026:2925-1	SLE15	curl	2026-07-14
SUSE	SUSE-SU-2026:22582-1	SLE16.0	curl	2026-07-14
SUSE	SUSE-SU-2026:3099-1	SLE15	dash	2026-07-17
SUSE	SUSE-SU-2026:22561-1	SLE16.0	dhcpcd	2026-07-14
SUSE	SUSE-SU-2026:22706-1	SLE-m6.0	dnsmasq	2026-07-22
SUSE	SUSE-SU-2026:22668-1	SLE-m6.1	dnsmasq	2026-07-20
SUSE	SUSE-SU-2026:2974-1	SLE12	dnsmasq	2026-07-14
SUSE	SUSE-SU-2026:3064-1	SLE15 SLE5.3 SLE5.4 SLE5.5 SLE-m5.3 SLE-m5.4 SLE-m5.5	docker	2026-07-15
SUSE	SUSE-SU-2026:22703-1	SLE-m6.0	docker-compose	2026-07-22
SUSE	SUSE-SU-2026:22887-1	SLE-m6.1	docker-compose	2026-07-27
SUSE	SUSE-SU-2026:22567-1	SLE16.0	docker-compose	2026-07-14
SUSE	SUSE-SU-2026:22573-1	SLE16.0	ffmpeg-7	2026-07-14
SUSE	openSUSE-SU-2026:11361-1	TW	ffmpeg-7	2026-07-26
SUSE	openSUSE-SU-2026:11347-1	TW	ffmpeg-8	2026-07-25
SUSE	SUSE-SU-2026:3149-1	SLE15	ffmpeg	2026-07-21
SUSE	SUSE-SU-2026:3200-1	SLE12	firefox	2026-07-23
SUSE	SUSE-SU-2026:3221-1	SLE15	firefox	2026-07-24
SUSE	openSUSE-SU-2026:11358-1	TW	firefox	2026-07-26
SUSE	openSUSE-SU-2026:11329-1	TW	firefox-esr	2026-07-23
SUSE	SUSE-SU-2026:22922-1	SLE-m6.0	freetype2	2026-07-27
SUSE	SUSE-SU-2026:22750-1	SLE-m6.2	freetype2	2026-07-22
SUSE	SUSE-SU-2026:22815-1	SLE16.0	freetype2	2026-07-27
SUSE	SUSE-SU-2026:22767-1	SLE-m6.2	gawk	2026-07-22
SUSE	SUSE-SU-2026:3211-1	SLE12	gawk	2026-07-23
SUSE	SUSE-SU-2026:22831-1	SLE16.0	gawk	2026-07-27
SUSE	openSUSE-SU-2026:21393-1	oS16.0	gawk	2026-07-23
SUSE	openSUSE-SU-2026:21432-1	oS16.0	gh	2026-07-24
SUSE	openSUSE-SU-2026:0259-1	osB15	gh	2026-07-24
SUSE	SUSE-SU-2026:3399-1	SLE15 oS15.4	gimp	2026-07-29
SUSE	SUSE-SU-2026:3121-1	SLE12	glib-networking	2026-07-20
SUSE	SUSE-SU-2026:3236-1	SLE12	glib2	2026-07-27
SUSE	SUSE-SU-2026:3235-1	SLE15 SLE5.3 SLE5.4 SLE5.5 SLE-m5.3 SLE-m5.4 SLE-m5.5 oS15.4	glib2	2026-07-27
SUSE	SUSE-SU-2026:3341-1	SLE15 oS15.6	glib2	2026-07-28
SUSE	SUSE-SU-2026:22846-1	SLE16.0	glib2	2026-07-27
SUSE	openSUSE-SU-2026:21410-1	oS16.0	glib2	2026-07-24
SUSE	SUSE-SU-2026:2987-1	SLE12	glibc	2026-07-14
SUSE	SUSE-SU-2026:2924-1	SLE12	gnutls	2026-07-14
SUSE	SUSE-SU-2026:2923-1	SLE12	gnutls	2026-07-14
SUSE	SUSE-SU-2026:22643-1	SLE16.0	go1.25	2026-07-16
SUSE	SUSE-SU-2026:3046-1	SLE15	go1.25-openssl	2026-07-15
SUSE	SUSE-SU-2026:22638-1	SLE16.0	go1.25-openssl	2026-07-16
SUSE	SUSE-SU-2026:22656-1	SLE16.0	go1.26	2026-07-16
SUSE	SUSE-SU-2026:3047-1	SLE15	go1.26-openssl	2026-07-15
SUSE	SUSE-SU-2026:22572-1	SLE16.0	go1.26-openssl	2026-07-14
SUSE	SUSE-SU-2026:22641-1	SLE16.0	go1.26-openssl	2026-07-16
SUSE	SUSE-SU-2026:22848-1	SLE16.0	google-cloud-sap-agent	2026-07-27
SUSE	SUSE-SU-2026:3210-1	MP4.3 SLE15 SLE5.5 SLE-m5.5	google-guest-agent	2026-07-23
SUSE	SUSE-SU-2026:3209-1	SLE12	google-osconfig-agent	2026-07-23
SUSE	SUSE-SU-2026:22558-1	SLE16.0	google-osconfig-agent	2026-07-14
SUSE	openSUSE-SU-2026:11331-1	TW	google-osconfig-agent	2026-07-23
SUSE	openSUSE-SU-2026:11349-1	TW	google-osconfig-agent	2026-07-25
SUSE	SUSE-SU-2026:22923-1	SLE-m6.1	gpg2	2026-07-27
SUSE	SUSE-SU-2026:22757-1	SLE-m6.2	gpg2	2026-07-22
SUSE	SUSE-SU-2026:3243-1	SLE15 oS15.6	gpg2	2026-07-27
SUSE	SUSE-SU-2026:22825-1	SLE16.0	gpg2	2026-07-27
SUSE	openSUSE-SU-2026:21385-1	oS16.0	gpg2	2026-07-23
SUSE	SUSE-SU-2026:22631-1	SLE16.0	gsasl	2026-07-16
SUSE	SUSE-SU-2026:22752-1	SLE-m6.2	gstreamer-plugins-bad	2026-07-22
SUSE	SUSE-SU-2026:22817-1	SLE16.0	gstreamer-plugins-bad	2026-07-27
SUSE	SUSE-SU-2026:22918-1	SLE-m6.0	gzip	2026-07-27
SUSE	SUSE-SU-2026:22906-1	SLE-m6.1	gzip	2026-07-27
SUSE	SUSE-SU-2026:22753-1	SLE-m6.2	gzip	2026-07-22
SUSE	SUSE-SU-2026:3241-1	SLE12	gzip	2026-07-27
SUSE	SUSE-SU-2026:3269-1	SLE15 SLE5.3 SLE5.4 SLE5.5 SLE-m5.3 SLE-m5.4 SLE-m5.5	gzip	2026-07-27
SUSE	SUSE-SU-2026:22818-1	SLE16.0	gzip	2026-07-27
SUSE	SUSE-SU-2026:22663-1	SLE-m6.1	haproxy	2026-07-20
SUSE	SUSE-SU-2026:22587-1	SLE16.0	haproxy	2026-07-14
SUSE	SUSE-SU-2026:22557-1	SLE16.0	haproxy	2026-07-14
SUSE	openSUSE-SU-2026:21433-1	oS16.0	hauler	2026-07-24
SUSE	SUSE-SU-2026:22603-1	SLE-m6.2	helm	2026-07-15
SUSE	SUSE-SU-2026:3050-1	SLE15 SLE5.5 SLE-m5.5	helm	2026-07-15
SUSE	SUSE-SU-2026:22650-1	SLE16.0	helm	2026-07-16
SUSE	SUSE-SU-2026:22855-1	SLE16.0	helm	2026-07-27
SUSE	openSUSE-SU-2026:21422-1	oS16.0	helm	2026-07-24
SUSE	openSUSE-SU-2026:11334-1	TW	helm3	2026-07-24
SUSE	SUSE-SU-2026:3300-1	SLE15 oS15.4	ignition	2026-07-28
SUSE	SUSE-SU-2026:3267-1	SLE5.3 SLE-m5.3	ignition	2026-07-27
SUSE	SUSE-SU-2026:3266-1	SLE5.4 SLE-m5.4	ignition	2026-07-27
SUSE	SUSE-SU-2026:3265-1	SLE5.5 SLE-m5.5	ignition	2026-07-27
SUSE	openSUSE-SU-2026:11376-1	TW	ignition	2026-07-28
SUSE	openSUSE-SU-2026:21391-1	oS16.0	imagemagick	2026-07-23
SUSE	openSUSE-SU-2026:21426-1	oS16.0	imagemagick	2026-07-24
SUSE	SUSE-SU-2026:3150-1	SLE12	iproute2	2026-07-21
SUSE	SUSE-SU-2026:3273-1	SLE15	jackson-annotations, jackson-bom, jackson-core, jackson- databind, jackson-dataformats-binary, jackson-modules-base	2026-07-27
SUSE	SUSE-SU-2026:22822-1	SLE16.0	jackson-annotations, jackson-core, jackson-databind	2026-07-27
SUSE	SUSE-SU-2026:3284-1	SLE12	java-11-openjdk	2026-07-27
SUSE	openSUSE-SU-2026:11335-1	TW	java-11-openjdk	2026-07-24
SUSE	openSUSE-SU-2026:21440-1	oS16.0	java-17-openjdk	2026-07-26
SUSE	SUSE-SU-2026:3332-1	SLE15 oS15.6	java-21-openjdk	2026-07-28
SUSE	openSUSE-SU-2026:11363-1	TW	java-25-openjdk	2026-07-26
SUSE	openSUSE-SU-2026:11337-1	TW	java-26-openjdk	2026-07-24
SUSE	SUSE-SU-2026:22562-1	SLE16.0	jline3	2026-07-14
SUSE	SUSE-SU-2026:22856-1	SLE16.0	jline3	2026-07-27
SUSE	openSUSE-SU-2026:21423-1	oS16.0	jline3	2026-07-24
SUSE	SUSE-SU-2026:3196-1	SLE12	joe	2026-07-22
SUSE	SUSE-SU-2026:3108-1	SLE15	joe	2026-07-17
SUSE	SUSE-SU-2026:22843-1	SLE16.0	joe	2026-07-27
SUSE	openSUSE-SU-2026:21408-1	oS16.0	joe	2026-07-24
SUSE	SUSE-SU-2026:22705-1	SLE-m6.0	jq	2026-07-22
SUSE	SUSE-SU-2026:22664-1	SLE-m6.1	jq	2026-07-20
SUSE	SUSE-SU-2026:22900-1	SLE-m6.1	jq	2026-07-27
SUSE	SUSE-SU-2026:22597-1	SLE-m6.2	jq	2026-07-15
SUSE	SUSE-SU-2026:2983-1	SLE15 SLE5.3 SLE5.4 SLE5.5 SLE-m5.3 SLE-m5.4 SLE-m5.5	jq	2026-07-14
SUSE	SUSE-SU-2026:22566-1	SLE16.0	jq	2026-07-14
SUSE	SUSE-SU-2026:22637-1	SLE16.0	jq	2026-07-16
SUSE	SUSE-SU-2026:3130-1	SLE15	kernel	2026-07-20
SUSE	SUSE-SU-2026:3166-1	SLE15	kernel	2026-07-22
SUSE	SUSE-SU-2026:22812-1	SLE16.0	kernel	2026-07-27
SUSE	SUSE-SU-2026:22835-1	SLE16.0	kernel	2026-07-27
SUSE	SUSE-SU-2026:22769-1	SLE16.0 SLE-m6.2	kernel	2026-07-22
SUSE	SUSE-SU-2026:22742-1	SLE16.0 SLE-m6.2	kernel	2026-07-22
SUSE	openSUSE-SU-2026:21388-1	SLE16.0 oS16.0	kernel	2026-07-23
SUSE	SUSE-SU-2026:22810-1	SLE6.0 SLE-m6.0	kernel	2026-07-27
SUSE	SUSE-SU-2026:22809-1	SLE6.0 SLE-m6.0	kernel	2026-07-27
SUSE	SUSE-SU-2026:22791-1	SLE6.0 SLE-m6.0	kernel	2026-07-27
SUSE	SUSE-SU-2026:22790-1	SLE6.0 SLE-m6.0	kernel	2026-07-27
SUSE	SUSE-SU-2026:22666-1	SLE6.0 SLE-m6.0 SLE-m6.1	kernel	2026-07-20
SUSE	SUSE-SU-2026:22665-1	SLE6.0 SLE-m6.0 SLE-m6.1	kernel	2026-07-20
SUSE	SUSE-SU-2026:22699-1	SLE6.0 SLE-m6.0 SLE-m6.1	kernel	2026-07-20
SUSE	SUSE-SU-2026:22883-1	SLE6.0 SLE-m6.0 SLE-m6.1	kernel	2026-07-27
SUSE	SUSE-SU-2026:22904-1	SLE6.0 SLE-m6.0 SLE-m6.1	kernel	2026-07-27
SUSE	SUSE-SU-2026:22903-1	SLE6.0 SLE-m6.0 SLE-m6.1	kernel	2026-07-27
SUSE	openSUSE-SU-2026:11339-1	TW	kernel-devel	2026-07-24
SUSE	SUSE-SU-2026:22702-1	SLE-m6.0	krb5	2026-07-22
SUSE	SUSE-SU-2026:22700-1	SLE-m6.0	krb5	2026-07-22
SUSE	SUSE-SU-2026:3203-1	SLE15	kubevirt	2026-07-23
SUSE	SUSE-SU-2026:22614-1	SLE16.0	libXfont2	2026-07-16
SUSE	SUSE-SU-2026:22919-1	SLE-m6.0	libgcrypt	2026-07-27
SUSE	SUSE-SU-2026:22907-1	SLE-m6.1	libgcrypt	2026-07-27
SUSE	SUSE-SU-2026:22760-1	SLE-m6.2	libgcrypt	2026-07-22
SUSE	SUSE-SU-2026:3182-1	SLE15	libgcrypt	2026-07-22
SUSE	SUSE-SU-2026:22826-1	SLE16.0	libgcrypt	2026-07-27
SUSE	openSUSE-SU-2026:21387-1	oS16.0	libgcrypt	2026-07-23
SUSE	SUSE-SU-2026:2967-1	SLE12 oS15.0	libgnt, meson, pidgin	2026-07-14
SUSE	openSUSE-SU-2026:11364-1	TW	libknet-devel	2026-07-27
SUSE	SUSE-SU-2026:3039-1	SLE12	libpng12	2026-07-15
SUSE	SUSE-SU-2026:3116-1	SLE12	libqt4	2026-07-17
SUSE	SUSE-SU-2026:22920-1	SLE-m6.0	libsoup	2026-07-27
SUSE	openSUSE-SU-2026:11357-1	TW	libsrt1_5	2026-07-26
SUSE	SUSE-SU-2026:3330-1	SLE15 oS15.6	libssh	2026-07-28
SUSE	openSUSE-SU-2026:11377-1	TW	libssh-config	2026-07-28
SUSE	SUSE-SU-2026:3082-1	SLE15	libssh2_org	2026-07-17
SUSE	SUSE-SU-2026:3074-1	SLE15 SLE5.3 SLE5.4 SLE5.5 SLE-m5.3 SLE-m5.4 SLE-m5.5	libssh2_org	2026-07-16
SUSE	SUSE-SU-2026:22806-1	SLE-m6.0	libxml2	2026-07-27
SUSE	SUSE-SU-2026:22894-1	SLE-m6.1	libxml2	2026-07-27
SUSE	SUSE-SU-2026:22596-1	SLE-m6.2	libxml2	2026-07-15
SUSE	SUSE-SU-2026:3111-1	SLE12	libxml2	2026-07-17
SUSE	SUSE-SU-2026:3097-1	SLE15	libxml2	2026-07-17
SUSE	SUSE-SU-2026:22636-1	SLE16.0	libxml2	2026-07-16
SUSE	SUSE-SU-2026:3135-1	SLE12	mariadb-connector-c	2026-07-20
SUSE	SUSE-SU-2026:3134-1	SLE15	mariadb-connector-c	2026-07-20
SUSE	SUSE-SU-2026:22844-1	SLE16.0	mariadb-connector-c	2026-07-27
SUSE	openSUSE-SU-2026:21409-1	oS16.0	mariadb-connector-c	2026-07-24
SUSE	openSUSE-SU-2026:11366-1	TW	mcphost	2026-07-27
SUSE	SUSE-SU-2026:3124-1	SLE11	microcode_ctl	2026-07-20
SUSE	SUSE-SU-2026:3212-1	SLE12	multipath-tools	2026-07-23
SUSE	SUSE-SU-2026:3199-1	SLE5.3 SLE5.4 SLE-m5.3 SLE-m5.4 oS15.4	multipath-tools	2026-07-23
SUSE	SUSE-SU-2026:3184-1	oS15.6	multipath-tools	2026-07-22
SUSE	SUSE-SU-2026:3178-1	SLE15	nasm	2026-07-22
SUSE	SUSE-SU-2026:3222-1	SLE12	net-tools	2026-07-24
SUSE	SUSE-SU-2026:3223-1	SLE15 SLE5.3 SLE5.4 SLE5.5 SLE-m5.3 SLE-m5.4 SLE-m5.5	net-tools	2026-07-24
SUSE	SUSE-SU-2026:22862-1	SLE16.0	net-tools	2026-07-27
SUSE	openSUSE-SU-2026:21429-1	oS16.0	net-tools	2026-07-24
SUSE	SUSE-SU-2026:22707-1	SLE-m6.0	nghttp2	2026-07-22
SUSE	SUSE-SU-2026:22893-1	SLE-m6.1	nghttp2	2026-07-27
SUSE	SUSE-SU-2026:22594-1	SLE-m6.2	nghttp2	2026-07-15
SUSE	SUSE-SU-2026:3154-1	SLE12	nghttp2	2026-07-21
SUSE	SUSE-SU-2026:22630-1	SLE16.0	nghttp2	2026-07-16
SUSE	SUSE-SU-2026:3329-1	SLE15 oS15.6	nginx	2026-07-28
SUSE	openSUSE-SU-2026:21439-1	oS16.0	nginx	2026-07-26
SUSE	SUSE-SU-2026:22739-1	SLE-m6.2	nmap	2026-07-22
SUSE	SUSE-SU-2026:3340-1	SLE15 oS15.6	nmap	2026-07-28
SUSE	SUSE-SU-2026:3220-1	oS15.4	nmap	2026-07-24
SUSE	SUSE-SU-2026:22565-1	SLE16.0	nodejs24	2026-07-14
SUSE	openSUSE-SU-2026:0265-1	osB15	nsd	2026-07-29
SUSE	SUSE-SU-2026:3213-1	SLE12	ntfs-3g_ntfsprogs	2026-07-23
SUSE	SUSE-SU-2026:3214-1	SLE15	ntfs-3g_ntfsprogs	2026-07-23
SUSE	SUSE-SU-2026:3168-1	SLE12	openexr	2026-07-22
SUSE	SUSE-SU-2026:3169-1	SLE15	openexr	2026-07-22
SUSE	SUSE-SU-2026:22653-1	SLE16.0	openexr	2026-07-16
SUSE	openSUSE-SU-2026:11369-1	TW	opennlp	2026-07-27
SUSE	SUSE-SU-2026:3272-1	SLE12	openssl-1_0_0	2026-07-27
SUSE	SUSE-SU-2026:2970-1	SLE12	pacemaker	2026-07-14
SUSE	openSUSE-SU-2026:21425-1	oS16.0	packagekit	2026-07-24
SUSE	SUSE-SU-2026:22807-1	SLE-m6.0	pam	2026-07-27
SUSE	SUSE-SU-2026:22896-1	SLE-m6.1	pam	2026-07-27
SUSE	SUSE-SU-2026:22599-1	SLE-m6.2	pam	2026-07-15
SUSE	SUSE-SU-2026:3162-1	SLE12	pam	2026-07-21
SUSE	SUSE-SU-2026:3163-1	SLE15 SLE5.3 SLE5.4 SLE5.5 SLE-m5.3 SLE-m5.4 SLE-m5.5	pam	2026-07-21
SUSE	SUSE-SU-2026:22639-1	SLE16.0	pam	2026-07-16
SUSE	SUSE-SU-2026:22905-1	SLE-m6.1	patch	2026-07-27
SUSE	SUSE-SU-2026:22604-1	SLE-m6.2	patch	2026-07-15
SUSE	SUSE-SU-2026:2922-1	SLE12	patch	2026-07-14
SUSE	SUSE-SU-2026:3161-1	SLE15	patch	2026-07-21
SUSE	SUSE-SU-2026:22651-1	SLE16.0	patch	2026-07-16
SUSE	SUSE-SU-2026:22798-1	SLE-m6.0	pcr-oracle	2026-07-27
SUSE	SUSE-SU-2026:22592-1	SLE-m6.2	perl-DBI	2026-07-15
SUSE	SUSE-SU-2026:3283-1	SLE15	perl-DBI	2026-07-27
SUSE	SUSE-SU-2026:22623-1	SLE16.0	perl-DBI	2026-07-16
SUSE	SUSE-SU-2026:22845-1	SLE16.0	perl-DBI	2026-07-27
SUSE	SUSE-SU-2026:2948-1	SLE12	perl-HTML-Parser	2026-07-14
SUSE	SUSE-SU-2026:2950-1	SLE15	perl-HTML-Parser	2026-07-14
SUSE	SUSE-SU-2026:22859-1	SLE16.0	perl-HTTP-Date	2026-07-27
SUSE	openSUSE-SU-2026:11350-1	TW	perl-HTTP-Date	2026-07-25
SUSE	SUSE-SU-2026:22559-1	SLE16.0	perl-List-SomeUtils-XS	2026-07-14
SUSE	SUSE-SU-2026:22847-1	SLE16.0	perl	2026-07-27
SUSE	openSUSE-SU-2026:11351-1	TW	perl-XML-Bare	2026-07-25
SUSE	openSUSE-SU-2026:11321-1	TW	perl-YAML	2026-07-22
SUSE	openSUSE-SU-2026:21412-1	oS16.0	perl-dbi	2026-07-24
SUSE	openSUSE-SU-2026:21427-1	oS16.0	perl-http-date	2026-07-24
SUSE	SUSE-SU-2026:3033-1	SLE12	perl-libwww-perl	2026-07-15
SUSE	SUSE-SU-2026:2962-1	SLE15	perl-libwww-perl	2026-07-14
SUSE	openSUSE-SU-2026:21411-1	oS16.0	perl	2026-07-24
SUSE	openSUSE-SU-2026:21435-1	oS16.0	perl-xml-bare	2026-07-24
SUSE	SUSE-SU-2026:3164-1	SLE15	php8	2026-07-21
SUSE	SUSE-SU-2026:22635-1	SLE16.0	php8	2026-07-16
SUSE	openSUSE-SU-2026:11352-1	TW	proftpd	2026-07-25
SUSE	openSUSE-SU-2026:11340-1	TW	prometheus-ha_cluster_exporter	2026-07-24
SUSE	SUSE-SU-2026:3268-1	SLE15 oS15.4	python-Pillow	2026-07-27
SUSE	SUSE-SU-2026:22626-1	SLE16.0	python-Pillow	2026-07-16
SUSE	SUSE-SU-2026:2982-1	SLE15	python-WebOb	2026-07-14
SUSE	SUSE-SU-2026:3059-1	MP4.3 SLE15	python-aiohttp	2026-07-15
SUSE	SUSE-SU-2026:3208-1	MP4.3 SLE15	python-aiohttp	2026-07-23
SUSE	SUSE-SU-2026:3207-1	MP4.3 SLE15 oS15.4	python-aiohttp	2026-07-23
SUSE	SUSE-SU-2026:22819-1	SLE16.0	python-aiohttp	2026-07-27
SUSE	SUSE-SU-2026:22801-1	SLE-m6.0	python-cryptography	2026-07-27
SUSE	SUSE-SU-2026:22895-1	SLE-m6.1	python-cryptography	2026-07-27
SUSE	SUSE-SU-2026:22593-1	SLE-m6.2	python-cryptography	2026-07-15
SUSE	SUSE-SU-2026:22624-1	SLE16.0	python-cryptography	2026-07-16
SUSE	SUSE-SU-2026:3117-1	SLE12	python-dulwich	2026-07-17
SUSE	SUSE-SU-2026:3101-1	SLE12	python-idna	2026-07-17
SUSE	SUSE-SU-2026:3100-1	SLE15 SLE5.3 SLE5.4 SLE5.5 SLE-m5.3 SLE-m5.4 SLE-m5.5	python-idna	2026-07-17
SUSE	SUSE-SU-2026:22589-1	SLE-m6.2	python-maturin	2026-07-15
SUSE	SUSE-SU-2026:22615-1	SLE16.0	python-maturin	2026-07-16
SUSE	SUSE-SU-2026:22655-1	SLE16.0	python-mistune	2026-07-16
SUSE	SUSE-SU-2026:22704-1	SLE-m6.0	python-msgpack	2026-07-22
SUSE	SUSE-SU-2026:3113-1	SLE15 SLE5.3 SLE5.4 SLE5.5 SLE-m5.3 SLE-m5.4 SLE-m5.5	python-msgpack	2026-07-17
SUSE	SUSE-SU-2026:3031-1	SLE15	python-paramiko	2026-07-15
SUSE	SUSE-SU-2026:3238-1	MP4.3 SLE15 oS15.4	python-pyasn1	2026-07-27
SUSE	SUSE-SU-2026:22765-1	SLE-m6.2	python-pyasn1	2026-07-22
SUSE	SUSE-SU-2026:22830-1	SLE16.0	python-pyasn1	2026-07-27
SUSE	SUSE-SU-2026:3239-1	SLE15	python-soupsieve	2026-07-27
SUSE	SUSE-SU-2026:3240-1	SLE15 oS15.6	python-soupsieve	2026-07-27
SUSE	SUSE-SU-2026:22660-1	SLE16.0	python-soupsieve	2026-07-16
SUSE	SUSE-SU-2026:3179-1	MP4.3 SLE15 oS15.4	python-sqlparse	2026-07-22
SUSE	SUSE-SU-2026:3180-1	SLE15 oS15.6	python-sqlparse	2026-07-22
SUSE	SUSE-SU-2026:22657-1	SLE16.0	python-sqlparse	2026-07-16
SUSE	SUSE-SU-2026:3291-1	SLE12	python-tornado	2026-07-27
SUSE	SUSE-SU-2026:3160-1	SLE15 SLE5.3 SLE5.4 SLE5.5 SLE-m5.3 SLE-m5.4 SLE-m5.5	python-tornado	2026-07-21
SUSE	SUSE-SU-2026:22708-1	SLE-m6.0	python-tornado6	2026-07-22
SUSE	SUSE-SU-2026:22885-1	SLE-m6.1	python-tornado6	2026-07-27
SUSE	SUSE-SU-2026:3397-1	MP4.3 SLE15 oS15.4	python-urllib3	2026-07-29
SUSE	SUSE-SU-2026:2854-2	SLE15	python-urllib3	2026-07-16
SUSE	SUSE-SU-2026:0255-2	SLE15	python-urllib3	2026-07-23
SUSE	SUSE-SU-2026:0367-2	SLE15	python-urllib3	2026-07-23
SUSE	SUSE-SU-2026:22863-1	SLE16.0	python-urllib3	2026-07-27
SUSE	SUSE-SU-2026:3245-1	SLE12	python3	2026-07-27
SUSE	SUSE-SU-2026:3181-1	SLE15 oS15.3	python3-sqlparse	2026-07-22
SUSE	openSUSE-SU-2026:11378-1	TW	python313-CherryPy	2026-07-28
SUSE	openSUSE-SU-2026:11342-1	TW	python313	2026-07-24
SUSE	openSUSE-SU-2026:11353-1	TW	python313-astropy	2026-07-25
SUSE	openSUSE-SU-2026:11323-1	TW	python313-bleach	2026-07-22
SUSE	openSUSE-SU-2026:11341-1	TW	python313-pandas	2026-07-24
SUSE	openSUSE-SU-2026:11356-1	TW	python313-urwid	2026-07-26
SUSE	openSUSE-SU-2026:11343-1	TW	python314	2026-07-24
SUSE	SUSE-SU-2026:3038-1	SLE15	qemu	2026-07-15
SUSE	SUSE-SU-2026:22576-1	SLE16.0	qemu	2026-07-14
SUSE	SUSE-SU-2026:3055-1	SLE15	radvd	2026-07-15
SUSE	SUSE-SU-2026:22836-1	SLE16.0	radvd	2026-07-27
SUSE	SUSE-SU-2026:3045-1	SLE15	rootlesskit	2026-07-15
SUSE	SUSE-SU-2026:3078-1	SLE12	rpcbind	2026-07-16
SUSE	SUSE-SU-2026:3077-1	SLE15 SLE5.3 SLE5.4 SLE5.5 SLE-m5.3 SLE-m5.4 SLE-m5.5	rpcbind	2026-07-16
SUSE	SUSE-SU-2026:3398-1	SLE15 oS15.6	rsyslog	2026-07-29
SUSE	SUSE-SU-2026:3090-1	SLE15	ruby3.4	2026-07-17
SUSE	SUSE-SU-2026:3051-1	SLE15 SLE5.3 SLE5.4 SLE5.5 SLE-m5.3 SLE-m5.4 SLE-m5.5 SES7.1	runc	2026-07-15
SUSE	SUSE-SU-2026:22921-1	SLE-m6.0	rust-keylime	2026-07-27
SUSE	SUSE-SU-2026:22898-1	SLE-m6.1	rust-keylime	2026-07-27
SUSE	SUSE-SU-2026:22583-1	SLE16.0	rust-keylime	2026-07-14
SUSE	SUSE-SU-2026:22737-1	SLE-m6.0	s390-tools	2026-07-22
SUSE	SUSE-SU-2026:22910-1	SLE-m6.1	s390-tools	2026-07-27
SUSE	SUSE-SU-2026:3362-1	MP4.3 SLE15 SLE5.3 SLE5.4 SLE-m5.3 SLE-m5.4 oS15.4	samba	2026-07-28
SUSE	SUSE-SU-2026:3366-1	SLE15 SES7.1 oS15.3	samba	2026-07-28
SUSE	SUSE-SU-2026:3365-1	SLE15 SLE5.5 SLE-m5.5 oS15.5	samba	2026-07-28
SUSE	SUSE-SU-2026:3364-1	SLE15 oS15.6	samba	2026-07-28
SUSE	SUSE-SU-2026:3098-1	SLE12	shibboleth-sp	2026-07-17
SUSE	SUSE-SU-2026:22854-1	SLE16.0	shibboleth-sp	2026-07-27
SUSE	openSUSE-SU-2026:21418-1	oS16.0	shibboleth-sp	2026-07-24
SUSE	SUSE-SU-2026:22799-1	SLE-m6.0	sssd	2026-07-27
SUSE	SUSE-SU-2026:22897-1	SLE-m6.1	sssd	2026-07-27
SUSE	SUSE-SU-2026:22591-1	SLE-m6.2	sssd	2026-07-15
SUSE	SUSE-SU-2026:3131-1	SLE12	sssd	2026-07-20
SUSE	SUSE-SU-2026:3041-1	SLE15	sssd	2026-07-15
SUSE	SUSE-SU-2026:3195-1	SLE15 SLE5.5 SLE-m5.5 oS15.5	sssd	2026-07-22
SUSE	SUSE-SU-2026:22621-1	SLE16.0	sssd	2026-07-16
SUSE	SUSE-SU-2026:3368-1	SLE5.3 SLE5.4 SLE-m5.3 SLE-m5.4 oS15.4	sssd	2026-07-28
SUSE	SUSE-SU-2026:3122-1	SLE12	systemd, systemd-mini	2026-07-20
SUSE	SUSE-SU-2026:22736-1	SLE-m6.0	systemd	2026-07-22
SUSE	SUSE-SU-2026:22701-1	SLE-m6.0	systemd	2026-07-22
SUSE	SUSE-SU-2026:22813-1	SLE-m6.1	systemd	2026-07-27
SUSE	SUSE-SU-2026:22890-1	SLE-m6.1	systemd	2026-07-27
SUSE	SUSE-SU-2026:3244-1	SLE15 oS15.6	systemd	2026-07-27
SUSE	SUSE-SU-2026:3197-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-07-22
SUSE	SUSE-SU-2026:3056-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-07-15
SUSE	SUSE-SU-2026:3057-1	MP4.3 SLE15	terraform-provider-susepubliccloud	2026-07-15
SUSE	SUSE-SU-2026:3198-1	MP4.3 SLE15	terraform-provider-susepubliccloud	2026-07-22
SUSE	openSUSE-SU-2026:11359-1	TW	thunderbird	2026-07-26
SUSE	SUSE-SU-2026:22796-1	SLE-m6.0	tiff	2026-07-27
SUSE	SUSE-SU-2026:22886-1	SLE-m6.1	tiff	2026-07-27
SUSE	SUSE-SU-2026:22590-1	SLE-m6.2	tiff	2026-07-15
SUSE	SUSE-SU-2026:3027-1	SLE12	tiff	2026-07-15
SUSE	SUSE-SU-2026:3054-1	SLE15 SLE5.3 SLE5.4 SLE5.5 SLE-m5.3 SLE-m5.4 SLE-m5.5	tiff	2026-07-15
SUSE	SUSE-SU-2026:22616-1	SLE16.0	tiff	2026-07-16
SUSE	SUSE-SU-2026:3167-1	SLE12	tomcat	2026-07-22
SUSE	SUSE-SU-2026:3088-1	SLE15	tomcat	2026-07-17
SUSE	SUSE-SU-2026:22646-1	SLE16.0	tomcat	2026-07-16
SUSE	SUSE-SU-2026:3112-1	SLE15	tomcat10	2026-07-17
SUSE	SUSE-SU-2026:22647-1	SLE16.0	tomcat10	2026-07-16
SUSE	SUSE-SU-2026:22648-1	SLE16.0	tomcat11	2026-07-16
SUSE	openSUSE-SU-2026:21395-1	oS16.0	trivy	2026-07-23
SUSE	openSUSE-SU-2026:0263-1	osB15	trivy	2026-07-27
SUSE	SUSE-SU-2026:2981-1	SLE12	ucode-intel	2026-07-14
SUSE	SUSE-SU-2026:2963-1	SLE15 SLE5.3 SLE5.4 SLE5.5 SLE-m5.3 SLE-m5.4 SLE-m5.5	ucode-intel	2026-07-14
SUSE	SUSE-SU-2026:3021-1	SLE15	uriparser	2026-07-15
SUSE	SUSE-SU-2026:22627-1	SLE16.0	uriparser	2026-07-16
SUSE	openSUSE-SU-2026:11381-1	TW	valkey	2026-07-28
SUSE	SUSE-SU-2026:22797-1	SLE-m6.0	vim	2026-07-27
SUSE	SUSE-SU-2026:22789-1	SLE-m6.0	vim	2026-07-27
SUSE	SUSE-SU-2026:22901-1	SLE-m6.1	vim	2026-07-27
SUSE	SUSE-SU-2026:22754-1	SLE-m6.2	vim	2026-07-22
SUSE	SUSE-SU-2026:22740-1	SLE-m6.2	vim	2026-07-22
SUSE	SUSE-SU-2026:3237-1	SLE12	vim	2026-07-27
SUSE	SUSE-SU-2026:3271-1	SLE15 SLE5.3 SLE5.4 SLE-m5.3 SLE-m5.4	vim	2026-07-27
SUSE	SUSE-SU-2026:22821-1	SLE16.0	vim	2026-07-27
SUSE	SUSE-SU-2026:22814-1	SLE16.0 SLE-m6.1	vim	2026-07-27
SUSE	SUSE-SU-2026:3114-1	SLE12	vorbis-tools	2026-07-17
SUSE	SUSE-SU-2026:3115-1	SLE15	vorbis-tools	2026-07-17
SUSE	SUSE-SU-2026:3396-1	SLE15 oS15.4	webkit2gtk3	2026-07-29
SUSE	SUSE-SU-2026:3338-1	SLE15 oS15.6	webkit2gtk3	2026-07-28
SUSE	SUSE-SU-2026:3205-1	SLE12	wget	2026-07-23
SUSE	SUSE-SU-2026:3148-1	SLE15	wget	2026-07-21
SUSE	SUSE-SU-2026:3206-1	SLE15 SLE5.5 SLE-m5.5	wget	2026-07-23
SUSE	SUSE-SU-2026:2969-1	SLE12	wireshark	2026-07-14
SUSE	SUSE-SU-2026:3159-1	SLE12	wpa_supplicant	2026-07-21
SUSE	SUSE-SU-2026:3103-1	SLE15	wpa_supplicant	2026-07-17
SUSE	SUSE-SU-2026:22851-1	SLE16.0	wpa_supplicant	2026-07-27
SUSE	SUSE-SU-2026:3281-1	SLE5.3 SLE5.4 SLE-m5.3 SLE-m5.4	wpa_supplicant	2026-07-27
SUSE	SUSE-SU-2026:22617-1	SLE16.0	xwayland	2026-07-16
SUSE	SUSE-SU-2026:3035-1	SLE12	yelp	2026-07-15
SUSE	SUSE-SU-2026:22625-1	SLE16.0	yelp	2026-07-16
SUSE	SUSE-SU-2026:3327-1	SLE15 oS15.5	yq	2026-07-28
Ubuntu	USN-8613-1	14.04 16.04 18.04 20.04 22.04 24.04 26.04	FreeIPMI	2026-07-27
Ubuntu	USN-8589-1	14.04 16.04 18.04 20.04	apache2	2026-07-22
Ubuntu	USN-8322-2	16.04	commons-beanutils	2026-07-23
Ubuntu	USN-8590-1	22.04 24.04 26.04	exim4	2026-07-22
Ubuntu	USN-8561-2	24.04 26.04	freerdp3	2026-07-28
Ubuntu	USN-8588-1	14.04 16.04 18.04 20.04 22.04 24.04 26.04	gawk	2026-07-22
Ubuntu	USN-8583-1	22.04 24.04 26.04	giflib	2026-07-22
Ubuntu	USN-8611-1	22.04 24.04 26.04	glibc	2026-07-27
Ubuntu	USN-8584-1	22.04 24.04 26.04	gst-plugins-good1.0	2026-07-22
Ubuntu	USN-8585-1	22.04 24.04 26.04	krb5	2026-07-22
Ubuntu	USN-8369-2	16.04	libapache-mod-jk	2026-07-23
Ubuntu	USN-8581-1	20.04 22.04 24.04 26.04	libarchive	2026-07-22
Ubuntu	USN-8586-1	22.04 24.04 26.04	libgphoto2	2026-07-22
Ubuntu	USN-8587-1	22.04 24.04 26.04	libhtml-parser-perl	2026-07-22
Ubuntu	USN-8599-1	22.04 24.04 26.04	libhttp-date-perl	2026-07-23
Ubuntu	USN-8600-1	22.04 24.04 26.04	libxpm	2026-07-23
Ubuntu	USN-8615-1	18.04 20.04	linux, linux-aws, linux-aws-5.4, linux-aws-fips, linux-azure, linux-azure-5.4, linux-azure-fips, linux-bluefield, linux-fips, linux-gcp, linux-gcp-5.4, linux-gcp-fips, linux-hwe-5.4, linux-iot, linux-oracle, linux-oracle-5.4, linux-xilinx-zynqmp	2026-07-28
Ubuntu	USN-8575-2	20.04 22.04	linux-aws, linux-aws-5.15, linux-aws-fips, linux-fips, linux-ibm, linux-nvidia	2026-07-23
Ubuntu	USN-8618-1	26.04	linux-aws, linux-raspi	2026-07-28
Ubuntu	USN-8595-2	24.04	linux-aws	2026-07-24
Ubuntu	USN-8595-3	22.04 24.04	linux-aws-6.8, linux-aws-fips	2026-07-28
Ubuntu	USN-8606-1	22.04 24.04	linux-azure, linux-azure-6.8	2026-07-24
Ubuntu	USN-8603-1	26.04	linux-azure, linux-azure-fde	2026-07-24
Ubuntu	USN-8575-3	22.04	linux-azure, linux-oracle	2026-07-24
Ubuntu	USN-8620-1	20.04	linux-azure-5.15, linux-azure-fde-5.15, linux-oracle-5.15	2026-07-28
Ubuntu	USN-8604-1	24.04	linux-azure-6.17	2026-07-24
Ubuntu	USN-8610-1	22.04	linux-azure-fde	2026-07-24
Ubuntu	USN-8607-1	24.04	linux-azure-fde	2026-07-24
Ubuntu	USN-8605-1	24.04	linux-azure-fde-6.17	2026-07-24
Ubuntu	USN-8609-1	22.04	linux-azure-fde-6.8	2026-07-24
Ubuntu	USN-8620-2	22.04	linux-azure-fips	2026-07-29
Ubuntu	USN-8547-2	22.04	linux-azure-fips	2026-07-28
Ubuntu	USN-8608-1	24.04	linux-azure-fips	2026-07-24
Ubuntu	USN-8574-2	22.04 24.04	linux-fips, linux-lowlatency, linux-lowlatency-hwe-6.8, linux-oracle	2026-07-23
Ubuntu	USN-8619-1	22.04	linux-hwe-6.8	2026-07-28
Ubuntu	USN-8616-1	18.04 20.04	linux-ibm, linux-ibm-5.4	2026-07-28
Ubuntu	USN-8574-3	22.04 24.04	linux-ibm, linux-ibm-6.8, linux-nvidia-tegra, linux-xilinx	2026-07-28
Ubuntu	USN-8593-1	26.04	linux-ibm, linux-oracle	2026-07-23
Ubuntu	USN-8597-1	20.04	linux-ibm-5.15	2026-07-23
Ubuntu	USN-8617-1	20.04	linux-kvm	2026-07-28
Ubuntu	USN-8596-1	22.04 24.04	linux-nvidia, linux-nvidia-6.8, linux-nvidia-lowlatency	2026-07-23
Ubuntu	USN-8576-2	22.04	linux-nvidia-tegra, linux-nvidia-tegra-igx	2026-07-23
Ubuntu	USN-8594-1	24.04	linux-oem-6.17	2026-07-23
Ubuntu	USN-8570-2	24.04	linux-oracle-6.17	2026-07-28
Ubuntu	USN-8595-1	22.04	linux-oracle-6.8	2026-07-23
Ubuntu	USN-8615-2	18.04 20.04	linux-raspi, linux-raspi-5.4	2026-07-29
Ubuntu	USN-8601-1	22.04 24.04 26.04	pam	2026-07-23
Ubuntu	USN-8591-1	16.04 18.04 20.04 22.04 24.04 26.04	python-aiohttp	2026-07-22
Ubuntu	USN-8612-1	26.04	roc-toolkit	2026-07-27
Ubuntu	USN-8598-1	22.04 24.04 26.04	rsyslog	2026-07-23
Ubuntu	USN-8621-1	22.04 24.04 26.04	samba	2026-07-28
Ubuntu	USN-8477-3	14.04 16.04 18.04 20.04 22.04 24.04 26.04	tar	2026-07-22

Full Story (comments: none)