Welcome to the LWN.net Weekly Edition for May 1, 2025

This edition contains the following feature content:

• The mystery of the Mailman 2 CVEs: the report of three vulnerabilities in the end-of-life Mailman 2 system led to concern — and to doubts about whether those vulnerabilities actually exist.
• Debian debates AI models and the DFSG: what should be required of a model-based system before it can be part of Debian?
• Some __nonstring__ turbulence: a broken 6.15-rc3 release leads to disagreement in the kernel community.
• Cache awareness for the CPU scheduler: trying to do a better job of keeping processes near their data.
• LSFMM+BPF 2025 coverage:
  • Freezing filesystems for suspend: the system suspend/resume path lacks the ability to freeze and thaw filesystems; what would it take to add that functionality?
  • Inline socket-local storage for BPF: BPF developers discuss changing the layout of BPF map information in the networking subsystem to reduce cache misses.
  • Better debugging information for inline kernel functions: selectively inlined functions can be difficult to debug; perhaps enriching the kernel's BTF debugging information could help.

• How LWN is faring in 2025: navigating through stormy waters.

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 mystery of the Mailman 2 CVEs

Many eyebrows were raised recently when three vulnerabilities were announced that allegedly impact GNU Mailman 2.1, since many folks assumed that it was no longer being supported. That's not quite the case. Even though version 3 of the GNU Mailman mailing-list manager has been available since 2015, and version 2 was declared (mostly) end of life (EOL) in 2020, there are still plenty of users and projects still using version 2.1.x. There is, as it turns out, a big difference between mostly EOL and actually EOL. For example: WebPros, the company behind the cPanel server and web-site-management platform, still maintains a port of Mailman 2.1.x to Python 3 for its customers and was quick to respond to reports of vulnerabilities. However, the company and upstream Mailman project dispute that the CVEs are valid.

GNU Mailman 2

Mailman has been in development since 1998, and no doubt many LWN readers have had, or still have, subscriptions to mailing lists managed by some version of the software. The 1.0 release was announced in July 1999, with the 2.0 release following closely in November 2000. The project embarked on a major rewrite for the 3.0 release, which provided support for Python 3 and split Mailman into several components. The new Mailman was not, and still is not, a simple upgrade from the earlier version. It lacked feature parity with 2.1.x when it was first released in 2015, and still lacks a few features (such as topic filters) that users liked.

However, Mailman 2.x does not run on Python 3—and the project has been gently trying to nudge users away from the 2.x series for quite some time. Python 2.x was sunset on January 1, 2020, though it is currently still supported by some Linux vendors as part of long-term-support releases. Mailman core contributor Mark Sapiro said in 2017 that he was the only person still supporting 2.1.x. In 2020, Sapiro announced 2.1.30 as the last release to contain any new features. But he also said that there might be further updates with bug and security fixes, as well as internationalization updates.

The last 2.1.x release, so far, is version 2.1.39, which was announced in December 2021. It fixed two CVEs: a remote-privilege-escalation vulnerability (CVE-2021-42097), and a flaw that could allow list members or moderators to obtain a token to make administrative changes (CVE-2021-44227). According to that announcement, there is still the possibility that there will be more patch releases to address security problems. The Mailman web site also lists 2.1.39 as a current, stable version rather than as an EOL version, but its home page also has a thank you for donors who helped a Mailman core developer attend PyCon 2015. It's just possible that the project's web-site maintenance has fallen a bit behind.

In any case, plenty of users are still on Mailman 2.x with little sign of budging, including those who use the proprietary cPanel control panel. Last year, rather than trying to force its users to migrate, cPanel announced that it would provide extended support for Mailman 2 by upgrading it to Python 3 and taking responsibility for continued maintenance. The cPanel fork of Mailman is on GitHub and is based on a port to Python 3 by Jared Mauch. That fork has received a steady trickle of small commits from WebPros developers, with nearly 30 commits in 2025 from six people.

Vulnerabilities

On April 20, three CVEs were published that are supposed to affect "GNU Mailman 2.1.39, as bundled with cPanel and WHM" by two researchers—Firudin Davudzada and Aydan Musazade—from a company called Datricon. CVE-2025-43919, is described as a path-traversal vulnerability that would allow attackers to read arbitrary files. CVE-2025-43920 claims that unauthenticated attackers can execute arbitrary commands by using shell metacharacters in an email Subject line, if an external archiver (such as MHonArc) is used to archive mailman emails. It does not specify which external archiving software has been tested to produce this vulnerability, but blames Mailman for not sanitizing input to the external archiver. Finally, CVE-2025-43921 reports that unauthenticated attackers could create mailing lists.

Each of the CVEs has a corresponding repository on GitHub (CVE-2025-43919, CVE-2025-43920, and CVE-2025-43921) with a description of the vulnerability, exploitation scenarios, and so forth. The overviews published on GitHub by Davudzada and Musazade claim that these vulnerabilities were discovered in "Q1 2025" and reported to cPanel and the GNU Mailman project in Q1.

Alan Coopersmith forwarded the CVEs to the oss-security list on April 21. Valtteri Vuorikoski replied: "I saw these mentioned earlier and could not reproduce either on a stock 2.1.39 install." Vuorikoski wondered if the vulnerabilities might be specific to the cPanel version.

According to the cPanel support forum, they do not affect its version, either. On April 28, the company posted a support article to say that it had investigated the CVEs "both internally and via third party subject-matter experts" and could not reproduce the vulnerabilities using the information provided. The article also states that there is no record that the reporters attempted to contact the company.

We have contacted the Mailman maintainers, and they do not show any records of an attempted contact from the reporters either. We have attempted to contact the reporter multiple times via their publicly listed email addresses and have received no response. We do not consider these vulnerabilities to be valid. We will be taking no further action unless new information is provided.

I reached out to Sapiro by email, and he said no one with the GNU Mailman project had been contacted "as far as we know" and described the vulnerabilities as "bogus".

CVE-2025-43919 and CVE-2025-43921 ignore the fact that the attacker would need to provide authentication which the proof of concept attacks do not do and hence do not work. Thus, there is no vulnerability.

The vulnerability described by CVE-2025-43920 "relies on a convoluted configuration with an external archiver", he said, and that attack could be carried out equally well by sending the email directly to the archiver. "There are no plans to address this in Mailman 2.1."

I also contacted Datricon about the vulnerabilities and received a reply from Musazade. She said they had emailed cPanel on February 27 before applying for the CVEs, but made no mention of contacting the Mailman maintainers. She said that the lack of response to cPanel was because the messages from cPanel fell on non-business days, though that does not explain why they did not follow up later. However, she said that they have now communicated with the cPanel team—presumably since cPanel published its update on April 28—and would "provide best support and advisory regarding technical explanations of the CVEs" to help them reproduce the issues.

