Welcome to the LWN.net Weekly Edition for June 18, 2026

This edition contains the following feature content:

• The state of Fedora in 2026: good news and bad news about the state of this important distribution.
• Automatic mTHP creation in 7.2: making the use of mTHPs even more transparent.
• Continued coverage from the 2026 Linux Storage, Filesystem, Memory Management, and BPF Summit:
• An overlayfs update: what have the overlayfs developers been up to and what might be coming in the future?
• Some buffer-heads cleanup work: work on cleaning up the venerable buffer-heads code for multiple filesystems.
• Development statistics for the 7.1 kernel: a record-breaking number of developers contributed to the 7.1 kernel.

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)

The state of Fedora in 2026

On June 15 at Fedora's Flock conference, held in Prague, Fedora Project Leader (FPL) Jef Spaleta delivered a short "State of Fedora" keynote that provided a bit of insight into the status of the project. Topics included the overall growth for Fedora usage, ways to increase contributions, and an alarming decline in the number of active packagers working on the project.

I did not attend Flock this year but I did watch the live stream; the unedited video is available now, and edited videos should be published soon. Spaleta's slides are not yet available, but are expected to be posted to the session page at any time.

Good, bad, weird

Spaleta is now in his second year as FPL; he began the talk by alluding to that fact, and commented that it still felt weird to be called the FPL. He said he would show "some good things, bad things, and a weird thing" related to the state of Fedora.

Fedora usage fell into the "good" category. Overall, Fedora usage continues to climb; he showed a slide that tracked the number of systems that were "seen" for each of Fedora's variants (22 in all). The graph indicated that almost all of the variants showed increasing usage over time; Spaleta said that there had been almost one million systems checking in, according to the "Count Me" system, in the past week. That meant a nine percent increase in the last year. This article on the Fedora Magazine blog explains how Fedora's tracking system works, as well as how to disable it if one does not wish to be counted.

Fedora KDE Plasma, which was recently promoted from a Fedora Spin to a full edition, showed "super year-over-year growth", he said. In the past week, it had more than 158,000 systems checking in, for more than 120% growth compared to last year. He speculated that was due to its promotion but he couldn't be sure.

Fedora Workstation, the project's GNOME-based edition, also showed year-over-year growth, but of a more modest sort. In the past week, the project had tracked about 297,000 systems, or 18.8% growth in the past year. Fedora counted about 167,000 image-based systems in the last week, which includes all of its Atomic Desktops as well as Fedora CoreOS. Spaleta's chart showed a 30.5% increase in usage from last year. The bulk of that growth, he said, is attributed to CoreOS; the project identified about 146,000 live CoreOS systems in the past week.

The "weird" lies in the active system reports for the Cloud edition. While most of the graphs Spaleta displayed showed a consistent upward trend, the Cloud graph was closer to spiky abstract art than a coherent usage pattern. All told, if the collected statistics are accurate, there were nearly 65% fewer systems active—about 75,000—in the past week than a year ago. He said that it had indicated a number of systems had shown up "instantly as 25 weeks old", and that he didn't understand the graph at all.

He also covered "Fedora visitors": that is, Fedora-based distributions, such Bazzite from the Universal Blue project and the Asahi Remix, which are tracked in the Count Me statistics as well. There were about 97,000 visitor systems counted in the past week, for a year-over-year growth of more than 210%. Spaleta said that those distributions are part of Fedora's larger ecosystem, "and when they do well, we do well. I would like to find ways to bring them closer to us".

Disappearing packagers

"Here's where we get to the not-so-great part", Spaleta said while displaying a graph (reproduced below) that tracked Fedora packagers by month in 2020, 2023, and 2026 so far. The graph indicates some decline throughout 2020, a steeper decline in 2023, and even steeper decline in 2026. "It's only four months, but it's a pretty straight line, that is concerning.".

At the beginning of 2020 there were more than 420 package committers, and the year closed with slightly fewer packagers. In 2023, Fedora had about 410 packagers at the beginning of the year, but ended with fewer than 340. It began this year with about 350, and is now at about 325 packagers.

He said he was unsure what the reasons were for the decline, or exactly how to solve it. "It could be that we need to double down on outreach, or the new normal for us may be that we need to do more with less." Spaleta said it may be that there is a need to automate more work, and that packaging was less interesting to newer contributors. He thought that it might be a "generational switchover" but he did not want to just throw darts at the problem by guessing. "I want to solve the problem".

He was not sure what the solution could be, but he did have some thoughts. "I'm the FPL, I can't not have thoughts on this." Unfortunately, he said, he would share his thoughts with the audience. Spaleta said that Fedora needed to modernize its contributor experience. The transition from Fedora's homegrown Pagure collaboration platform to Fedora Forge, which is based on the Forgejo GitHub-like "software forge", will be "a big leap forward" for the project in that regard by standardizing on workflows people expect for open-source development.

In addition, Spaleta said that Fedora needed to modernize how its governance works, and improve its outreach to new contributors in a more programmatic way. "We don't necessarily have the resources to do that right now. We need to expand resources." He noted that there is a group looking into a way to take in donations, "to broaden support beyond what Red Hat can do with its budget". The council is hoping to do an experiment with Open Collective, he said, and work on creating a framework to rebuild Fedora's global outreach program. LWN covered early discussion about this in March 2026.

He also complained that Fedora tends to "frontload a lot of discussion and get things perfect" before trying experiments. He said he didn't want to use the word "bikeshedding" but then added "it's bikeshedding": to curb that, Spaleta has proposed an innovation lifecycle process that was inspired by the Cloud Native Computing Foundation (CNCF) Sandbox. The idea behind the proposal is to have a "sandbox" for innovations that are "too big" for Fedora's usual change process.

He said that an innovation process was necessary at this stage, especially now that multiple vendors depend on Fedora; AWS and Microsoft now have Fedora-based Linux distributions (Amazon Linux and Azure Linux, respectively). Spaleta has submitted the proposal to the council, and there is a plan to have a formal discussion and decision on it after Flock.

Hummingbird

He also briefly mentioned Fedora Hummingbird. Spaleta said it was an "innovative approach to build an operating system" that relies on automation; it would have been an obvious fit for the innovation sandbox, but the sandbox did not exist yet.

Hummingbird, which is described as a container-based, rolling Fedora distribution, has been a bit controversial; not the idea itself, necessarily, but the way it was rolled out. The idea had been raised by Scott McCarty on the Fedora development list at the end of April. It was received with interest, and some confusion, about how it would differ from other Fedora variants. McCarty said that the plan was to bring Hummingbird in under the innovation lifecycle proposal, and said in his last message on the subject on May 1 that he was looking forward to more discussions about Hummingbird.

Those discussions did not happen, and Hummingbird was not formally proposed to the project via a public ticket. Instead, a request was submitted to the council privately to approve the usage of the Fedora trademark. The council voted in favor of this in secret in order to expedite the process so it could be announced during Red Hat Summit in May as an official Fedora initiative.

Q&A

The first question from the audience was about the decline in packager contributions; an attendee wanted to know what the split was like between Red Hat employees and non-Red Hat employees. Spaleta said that it was a good question, but he was unable to answer it; the graph had been generated the day before, and he had not had time to dig into more detail.

Another attendee questioned the theory that the decline was due to "generational switchover" since no one at Flock looked as if they were close to retirement. Spaleta responded that getting a "why" out of data is very difficult. "We'd need to reach out to people who've stopped and ask them." He thought that part of the problem in attracting new contributors was that "the goalposts have creeped". What Fedora considers high-quality now is a higher bar than in the early days of the project. "We have to have space for people who are doing skills development." He also said that the sandbox process would be good to allow contributors to do things "that are not good" and provide an opportunity to feel like part of the project while improving their skills. With that, the session ran out of time.

Comments (29 posted)

Automatic mTHP creation in 7.2

The Linux kernel has long tried to use huge pages as a way to improve performance, sometimes with more success than others. The size of huge pages has traditionally been imposed by the hardware, which typically only offers a couple of relatively large options. In more recent times, though, the use of multi-size transparent huge pages (mTHPs), with more flexible sizing implemented in software, has been growing. If all goes well, the 7.2 development cycle will include the addition of a new feature, contributed by Nico Pache, to make the use of mTHPs even more transparent.

A huge-page review

The implementation of traditional huge pages is driven by the system's page-table hierarchy; see this article for details on how that hierarchy works. In short, the smallest huge-page size is obtained by removing the lowest page-table layer (called PTE) for a given entry in the next-higher layer (called PMD) of the hierarchy. On many systems, a PMD-level huge page created in this way is 2MB in size.

The use of PMD-level huge pages can improve the system's performance in a couple of ways. A huge page can be managed as a unit rather than as 512 individual base pages, reducing memory-management overhead. Each huge page can also be covered by a single translation lookaside buffer (TLB) entry. Those entries are a scarce resource, and using them effectively matters for performance. A virtual-address reference that is resolved via the TLB is vastly faster than one that requires walking the page-table hierarchy, perhaps encountering numerous cache misses on the way.

Given the performance advantages of huge pages, there has long been a desire to make good use of them; thus the transparent-huge-page feature was added to provide processes with huge pages without the need for any code changes. But PMD-level huge pages have some problems of their own. They are large enough that they can be hard for the kernel to provide after the system has been running long enough to fragment memory. They are also subject to internal fragmentation; if only a small portion of a huge page is actually used by the process that owns it, the rest is simply wasted. Using huge pages in the wrong places can significantly increase a process's total memory use.

The folio transition has given the kernel a lot more flexibility to manage groups of physically contiguous pages in arbitrary (power-of-two) sizes. When used for a process's memory, larger folios are often referred to as mTHPs. Using mTHPs can, as with PMD-size huge pages, reduce memory-management overhead by reducing the number of folios that must be kept track of. At the same time, mTHPs that are smaller than the PMD size can be easier for the memory-management subsystem to create and allocate; they are also more likely to be fully utilized and less subject to internal fragmentation. More recent processors are capable of using a single TLB entry to cover eight (x86) or 16 (Arm) properly aligned, physically contiguous pages, so managing memory as mTHPs of the correct size can, once again, increase TLB coverage (and, thus, performance).

mTHP collapse support

All this means that large folios (and mTHPs in particular) can improve performance, but only if they are actually used in the right places. The filesystem layers are increasingly good at using large folios for file-backed memory when access patterns suggest that they might help performance. Anonymous memory, though, can be a harder problem. Using mTHPs unconditionally would result in internal fragmentation; they really only make sense when most or all of the base pages within the mTHP are being regularly accessed.

One part of the implementation of transparent huge pages in the kernel is the khugepaged kernel thread; in current kernels, it scans memory in an attempt to join (or "collapse") suitable groups of base pages into PMD-level huge pages. Processes access their anonymous memory in the usual way, faulting in one page at a time (with the kernel perhaps speculatively faulting in nearby pages as well). If a process is fully using a 2MB range of its memory, khugepaged may eventually, transparently, substitute one huge page for all of those base pages, a process that normally involves copying the data in those pages to a new location. The process using that memory is none the wiser, other than hopefully experiencing a performance boost.