It is not uncommon for vulnerabilities to be difficult to reproduce under differing configurations. Factors such as customized software builds (such as cPanel's Mailman variant), environmental differences, and specific operational conditions (authentication, user permissions), can all impact reproducibility. Nonetheless, reproduction difficulty does not invalidate a vulnerability, especially after independent vetting and CVE assignment by MITRE and [the National Vulnerability Database (NVD)].

MITRE, of course, does not provide independent testing or validation of vulnerability reports and the fact that a CVE was published does not guarantee that it's valid. NIST has updated each of the NVD's CVE entries to note that multiple third parties have reported they are unable to reproduce the vulnerabilities. It's also odd that, despite claiming to have contacted cPanel and the upstream project, those parties dispute that they'd had contact.

No rush

It would seem that users of Mailman 2.1.39, or the cPanel fork, are not in imminent danger. The consensus from all parties—except the reporters—seems to be that the alleged vulnerabilities are not valid. Or "bogus" as Sapiro put it.

However, 2.x is largely a dead end, even if it does not have any currently known vulnerabilities. As Russ Allbery said on the oss-security list, "it's probably more realistic to view Mailman 2 as orphaned, end-of-life software" that will require a major migration.

While cPanel is, currently, providing extended maintenance for the project, there is no indication how long it will continue to do so or that a community is forming around the fork. Those remaining on 2.x should probably be plotting the migration to another mailing-list-manager platform at some point, whether that is Mailman 3, or something like Discourse that provides a discussion forum with the ability to participate via email.

Comments (4 posted)

Debian debates AI models and the DFSG

The Debian project is discussing a General Resolution (GR) that would, if approved, clarify that AI models must include training data to be compliant with the Debian Free Software Guidelines (DFSG) and be distributed by Debian as free software. While GR discussions are sometimes contentious, the discussion around the proposal from Debian developer Mo Zhou has been anything but—there seems to be consensus that AI models are not DFSG-compliant if they lack training data. There are, however, some questions about the exact language and questions about the impact the GR will have on existing packages in the Debian archive.

While many folks in the free-software community are generally skeptical about AI and would be happy to see the trend come to an end, Zhou is certainly not in the anti-AI camp. He is a Ph.D. student at Johns Hopkins University, and his academic web site states that his research interest is in computer vision and machine learning. He has created a project called DebGPT that explores using LLMs to aid in Debian development. Clearly, he sees some value in the technology, but also wants to adhere to free-software principles.

GR proposal

In February, Zhou wrote to the debian-project mailing list to say that he had created "something draft-ish" for a general resolution about applying the DFSG to AI models, which he later defined thusly:

A pre-trained "AI model" is usually stored on disk in binary formats designed for numerical arrays, as a "model checkpoint" or "state dictionary", which is essentially a collection of matrices and vectors, holding the learned information from the training data or simulator. When the user make use of such file, it is usually loaded by an inference program, which performs numerical computations to produce outputs based on the learned information in the model.

He called for help in adding reference materials and to shape up the early draft before posting it. Zhou sent his revised proposal to the debian-vote mailing list on April 19, with a detailed explanation with his reasoning for the GR and several appendices containing background information on AI technology, previous discussions, and comments on possible implications if the proposal is passed.

Debian has taken up the topic previously (see LWN's coverage from 2018) but never settled the question. The goal now is to reach a consensus on handling AI models that are released under DFSG-compliant licenses, but do not provide training data. Zhou's proposal notes that the software that runs AI models, such as Python scripts or C++ programs, are out of scope of the proposal since traditional software is already a well-defined case.

The actual text of the proposal, what Debian members would vote for (or against), is short and to the point:

Proposal A: "AI models released under open source license without original training data or program" are not seen as DFSG-compliant.

Francois Mazen, Timo Röhling, Matthias Urlichs, Christian Kastner, Boyuan Yang, and others have replied to support and sponsor the proposal. Resolutions are required to have five additional sponsors before they are put to discussion and eligible for a vote. Currently, if put to a vote, Debian members would have a choice between "A" or "none of the above". It is possible, according to the resolution procedure, that amendments or alternative proposals, such as "AI models are DFSG-compliant if under DFSG licenses", could be added during the discussion period.

Thorsten Glaser posted what he called a counter-proposal on April 23, and requested comments. While Zhou's proposal would simply clarify that models without training data do not meet the DSFG, Glaser goes much further. For example, he wants Debian to require that models be "trained only from legally obtained and used works" and that the data itself be under a suitable license for distribution. His proposal would also place heavy requirements on building models that would be hosted in Debian's main archive:

For a model to enter the main archive, the model training itself must *either* happen during package build (which, for models of a certain size, may need special infrastructure; the handling of this is outside of the scope of this resolution), *or* the model resulting from training must build in a sufficiently reproducible way that a separate rebuilding effort from the same source will result in the same trained model.

Finally, the current language would ask that training sources not be obtained unethically and "the ecological impact of training and using AI models be considered". What constitutes ethical or unethical acquisition of training sources is not defined. When asked by Carsten Leonhardt to summarize the difference between the proposals, Glaser replied that his was "a hard anti-AI stance (with select exceptions)". Thomas Goirand said that he would second Glaser's proposal, but he is the only one so far to endorse it.

Possible impact

Gunnar Wolf replied to sponsor the proposal and added that that Debian "cannot magically extend DFSG-freeness to a binary we have no way to recreate". That does not mean, he said, that Debian is shut out entirely from participating in the LLM world. Users could always download models from other sources or the models could even be uploaded to Debian's non-free repository.

Among the potential implications listed in Appendix D of the proposal is the downside that there are almost no useful AI models that would be able to enter the main section of Debian's archive under this interpretation. The upside is that Debian does not have to immediately deal with "the technical problem of handling 10+GB models in .deb packages" or expect downstream mirrors that host the main repository to carry such large binary files.

Simon McVittie asked if anyone had an idea whether any models existed in Debian's main repository that already match the definition. He said it was typical for proposals to provide an estimate of how many packages that would be made "insta-RC-buggy". In other words, how many packages would be subject to release-critical bugs if the GR passes? Since Debian is currently in freeze to prepare for the release of Debian 13 ("trixie"), he wanted to know if the GR would take effect immediately, or would it take effect at the beginning of the cycle for the next release? The pre-release freeze is already lengthy, and he thought it would be best to avoid making it longer in order to deal with any packages affected by this GR.

Russ Allbery observed that GNU Backgammon comes with neural-network weights that do not have source code. He admitted that he did not give that much thought when he was maintaining the package because it predated the LLM craze. "I'm not even sure if the data on which it's trained (backgammon games, I think mostly against bots) is copyrightable." He was also unsure whether other old-school machine-learning applications might be lurking around, and said he had no strong opinion about what to do if there were.

Games are not the only software that may be impacted. Ansgar Burchardt said that the GR might impact other useful software. His list included the Tesseract optical-character-recognition (OCR) software, OpenCV image-recognition software, Festival text-to-speech software, or other software with weights and data of uncertain origin. Urlichs suggested that Burchardt could write a counter-proposal or a more-nuanced proposal that would take some of those packages into account. He also questioned whether the software would need to be removed—the packages could be relocated to Debian's contrib archive and models placed in non-free.

Next steps

So far, Burchardt has not offered any proposals of his own, but there is still time. Discussion will continue for at least two weeks from the initial proposal, though the Debian Project Leader could shorten the discussion period by calling for a vote sooner. The proposal already has enough seconds to proceed; if the discussion reflects the overall mood of Debian developers, the GR would be likely to pass.

If it does pass, it will be in contrast to the Open Source Initiative's controversial Open Source AI Definition (OSAID) which LWN looked at last year. The OSI requires that model weights be provided under "OSI-approved terms" (which are yet to be specified), but does not require training data to be supplied in order to meet its definition for open-source AI. That has been a sticking point for many, who feel that the OSAID devalues the OSI's Open Source Definition (OSD)—which was derived from the DFSG in the first place.

Comments (42 posted)

Some __nonstring__ turbulence

New compiler releases often bring with them new warnings; those warnings are usually welcome, since they help developers find problems before they turn into nasty bugs. Adapting to new warnings can also create disruption in the development process, though, especially when an important developer upgrades to a new compiler at an unfortunate time. This is just the scenario that played out with the 6.15-rc3 kernel release and the implementation of -Wunterminated-string-initialization in GCC 15.

Consider a C declaration like:

    char foo[8] = "bar";

The array will be initialized with the given string, including the normal trailing NUL byte indicating the end of the string. Now consider this variant:

    char foo[8] = "NUL-free";

This is a legal declaration, even though the declared array now lacks the room for the NUL byte. That byte will simply be omitted, creating an unterminated string. That is often not what the developer who wrote that code wants, and it can lead to unpleasant bugs that are not discovered until some later time. The -Wunterminated-string-initialization option emits a warning for this kind of initialization, with the result that, hopefully, the problem — if there is a problem — is fixed quickly.

The kernel community has worked to make use of this warning and, hopefully, eliminate a source of bugs. There is only one little problem with the new warning, though: sometimes the no-NUL initialization is exactly what is wanted and intended. See, for example, this declaration from fs/cachefiles/key.c:

    static const char cachefiles_charmap[64] =
	"0123456789"			/* 0 - 9 */
	"abcdefghijklmnopqrstuvwxyz"	/* 10 - 35 */
	"ABCDEFGHIJKLMNOPQRSTUVWXYZ"	/* 36 - 61 */
	"_-"				/* 62 - 63 */
	;

This char array is used as a lookup table, not as a string, so there is no need for a trailing NUL byte. GCC 15, being unaware of that usage, will emit a false-positive warning for this declaration. There are many places in the kernel with declarations like this; the ACPI code, for example, uses a lot of four-byte string arrays to handle the equally large set of four-letter ACPI acronyms.

Naturally, there is a way to suppress the warning when it does not apply by adding an attribute to the declaration indicating that the char array is not actually holding a string:

    __attribute__((__nonstring__))

Within the kernel, the macro __nonstring is used to shorten that attribute syntax. Work has been ongoing, primarily by Kees Cook, to fix all of the warnings added by GCC 15. Many patches have been circulated; quite a few of them are in linux-next. Cook has also been working with the GCC developers to improve how this annotation works and to fix a problem that the kernel project ran into. There was some time left to get this job done, though, since GCC 15 has not actually been released — or so Cook thought.

Fedora 42 has been released, though, and the Fedora developers, for better or worse, decided to include a pre-release version of GCC 15 with it as the default compiler. The Fedora project, it seems, has decided to follow a venerable Red Hat tradition with this release. Linus Torvalds, for better or worse, decided to update his development systems to Fedora 42 the day before tagging and releasing 6.15-rc3. Once he tried building the kernel with the new compiler, though, things started to go wrong, since the relevant patches were not yet in his repository. Torvalds responded with a series of changes of his own, applied directly to the mainline about two hours before the release, to fix the problems that he had encountered. They included this patch fixing warnings in the ACPI subsystem, and this one fixing several others, including the example shown above. He then tagged and pushed out 6.15-rc3 with those changes.

Unfortunately, his last-minute changes broke the build on any version of GCC prior to the GCC 15 pre-release — a problem that was likely to create a certain amount of inconvenience for any developers who were not running Fedora 42. So, shortly after the 6.15-rc3 release, Torvalds tacked on one more patch backing out the breaking change and disabling the new warning altogether.

This drew a somewhat grumpy note from Cook, who said that he had already sent patches fixing all of the problems, including the build-breaking one that Torvalds ran into. He asked Torvalds to revert the changes and use the planned fixes, adding: "It is, once again, really frustrating when you update to unreleased compiler versions". Torvalds disagreed, saying that he needed to make the changes because the kernel failed to build otherwise. He also asserted that GCC 15 was released by virtue of its presence in Fedora 42. Cook was unimpressed:

Yes, I understand that, but you didn't coordinate with anyone. You didn't search lore for the warning strings, you didn't even check -next where you've now created merge conflicts. You put insufficiently tested patches into the tree at the last minute and cut an rc release that broke for everyone using GCC <15. You mercilessly flame maintainers for much much less.

Torvalds stood his ground, though, blaming Cook for not having gotten the fixes into the mainline quickly enough.

That is where the situation stands, as of this writing. Others will undoubtedly take the time to fix the problems properly, adding the changes that were intended all along. But this course of events has created some bad feelings all around, feelings that could maybe have been avoided with a better understanding of just when a future version of GCC is expected to be able to build the kernel.

As a sort of coda, it is worth saying that Torvalds also has a fundamental disagreement with how this attribute is implemented. The __nonstring__ attribute applies to variables, not types, so it must be used in every place where a char array is used without trailing NUL bytes. He would rather annotate the type, indicating that every instance of that type holds bytes rather than a character string, and avoid the need to mark rather larger numbers of variable declarations. But that is not how the attribute works, so the kernel will have to include __nonstring markers for every char array that is used in that way.

Comments (111 posted)

Cache awareness for the CPU scheduler

The kernel's CPU scheduler has to balance a wide range of objectives. The tasks in the system must be scheduled fairly, with latency for any given task kept within bounds. All of the CPUs in the system should be kept busy if there is enough work to do, but unneeded CPUs should be shut down to reduce power consumption. A task should also run on the CPU that is most likely to have cached the memory that task is using. This patch series from Chen Yu aims to improve how the scheduler handles cache locality for multi-threaded processes.

RAM is fast, but it is still unable to provide data at anything resembling the rate that a CPU can consume it. For this reason, systems are built with multiple layers of cache that are meant to hold frequently used data and make it available more quickly. Reading a value from cache is relatively fast; a read that goes all the way to RAM, instead, can stall a CPU for the time it takes to execute hundreds of instructions. Making effective use of cache is, thus, important for an application to perform well. Well-written applications are implemented with cache behavior in mind, but the kernel has a role to play as well.

Each layer of cache is accessible by a different number of CPUs; the closest (L1) cache may be specific to a single CPU, while the subsequent (slower, but often larger) layers of cache will be shared by a group of CPUs. The last-level cache (LLC) farthest from the CPUs and, thus, the slowest, but it tends to be the largest and is shared by the largest number of CPUs. Moving a task from one CPU to another may move it away from the data it has built up in cache, hurting its performance. If a task is moved to another CPU in the same socket, much of its cached data may still be available in the lower-level caches; if it is moved to another NUMA node, it may have to start anew with an empty (from its point of view) cache.

Because moving a task can hurt its performance, the CPU scheduler tries to avoid doing that when it can. That objective often runs into conflict with others, such as the need to balance the load across the system to make the best use of the available CPU resources. What the scheduler currently does not do, though, is to try to identify groups of tasks that might be sharing resources and, as a result, could benefit from sharing a single cache if they were scheduled together. Spreading those tasks across the system, instead, could lead to contention as they fight to keep data in their local caches.

In March, Peter Zijlstra posted an RFC patch to explore improving this situation. It is based on the idea that, if a process has multiple threads, those threads are likely to be sharing memory and could benefit from running within the same cache domain. It adds some instrumentation to the (already large) mm_struct structure that describes an address space, including a per-CPU array that is used by the scheduler to keep track of how much time threads using that mm_struct spend on each CPU in the system. This data decays over time, so recent usage is more strongly represented than usage in the distant, forgotten past (a few tens of milliseconds ago, say).

When the time comes to wake a thread that had been waiting for some event, the scheduler goes to that per-CPU array and determines which CPU has spent the most time executing threads from the same process. If the thread of interest has been running elsewhere, it will be moved to the selected CPU, where it will be closer to the other threads and, with luck, benefit from sharing cache space with them. As Zijlstra noted at the time: "This patch is not meant to be merged, it is meant for testing and development. We need to first make it actually improve workloads".

Chen then picked up this work and made a number of improvements to it. The original code would move a task to the hot CPU even if the task was already running within the same LLC domain, and thus already sharing the largest cache with that CPU. In this case, the movement will just slow that task down without much, if any, performance benefit, so task migration is inhibited in that case.

The other problem that turned up might seem obvious from the description of how the original patch works. Threads are migrated to the hot CPU without regard to how busy that CPU already is. If the number of threads is large, that gathering may well overload the target cache domain, hurting performance overall. This problem was addressed by looking at the overall usage statistics generated by the scheduler's load-balancing algorithm to ensure that the process owning the thread in question is not overloading the target domain. Specifically, if the process is using more than 25% of the CPU time in that domain, or has more than 33% of the overall load there, then the scheduler will not move more threads there.

That has improved the situation, but this work is still in a relatively early state. For example, it can fight with the load balancer:

The aggregation of tasks will move tasks towards the preferred LLC pretty quickly during wake ups. However load balance will tend to move tasks away from the aggregated LLC. The two migrations are in the opposite directions and tend to bounce tasks between LLCs.

CPU scheduling is driven by a lot of heuristics that can often come into conflict. So a patch series adding yet another heuristic ("concentrate a process's threads in a single cache domain") is sure to bring more surprising interactions that, perhaps, need to be addressed with even more heuristics.

There is also a question that has not yet been asked here: is collecting a process's threads the best way to identify tasks that would benefit from sharing a cache? It may not be, but it has the advantage of actually being possible; detecting cache sharing in tasks without that kind of direct relationship could be difficult, if it is possible at all. In the end, the fate of this patch series will depend on whether it actually shows improvements on real workloads without causing regressions for others. That is a high bar to clear for a change like this. The kernel may well have more cache-aware scheduling in the future, but it seems like it may take a while yet before it is ready.

Comments (6 posted)

Freezing filesystems for suspend

Sometimes worms have a tendency to multiply once their can is opened. James Bottomley recently encountered that situation; he led a session in the filesystem track at the 2025 Linux Storage, Filesystem, Memory Management, and BPF Summit (LSFMM+BPF) to discuss filesystem behavior with respect to suspending and resuming the system. As he noted in his topic proposal, he came at the problem because he needed a way to resynchronize the contents of efivarfs after a system resume and thought there should be an API available to use. But, as the resulting thread shows, the filesystem freeze and thaw code had never been used by the system-wide suspend and resume code. Due to a scheduling mixup, though, several of us missed Bottomley's session, including Luis Chamberlain who has been working on hooking those two pieces up; what follows is largely from a second session that Chamberlain led, with some background information from the topic-proposal discussion and an email exchange with Bottomley.

Background

The underlying problem that Bottomley is trying to solve is that efivarfs may not reflect the correct state of the EFI variables on the system after a resume operation. That's because some other OS could have been booted on the system after the suspend and changed some of the variables. So he was looking for a hook where he could add a resync operation that would run when the system is resumed. He had a solution, though it was kind of ugly, but he thought other filesystems might benefit from having some kind of API in order to give better guarantees about filesystem consistency across a suspend-resume cycle. As his proposal notes:

Hibernate is a particularly risky operation and resume may not work leading to a full reboot and filesystem inconsistencies. In many ways, a failed resume is exactly like a system crash, for which filesystems already make specific guarantees. However, it is a crash for which they could, if they had power management hooks, be forewarned and possibly make the filesystem cleaner for eventual full restore. Things like guaranteeing that uncommitted data would be preserved even if a resume failed, which isn't something we guarantee across a crash today.

The API for freezing and thawing superblocks was believed to be the proper hooks to use, but that API is not called by suspend and resume, though many were under the impression that it was. In the proposal thread, Bottomley noted that there were several attempts to freeze filesystems when suspending, but they ran aground on deadlock problems of various sorts. Jan Kara described a problem for FUSE filesystems; user space needs to still be running or writes will block, so there are some ordering issues that need to be worked out.

As part of the first session, it was agreed that it would make sense to try freezing the filesystems in reverse superblock order, so that each level closer to the storage would still be active so that data could be flushed. Any user-space processes that are accessing the filesystems after they have been frozen will effectively suspend themselves and user space can be fully suspended after all of the filesystems are frozen. It was generally believed that would all work, but it would obviously need to be tested, which Bottomley started working on during the summit.

Second session

Chamberlain has been working on freezing filesystems for a few years now. He said that he was working on the patches, which he had last posted back in 2023, on the plane to the summit, but did not finish. His posting was made, in part, to prepare attendees for his session at LSFMM+BPF 2023. At the time of that posting, there were some locking problems that he had worked around, which he raised at the start of this year's session. Christian Brauner said that those problems had already been fixed; there were some locking inversions between the VFS and block layers for freezing, but it has all been untangled "and should be safe from that perspective, as far as I can tell".

The rest of Chamberlain's patches are all Coccinelle-driven and fairly straightforward, he said. After applying those, testing with XFS could commence, followed by adding them to ext4 and other filesystems, one by one, with, of course, more testing. There was some discussion of the ordering of freezing the filesystems, including various possible deadlock problems, but most of the problematic cases had already been addressed or were on their way toward removal from the kernel.

Automated testing of the change will be somewhat difficult, Chamberlain said, because there is no real framework for that. Fstests does not test the resume operation, for one thing. Currently the best way is to use a laptop for the testing, he said, so that there is access to a real system suspend and resume. Ted Ts'o suggested testing a loopback filesystem using a file on one filesystem that gets mounted on another as a good way to try to ensure that the ordering of the freeze operations is being handled correctly.

Lennart Poettering said that systemd has given up calling sync() before suspending the system due to problems with complicated mount topologies, often involving NFS, that take too much time to complete the operation. The project would have investigated freezing filesystems, but that is not something that user space can do because of the deadlock possibilities. He would be happy to see the kernel take care of all of that.

Chamberlain returned to the plan to get rid of the kthread freezer (which was the topic of his session in 2023). The first step is to remove its use by filesystems, which is what his Coccinelle scripts do, but then there are other users of the kthread-freezer API that need to be addressed. The API was added for filesystems to use, but other parts of the kernel have started using it as well, so the "next challenge" will be getting rid of it throughout the kernel, he said.

There was a lot of confusion in the audience about what the kthread freezer actually is. Bottomley suggested that it was the freeze_task() call, but could not find any uses of that by filesystems. Maybe things have changed, Chamberlain said, but it is something that needs more investigation once filesystems are properly frozen during suspend.

Over the remote link, Kara raised a potential problem with the proposed mechanism: loopback block devices that are not mounted but just have a file as their storage. Those devices may have dirty data but when that data is flushed, the underlying filesystem will be frozen, because block devices are frozen after filesystems, thus there will be a deadlock. That use case was deemed to be sufficiently rare that it could perhaps be ignored, at least for now.

Since the session, there have been several patch postings, including one from Chamberlain and another from Brauner that incorporates Chamberlain's patches.

Comments (1 posted)

Inline socket-local storage for BPF

Martin Lau gave a talk in the BPF track of the 2025 Linux Storage, Filesystem, Memory-Management, and BPF Summit about a performance problem plaguing the networking subsystem, and some potential ways to fix it. He works on BPF programs that need to store socket-local data; amid other improvements to the networking and BPF subsystems, retrieving that data has become a noticeable bottleneck for his use case. His proposed fix prompted a good deal of discussion about how the data should be laid out.

One day, Lau said, Yonghong Song showed him an instruction-level profile of some kernel code from the networking subsystem. Two instructions in particular were much hotter than it seemed like they should be. In bpf_sk_storage_get() (which looks up socket-local data for a BPF program), the inline function bpf_local_storage_lookup() needs to dereference two pointers in order to retrieve the user data associated with a given socket. As it turns out, both of those pointer indirections were causing expensive cache misses.

The socket-local data storage is laid out like this because the kernel can't know how much space BPF programs will need in their maps ahead of time, and so must be able to dynamically allocate the correct amount. In practice, however, the BPF programs in use at Meta, where Lau works, do not change the layout of their per-socket data frequently. One program hasn't changed the layout at all since 2021.

So what if that data could be stored inline in the socket structure? Specifically, Lau proposed adding a new kernel-configuration parameter for reserving space in the structure. When set to zero, the kernel would keep the current behavior. When set to some non-zero value, allocations of socket-local data from BPF programs could be taken from the reserved space until it fills up, before falling back to the existing path. For Meta, which knows how much storage its BPF programs use per socket, this would allow the kernel to be configured with the appropriate size ahead of time, completely avoiding the double-dereference and cache misses. Reorganizing the storage like this would also allow saving 64 bytes of internal overhead from the BPF map per socket.

One problem with the scheme is that the memory would no longer be visible to per-control-group accounting. Right now, when creating a per-socket BPF map, that memory is charged to the user-space program that created the map, Lau explained. With this proposal, it would count against the kernel instead.

Alexei Starovoitov asked whether the array size really needed to be configured at build time; couldn't the socket structure end with a variable-length array? Lau agreed that it was possible, but thought that it would be complex to handle for all of the different types of socket. After a bit of thought, Starovoitov suggested that this might be a good fit for run-time constants: values that are treated as constants and hard-coded into the kernel's machine code, but that can be patched at boot time. Lau said that he didn't know that was possible, but that it seemed like it could fit.

Another developer asked what would happen if a BPF program reserved space in the inline storage, and was then reloaded by user space — would it get a new allocation (leaving the old allocation as garbage), or reuse the old allocation somehow? Lau thought that still needed to be decided, and asked for ideas.

Andrii Nakryiko wanted to know how much space Lau intended to reserve; "like, kilobytes?" Lau clarified that they needed somewhere around 100 bytes, possibly less if BPF programs could be made to share data that they all need. That allayed some of Nakryiko's concerns, but he still wondered how bad a single pointer indirection would be. What if the socket structure stored a single pointer to a dynamically sized object? Data at the end of the socket structure is unlikely to be in cache anyway, he asserted. Lau disagreed, saying that it depends on how the packet has been processed so far.

That said, one potential benefit of using non-inline storage is the ability to share data between multiple sockets, he said. For some of the BPF programs he worked with, there might only be 500 different values in a given BPF map across 500,000 sockets. If those could be combined, it could decrease cache misses and make non-inline storage less expensive. He didn't think that it would help with the current design, however, since the first dereference would still not be cached.

Song Liu wondered if it would make more sense to compress the data — if there are only 500 variants, it should only need 9 bits. Nakryiko agreed, suggesting that the current data structures could be stored in a separate map, and the socket structures could store a small index into that map. Lau said that he had tried that, and the approach ran into some problems.

Unfortunately, the session also ran into the end of its scheduled time before a design could be pinned down.

Comments (none posted)

Better debugging information for inlined kernel functions

Modern compilers perform a lot of optimizations, which can complicate debugging. Song Liu and Thierry Treyer spoke about a potential improvement to BPF Type Format (BTF) debugging information that could partially combat that problem at the 2025 Linux Storage, Filesystem, Memory-Management, and BPF Summit. They want to add information on selectively inlined functions to BTF in order to better support tracing tools. Treyer participated remotely.

One of the most common compiler optimizations is inlining, which embeds the code of a function directly into its caller, avoiding the overhead of a function call and potentially exposing other hidden optimization opportunities. Modern compilers don't always inline every call to a particular function that would benefit from inlining, however. The compiler uses heuristics to decide which call sites will benefit from inlining. This means that a programmer can easily end up with a situation where a function still appears in a binary's symbol table (because some calls were not inlined), but tracing that function won't show calls to it (because the hot calls were inlined, and therefore the function's symbol no longer referrs to them).

That is a problem, Liu said. Both because it makes debugging harder, but also because it motivates developers to mark important kernel functions as not inlinable, so that they can rely on being able to trace them. It is technically possible to trace selectively inlined functions by finding the inlined locations using DWARF debugging information, which some tracing tools do automatically. DWARF is a bulky, complex format, however, which makes using it for this purpose slow. Other methods, such as tracepoints and Linux security-module hooks, also work with selectively inlined functions. Liu argued that those aren't a proper replacement for normal tracing, however, since when debugging a kernel problem it is often not clear what functions one will want to trace until one is actually working on the problem.

Liu outlined two different options for how to improve this situation: just marking selectively inlined functions in the kernel's BTF, and including information about where they have been inlined. The first option has the benefit of simplicity; it would be easy to add an additional function attribute and convert tools like pahole to handle it. Selectively inlined functions are mostly a problem because of the confusion they cause, Liu said. Just being able to warn the developer about what is happening would help.

The second idea would let other tools more easily match what perf probe does: set breakpoints at every location where a function was inlined, as well as its non-inlined location. perf does this by parsing DWARF; Liu's change would let other tools use BTF for the same purpose.

Tracing an inlined function is not as simple as putting breakpoints in the right place, however. When a function is inlined, arguments and return values can disappear due to other optimizations. BTF would need a way to indicate how to transform the machine state at the callsite to recover the function's arguments.

Liu and Treyer analyzed the kernel's existing debug information to figure out whether this was even possible. Out of 228,000 arguments to inlined functions, across 150,000 different call sites, the location of about 83% can be expressed as an offset from a register, usually because the argument is present on the calling function's stack or passed as a pointer. This analysis doesn't include a handful of the most commonly inlined functions, Liu warned, because those disproportionately skew the numbers.

One audience member asked whether that number was per-argument or per-function. Liu clarified that it was per-argument. The audience member then asked what percentage of functions have only arguments representable in this way. Liu showed a slide indicating that approximately half of the functions he looked at would have all their arguments available using this scheme.

With the knowledge that it was possible, Liu put together a proposal for how to encode information about inlined function arguments in BTF: each parameter would be described by a sequence of operators in a highly restricted virtual machine. Supported operations would include loading constants, dereferencing registers, applying offsets, etc. So, for example, an argument that was stored as a member of a structure pointed to by a register would be represented by something like "load register, add offset, dereference, end". Using Liu and Treyer's prototype implementation, this would add about 10MB to the kernel's BTF, although that number is before performing deduplication, which may help substantially.

A final problem is that BTF only exists for functions that were not fully inlined. Functions that are inlined at every call site are less confusing than selectively inlined functions, but they would be fairly simple to support. Adding those in would add an additional 32,000 functions to the kernel's BTF.

The audience had a number of questions about the design for encoding argument information, mostly focused around how to streamline it and remove redundant information. Alexei Starovoitov said that he thought this approach seemed "inspired by the DWARF state machine", and that they had the opportunity to do something simpler instead. Liu agreed that the proposal was a bit rough, and welcomed suggestions for how to improve it.

Starovoitov also pointed out that the encoding Liu had proposed wouldn't work properly for 16-byte values, of which the kernel uses a fair number. Andrii Nakryiko asked whether the problem was that these values were sometimes stored in a pair of registers, instead of in memory. Starovoitov agreed that was sometimes the case, but outlined a few other edge-cases that small structures could fall into. Liu agreed to look into the encoding of 16-byte values.

Comments (2 posted)

How LWN is faring in 2025

Just over six months ago, The Economist described the US economy as "the envy of the world". That headline would be unlikely to appear now. The economic boom referenced in that article feels like a distant memory, markets are falling, and uncertainty is at an all-time high. Like everybody else, LWN is affected by the current turbulence in the political and economic spheres; we expect to get through this period, but there will be some challenges.

To put it bluntly: starting around the beginning of March, we have observed a distinct drop in both new subscriptions and renewals. That timing roughly corresponds with the US administration's increasing attacks on the global system of trade and the economic downturn that has been its result. As it stands, this subscription drop does not pose an existential threat to LWN — or to the salaries of its writers — but it is a matter of concern.

We are responding by tightening our belt where we can, but otherwise working to provide the best coverage of the Linux and free-software communities, as we always have. Readers can help, of course, by subscribing if they have not already done so. Encouraging your employer to set up a group subscription is especially helpful. Subscriptions are the only thing that has kept LWN operating for all these years.

Beyond the immediate situation, there are a number of potential problems to be concerned about. For example, inflation did not stop after our price increase in 2022, with the result that subscription dollars buy significantly less then they once did. We are not considering a price increase at this time but, if the situation worsens, we may have to go there.

For better or worse, LWN is a US-based company, but a large portion of our subscription sales come from outside the country. If the backlash against US companies grows, we are unlikely to escape its effects entirely. Further attacks on global trade could make it more difficult for us to accept payments from outside the country, even when the buyer is willing. In a truly terrible world, there may be attempts to reduce US participation in (and support for) free software; the probability of that seems low, but not zero.

Those are all future worries, though. For now, we will focus on getting through the current economic storms. The good news is that LWN has been here since 1998, which is long enough to have been through more than one difficult cycle. We are still here, thanks entirely to the steady support from you, our readers. Our subscribers, especially, have our gratitude; if you have not yet subscribed to LWN, please consider doing so now.

Meanwhile our primary focus will remain being worthy of the support you all have given us since the beginning. It is the least we can do for all of you who have made our existence possible for the last 27 years.

Comments (106 posted)

Kernel release status

The current development kernel is 6.15-rc4, released on April 27. Linus said:

So let's see if this rc ends up avoiding any silly issues - things certainly look pretty normal, and there were no hurried last-minute changes this week due to system upgrades.

Stable Updates: 6.14.4, 6.12.25, 6.6.88, and 6.1.135 were released on April 25.

The 6.14.5, 6.12.26, 6.6.89, 6.1.136, 5.15.181, 5.10.237, and 5.4.293 updates are in the review process; they are due on May 1.

Comments (none posted)

Quote of the week

How the fsck did we go from zero hfs/hfsplus maintainers to three in a matter of days? I should threaten to remove more code. It's like tariffs for the kernel.

— Christian Brauner

Comments (1 posted)

Debian Project Leader Election 2025 results

The Debian Project Leader election results have been announced. Andreas Tille has been re-elected and will serve another term through April 2026. LWN looked at the election and candidates in early April.

Comments (none posted)

Signing key change for Kali Linux

The Kali Linux distribution has announced that software updates will soon start failing for all users:

This is not only you, this is for everyone, and this is entirely our fault. We lost access to the signing key of the repository, so we had to create a new one. At the same time, we froze the repository (you might have noticed that there was no update since Friday 18th), so nobody was impacted yet. But we're going to unfreeze the repository this week, and it's now signed with the new key.

The announcement includes instructions for how to recover from the problem.

Comments (18 posted)

OpenBSD 7.7 released

The OpenBSD 7.7 release is available. There is, as usual, a long list of changes; see the full changelog for lots of details.

Comments (none posted)

Distributions quote of the week

Maybe we've been ethical hypocrites all along about machine learning applications packaged in Debian, and the current LLM craze is a good opportunity to clean house and reaffirm a strict free software policy including training data. I'm rather sympathetic to that argument, frankly, just because the simplicity of the "source code for everything, no exceptions" position is comfortable in my brain. But we should be fairly sure about what we're agreeing to before making that decision.

— Russ Allbery

Comments (11 posted)

Barnes: Parallel ./configure

Tavian Barnes takes on the tedious process of waiting for configure scripts to run.

I paid good money for my 24 CPU cores, but ./configure can only manage to use 69% of one of them. As a result, this random project takes about 13.5× longer to configure the build than it does to actually do the build.

The purpose of a ./configure script is basically to run the compiler a bunch of times and check which runs succeeded. In this way it can test whether particular headers, functions, struct fields, etc. exist, which lets people write portable software. This is an embarrassingly parallel problem, but Autoconf can't parallelize it, and neither can CMake, neither can Meson, etc., etc.

(Thanks to Paul Wise).

Comments (42 posted)

Firefox 138.0 released

Version 138.0 of the Firefox web browser has been released. Changes include some profile-management improvements, the ability to get weather-related suggestions in the address bar (US only), and some security fixes.

Comments (3 posted)

GCC 15.1 released

Version 15.1 of the GNU Compiler Collection has been released. Changes include implementing the C23 dialect by default, a number of new C++26 features, experimental support for unsigned integers in Fortran, a new COBOL front end, and more. See the GCC 15 changes page for details.

Comments (12 posted)

Meson 1.8.0 released

Version 1.8.0 of the Meson build system has been released. Notable changes in this release include the ability to run rustdoc for Rust projects, support for the c2y and gnu2y compiler options, and a new argument (android_exe_type) that makes it possible to use the same meson.build file for Android and non-Android systems.

Comments (none posted)

Valgrind-3.25.0 is available

Version 3.25.0 of the Valgrind dynamic-analysis tool has been released. It has lots of new features, including initial support for RISC-V on Linux, handling zstd-compressed debug sections, integration of the Linux Test Project test suite, support for lots more Linux system calls, and more. It also has plenty of bug fixes, of course.

Full Story (comments: none)

The conclusion of the FSF board review

The Free Software Foundation has announced the completion of the review of its board of directors; the process resulted in the reconfirmation of all five sitting board members.

The review examined board members Ian Kelling, Geoffrey Knauth, Henry Poole, Richard Stallman, and Gerald Sussman. The process generated detailed philosophical and policy discussions between board members and the FSF's global associate members on topics ranging from the firmness of the Free Software Definition, developments in machine learning, to the board's president position.

Comments (33 posted)

OSI publishes election retrospective

The Open Source Initiative (OSI) has quietly published "takeaways" from its internal retrospective on the recent board of directors election as an update to the March blog post that announced the new members of the board. The election was controversial, in part, due to poor communication and OSI changing the election rules and disqualifying several candidates after the election finished. LWN covered the election and results in March. The update commits to improvements in communication and candidate selection:

What this election exposed was the need for the organization to also assess whether candidates were fully eligible to run and prepared to be seated on the board before voting begins. This is something we will add to the election timeline next year. While we have not finished figuring out all of the requirements for that assessment, part of it will be asking candidates to sign a Candidate Agreement at nomination time. We also have some ideas on ways for potential candidates to have more information even before submitting a nomination.

In a related note, there is a petition asking OSI to publish the "complete, unaltered" results of the board of directors election. Thanks to Josh Triplett for the tip on the petition.

Comments (19 posted)

LWN's Mastodon migration

The LWN.net fediverse (Mastodon) feed has moved; we are now known as @LWN@lwn.net. The migration magic has shifted many of our followers over automatically but, if you follow that stream, you might want to make sure that you have shifted to the new source.

Comments (16 posted)

Albertson: Future of OSL in Jeopardy

Lance Albertson writes that the Oregon State University Open Source Lab, the home of many prominent free-software projects over the years, has run into financial trouble:

I am writing to inform you about a critical and time-sensitive situation facing the Open Source Lab. Over the past several years, we have been operating at a deficit due to a decline in corporate donations. While OSU's College of Engineering (CoE) has generously filled this gap, recent changes in university funding have led to a significant reduction in CoE's budget. As a result, our current funding model is no longer sustainable and CoE needs to find ways to cut programs.

Earlier this week, I was informed that unless we secure $250,000 in committed funds, the OSL will be forced to shut down later this year.

Comments (none posted)

CFP Deadlines: May 1, 2025 to June 30, 2025

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

Deadline	Event Dates	Event	Location
May 6	August 28 August 29	Linux Security Summit Europe	Amsterdam, Netherlands
May 22	July 14 July 20	DebConf 2025	Brest, France
May 23	August 16 August 17	Free and Open Source Software Conference	Sankt Augustin, Germany
May 23	September 8	Workshop on eBPF and kernel extensions (colocated with ACM SIGCOMM)	Coimbra, Portugal
June 13	September 30 October 1	All Systems Go! 2025	Berlin, Germany
June 13	October 17 October 19	OpenInfra Summit Europe 2025	Paris-Saclay, France
June 15	November 7 November 8	Seattle GNU/Linux Conference	Seattle, US
June 20	August 29 August 31	openSUSE.Asia Summit	Faridabad, India
June 22	December 10 December 11	Open Source Experience 2025	Paris, France

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

Events: May 1, 2025 to June 30, 2025

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

Date(s)	Event	Location
April 30 May 5	MiniDebConf Hamburg	Hamburg, Germany
May 8 May 9	PostgreSQL Conference Germany	Berlin, Germany
May 12 May 15	Risc-V Summit Europe	Paris, France
May 13 May 17	RustWeek / RustNL 2025	Utrecht, The Netherlands
May 13 May 16	PGConf.dev	Montreal, Canada
May 14 May 16	Linaro Connect Lisbon 2025	Lisbon, Portugal
May 14 May 16	Embedded Recipes	Nice, France
May 16 May 18	Debian MountainCamp	Innsbruck, Austria
May 16 May 18	PyCon US 2024	Pittsburgh, Pennsylvania, US
May 22	NLUUG Spring Conference 2025	Utrecht, The Netherlands
May 24 May 25	Journées du Logiciel Libre	Lyon, France
June 5 June 8	Flock to Fedora 2025	Prague, Czech Republic
June 12 June 14	DevConf.CZ	Brno, Czech Republic
June 13 June 15	SouthEast LinuxFest	Charlotte, NC, US
June 15 June 17	Berlin Buzzwords	Berlin, Germany
June 23 June 25	Open Source Summit North America	Denver, CO, US
June 26 June 27	Linux Security Summit North America	Denver, CO, US
June 26 June 28	Linux Audio Conference	Lyon, France
June 26 June 28	openSUSE Conference	Nuremberg, Germany

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

Alert summary April 24, 2025 to April 30, 2025

Dist.	ID	Release	Package	Date
AlmaLinux	ALSA-2025:4244	9	glibc	2025-04-28
AlmaLinux	ALSA-2025:4263	9	php:8.1	2025-04-29
AlmaLinux	ALSA-2025:4170	8	thunderbird	2025-04-25
AlmaLinux	ALSA-2025:4169	9	thunderbird	2025-04-25
AlmaLinux	ALSA-2025:4229	9	thunderbird	2025-04-28
Debian	DLA-4138-1	LTS	distro-info-data	2025-04-26
Debian	DLA-4143-1	LTS	glibc	2025-04-30
Debian	DLA-4135-1	LTS	haproxy	2025-04-23
Debian	DLA-4139-1	LTS	imagemagick	2025-04-26
Debian	DSA-5907-1	stable	kernel	2025-04-27
Debian	DLA-4137-1	LTS	libbpf	2025-04-24
Debian	DLA-4142-1	LTS	libraw	2025-04-29
Debian	DSA-5908-1	stable	libreoffice	2025-04-28
Debian	DLA-4140-1	LTS	libsoup2.4	2025-04-27
Debian	DLA-4136-1	LTS	openrazer	2025-04-24
Debian	DLA-4141-1	LTS	poppler	2025-04-28
Fedora	FEDORA-2025-9ba0ebe67a	F40	ImageMagick	2025-04-25
Fedora	FEDORA-2025-e2287efebb	F41	ImageMagick	2025-04-25
Fedora	FEDORA-2025-942a0d7e5d	F40	c-ares	2025-04-24
Fedora	FEDORA-2025-4518c12e2f	F42	caddy	2025-04-29
Fedora	FEDORA-2025-3e26fc9217	F40	chromium	2025-04-26
Fedora	FEDORA-2025-9ea1ed1fcf	F41	chromium	2025-04-27
Fedora	FEDORA-2025-ca9bc14500	F42	chromium	2025-04-26
Fedora	FEDORA-2025-97687e7f68	F40	digikam	2025-04-30
Fedora	FEDORA-2025-5bbbb2df79	F41	digikam	2025-04-30
Fedora	FEDORA-2025-1c1e378468	F42	digikam	2025-04-29
Fedora	FEDORA-2025-2280949271	F40	golang-github-openprinting-ipp-usb	2025-04-25
Fedora	FEDORA-2025-bca38111fc	F40	icecat	2025-04-30
Fedora	FEDORA-2025-883816b756	F41	icecat	2025-04-30
Fedora	FEDORA-2025-17f64d2c4d	F42	icecat	2025-04-29
Fedora	FEDORA-2025-b6323169bc	F40	java-1.8.0-openjdk	2025-04-27
Fedora	FEDORA-2025-e81dbae527	F41	java-1.8.0-openjdk	2025-04-27
Fedora	FEDORA-2025-5c15947cd4	F41	java-1.8.0-openjdk-portable	2025-04-27
Fedora	FEDORA-2025-22226bdb44	F41	java-17-openjdk	2025-04-27
Fedora	FEDORA-2025-5c15947cd4	F41	java-17-openjdk-portable	2025-04-27
Fedora	FEDORA-2025-186e31ca40	F40	java-latest-openjdk	2025-04-27
Fedora	FEDORA-2025-aad560ca4b	F41	java-latest-openjdk	2025-04-27
Fedora	FEDORA-2025-687b2b4011	F42	java-latest-openjdk	2025-04-27
Fedora	FEDORA-2025-32a9eb17af	F40	mingw-LibRaw	2025-04-30
Fedora	FEDORA-2025-e7dea91428	F41	mingw-LibRaw	2025-04-30
Fedora	FEDORA-2025-caed275f11	F42	mingw-LibRaw	2025-04-29
Fedora	FEDORA-2025-67e824b908	F40	mingw-libsoup	2025-04-25
Fedora	FEDORA-2025-bd12d23d21	F41	mingw-libsoup	2025-04-25
Fedora	FEDORA-2025-c4605302b8	F42	mingw-libsoup	2025-04-25
Fedora	FEDORA-2025-bce8e14ac6	F40	mingw-poppler	2025-04-24
Fedora	FEDORA-2025-5e9faa5173	F41	mingw-poppler	2025-04-24
Fedora	FEDORA-2025-67d2e84a2b	F42	mingw-poppler	2025-04-24
Fedora	FEDORA-2025-8445f115f6	F40	perl-Devel-Cover	2025-04-30
Fedora	FEDORA-2025-8445f115f6	F40	perl	2025-04-30
Fedora	FEDORA-2025-8445f115f6	F40	perl-PAR-Packer	2025-04-30
Fedora	FEDORA-2025-49d6f62c0e	F41	pgadmin4	2025-04-27
Fedora	FEDORA-2025-31397c2b6c	F40	pgbouncer	2025-04-25
Fedora	FEDORA-2025-d919f11f99	F41	pgbouncer	2025-04-25
Fedora	FEDORA-2025-25e04398c7	F42	pgbouncer	2025-04-25
Fedora	FEDORA-2025-fd8eb9ca57	F40	thunderbird	2025-04-27
Fedora	FEDORA-2025-7f00e5e744	F42	xz	2025-04-26
Mageia	MGASA-2025-0140	9	chromium-browser-stable	2025-04-28
Mageia	MGASA-2025-0138	9	haproxy	2025-04-25
Mageia	MGASA-2025-0139	9	libxml2	2025-04-25
Oracle	ELSA-2025-4043	OL8	bluez	2025-04-25
Oracle	ELSA-2025-3628	OL7	firefox	2025-04-25
Oracle	ELSA-2025-4051	OL8	gnutls	2025-04-25
Oracle	ELSA-2025-4049	OL8	libtasn1	2025-04-25
Oracle	ELSA-2025-4025	OL9	libxslt	2025-04-25
Oracle	ELSA-2025-3997	OL8	mod_auth_openidc:2.3	2025-04-25
Oracle	ELSA-2025-4063	OL8	ruby:3.1	2025-04-25
Oracle	ELSA-2025-4170	OL8	thunderbird	2025-04-25
Oracle	ELSA-2025-4169	OL9	thunderbird	2025-04-25
Oracle	ELSA-2025-4048	OL8	xmlrpc-c	2025-04-25
Red Hat	RHSA-2025:3773-01	EL9	delve and golang	2025-04-28
Red Hat	RHSA-2025:4362-01	EL8	ghostscript	2025-04-30
Red Hat	RHSA-2025:3828-01	EL8	glibc	2025-04-28
Red Hat	RHSA-2025:4244-01	EL9	glibc	2025-04-28
Red Hat	RHSA-2025:4242-01	EL9.0	glibc	2025-04-28
Red Hat	RHSA-2025:4241-01	EL9.2	glibc	2025-04-28
Red Hat	RHSA-2025:4243-01	EL9.4	glibc	2025-04-28
Red Hat	RHSA-2025:4341-01	EL9	kernel	2025-04-30
Red Hat	RHSA-2025:4339-01	EL9.2	kernel	2025-04-30
Red Hat	RHSA-2025:4340-01	EL9.2	kernel-rt	2025-04-30
Red Hat	RHSA-2025:4225-01	EL9.2	mod_auth_openidc	2025-04-28
Red Hat	RHSA-2025:4224-01	EL9.4	mod_auth_openidc	2025-04-28
Red Hat	RHSA-2025:3997-01	EL8	mod_auth_openidc:2.3	2025-04-28
Red Hat	RHSA-2025:4228-01	EL8.2	mod_auth_openidc:2.3	2025-04-28
Red Hat	RHSA-2025:4227-01	EL8.4	mod_auth_openidc:2.3	2025-04-28
Red Hat	RHSA-2025:4192-01	EL8.6	mod_auth_openidc:2.3	2025-04-28
Red Hat	RHSA-2025:4263-01	EL9	php:8.1	2025-04-28
Red Hat	RHSA-2025:4170-01	EL8	thunderbird	2025-04-24
Red Hat	RHSA-2025:4169-01	EL9	thunderbird	2025-04-24
Red Hat	RHSA-2025:4229-01	EL9	thunderbird	2025-04-28
Red Hat	RHSA-2025:4026-01	EL9.4	thunderbird	2025-04-24
Slackware	SSA:2025-119-02		mozilla	2025-04-29
Slackware	SSA:2025-119-01		mozilla	2025-04-29
SUSE	SUSE-SU-2025:1413-1	SLE-m5.3 SLE-m5.4 SLE-m5.5 oS15.4	augeas	2025-04-30
SUSE	openSUSE-SU-2025:15021-1	TW	augeas	2025-04-25
SUSE	openSUSE-SU-2025:15027-1	TW	chromedriver	2025-04-26
SUSE	SUSE-SU-2025:1381-1	SLE15 SLE-m5.3 SLE-m5.4 SLE-m5.5 oS15.4 oS15.6	cifs-utils	2025-04-28
SUSE	openSUSE-SU-2025:15011-1	TW	epiphany	2025-04-23
SUSE	openSUSE-SU-2025:15012-1	TW	ffmpeg-6	2025-04-23
SUSE	SUSE-SU-2025:1414-1	SLE12	firefox	2025-04-30
SUSE	SUSE-SU-2025:1367-1	SLE15 oS15.6	glib2	2025-04-24
SUSE	openSUSE-SU-2025:15036-1	TW	glow	2025-04-28
SUSE	openSUSE-SU-2025:15013-1	TW	gopass	2025-04-23
SUSE	SUSE-SU-2025:1370-1	SLE15 oS15.6	govulncheck-vulndb	2025-04-25
SUSE	openSUSE-SU-2025:15017-1	TW	govulncheck-vulndb	2025-04-24
SUSE	openSUSE-SU-2025:15033-1	TW	govulncheck-vulndb	2025-04-27
SUSE	SUSE-SU-2025:1399-1	SLE12	java-11-openjdk	2025-04-29
SUSE	openSUSE-SU-2025:15022-1	TW	java-11-openjdk	2025-04-25
SUSE	openSUSE-SU-2025:15024-1	TW	java-21-openjdk	2025-04-25
SUSE	openSUSE-SU-2025:15029-1	TW	kyverno	2025-04-26
SUSE	SUSE-SU-2025:1380-1	SLE12	libraw	2025-04-28
SUSE	openSUSE-SU-2025:15018-1	TW	libsoup-2_4-1	2025-04-24
SUSE	openSUSE-SU-2025:15015-1	TW	libsoup-3_0-0	2025-04-23
SUSE	openSUSE-SU-2025:15019-1	TW	libxml2-2	2025-04-24
SUSE	SUSE-SU-2025:1365-1	SLE15 SLE-m5.1 SLE-m5.2 SLE-m5.3 SLE-m5.4 oS15.6	mozjs60	2025-04-24
SUSE	openSUSE-SU-2025:15030-1	TW	opentofu	2025-04-26
SUSE	SUSE-SU-2025:1369-1	MP4.3 SLE15 SES7.1 oS15.6	ruby2.5	2025-04-24
SUSE	SUSE-SU-2025:1374-1	SLE12	runc	2025-04-25
SUSE	openSUSE-SU-2025:15034-1	TW	subfinder	2025-04-27
SUSE	SUSE-SU-2025:1366-1	SLE15 oS15.6	thunderbird	2025-04-24
SUSE	openSUSE-SU-2025:15035-1	TW	valkey	2025-04-27
Ubuntu	USN-7423-2	16.04 18.04	binutils	2025-04-29
Ubuntu	USN-7443-2	25.04	erlang	2025-04-23
Ubuntu	USN-7431-2	25.04	haproxy	2025-04-23
Ubuntu	USN-7464-1	22.04 24.04 24.10 25.04	jupyter-notebook	2025-04-28
Ubuntu	USN-7466-1	18.04 20.04	kicad	2025-04-28
Ubuntu	USN-7446-1	22.04 24.04 24.10 25.04	libapache2-mod-auth-openidc	2025-04-23
Ubuntu	USN-7454-1	20.04 22.04 24.04 24.10 25.04	libarchive	2025-04-23
Ubuntu	USN-7467-2	16.04 18.04	libxml2	2025-04-29
Ubuntu	USN-7467-1	20.04 22.04 24.04 24.10 25.04	libxml2	2025-04-28
Ubuntu	USN-7455-1	20.04 22.04	linux, linux-aws, linux-azure, linux-azure-5.15, linux-azure-fde, linux-azure-fde-5.15, linux-gcp, linux-gke, linux-gkeop, linux-hwe-5.15, linux-ibm, linux-intel-iotg, linux-kvm, linux-lowlatency, linux-lowlatency-hwe-5.15, linux-nvidia, linux-nvidia-tegra, linux-nvidia-tegra-igx, linux-oracle, linux-raspi	2025-04-24
Ubuntu	USN-7449-1	22.04 24.04	linux, linux-aws, linux-azure, linux-azure-6.8, linux-ibm, linux-lowlatency, linux-lowlatency-hwe-6.8, linux-nvidia, linux-nvidia-6.8, linux-nvidia-lowlatency, linux-oem-6.8, linux-oracle, linux-oracle-6.8	2025-04-23
Ubuntu	USN-7461-1	18.04 20.04	linux, linux-azure, linux-azure-5.4, linux-bluefield, linux-gcp, linux-hwe-5.4, linux-ibm, linux-kvm, linux-oracle, linux-oracle-5.4	2025-04-24
Ubuntu	USN-7462-1	18.04 20.04	linux-aws, linux-aws-5.4, linux-gcp-5.4, linux-iot	2025-04-24
Ubuntu	USN-7455-5	20.04	linux-aws-5.15	2025-04-29
Ubuntu	USN-7451-1	22.04	linux-aws-6.8	2025-04-23
Ubuntu	USN-7455-2	22.04	linux-aws-fips, linux-fips, linux-gcp-fips	2025-04-24
Ubuntu	USN-7462-2	20.04	linux-aws-fips	2025-04-24
Ubuntu	USN-7461-2	20.04	linux-azure-fips, linux-fips, linux-gcp-fips	2025-04-24
Ubuntu	USN-7460-1	22.04	linux-azure-fips	2025-04-24
Ubuntu	USN-7468-1	24.04	linux-azure-nvidia	2025-04-28
Ubuntu	USN-7450-1	24.04	linux-gcp, linux-gke, linux-gkeop	2025-04-23
Ubuntu	USN-7459-2	20.04	linux-gcp-5.15	2025-04-28
Ubuntu	USN-7452-1	22.04	linux-gcp-6.8	2025-04-23
Ubuntu	USN-7449-2	22.04	linux-hwe-6.8	2025-04-24
Ubuntu	USN-7458-1	20.04	linux-ibm-5.15	2025-04-24
Ubuntu	USN-7463-1	18.04	linux-ibm-5.4	2025-04-24
Ubuntu	USN-7455-3	22.04	linux-intel-iot-realtime, linux-realtime	2025-04-24
Ubuntu	USN-7459-1	20.04	linux-intel-iotg-5.15	2025-04-24
Ubuntu	USN-7455-4	20.04	linux-oracle-5.15	2025-04-25
Ubuntu	USN-7453-1	24.04	linux-realtime	2025-04-23
Ubuntu	USN-7465-1	16.04 18.04	mistral, python-mistral-lib	2025-04-28
Ubuntu	USN-7469-3	18.04 20.04 22.04	nodejs	2025-04-29
Ubuntu	USN-7457-1	20.04 22.04 24.04 24.10 25.04	openssh	2025-04-24
Ubuntu	USN-7434-2	25.04	perl	2025-04-23
Ubuntu	USN-7456-1	20.04 22.04 24.04	php-twig	2025-04-24
Ubuntu	USN-7469-2	18.04	tomcat8	2025-04-28
Ubuntu	USN-7469-1	20.04 22.04	trafficserver	2025-04-28
Ubuntu	USN-7447-1	20.04 22.04 24.04 24.10 25.04	yelp, yelp-xsl	2025-04-23

Full Story (comments: none)