khugepaged only operates at the PMD level, though. Pache's patch series changes that by allowing khugepaged to create mTHPs at other sizes as well. The algorithm used to do this work functions approximately like this, as applied to each 2MB chunk of a process's virtual address space:

1. A bitmap is created indicating how many of the base pages within that 2MB region are actually used. In simple terms, a page is deemed to be used if it is present, accessed relatively recently, and contains something other than zeroes. Readers who are interested in the gory details (of which there are many) can look at the implementation of collapse_scan_pmd().

   In current kernels, this scan is aborted for a given 2MB range if too many unused pages (as determined by the max_ptes_none sysctl knob) are found; with too many unused pages, that range is not a candidate for collapsing into a PMD-level huge page. It might still be possible to create mTHPs in that range, though, so Pache's patch set causes the scan to look at all of the pages in the range unconditionally.

2. An attempt is made to collapse the full set of pages into a PMD-level huge page, as is done in current kernels. If that attempt succeeds, the job is done. It could fail, though, if more than max_ptes_none pages are unused, if a PMD-level huge page cannot be allocated, or for a number of other reasons.
3. An attempt is made to collapse pages, starting at the same base, into a smaller mTHP. The size of that mTHP might be half of the previously attempted size, or the kernel could, depending on how it is configured, drop immediately to a smaller size. For example, it might make sense to configure the system to attempt only the PMD size and the size that matches the TLB coalescing done by the processor. The knobs controlling this configuration are documented in Documentation/mm/transhuge.rst.
4. If the smaller attempt succeeds, khugepage will advance its offset beyond the newly created mTHP and restart the process with the largest mTHP size consistent with the alignment of the new address. Otherwise, the target size will be reduced again and control returns to the previous step.
5. If the attempt to collapse pages into the smallest possible mTHP fails, the offset is advanced past the failed range of pages, and control returns to step 3.

Once a 2MB region has been processed in this way, khugepaged moves onto the next 2MB range and restarts from the beginning. If all goes well, the target process's address space will eventually be converted into the largest mTHPs that are consistent with its memory usage and the supply of larger folios.

Avoiding mTHP creep

Creating the largest mTHPs possible is a good goal in general, but there is a problematic failure mode that must be avoided. Imagine a system configured with max_ptes_none set to two, meaning that an mTHP will only be created if there are two or fewer unused pages within the range under consideration. On this system, khugepaged encounters a range of 16 pages that looks like this:

In this diagram, the pages filled in with green are seen to be in use, while those that are gray are unused. When khugepaged attempts to create a 16-page mTHP from this range, it will observe four unused pages, so the attempt will fail. Subsequently, though, after khugepaged drops back and looks at the beginning of this range as an eight-page mTHP candidate, it will only see two unused pages, so the attempt will succeed, leading to a situation that looks like this:

The lower eight pages have now been collapsed into an mTHP; the same thing will happen to the upper eight pages after khugepaged advances its offset.

Once an mTHP has been created, all of the base pages within it appear to be used if the mTHP itself is used. When, at some future time, khugepaged examines this 16-page range again, it will see that all of the pages within it appear to be used; this time, the creation of a 16-page mTHP will proceed. This behavior is referred to as "creep" — the size of the created mTHPs creeps upward with every scan pass until it reaches the PMD size, even if many more than the desired number of base pages within that range are not used by the owning process.

A fair amount of effort has gone into avoiding creep in the mTHP patch set. Perhaps most visibly, the allowed values of max_ptes_none are restricted when creating anything other than PMD-size huge pages. The knob can be set to zero (meaning that an mTHP will only be created if all of the pages in the range look used) or 511, just below the 512 base pages that make up a PMD-size huge page (in which case collapse will always be attempted). Any other value of max_ptes_none will result in a warning, with the resulting behavior being as if it were set to zero. Other values of max_ptes_none are still implemented as usual for PMD-size huge pages, though.

This patch series has been through an impressive 19 revisions since the RFC version was posted in January 2025. At this point, though, the memory-management developers appear to be happy with it; Lorenzo Stoakes commented: "We're good to take this this cycle". The patches are currently in linux-next and, with luck, will find their way into the mainline in the upcoming merge window. Attention can now, maybe, turn to a rather long list of other huge-page-related patches that have been waiting while this work went through the review process; stay tuned.

Comments (none posted)

An overlayfs update

In a shortened session in the filesystem track at the 2026 Linux Storage, Filesystem, Memory Management, and BPF Summit, Amir Goldstein gave an update on the overlayfs union filesystem. There are some new features over the last few years that he wanted to mention, along with looking at the status of nesting overlayfs layers. The composefs use case that was discussed at the summit in 2023 has led to some interesting changes to overlayfs.

Overlayfs provides a way to create a single mounted filesystem that is created from multiple other filesystems fused together. It presents a union of the files in the various filesystems, though the underlying filesystems are ordered so that entries from filesystems above take precedence over the same file and directory names in the lower layers. Often, the top layer is writable so that users can change the files as they appear in the mounted overlayfs without actually changing anything in the (typically read-only) lower layers.

Goldstein began by noting that Miklos Szeredi, who developed overlayfs and co-maintains it with him, once talked about a time "when overlayfs is done", which reminded him of the concept of "the end of history". "So, what happened since the end of history?", Goldstein asked with a grin. For one thing, Szeredi added the ability to mount overlayfs filesystems in user namespaces "after he thought he was done with it".

Supporting composefs, where the file contents are stored as content-addressable objects using fs-verity for integrity protection, has led to some new concepts for overlayfs. There can now be data-only lower layers, lacking metadata, which are somewhat similar to the metacopy feature that was already present, but allows verifying the connection between the metadata of the inode and its contents using fs-verity.

He noted that Christian Brauner had switched overlayfs to use the "new" mount API, which lifted some restrictions on things like the number of lower layers and the path-name length for them. Brauner described another change that would allow separating the credentials needed to mount a layer as part of an overlayfs from those needed to access the layer after the mount. For example, the mounter may require a different SELinux context than the one that will be used by the tasks accessing the mount, he said. The feature has more widespread applicability, but for overlayfs, it allows the administrator to specify the credentials that will be used for accessing the layer via the mounted filesystem.

Goldstein said that, previously, overlayfs had a single set of credentials, which corresponded to the task mounting the filesystem. It used those credentials to access the lower layers, rather than those of the user who was doing the filesystem operations on the mounted overlayfs. Now the credentials used to mount the filesystem can be separated from those used when the filesystem is accessed. "It's a good sign for our security model that we need two different people to provide two different explanations", Brauner said with a laugh. "None of which would be understood", Goldstein added to general laughter.

Nested overlayfs

Overlayfs can be nested, which means that one of the layers making up an overlayfs filesystem is, itself, an overlayfs filesystem, Goldstein said. It has been possible to do that for more than ten years. The classic example is to create an overlayfs with two, say, XFS layers and use that as the lower layer; the upper layer is some other filesystem and all are fused into an overlayfs with the first overlayfs as its lower layer. "I'm not sure exactly" when that is useful, he said, but sometimes in containers, or for OpenWrt, the root filesystem is an overlayfs and users want to be able to make non-destructive changes to it.

There are other nested-overlayfs types, including one for composefs as he had mentioned earlier. Composefs knows the overlayfs on-disk format and how to create the extended attributes needed for that structure, so it can create its own lower layers to contain its data. Features were added to overlayfs in the 6.7 kernel to allow composefs to create the needed extended attributes, which are normally treated as private, overlayfs-only attributes. But, all of the nested types would only allow overlayfs as a lower layer, not for the upper.

Another use case that had come up recently was running a Docker application inside another container that had an overlayfs root filesystem. Docker will try to create an overlayfs using the existing root filesystem as the upper layer, but an overlayfs cannot be the upper layer. Instead, it unpacks its image using the "naive storage driver", which copies all of the files out of their layers and into a flat filesystem, which takes time and lots of I/O. It would be nicer if overlayfs could be extended so that it could use another overlayfs as its upper layer too. "That would be the end of nested overlayfs history", he said with a grin.

Brauner asked about whether overlayfs would allow multiple lower layers that were themselves overlayfs, but Goldstein was not sure there was a use case for it. The number of nested layers that can be used in an overlayfs is capped in the kernel based on stack-depth concerns; it could increased, but only if it could be shown that it would not overflow the kernel stack.

Instead of nesting the overlayfs layers, it might make sense to collapse them, Brauner said. Overlayfs could collect the credentials needed for accessing the different layers, but effectively treat them as a single layer so that there are no nesting limits due to stack concerns. Szeredi wondered how that would work; there was some discussion between he and Goldstein before Brauner described what he was envisioning.

Traditionally, users have updated their systems using package managers, but much of the industry is moving toward image-based updates, Brauner said. Systemd supports this by having a read-only /usr that gets updated with multiple system extensions (i.e. sysext) layers added on top, all of which get fused into a single overlayfs. Over time, there are more and more sysext layers, so systemd has to reassemble the overlayfs periodically and then swap in the new one in place of the old. It would be nicer if it could just operate on the overlayfs directly to see what the layers are and to swap in new ones as needed.

Lennart Poettering said that the systemd developers would really like a tool of some kind to be able to see the different layers that make up the /usr mount. That would allow them to cryptographically trace a file back to its origin in the fs-verity-protected data. Goldstein said that providing some kind of introspection API was doable; it is mostly a matter of iteratively working out the details of the API.

Ted Ts'o wondered if the use case being described was similar to doing distribution updates in an overlayfs-based layered installation (e.g. with base and package layers); the user may change a configuration file that now needs to be updated, which leads to some kind of conflict-resolution process. Brauner said that it was a completely different use case. In this one, the /usr filesystem is read-only and, ideally, /etc will be also. If the user is ever shown a diff and has to make a choice, "you've already lost the plot in my opinion".

For the /etc case, the lower layers would be read-only, with a writable layer at the top so that users can make changes to the configuration, an attendee said. Sometimes the user wants to remove their changes and revert to the version in the lower layers, but deleting their file leads to a whiteout; he would like to have a way to reveal the underlying file instead of blocking it with the whiteout. Brauner asked if he wanted that on an individual-file basis or for the whole filesystem; the former requires some system-call-level change, which is probably harder.

Goldstein asked what was known about the file to reveal; is it just the file name or is there a file handle? That latter might be more useful because there are already guards in overlayfs to prevent using a file handle to evade the whiteout; those could perhaps be overridden under some circumstances. David Howells was concerned about nested overlayfs and identifying which file should be resurrected, but Goldstein said that the overlayfs file handle does describe both layers, so it could be used. But, "I'm not committing to this", he said. The session ran out of time shortly thereafter.

Comments (6 posted)

Some buffer-heads cleanup work

Jan Kara has been working on cleaning up how buffer heads are used by some kernel filesystems. In a short filesystem-track session at the 2026 Linux Storage, Filesystem, Memory Management, and BPF Summit, he gave an update on that work and where it is headed. Topics included generic infrastructure to track buffer heads for metadata, a buffer-head cleanup for the Amiga filesystem, and some planned locking fixes.

Buffer heads are "ancient stuff", he began, having been part of the kernel "basically since day zero of Linux". They are used to track filesystem information at the granularity of blocks, rather than folios. Kernel filesystem developers are trying to remove buffer heads from the data path in filesystems, but they are still used in the metadata path for many filesystems. Overall, buffer heads are not going away anytime soon because those filesystems need fine-grained tracking for the state of individual blocks.

One of the things he has been working on is generic infrastructure for tracking all of the metadata blocks that belong to a given inode so that they can be flushed on an fsync() call. That infrastructure is used by ext4, ext2, UDF, VFAT, and a few others, he said. He factored the metadata-buffer-head tracking out of the generic inode structure and into the filesystem-private part of the inode that can be used by filesystems that care. Filesystems that do not need that tracking can have an inode that is 40 bytes smaller, he said. That work has been merged by Christian Brauner for the 7.1 kernel.

Kara also made a small cleanup for the Amiga Fast File System (AFFS) Linux implementation. The filesystem took the trouble to track the metadata buffer heads, but never used that information at fsync() time. Since the maintainer told him that AFFS performance is not really a concern, he removed the tracking instead of switching AFFS to use the new infrastructure.

There is a race in the tracking of the metadata buffer heads that can result in the inode and all of the metadata not being written to the backing store. So if an fsync() is followed by a crash, the metadata that should have been flushed to disk may be missing. That has been worked around for ext4, but all of the other filesystems using the new infrastructure are vulnerable to it. He is working on a generic fix, which will require expanding the structure used to track the metadata buffer heads.

He is also planning to rework the locking for buffer heads. There are two locks that protect buffer heads when they are attached to folios, he said; one is the folio lock (folio_lock()) for the folio it is attached to and the other is the private lock for the mapping (i_private_lock in struct address_space). The latter is used in places where the folio lock, which can sleep, cannot be taken, but he would like to stop using the private lock because it substantially complicates the locking; he would like to use read-copy-update (RCU) instead. He hopes to get that work done over the next year or less.

Christoph Hellwig asked about an "only vaguely related" problem where ext4 in data=journal mode can create dirty buffer heads that are detached from the mapping and "need magic handling". He wondered if Kara had any ideas on how to untangle that. Kara said that the problem can occur in other modes, but is more common with data=journal. It happens when the VFS would like to reclaim a block or folio, but the filesystem will not allow that to be done because it is still journaling the data, which puts the data into "a strange limbo state".

He has some ideas on what needs to be done. There are two paths where journaled buffer heads undergo writeback; one is the standard path that ends up at the block layer and works fine, but the other is in the journal path that simply writes the blocks tracked by the buffer heads without changing the state of the folios that contain them, which creates the problem. The fix is for the journal path to use the standard writeback machinery to write folios "instead of stealing the buffer heads from underneath", which "is a bit non-trivial of a rewrite of the journaling machinery", he said to some knowing laughter. He can provide pointers and some code to anyone who wants to tackle the problem.

Hellwig said that he has been working with Namjae Jeon on converting the exfat filesystem to use iomap for its data path. Since exfat is a "typical simple filesystem", that work could provide a good template to convert other filesystems to use iomap in a similar way, "because it's a recent conversion of a generic doesn't-do-anything-crazy filesystem". That work originally targeted the 7.1 merge window but ran into some problems; it should appear in 7.2. With no more topics to discuss, the session concluded.

Comments (3 posted)

Development statistics for the 7.1 kernel

Linus Torvalds released the 7.1 kernel as expected on June 14. This development cycle brought in a lot of new features — and a lot of new developers as well. The time has come for our traditional look at where the changes in 7.1 came from, with a digression into how our community may be changing in general.

This release saw the merging of 15,849 non-merge changesets from 2,479 developers. That makes 7.1 one of the busiest development cycles in the kernel's history; only four other releases brought in more commits. The 6.7 release remains the busiest ever, with 17,284 commits; the size of that release was driven by the ill-fated addition of the bcachefs filesystem and all of its development history. The 5.8, 5.10, and 5.13 also brought in more commits than 7.1, though by much smaller margins.

The number of developers working on 7.1 does set a new record, beating the short-lived record of 2,362 set by 7.0. The trend here merits some attention, but we'll start with the usual numbers. The most prolific developers working on 7.1 were:

Most active 7.1 developers

By changesets Johan Hovold 181 1.1% Thomas Weißschuh 175 1.1% Eric Biggers 168 1.1% Stefan Metzmacher 155 1.0% Krzysztof Kozlowski 148 0.9% Rafael J. Wysocki 147 0.9% Russell King 130 0.8% Tejun Heo 125 0.8% Christoph Hellwig 122 0.8% Eric Dumazet 120 0.8% Jakub Kicinski 119 0.8% Sean Christopherson 113 0.7% Thorsten Blum 101 0.6% Thomas Zimmermann 86 0.5% Dmitry Torokhov 85 0.5% Andy Shevchenko 84 0.5% Mauro Carvalho Chehab 84 0.5% Chuck Lever 79 0.5% Bartosz Golaszewski 77 0.5% Lorenzo Stoakes 77 0.5%

By changed lines Jakub Kicinski 126367 12.7% Roman Li 105777 10.7% Namjae Jeon 54445 5.5% Andrew Lunn 16180 1.6% Eric Biggers 14471 1.5% Stefan Metzmacher 14403 1.5% Taniya Das 11956 1.2% Alexei Starovoitov 11410 1.2% Andy Shevchenko 7673 0.8% Mauro Carvalho Chehab 7637 0.8% Christian Brauner 7483 0.8% Pankaj Patil 7181 0.7% Christoph Hellwig 6368 0.6% Krzysztof Kozlowski 5993 0.6% Besar Wicaksono 5873 0.6% Dmitry Baryshkov 5787 0.6% Tejun Heo 5698 0.6% Derek J. Clark 5288 0.5% Vincent Donnefort 5033 0.5% Ratheesh Kannoth 4992 0.5%

Johan Hovold [KSDB] was the biggest contributor of changesets in this development cycle, with a lot of cleanup work in the SPI subsystem and beyond. Thomas Weißschuh's [KSDB] work covered many parts of the kernel, including the build system, nolibc, SPARC architecture code, and more. Eric Biggers [KSDB] has been busily refactoring the kernel's cryptographic code. Stefan Metzmacher [KSDB] contributed improvements to the SMB filesystem implementation, and Krzysztof Kozlowski [KSDB] continues to work throughout the system-on-chip and devicetree subsystems.

In the lines-changed column, Jakub Kicinski [KSDB] removed a large chunk of old and unmaintained networking code, including the ISDN, Bluetooth CMTP, and ATM subsystems. Roman Li [KSDB] added yet another big set of amdgpu header files. Namjae Jeon [KSDB] has brought back the older NTFS filesystem implementation and added a lot of new features to it. Andrew Lunn [KSDB] removed a set of unmaintained networking drivers.

Nearly 8% of the commits in 7.1 carried Tested-by tags, while almost 51% had Reviewed-by tags. Both of those numbers are relatively low compared to recent releases. The top testers and reviewers this time were:

Test and review credits in 7.1
Tested-by Daniel Wheeler 89 5.8% Fuad Tabba 61 3.9% Gavin Shan 40 2.6% Shaopeng Tan 40 2.6% Mohd Ayaan Anwar 40 2.6% Jesse Chick 40 2.6% Mostafa Saleh 36 2.3% Punit Agrawal 34 2.2% Jon Hunter 33 2.1% Zeng Heng 31 2.0% Lad Prabhakar 29 1.9% Peter Newman 28 1.8% Eric Biggers 27 1.7% Venkat Rao Bagalkote 22 1.4% Randy Dunlap 21 1.4%	Reviewed-by Konrad Dybcio 334 3.1% Dmitry Baryshkov 300 2.8% Andy Shevchenko 197 1.9% Krzysztof Kozlowski 181 1.7% Christian König 170 1.6% Ilpo Järvinen 161 1.5% Simon Horman 140 1.3% Frank Li 134 1.3% Geert Uytterhoeven 122 1.1% Christoph Hellwig 119 1.1% Jonathan Cameron 118 1.1% Gary Guo 114 1.1% Andrea Righi 103 1.0% Rob Herring 100 0.9% Lorenzo Stoakes 94 0.9%

Daniel Wheeler [KSDB] maintains his perpetual position as the kernel's top credited tester. On the review side, Konrad Dybcio [KSDB] added his tag to 334 changes while Dmitry Baryshkov [KSDB] tagged 300; both performed reviews almost exclusively for Qualcomm drivers and devicetree files, mostly written by their Qualcomm colleagues.

Development for the 7.1 release was supported by 230 employers that we were able to identify; the most active of those were:

Most active 7.1 employers

By changesets (Unknown) 2160 13.6% Intel 1435 9.1% Google 1227 7.7% AMD 828 5.2% Qualcomm 787 5.0% Red Hat 745 4.7% (None) 694 4.4% NVIDIA 595 3.8% Meta 535 3.4% (Consultant) 500 3.2% SUSE 459 2.9% Oracle 390 2.5% Arm 334 2.1% Renesas Electronics 289 1.8% NXP Semiconductors 254 1.6% IBM 215 1.4% Huawei Technologies 210 1.3% Kylin 181 1.1% Linutronix 171 1.1% SerNet 155 1.0%

By lines changed Meta 156583 15.8% AMD 136736 13.8% (Unknown) 76738 7.7% Qualcomm 75847 7.6% Samsung 55391 5.6% Google 54537 5.5% Intel 48917 4.9% NVIDIA 37374 3.8% Red Hat 35706 3.6% (None) 35178 3.5% Oracle 15837 1.6% SerNet 14403 1.5% Arm 13030 1.3% SUSE 12208 1.2% NXP Semiconductors 11777 1.2% Huawei Technologies 11580 1.2% Realtek 10314 1.0% (Consultant) 9984 1.0% Marvell 8282 0.8% Amutable 7483 0.8%

As usual, there is little change here from previous development cycles.

The developers keep coming

There is one thing that is clearly changing, though. The 7.0 development-statistics article noted that the number of first-time kernel contributors has been growing. The 7.1 cycle continued that trend with 530 new contributors [KSDB], far more than the previous record of 489 set by 7.0. The numbers now look like this:

This trend, which shows no signs of stopping, is almost certainly driven by the increasing availability of LLM-based development tools; it has made itself felt in a number of ways. There are 299 commits in 7.1 that include an Assisted-by tag indicating the use of such a tool. The number of actual commits created with LLM involvement must be significantly higher, though; a number of developers are clearly not complying with the kernel's rules for disclosing that use.

These new developers are showing up in surprising places. The serial-line IP (SLIP) protocol implementation, for example, has seen almost no attention outside of maintenance changes for years, but it is now seeing fixes like this one from Weiming Shi [KSDB], a developer who first showed up in 6.19. The long-unloved floppy driver received this fix (since reverted) from 6.17 first-timer Guangshuo Li [KSDB]. The OMFS filesystem received its first non-mechanical change in many years from first-timer HyungJung Joo [KSDB].

The most prolific 7.1 first-timer, Michael Bommarito [KSDB] with 60 commits, contributed fixes to the SMB filesystem, the SCTP network protocol, the Bluetooth subsystem, io_uring, the SCSI subsystem, the amdgpu driver, the RDMA RoCEv2 implementation, and beyond. Almost all of those patches carried Assisted-by tags. There are few kernel developers who could make substantial changes across that much of the kernel; the ability of a previously unseen developer to do that is something new. Whether any developer, new or old, can fully understand substantive patches to that range of kernel subsystems is a different question.

Then, there is the seemingly infinite stream of typo fixes that has turned into an outright flood in recent times. As the documentation maintainer, I welcome these changes as a way for a new developer to become familiar with the development process, but I also try to encourage developers to move on to more substantial changes — advice that is taken less often than I would like.

Of course, access to an LLM is not the only reason a developer might enter our community. A minimum of 132 of the first-time developers seen in this development cycle can already be associated with an employer. Qualcomm leads the pack with 15 first-time developers; AMD employed 14, and Google 12. In total, 51 companies employed first-time 7.1 developers.

One of the many motivations behind bringing Rust into the kernel was the hope of attracting younger developers into the community. A total of five of the new developers (just under 1%) touched Rust files (those whose names end in ".rs"). Three of those developers contributed single, small patches, one added a number of tracepoints to the binder driver, and one (Eliot Courtney [KSDB]) contributed 23 commits, 19 of which were to the in-progress "nova" driver for NVIDIA GPUs. So Rust may be bringing in developers, but not yet in huge numbers yet.

Overall, the areas most frequently touched by new developers were:

Subsystem	# developers
Documentation	78
net	66
other drivers	52
drivers/net	49
drivers/staging	47
sound	46
include	36
drivers/gpu/drm	35
other fs	33
tools	32
arch/arm64	26
kernel	25
fs/smb	19
drivers/usb	17
drivers/iio	15
drivers/hwmon	13
drivers/bluetooth	10
MAINTAINERS	10
drivers/platform	10
drivers/i2c	9
mm	8

There are some interesting patterns here. The crowd of new developers working on the documentation is nice on its face .... but see "typo fixes", above. The number of first-timers changing the MAINTAINERS file could be of concern; there has been an episode or two recently where an unknown developer tried to claim maintainership of a subsystem, a prospect that is worrisome for obvious reasons. In this case, roughly half of the MAINTAINERS changes accompanied new drivers submitted by the new developer in question. There are a couple of previously unseen developers who showed up and claimed the maintainership of an existing subsystem, but they used email addresses from the company involved and, at a first glance, look legitimate. Meanwhile, the staging tree was meant to be a way for new developers to enter the community; it appears to still be serving that purpose.

One number that stands out is the number of new developers contributing to the SMB filesystem. These developers are not fixing typos; instead, they are addressing what appear to be serious, perhaps security-relevant bugs. Whether these developers are running their own tools to find bugs, or whether instead there is some sort of organized effort to direct new developers at those bugs is unclear. What does seem clear is that anybody who is using SMB in a setting where security matters may want to apply extra diligence to following kernel updates for a while.

As the numbers in the first part of this article show, the kernel's development process appears to be rolling along at its usual fast pace — or even a bit faster. But things are changing. New development tools have facilitated the entry of a large crowd of new developers into the community. If enough of them stay around, it should not take long to change the makeup of the kernel community — and how that community works — substantially. We live in interesting times.

Comments (20 posted)

Everything security at PyCon US 2026

The Python Software Foundation blog has a post with a summary of the security-related content at PyCon US 2026 with links to slides from important sessions. The recordings will be published to the PyCon US channel on YouTube, and the post will be updated with links to those videos as they are made available.

Comments (none posted)

Stenberg: curl summer of bliss

Daniel Stenberg has announced that curl will not be accepting vulnerability reports from July 1 through August 3, unless the submitter has a paid support contract. He is calling it the "curl summer of bliss".

As previously mentioned, we have been under a huge pressure for the last four months or so. Now we need some rest. We do not expect this deluge to be over.

[...] If you and your Open Source projects also want to participate in the summer of bliss 2026: just do it and let us know! I would of course encourage you to do so. To take care of yourself as a top priority.

The project's issue and pull-request trackers on GitHub will remain open. The planned release date for curl 8.22.0 has been pushed back two weeks to September 2, 2026.

Comments (11 posted)

Kernel release status

The 7.1 kernel is out, released on June 14. Quoth Linus: "So it's only Sunday morning back home, but it's Sunday afternoon where I am right now, so I'm doing the 7.1 release at the regular time - just not in the regular timezone."

Significant changes in 7.1 include the removal of support for some old 486-based architectures, some new clone() flags making process management easier, BPF support for io_uring, zero-copy-I/O support for the ublk user-space block driver, initial (incomplete) sub-scheduler support in sched_ext, more swapping improvements, a completely rewritten NTFS implementation, and much more. See the LWN merge-window summaries (part 1, part 2) for details.

This release cycle brought in 15,849 non-merge changesets from 2,478 developers, 530 of whom were first-time kernel contributors. The release history looks like:

RC	Date	Commits
v7.1-rc1	2026-04-26	13963	13963
v7.1-rc2	2026-05-03	475	475
v7.1-rc3	2026-05-10	584	584
v7.1-rc4	2026-05-17	428	428
v7.1-rc5	2026-05-24	748	748
v7.1-rc6	2026-05-31	473	473
v7.1-rc7	2026-06-07	332	332
(final)	2026-06-14	272	272

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

Stable updates: none have been released in the last week.

The 7.1.1, 7.0.13, 6.18.36, 6.12.94, 6.6.143, 6.1.176, 5.15.210, and 5.10.259 updates are all in the review process; they are due on June 18.

Comments (none posted)

Quotes of the week

So far, one of the huge advantages of open source operating systems has always been that even niche use cases were supported and people could make use of old hardware by using open source operating systems over commercial offerings such as Windows or macOS.

With the advent of AI security reports, these niche use cases are more and more being killed off with the argument that a vulnerability in the hamradio code could pose a threat to a large SAP database running on a Linux enterprise distribution. However, if your enterprise distribution is enabling kernel features their customers aren't using and therefore enlarging the attack surface, it's more a problem of said enterprise distribution and not of these old and obscure network protocols.

— John Paul Adrian Glaubitz

It feels like the new world of AI tooling has slowed us down a little on the feature side when compared to the fixes side. The extra rounds of Sashiko review have also pushed a few things out until next time.

— Will Deacon in the arm64 pull request.

Comments (3 posted)

Hundreds of AUR packages compromised

Hundreds of orphaned packages hosted by the Arch User Repository (AUR) have been compromised by an attacker who has added a malicious npm package (atomic-lockfile) that can exfiltrate sensitive data. The project is currently working on cleaning up the mess. There is a list of affected packages and post (possibly NSFW domain) by "sodiboo" with additional information. Arch Linux users (or users of Arch-based distributions) that use AUR packages may wish to see if they have installed any of the compromised updates.

Comments (31 posted)

Fedora F44 election results

The results are in for Fedora's F44 election cycle for seats on the Fedora Council, Fedora Engineering Steering Committee, Fedora Mindshare Committee, and EPEL Steering Committee.

Miro Hrončok and Aleksandra Fedorova have won seats on the council. Neal Gompa, Fabio Valentini, Michel Lind, Maxwell G, and Simon de Vlieger have been elected to FESCo. Samyak Jain, Akashdeep Dhar, Luis Bazan, and Mat Holmes have all been elected to the Mindshare Committee. The four candidates for the EPEL committee, Carl George, Diego Hererra, Jonathan Wright, and Troy Dawson were all automatically elected as there were an equal number of candidates and seats open. Congratulations to all the winners.

Comments (none posted)

Distributions quote of the week

Bluntly stated, making people use an open source thing that sucks is a great way to make it better. Fedora has believed this for a long time, we just usually say it in nicer words, but that's what we *mean*. That's why we shipped GNOME 3.0 and systemd in the same release!

— Adam Williamson

The [Debian Free Software Guidelines] and the Social Contract are not comprehensive lists of everything that we can possibly have an ethical position on, and it's neither necessary nor a good idea to try to tie every dispute in Debian back to one of those documents. It turns the conversation into rules lawyering without addressing the actual issue.

— Russ Allbery

Comments (none posted)

FairScan 2.0 released

Version 2.0 of the FairScan document-scanning app for Android has been released. The headline feature for this release is the addition of optical-character-recognition (OCR) support using Tesseract to produce PDFs with searchable text from scans. FairScan developer Pierre-Yves Nicolas has written a detailed blog about adding the feature and explaining why it had not been added previously.

That looks nice, so why didn't FairScan have it before? That's because FairScan wasn't ready for it: I wouldn't be comfortable if FairScan was giving you wrong text half of the time. To get good results from an OCR engine, you need to provide it a readable image. If it's hard to read for a human, it's certainly also hard to read for an OCR engine.

Over the past year, I worked on different parts of FairScan's automatic processing to transform photos of documents into PDFs that are easy for humans to read:

• document detection
• perspective correction
• shadow reduction
• brightness and contrast enhancement

All this work on image processing helped FairScan produce clean PDFs and can now also contribute to making text recognition effective.

FairScan is available via Google Play or F-Droid.

Comments (3 posted)

Firefox 152.0 released

Version 152.0 of the Firefox web browser has been released. Notable changes in this release include a brand-new look for the Firefox Settings interface, the ability to disable tracker blocking in private browsing tabs, a feature to mute browser sound from the address bar, experimental support for the JPEG XL image format, and more.

Comments (none posted)

Homebrew 6.0.0 released

Version 6.0.0 of the Homebrew package-management system has been released. Notable changes in this release include the introduction of tap trust to improve supply-chain security, improvements in sandboxing on Linux, a number of performance tweaks, and many other changes.

See the changelog for a full list. LWN covered Homebrew in November 2025.

Comments (1 posted)

KDE Plasma 6.7 released

Version 6.7 of KDE's Plasma desktop has been released. Notable changes in this release include per-screen virtual desktops, faster desktop switching, introduction of the Union theming system as a tech preview, as well as many other improvements and bug fixes. The release is dedicated to Eric Laffoon, a longtime KDE supporter, who passed away in May.

See the KDE wiki for a full list of new features, and the Changelog for a list of all commits in this release.

Comments (none posted)

Development quote of the week

Pretty much no other company in the Tech Industry is like Mozilla. So it's really hard to hire people with experience running traditional Tech Industry companies that have any clue about how to deal with being that level of open. They all come from worlds where The Black Turtlenecked God told you "Do Not Tell Anyone about Anything". The idea that they literally give things away and are actually transparent as hell is like telling them Mozilla employees are martians. They smile, say polite things, then ignore our history and actions and do things that they know because the concept of anything alien is clearly evil.

This sort of thing manifests in weird ways. One of the more hilarious ones is the "Chase for the DAU" (Daily Active User). Mozilla's DAU count has been dropping for years. There's all sorts of reasons for that. I bet you can come up with a few yourself. Of course, New Leadership comes in with guns a'blazing and Big Ideas for how to make DAU go Up. Those proposals seldom work because those Big Ideas inevitably are "We should copy what the Big Browsers do!". Remember when I said that our users are deeply abnormal? Yeah, they already have that feature in the browser that's already on their machine. If they wanted it that bad, they already have it.

— JR Conlin

Comments (1 posted)

The LWN public topics list

Part of running LWN is keeping a list of potentially interesting topics that may merit the effort to turn into articles. As an experiment, we are now exposing that list to our subscribers at the Project Leader and Supporter levels. The hope is that this list will provide useful insights into what is on our radar and which might be coming to LWN in the near future.

With this feature, we hope to give our most committed subscribers a look behind the curtain and the ability to provide input on the topics they are most interested in reading about. There, is, thus, a simple voting mechanism built into this list. No topic will be chosen (or rejected) solely on the basis of votes; there are a lot of considerations that go into topic selection, and that will not change. But more information about where our readers' interests lie will, hopefully, be helpful.

For all readers: we are always happy to welcome topic suggestions sent to lwn@lwn.net.

Comments (14 posted)

CFP Deadlines: June 18, 2026 to August 17, 2026

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

Deadline	Event Dates	Event	Location
June 24	October 7 October 9	Embedded Linux Conference Europe	Prague, Czech Republic
June 24	October 7 October 9	Open Source Summit Europe	Prague, Czech Republic
June 28	October 8	Linux Security Summit Europe	Prague, Czechia
June 30	November 17 November 19	Open Source Monitoring Conference	Nuremberg, Germany
July 1	October 3 October 4	openSUSE.Asia Summit 2026	Yogyakarta, Indonesia
July 3	September 28 September 30	X.Org Developers Conference	Toronto, Canada
July 15	July 15 July 22	BornHack 2026	Funen, Denmark
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
August 1	August 25 August 30	MiniDebConf and MiniDebCamp Winterthur 2026	Winterthur, Switzerland

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

Events: June 18, 2026 to August 17, 2026

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

Date(s)	Event	Location
June 18 June 20	Linux Audio Conference	Maynooth, Ireland
July 13 July 16	Netdev	Rome, Italy
July 13 July 19	EuroPython	Kraków, Poland
July 13 July 19	DebCamp 26	Santa Fe, Argentina
July 15 July 22	BornHack 2026	Funen, Denmark
July 16 July 19	Electromagnetic Field	Eastnor, UK
July 18	AlmaLinux Day: Los Angeles	Los Angeles, CA, US
July 20 July 25	DebConf 26	Santa Fe, Argentina
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

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

Alert summary June 11, 2026 to June 17, 2026

Dist.	ID	Release	Package	Date
AlmaLinux	ALSA-2026:25115	10	.NET 10.0	2026-06-11
AlmaLinux	ALSA-2026:25114	8	.NET 10.0	2026-06-11
AlmaLinux	ALSA-2026:25222	9	.NET 10.0	2026-06-12
AlmaLinux	ALSA-2026:25111	10	.NET 8.0	2026-06-11
AlmaLinux	ALSA-2026:25110	8	.NET 8.0	2026-06-11
AlmaLinux	ALSA-2026:25220	9	.NET 8.0	2026-06-12
AlmaLinux	ALSA-2026:25112	10	.NET 9.0	2026-06-11
AlmaLinux	ALSA-2026:25113	8	.NET 9.0	2026-06-11
AlmaLinux	ALSA-2026:25221	9	.NET 9.0	2026-06-12
AlmaLinux	ALSA-2026:24367	9	bind	2026-06-11
AlmaLinux	ALSA-2026:23230	9	expat	2026-06-11
AlmaLinux	ALSA-2026:26335	8	hplip	2026-06-17
AlmaLinux	ALSA-2026:25090	8	httpd:2.4	2026-06-11
AlmaLinux	ALSA-2026:25191	10	kernel	2026-06-11
AlmaLinux	ALSA-2026:25121	8	kernel	2026-06-11
AlmaLinux	ALSA-2026:26427	8	kernel	2026-06-17
AlmaLinux	ALSA-2026:25217	9	kernel	2026-06-11
AlmaLinux	ALSA-2026:24381	9	kernel	2026-06-12
AlmaLinux	ALSA-2026:25120	8	kernel-rt	2026-06-11
AlmaLinux	ALSA-2026:26428	8	kernel-rt	2026-06-17
AlmaLinux	ALSA-2026:26348	8	libpng12	2026-06-17
AlmaLinux	ALSA-2026:26347	8	libpng15	2026-06-17
AlmaLinux	ALSA-2026:26354	8	libxml2	2026-06-17
AlmaLinux	ALSA-2026:26355	8	libxslt	2026-06-17
AlmaLinux	ALSA-2026:25225	10	mod_http2	2026-06-15
AlmaLinux	ALSA-2026:25057	9	mod_http2	2026-06-11
AlmaLinux	ALSA-2026:25919	8	mysql:8.0	2026-06-16
AlmaLinux	ALSA-2026:26180	8	mysql:8.4	2026-06-16
AlmaLinux	ALSA-2026:26352	8	opencryptoki	2026-06-17
AlmaLinux	ALSA-2026:25237	10	openssl	2026-06-11
AlmaLinux	ALSA-2026:26275	8	openssl	2026-06-17
AlmaLinux	ALSA-2026:25239	9	openssl	2026-06-12
AlmaLinux	ALSA-2026:24470	10	podman	2026-06-11
AlmaLinux	ALSA-2026:24985	10	poppler	2026-06-11
AlmaLinux	ALSA-2026:25058	9	poppler	2026-06-11
AlmaLinux	ALSA-2026:25930	10	postfix	2026-06-15
AlmaLinux	ALSA-2026:25932	8	postfix	2026-06-16
AlmaLinux	ALSA-2026:25030	8	postgresql-jdbc	2026-06-10
AlmaLinux	ALSA-2026:26181	8	postgresql:15	2026-06-17
AlmaLinux	ALSA-2026:23229	9	redis	2026-06-11
AlmaLinux	ALSA-2026:25219	9	redis:7	2026-06-12
AlmaLinux	ALSA-2026:26332	10	rsync	2026-06-17
AlmaLinux	ALSA-2026:26408	8	rsync	2026-06-17
AlmaLinux	ALSA-2026:25049	9	samba	2026-06-11
AlmaLinux	ALSA-2026:24369	9	unbound	2026-06-11
AlmaLinux	ALSA-2026:25918	8	webkit2gtk3	2026-06-16
AlmaLinux	ALSA-2026:25927	9	webkit2gtk3	2026-06-16
Debian	DLA-4629-1	LTS	apache2	2026-06-12
Debian	DLA-4631-1	LTS	asterisk	2026-06-16
Debian	DLA-4632-1	LTS	atril	2026-06-16
Debian	DSA-6347-1	stable	bird2	2026-06-15
Debian	DSA-6337-1	stable	chromium	2026-06-10
Debian	DSA-6344-1	stable	chromium	2026-06-13
Debian	DSA-6348-1	stable	gsasl	2026-06-16
Debian	DSA-6341-1	stable	ironic	2026-06-11
Debian	DSA-6336-1	stable	jackson-core	2026-06-10
Debian	DSA-6342-1	stable	jpeg-xl	2026-06-12
Debian	DLA-4627-1	LTS	kernel-wedge	2026-06-12
Debian	DSA-6338-1	stable	libdbi-perl	2026-06-11
Debian	DSA-6345-1	stable	libgd-perl	2026-06-15
Debian	DLA-4626-1	LTS	libinput	2026-06-12
Debian	DSA-6339-1	stable	libinput	2026-06-11
Debian	DSA-6343-1	stable	librabbitmq	2026-06-12
Debian	DLA-4633-1	LTS	libreoffice	2026-06-17
Debian	DSA-6346-1	stable	libreoffice	2026-06-15
Debian	DLA-4628-1	LTS	linux-base	2026-06-12
Debian	DSA-6340-1	stable	neutron	2026-06-11
Debian	DLA-4630-1	LTS	openssl	2026-06-15
Fedora	FEDORA-2026-f36864b408	F43	7zip	2026-06-16
Fedora	FEDORA-2026-4be7569210	F44	7zip	2026-06-16
Fedora	FEDORA-2026-45190a3b6b	F43	ack	2026-06-17
Fedora	FEDORA-2026-bb708e11d7	F44	ack	2026-06-16
Fedora	FEDORA-2026-77b4ea4fb8	F43	apptainer	2026-06-14
Fedora	FEDORA-2026-ff5370cd61	F44	apptainer	2026-06-13
Fedora	FEDORA-2026-ec095a4675	F43	bind9-next	2026-06-15
Fedora	FEDORA-2026-dbb0776ac5	F44	bind9-next	2026-06-15
Fedora	FEDORA-2026-564680920c	F43	bird	2026-06-17
Fedora	FEDORA-2026-8f225adf49	F44	bird	2026-06-17
Fedora	FEDORA-2026-905e9afc79	F44	chezmoi	2026-06-13
Fedora	FEDORA-2026-c5c0986fb6	F43	chromium	2026-06-14
Fedora	FEDORA-2026-2debc85b3c	F44	chromium	2026-06-13
Fedora	FEDORA-2026-59f46c195f	F44	chromium	2026-06-17
Fedora	FEDORA-2026-2148c0e80b	F44	collectd	2026-06-13
Fedora	FEDORA-2026-4308b5fc39	F43	composer	2026-06-14
Fedora	FEDORA-2026-9b34a78e81	F44	composer	2026-06-13
Fedora	FEDORA-2026-51cdd1292b	F44	dnsdist	2026-06-15
Fedora	FEDORA-2026-5eeadd9b1b	F44	firefox	2026-06-17
Fedora	FEDORA-2026-f07b3548d4	F44	gh	2026-06-15
Fedora	FEDORA-2026-d4136fe979	F44	httpd	2026-06-11
Fedora	FEDORA-2026-6f3d11bdc6	F43	hugo	2026-06-16
Fedora	FEDORA-2026-7fe2bb8a08	F44	hugo	2026-06-16
Fedora	FEDORA-2026-75fcc75b5f	F43	kernel	2026-06-12
Fedora	FEDORA-2026-8b619eef6f	F44	kernel	2026-06-12
Fedora	FEDORA-2026-1c6479b257	F44	ldns	2026-06-17
Fedora	FEDORA-2026-7174ee9a91	F44	librabbitmq	2026-06-17
Fedora	FEDORA-2026-cb3feafe41	F43	nextcloud	2026-06-17
Fedora	FEDORA-2026-86fab2703b	F44	nextcloud	2026-06-17
Fedora	FEDORA-2026-5eeadd9b1b	F44	nss	2026-06-17
Fedora	FEDORA-2026-3c93ea23b5	F43	openslide	2026-06-17
Fedora	FEDORA-2026-e31dda6e44	F44	openslide	2026-06-17
Fedora	FEDORA-2026-228373a496	F44	openssl	2026-06-12
Fedora	FEDORA-2026-1da54e6cb8	F43	perl-Mojo-JWT	2026-06-16
Fedora	FEDORA-2026-80333f8f56	F44	perl-Mojo-JWT	2026-06-16
Fedora	FEDORA-2026-4c8da3ad64	F43	perl-Protocol-HTTP2	2026-06-17
Fedora	FEDORA-2026-12765c0719	F44	perl-Protocol-HTTP2	2026-06-17
Fedora	FEDORA-2026-f140cb16b6	F43	python-django5	2026-06-15
Fedora	FEDORA-2026-e4146022ce	F44	python-django5	2026-06-15
Fedora	FEDORA-2026-2cfc16a621	F43	python-python-multipart	2026-06-15
Fedora	FEDORA-2026-104e079187	F44	python-python-multipart	2026-06-15
Fedora	FEDORA-2026-d7436d12ae	F43	rust	2026-06-11
Fedora	FEDORA-2026-28df92c223	F43	tig	2026-06-17
Fedora	FEDORA-2026-5cb64cc909	F44	tig	2026-06-17
Fedora	FEDORA-2026-2148c0e80b	F44	varnish	2026-06-13
Fedora	FEDORA-2026-2148c0e80b	F44	varnish-modules	2026-06-13
Fedora	FEDORA-2026-264f9ef567	F43	vaultwarden	2026-06-12
Fedora	FEDORA-2026-e14ea170b6	F44	vaultwarden	2026-06-12
Fedora	FEDORA-2026-064873552d	F43	vaultwarden-web	2026-06-12
Fedora	FEDORA-2026-111cf6d28f	F44	vaultwarden-web	2026-06-12
Fedora	FEDORA-2026-2148c0e80b	F44	vmod-querystring	2026-06-13
Fedora	FEDORA-2026-2148c0e80b	F44	vmod-uuid	2026-06-13
Fedora	FEDORA-2026-884a9f0fc3	F44	vorbis-tools	2026-06-17
Fedora	FEDORA-2026-2080c5c036	F43	weasyprint	2026-06-14
Fedora	FEDORA-2026-6525541bb8	F44	weasyprint	2026-06-13
Fedora	FEDORA-2026-24b84f97af	F44	xen	2026-06-17
Fedora	FEDORA-2026-3c78c99467	F43	xmlstarlet	2026-06-11
Fedora	FEDORA-2026-dbf44e0b72	F44	xmlstarlet	2026-06-11
Fedora	FEDORA-2026-557e726e74	F43	xorg-x11-server-Xwayland	2026-06-14
Mageia	MGASA-2026-0209	9	atril, evince, xreader	2026-06-15
Mageia	MGASA-2026-0217	9	coturn	2026-06-17
Mageia	MGASA-2026-0201	9	cups	2026-06-13
Mageia	MGASA-2026-0213	9	emacs	2026-06-16
Mageia	MGASA-2026-0196	9	erlang-hex_core, erlang-rebar3	2026-06-11
Mageia	MGASA-2026-0204	9	expat	2026-06-13
Mageia	MGASA-2026-0197	9	gnupg2	2026-06-11
Mageia	MGASA-2026-0214	9	lcms2	2026-06-16
Mageia	MGASA-2026-0212	9	libgcrypt	2026-06-15
Mageia	MGASA-2026-0208	9	libinput	2026-06-15
Mageia	MGASA-2026-0205	9	libpng	2026-06-13
Mageia	MGASA-2026-0215	9	libsndfile	2026-06-16
Mageia	MGASA-2026-0202	9	libssh	2026-06-13
Mageia	MGASA-2026-0218	9	log4cxx	2026-06-17
Mageia	MGASA-2026-0203	9	memcached	2026-06-13
Mageia	MGASA-2026-0199	9	nghttp2	2026-06-12
Mageia	MGASA-2026-0206	9	openimageio	2026-06-13
Mageia	MGASA-2026-0193	9	openssh	2026-06-10
Mageia	MGASA-2026-0207	9	packages	2026-06-13
Mageia	MGASA-2026-0192	9	postfix	2026-06-10
Mageia	MGASA-2026-0200	9	proftpd	2026-06-13
Mageia	MGASA-2026-0210	9	putty	2026-06-15
Mageia	MGASA-2026-0216	9	python-tornado	2026-06-17
Mageia	MGASA-2026-0198	9	radare2	2026-06-12
Mageia	MGASA-2026-0194	9	roundcubemail	2026-06-11
Mageia	MGASA-2026-0195	9	sqlite3	2026-06-11
Mageia	MGASA-2026-0211	9	sudo	2026-06-15
Oracle	ELSA-2026-25114	OL8	.NET 10.0	2026-06-12
Oracle	ELSA-2026-25110	OL8	.NET 8.0	2026-06-12
Oracle	ELSA-2026-25113	OL8	.NET 9.0	2026-06-12
Oracle	ELSA-2026-13977	OL7	firefox	2026-06-12
Oracle	ELSA-2026-3984	OL7	firefox	2026-06-12
Oracle	ELSA-2026-8427	OL7	firefox	2026-06-12
Oracle	ELSA-2026-24340	OL8	frr	2026-06-10
Oracle	ELSA-2026-50306	OL7	kernel	2026-06-10
Oracle	ELSA-2026-50306	OL8	kernel	2026-06-10
Oracle	ELSA-2026-50306	OL8	kernel	2026-06-10
Oracle	ELSA-2026-50305	OL8	kernel	2026-06-10
Oracle	ELSA-2026-50305	OL9	kernel	2026-06-10
Oracle	ELSA-2026-50305	OL9	kernel	2026-06-10
Oracle	ELSA-2026-50304	OL9	kernel	2026-06-10
Oracle	ELSA-2026-24545	OL8	libyang	2026-06-10
Oracle	ELSA-2026-50304		n	2026-06-10
Oracle	ELSA-2026-25030	OL8	postgresql-jdbc	2026-06-11
Oracle	ELSA-2026-24365	OL8	unbound	2026-06-10
Red Hat	RHSA-2026:25115-01	EL10	.NET 10.0	2026-06-11
Red Hat	RHSA-2026:25114-01	EL8	.NET 10.0	2026-06-11
Red Hat	RHSA-2026:25222-01	EL9	.NET 10.0	2026-06-11
Red Hat	RHSA-2026:25111-01	EL10	.NET 8.0	2026-06-11
Red Hat	RHSA-2026:25110-01	EL8	.NET 8.0	2026-06-11
Red Hat	RHSA-2026:25220-01	EL9	.NET 8.0	2026-06-11
Red Hat	RHSA-2026:25112-01	EL10	.NET 9.0	2026-06-11
Red Hat	RHSA-2026:25113-01	EL8	.NET 9.0	2026-06-11
Red Hat	RHSA-2026:25252-01	EL9.2	buildah	2026-06-12
Red Hat	RHSA-2026:25237-01	EL10	openssl	2026-06-16
Red Hat	RHSA-2026:26275-01	EL8	openssl	2026-06-16
Red Hat	RHSA-2026:25239-01	EL9	openssl	2026-06-16
Red Hat	RHSA-2026:26054-01	EL9.6	osbuild-composer	2026-06-16
Red Hat	RHSA-2026:25248-01	EL9.2	podman	2026-06-12
Red Hat	RHSA-2026:25930-01	EL10	postfix	2026-06-15
Red Hat	RHSA-2026:23229-01	EL9	redis	2026-06-11
Red Hat	RHSA-2026:25219-01	EL9	redis:7	2026-06-11
Red Hat	RHSA-2026:25250-01	EL9.2	skopeo	2026-06-12
Red Hat	RHSA-2026:25216-01	EL10	valkey	2026-06-15
Red Hat	RHSA-2026:25925-01	EL9	valkey	2026-06-15
SUSE	SUSE-SU-2026:2419-1	SLE15	389-ds	2026-06-16
SUSE	SUSE-SU-2026:2417-1	SLE15 oS15.5	389-ds	2026-06-16
SUSE	SUSE-SU-2026:2418-1	SLE15 oS15.6	389-ds	2026-06-16
SUSE	SUSE-SU-2026:2389-1	SLE15 oS15.6	GraphicsMagick	2026-06-12
SUSE	SUSE-SU-2026:22086-1	SLE16.0	NetworkManager	2026-06-15
SUSE	openSUSE-SU-2026:0200-1	osB15	NetworkManager-libreswan	2026-06-10
SUSE	openSUSE-SU-2026:10991-1	TW	afl	2026-06-12
SUSE	openSUSE-SU-2026:10979-1	TW	agama-web-ui	2026-06-10
SUSE	openSUSE-SU-2026:10992-1	TW	alloy	2026-06-12
SUSE	openSUSE-SU-2026:11007-1	TW	ansible-core	2026-06-13
SUSE	SUSE-SU-2026:22088-1	SLE16.0	apache-pdfbox	2026-06-15
SUSE	SUSE-SU-2026:2416-1	SLE15 oS15.4	buildah	2026-06-16
SUSE	SUSE-SU-2026:2415-1	SLE15 oS15.5	buildah	2026-06-16
SUSE	openSUSE-SU-2026:0205-1	osB15	cheat	2026-06-15
SUSE	openSUSE-SU-2026:11008-1	TW	chromedriver	2026-06-13
SUSE	openSUSE-SU-2026:11029-1	TW	chromedriver	2026-06-15
SUSE	openSUSE-SU-2026:20944-1	oS16.0	chromium	2026-06-12
SUSE	SUSE-SU-2026:2363-1	SLE5.5 SLE-m5.5	cockpit	2026-06-11
SUSE	SUSE-SU-2026:2420-1	SLE15	container-suseconnect	2026-06-16
SUSE	SUSE-SU-2026:2407-1	SLE15	containerized-data-importer	2026-06-16
SUSE	SUSE-SU-2026:2365-1	SLE15 oS15.4	cosign	2026-06-11
SUSE	openSUSE-SU-2026:10994-1	TW	cpp-httplib-devel	2026-06-12
SUSE	openSUSE-SU-2026:20962-1	oS16.0	cyrus-imapd	2026-06-15
SUSE	openSUSE-SU-2026:0204-1	osB15	cyrus-imapd	2026-06-15
SUSE	SUSE-SU-2026:2413-1	SLE15 oS15.4	distribution	2026-06-16
SUSE	SUSE-SU-2026:22085-1	SLE16.0	dpkg	2026-06-15
SUSE	SUSE-SU-2026:22125-1	SLE16.0	editorconfig-core-c	2026-06-16
SUSE	SUSE-SU-2026:22066-1	SLE-m6.0	elemental-operator	2026-06-12
SUSE	SUSE-SU-2026:22075-1	SLE-m6.1	elemental-operator	2026-06-12
SUSE	SUSE-SU-2026:22101-1	SLE-m6.0	elemental-system-agent	2026-06-16
SUSE	SUSE-SU-2026:22065-1	SLE-m6.0	elemental-toolkit	2026-06-12
SUSE	SUSE-SU-2026:22074-1	SLE-m6.1	elemental-toolkit	2026-06-12
SUSE	openSUSE-SU-2026:10995-1	TW	enc	2026-06-12
SUSE	SUSE-SU-2026:22082-1	SLE16.0	erlang	2026-06-15
SUSE	openSUSE-SU-2026:11009-1	TW	ffmpeg-7	2026-06-13
SUSE	SUSE-SU-2026:22060-1	SLE-m6.0 SLE-m6.1	firewalld	2026-06-12
SUSE	openSUSE-SU-2026:10980-1	TW	flannel	2026-06-11
SUSE	openSUSE-SU-2026:11020-1	TW	freeipmi	2026-06-15
SUSE	openSUSE-SU-2026:10983-1	TW	gdk-pixbuf-loader-libheif	2026-06-11
SUSE	openSUSE-SU-2026:10996-1	TW	git-bug	2026-06-12
SUSE	SUSE-SU-2026:22102-1	SLE-m6.0	glib-networking	2026-06-16
SUSE	SUSE-SU-2026:22135-1	SLE-m6.1	glib-networking	2026-06-17
SUSE	SUSE-SU-2026:2333-1	SLE15 SLE5.3 SLE5.4 SLE5.5 SLE-m5.3 SLE-m5.4 SLE-m5.5 oS15.3	glibc	2026-06-10
SUSE	SUSE-SU-2026:2367-1	SLE12	gnutls	2026-06-11
SUSE	SUSE-SU-2026:2366-1	SLE12	gnutls	2026-06-11
SUSE	openSUSE-SU-2026:10997-1	TW	golang-github-prometheus-prometheus	2026-06-12
SUSE	SUSE-SU-2026:2372-1	MP4.3 SLE15	google-cloud-sap-agent	2026-06-11
SUSE	SUSE-SU-2026:2348-1	SLE12	google-cloud-sap-agent	2026-06-10
SUSE	SUSE-SU-2026:22133-1	SLE-m6.1	google-guest-agent	2026-06-17
SUSE	SUSE-SU-2026:22128-1	SLE16.0	google-guest-agent	2026-06-16
SUSE	SUSE-SU-2026:2347-1	SLE12	google-osconfig-agent	2026-06-10
SUSE	openSUSE-SU-2026:11032-1	TW	google-osconfig-agent	2026-06-16
SUSE	openSUSE-SU-2026:10981-1	TW	grafana	2026-06-11
SUSE	openSUSE-SU-2026:11013-1	TW	grafana	2026-06-14
SUSE	openSUSE-SU-2026:20961-1	oS16.0	graphicsmagick	2026-06-15
SUSE	SUSE-SU-2026:22063-1	SLE-m6.0	graphite2	2026-06-12
SUSE	SUSE-SU-2026:22072-1	SLE-m6.1	graphite2	2026-06-12
SUSE	openSUSE-SU-2026:10982-1	TW	graphite2	2026-06-11
SUSE	SUSE-SU-2026:2380-1	SLE15 oS15.4	hplip	2026-06-12
SUSE	openSUSE-SU-2026:0207-1	osB15	java-11-openj9	2026-06-15
SUSE	openSUSE-SU-2026:0208-1	osB15	java-17-openj9	2026-06-15
SUSE	openSUSE-SU-2026:0198-1	osB15	kanidm	2026-06-10
SUSE	SUSE-SU-2026:2383-1	MP4.3 SLE15 SLE5.3 SLE5.4 SLE-m5.3 SLE-m5.4 oS15.4	kernel	2026-06-12
SUSE	SUSE-SU-2026:2331-1	SLE15 SLE5.3 SLE5.4 SLE-m5.3 SLE-m5.4	kernel	2026-06-10
SUSE	SUSE-SU-2026:2332-1	SLE15 SLE5.5 SLE-m5.5 oS15.5	kernel	2026-06-10
SUSE	SUSE-SU-2026:2421-1	SLE15 SLE5.5 SLE-m5.5 oS15.5	kernel	2026-06-16
SUSE	SUSE-SU-2026:22087-1	SLE16.0	kernel	2026-06-15
SUSE	SUSE-SU-2026:22076-1	SLE16.0	kernel	2026-06-15
SUSE	SUSE-SU-2026:22099-1	SLE16.0	kernel	2026-06-16
SUSE	SUSE-SU-2026:22127-1	SLE16.0	kernel	2026-06-16
SUSE	SUSE-SU-2026:22117-1	SLE16.0 SLE-m6.2	kernel	2026-06-16
SUSE	SUSE-SU-2026:22112-1	SLE16.0 SLE-m6.2	kernel	2026-06-16
SUSE	SUSE-SU-2026:22108-1	SLE6.0 SLE-m6.0	kernel	2026-06-16
SUSE	SUSE-SU-2026:22100-1	SLE6.0 SLE-m6.0	kernel	2026-06-16
SUSE	SUSE-SU-2026:22140-1	SLE6.0 SLE-m6.0 SLE-m6.1	kernel	2026-06-17
SUSE	SUSE-SU-2026:22137-1	SLE6.0 SLE-m6.0 SLE-m6.1	kernel	2026-06-17
SUSE	openSUSE-SU-2026:11014-1	TW	kernel-devel	2026-06-14
SUSE	openSUSE-SU-2026:11021-1	TW	kitty	2026-06-15
SUSE	SUSE-SU-2026:2342-1	SLE15 oS15.6	kubernetes	2026-06-10
SUSE	SUSE-SU-2026:2340-1	SLE15 oS15.5	kubernetes1.23	2026-06-10
SUSE	SUSE-SU-2026:2343-1	SLE15 oS15.5	kubernetes1.24	2026-06-10
SUSE	SUSE-SU-2026:2345-1	SLE15 oS15.4	kubernetes1.25	2026-06-10
SUSE	SUSE-SU-2026:2339-1	SLE15 oS15.4	kubernetes1.27	2026-06-10
SUSE	SUSE-SU-2026:2344-1	SLE15 oS15.4	kubernetes1.28	2026-06-10
SUSE	SUSE-SU-2026:2401-1	SLE15	kubevirt-1.6	2026-06-15
SUSE	SUSE-SU-2026:2400-1	SLE15	kubevirt	2026-06-15
SUSE	SUSE-SU-2026:22070-1	SLE-m6.1	lcms2	2026-06-12
SUSE	openSUSE-SU-2026:10998-1	TW	ldns	2026-06-12
SUSE	openSUSE-SU-2026:10985-1	TW	libIex-3_4-33	2026-06-11
SUSE	SUSE-SU-2026:22121-1	SLE16.0	libXpm	2026-06-16
SUSE	SUSE-SU-2026:2394-1	SLE12	libcaca	2026-06-15
SUSE	SUSE-SU-2026:2424-1	SLE15	libcaca	2026-06-16
SUSE	SUSE-SU-2026:2423-1	SLE15 oS15.6	libcaca	2026-06-16
SUSE	openSUSE-SU-2026:11023-1	TW	libopenssl-3-devel	2026-06-15
SUSE	openSUSE-SU-2026:10970-1	TW	libpodofo-devel	2026-06-10
SUSE	openSUSE-SU-2026:11028-1	TW	librav1e0_8	2026-06-15
SUSE	SUSE-SU-2026:22061-1	SLE-m6.0	libsoup	2026-06-12
SUSE	SUSE-SU-2026:22071-1	SLE-m6.1	libsoup	2026-06-12
SUSE	SUSE-SU-2026:2334-1	SLE12	libyang	2026-06-10
SUSE	SUSE-SU-2026:2337-1	SLE15	libyang	2026-06-10
SUSE	SUSE-SU-2026:2381-1	SLE15 oS15.3	libyang	2026-06-12
SUSE	SUSE-SU-2026:2335-1	SLE15 oS15.5	libyang	2026-06-10
SUSE	SUSE-SU-2026:22064-1	SLE-m6.0	libzypp	2026-06-12
SUSE	SUSE-SU-2026:22062-1	SLE-m6.0	libzypp	2026-06-12
SUSE	SUSE-SU-2026:22073-1	SLE-m6.1	libzypp	2026-06-12
SUSE	openSUSE-SU-2026:10984-1	TW	libzypp	2026-06-11
SUSE	openSUSE-SU-2026:11016-1	TW	logback	2026-06-14
SUSE	openSUSE-SU-2026:10999-1	TW	logback	2026-06-12
SUSE	SUSE-SU-2026:22095-1	SLE16.0	mariadb	2026-06-15
SUSE	openSUSE-SU-2026:20963-1	oS16.0	neonmodem	2026-06-15
SUSE	SUSE-SU-2026:2370-1	SLE15 oS15.4	nginx	2026-06-11
SUSE	SUSE-SU-2026:2355-1	SLE5.4 SLE-m5.4 oS15.4	openCryptoki	2026-06-10
SUSE	SUSE-SU-2026:22103-1	SLE-m6.0	opensc	2026-06-16
SUSE	SUSE-SU-2026:22139-1	SLE-m6.1	opensc	2026-06-17
SUSE	SUSE-SU-2026:22114-1	SLE-m6.2	opensc	2026-06-16
SUSE	SUSE-SU-2026:22126-1	SLE16.0	opensc	2026-06-16
SUSE	openSUSE-SU-2026:11022-1	TW	opensc	2026-06-15
SUSE	SUSE-SU-2026:22067-1	SLE-m6.1	openssh	2026-06-12
SUSE	SUSE-SU-2026:2395-1	SLE12	openssh	2026-06-15
SUSE	SUSE-SU-2026:2375-1	SLE15 SLE5.3 SLE5.4 SLE5.5 SLE-m5.3 SLE-m5.4 SLE-m5.5 oS15.3	openssh	2026-06-11
SUSE	SUSE-SU-2026:2371-1	SLE15 oS15.6	openssh	2026-06-11
SUSE	SUSE-SU-2026:2396-1	SLE12	openssl-1_0_0	2026-06-15
SUSE	SUSE-SU-2026:2399-1	SLE15	openssl-1_0_0	2026-06-15
SUSE	SUSE-SU-2026:2403-1	SLE12	openssl-1_1	2026-06-16
SUSE	SUSE-SU-2026:2392-1	SLE15	openssl-1_1	2026-06-15
SUSE	SUSE-SU-2026:2405-1	SLE15 SLE5.5 SLE-m5.5 oS15.5	openssl-1_1	2026-06-16
SUSE	SUSE-SU-2026:2404-1	SLE15 oS15.6	openssl-1_1	2026-06-16
SUSE	SUSE-SU-2026:22132-1	SLE-m6.1	openssl-3	2026-06-17
SUSE	SUSE-SU-2026:2397-1	SLE15 oS15.5	openssl-3	2026-06-15
SUSE	SUSE-SU-2026:2393-1	SLE15 oS15.6	openssl-3	2026-06-15
SUSE	SUSE-SU-2026:22105-1	SLE-m6.0	openvswitch	2026-06-16
SUSE	SUSE-SU-2026:22068-1	SLE-m6.1	openvswitch	2026-06-12
SUSE	openSUSE-SU-2026:11034-1	TW	perl-Crypt-PBKDF2	2026-06-16
SUSE	openSUSE-SU-2026:10986-1	TW	perl-DBI	2026-06-11
SUSE	openSUSE-SU-2026:11017-1	TW	perl-GD	2026-06-14
SUSE	openSUSE-SU-2026:10987-1	TW	perl-Git-Repository	2026-06-11
SUSE	SUSE-SU-2026:2408-1	SLE12	perl-HTTP-Daemon	2026-06-16
SUSE	openSUSE-SU-2026:10988-1	TW	perl-Protocol-HTTP2	2026-06-11
SUSE	SUSE-SU-2026:2402-1	SLE12	perl-XML-LibXML	2026-06-16
SUSE	SUSE-SU-2026:22081-1	SLE16.0	perl-XML-LibXML	2026-06-15
SUSE	SUSE-SU-2026:22090-1	SLE16.0	polkit	2026-06-15
SUSE	openSUSE-SU-2026:11001-1	TW	postgresql-jdbc	2026-06-13
SUSE	SUSE-SU-2026:22077-1	SLE16.0	postgresql18	2026-06-15
SUSE	openSUSE-SU-2026:10990-1	TW	python-M2Crypto-doc	2026-06-12
SUSE	SUSE-SU-2026:22058-1	SLE-m6.2	python-Pygments	2026-06-12
SUSE	SUSE-SU-2026:22093-1	SLE16.0	python-Pygments	2026-06-15
SUSE	SUSE-SU-2026:2387-1	SLE15	python	2026-06-12
SUSE	openSUSE-SU-2026:20937-1	oS16.0	python-django	2026-06-12
SUSE	openSUSE-SU-2026:20931-1	oS16.0	python-pygments	2026-06-12
SUSE	SUSE-SU-2026:22118-1	SLE16.0	python-python-dotenv	2026-06-16
SUSE	openSUSE-SU-2026:20952-1	oS16.0	python-python-dotenv	2026-06-15
SUSE	SUSE-SU-2026:22091-1	SLE16.0	python-requests	2026-06-15
SUSE	openSUSE-SU-2026:0087-1	osB15	python-simpleeval	2026-06-12
SUSE	openSUSE-SU-2026:10989-1	TW	python311-Django4	2026-06-11
SUSE	openSUSE-SU-2026:11024-1	TW	python311-PyJWT	2026-06-15
SUSE	openSUSE-SU-2026:11035-1	TW	python311-aiosmtplib	2026-06-16
SUSE	openSUSE-SU-2026:11025-1	TW	python311-paramiko	2026-06-15
SUSE	openSUSE-SU-2026:10974-1	TW	python311-pypdf	2026-06-10
SUSE	openSUSE-SU-2026:11026-1	TW	python311-starlette	2026-06-15
SUSE	openSUSE-SU-2026:11027-1	TW	python311-tornado6	2026-06-15
SUSE	openSUSE-SU-2026:11036-1	TW	python311-zeroconf	2026-06-16
SUSE	openSUSE-SU-2026:11003-1	TW	python313-Django6	2026-06-13
SUSE	SUSE-SU-2026:2406-1	SLE12	qemu	2026-06-16
SUSE	SUSE-SU-2026:2385-1	SLE15	qemu	2026-06-12
SUSE	SUSE-SU-2026:2388-1	SLE15 SLE5.5 SLE-m5.5 oS15.5	qemu	2026-06-12
SUSE	SUSE-SU-2026:2386-1	SLE15 oS15.6	qemu	2026-06-12
SUSE	openSUSE-SU-2026:10975-1	TW	rclone	2026-06-10
SUSE	openSUSE-SU-2026:0199-1	osB15	rclone	2026-06-12
SUSE	openSUSE-SU-2026:0206-1	osB15	restic	2026-06-15
SUSE	openSUSE-SU-2026:0183-1	osB15	roundcubemail	2026-06-12
SUSE	SUSE-SU-2026:22069-1	SLE-m6.1	rpcbind	2026-06-12
SUSE	SUSE-SU-2026:2414-1	SLE15 SLE5.3 SLE5.4 SLE5.5 SLE-m5.3 SLE-m5.4 SLE-m5.5 SES7.1	runc	2026-06-16
SUSE	SUSE-SU-2026:22080-1	SLE16.0	samba	2026-06-15
SUSE	SUSE-SU-2026:0741-2	SLE15	shim	2026-06-16
SUSE	SUSE-SU-2026:22104-1	SLE-m6.0	sqlite3	2026-06-16
SUSE	SUSE-SU-2026:22134-1	SLE-m6.1	sqlite3	2026-06-17
SUSE	openSUSE-SU-2026:10976-1	TW	steampipe	2026-06-10
SUSE	SUSE-SU-2026:2368-1	SLE15 oS15.4	strongswan	2026-06-11
SUSE	openSUSE-SU-2026:11005-1	TW	strongswan	2026-06-13
SUSE	openSUSE-SU-2026:11006-1	TW	tmux	2026-06-13
SUSE	SUSE-SU-2026:2377-1	SLE15	tomcat10	2026-06-11
SUSE	SUSE-SU-2026:2374-1	SLE15 oS15.6	tomcat11	2026-06-11
SUSE	openSUSE-SU-2026:20956-1	oS16.0	trivy	2026-06-15
SUSE	SUSE-SU-2026:2369-1	SLE15 SLE5.5 SLE-m5.5	unbound	2026-06-11
SUSE	SUSE-SU-2026:22084-1	SLE16.0	uriparser	2026-06-15
SUSE	SUSE-SU-2026:2378-1	SLE15 oS15.4	webkit2gtk3	2026-06-11
SUSE	SUSE-SU-2026:2376-1	SLE15 oS15.6	webkit2gtk3	2026-06-11
SUSE	SUSE-SU-2026:2350-1	SLE12	wicked	2026-06-10
SUSE	SUSE-SU-2026:2349-1	SLE15	wicked	2026-06-10
SUSE	SUSE-SU-2026:2354-1	SLE15 SLE5.3 SLE5.4 SLE-m5.3 SLE-m5.4 oS15.4	wicked	2026-06-10
SUSE	SUSE-SU-2026:2353-1	SLE15 SLE5.5 SLE-m5.5 oS15.5	wicked	2026-06-10
SUSE	SUSE-SU-2026:22096-1	SLE16.0	xdg-dbus-proxy	2026-06-15
SUSE	SUSE-SU-2026:2364-1	SLE15	xen	2026-06-11
Ubuntu	USN-8430-1	20.04 22.04 24.04 25.10 26.04	adsys	2026-06-16
Ubuntu	USN-8396-1	14.04 16.04 18.04 20.04	apache2	2026-06-12
Ubuntu	USN-8436-1	22.04 24.04 25.10 26.04	ca-certificates	2026-06-16
Ubuntu	USN-8405-2	22.04 24.04 25.10 26.04	cups	2026-06-15
Ubuntu	USN-8420-1	22.04 24.04 25.10 26.04	dotnet8, dotnet9, dotnet10	2026-06-11
Ubuntu	USN-6455-2	22.04	exim4	2026-06-10
Ubuntu	USN-8429-1	20.04 24.04 26.04	fastnetmon	2026-06-16
Ubuntu	USN-8432-1	18.04 20.04 22.04 24.04 25.10 26.04	freerdp2, freerdp3	2026-06-16
Ubuntu	USN-8130-3	16.04	gst-plugins-base1.0	2026-06-12
Ubuntu	USN-8421-1	22.04 24.04 25.10 26.04	ironic	2026-06-11
Ubuntu	USN-8433-1	22.04 24.04 25.10 26.04	keystone	2026-06-16
Ubuntu	USN-8418-1	16.04 18.04 20.04 22.04 24.04 25.10 26.04	libcrypt-saltedhash-perl	2026-06-11
Ubuntu	USN-8419-1	14.04 16.04 18.04 20.04 22.04 24.04 25.10 26.04	libhttp-daemon-perl	2026-06-10
Ubuntu	USN-8437-1	22.04 24.04 25.10 26.04	librabbitmq	2026-06-16
Ubuntu	USN-8361-3	16.04	linux, linux-aws, linux-kvm	2026-06-17
Ubuntu	USN-8441-1	16.04	linux-aws-hwe, linux-azure, linux-gcp, linux-hwe, linux-oracle	2026-06-17
Ubuntu	USN-8390-2	16.04	linux-azure, linux-gcp, linux-hwe, linux-oracle	2026-06-17
Ubuntu	USN-8426-2	22.04	linux-azure	2026-06-16
Ubuntu	USN-8426-1	20.04 22.04	linux-azure-5.15, linux-azure-fips	2026-06-11
Ubuntu	USN-8440-1	22.04	linux-azure-6.8	2026-06-16
Ubuntu	USN-8439-1	20.04	linux-oracle-5.15	2026-06-16
Ubuntu	USN-8423-1	20.04 22.04 24.04 26.04	lwip	2026-06-11
Ubuntu	USN-8427-1	22.04 24.04 25.10	mesa	2026-06-15
Ubuntu	USN-8422-1	22.04 24.04 25.10 26.04	mistral	2026-06-11
Ubuntu	USN-8398-3	22.04 24.04 25.10 26.04	nginx	2026-06-15
Ubuntu	USN-8434-1	22.04 24.04 25.10 26.04	nova	2026-06-17
Ubuntu	USN-8438-1	16.04 18.04 20.04 24.04 26.04	openimageio	2026-06-16
Ubuntu	USN-8412-2	18.04 20.04	qemu	2026-06-16
Ubuntu	USN-8349-3	14.04 16.04 18.04 20.04	rsync	2026-06-16
Ubuntu	USN-8431-1	16.04 18.04	ruby2.3, ruby2.5	2026-06-16
Ubuntu	USN-8306-2	20.04	samba	2026-06-10
Ubuntu	USN-8435-1	22.04 24.04 25.10 26.04	squid	2026-06-16
Ubuntu	USN-8428-1	26.04	tmux	2026-06-15
Ubuntu	USN-8424-1	26.04	ubuntu-kylin-software-center	2026-06-11
Ubuntu	USN-8409-1	14.04 16.04 18.04 20.04 22.04 24.04	uriparser	2026-06-10

Full Story (comments: none)