|
|
Log in / Subscribe / Register

LWN.net Weekly Edition for July 2, 2026

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

This edition contains the following feature content:

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)

Xsnow "protestware" in Debian

By Joe Brockmeier
June 29, 2026

The xsnow application, which generates an animated snowfall effect (and other pleasant diversions) for X11 desktops, does not seem like an obvious channel for political statements. Nevertheless, xsnow's maintainer seems to have included a political protest in the program: an Easter egg that is triggered when the program's language is set to Russia ("ru"). One user has complained that this functionality should be removed from the Debian xsnow package, but Debian does not seem to have any rules that forbid such a feature outright.

The complaint

On June 14, Alexander Ivanov sent a message to Debian's development list to complain that if a user's language settings were set to Russian, it would trigger "a disguised visual element (Ukrainian flags labeled as 'EXTRATREE') with a significantly higher probability". The code is found in the src/scenery.c file beginning on line 326 in xsnow 3.8.3, the version packaged for Debian 13 ("trixie") and in 3.8.6, which is in unstable:

    #ifdef USE_EXTRATREE
          if (global.Language && !strcmp(global.Language,"ru") && drand48() < 0.3)
	     tt = MAXTREETYPE;
          if (drand48() < 0.02)
	     tt = MAXTREETYPE;
    #endif

Xsnow is more likely to display Ukrainian flags (src/Pixmaps/extratree.xpm) if the language is set to Russian. Xsnow allows users to pick from one of several languages; when the application was set to English, I did not see any Ukrainian flags but they should pop up about 2% of the time. I did see the expected decorations such as a moon, snow, trees, polar bears, birds, and Santa with his sleigh. After I changed the language setting to Russian, xsnow immediately placed several flags on the desktop along with the other decorations. The screenshot below shows what this looks like on Debian 13.

[xsnow running on Debian Trixie]

DFSG violation

Ivanov claimed that the behavior violated the Debian Free Software Guidelines (DFSG) that are part of the project's Social Contract. Specifically, he said that the "targeted behavior" violated the principles of no discrimination against persons or groups (DFSG #5) and no discrimination against fields of endeavor (DFSG #6).

Ivanov had not filed a bug, but was, instead reporting the problem to "the wider Debian development community". He said he took that route because the maintainer of the Debian package, Willem Vermin, is also the maintainer of the xsnow project and had been the one to introduce the change in the first place.

Chris Hofstaedtler replied that Ivanov was mistaken; the DFSG does not require that the software is non-discriminatory, but that the license for the software is. "The licenses in use do not appear to violate the DFSG's points 5 or 6. Please read the DFSG carefully next time." Xsnow is primarily licensed under the GPLv3, though some files carry other Debian-approved licenses.

Russ Allbery agreed that the DFSG was not relevant; he also warned that citing the Social Contract and DFSG "turns the conversation into rules lawyering without addressing the actual issue". However, even though xsnow is DFSG-compliant, he did say that the flag display may be something Debian does not want in its archives:

I would, in general, say that software that behaves in deceptive ways, which includes hidden behavior changes based on usernames, locales, or other local settings or information that no user would reasonably expect to change behavior in this way is probably not something that we want to have in Debian. It's a very slippery slope and also likely to create a lot of drama to very little benefit.

Ivanov said that he understood the point that xsnow did not violate the DFSG. But, he asked, shouldn't its hidden functionality be treated as a bug or behavior that should be patched out "to restore the application's neutral and intended functionality for all users equally?" Bill Allombert suggested that he open a bug report, since the Debian development list was not the correct venue for the complaint.

Forecast calls for no xsnow changes

To date, Ivanov has not opened a bug report, and the conversation seems to have run its course. I have emailed Vermin to ask if he was aware of the complaint, and if he would be willing to roll back the Ukrainian flag display if a bug were filed. So far, I have not received a response.

Even though Vermin may not want to change xsnow's behavior, Debian package maintainers have been required to make changes for technical reasons—or have had packages removed from the archive for offensive content. In August 2025, two "offensive" fortune packages were removed ahead of the trixie release following a lengthy discussion. In October 2025, Debian's Technical Committee decided that an upstream systemd change would need to be reverted because the new behavior broke a number of programs that depended on a world-writable /run/lock directory. In each case, there was a fair bit of discussion and deliberation before the maintainers were overridden.

This is not to argue one way or the other whether xsnow's Easter egg should be removed; it is simply worth pointing out that it is not futile to file a bug against a package even if it's likely that the maintainer will disagree. As a project, Debian gives its developers a wide latitude in how they manage their packages, but a packager's decisions can be overridden on the rare occasions when the project deems it necessary. Convincing the project to do so, however, requires the petitioner to put in the work. Merely complaining on the mailing list is unlikely to achieve any results.

Comments (122 posted)

What's coming in Git 2.55

By Jonathan Corbet
June 26, 2026
The Git v2.55.0-rc2 testing release appeared on June 23, suggesting that the final Git 2.55 release can be expected in the near future. While this Git update lacks radical new features, it does include a number of improvements that regular Git users will appreciate, including commands to easily edit the commit history, more formatting options, fsmonitor support for Linux, and more.

The current release, v2.54, added an experimental "git history" command. It is, in many ways, like "git rebase", in that it allows the rewriting of commits in the history, but there are some significant differences, mostly aimed at making rebasing a bit less of a fraught operation. It can work on bare repositories, which may be of use to some people. Perhaps more widely useful is "git history reword", which makes it easy to edit the changelog of a past commit with a single command.

There is one aspect of how "git history" behaves that is worthy of note: unlike "git rebase", it will cause the rebasing of all local branches that descend from the modified commit, not just the current branch. That is likely to be what is wanted most of the time, but it has the potential to generate surprises if one is experimenting with it on a throwaway branch. I have, of course, simply understood that this could happen from my perusing of the source, and would never have actually unintentionally changed an important branch by playing around in this way. The "--update-refs=head" option can be used to restrict the rebase to the current branch only.

Anyway, "git history" is still marked as being experimental, but it is also gaining more features; new to 2.55 is "git history fixup". It can be thought of as a variant of "git history reword" that changes the body of the commit rather than the changelog. If a given commit (let's call it abcdef01) made a change to a file (call it foo.c), but neglected to update a comment, one can always repair the situation later with git rebase. But an alternative is to simply edit foo.c to make the desired change, then: 

    git add foo.c
    git history fixup abcdef01

The indicated commit will be amended with the changes to foo.c, and all branches descending from it will be rebased on top of the new version. The changelog of the affected commit will not be modified unless the "--reedit-message" option is provided. If, however, merge conflicts arise during the rebasing, the command simply aborts.

Other additions include the "git format-rev" command, which reads one or more commit IDs and formats them using a provided "pretty" string. This example from the man page: 

    git last-modified -- <files> | git format-rev --stdin-mode=text --format=%an

Will print the name of the developer who last modified each of the given files.

The Git "fsmonitor" is a daemon process that watches the current directory and makes a note of changes made there. Various Git subcommands, such as "git status", can query the fsmonitor daemon rather than scanning through the directory for changed files. On systems where filesystem access is slow and repositories are big, using the fsmonitor daemon can significantly speed things up. This feature has been unavailable for Linux systems — until now. As of 2.55, the fsmonitor daemon has a Linux implementation as well.

The "git push" subcommand can now push changes to a "remote group", which is just a list of independent remotes. Groups are defined in the Git configuration file; a command like: 

    git config remotes.new-remote "remote1 remote2"

Would create a group named new-remote. A subsequent: 

    git push new-remote

Will push to both remote1 and remote2.

Other changes of note in this release include:

  • Git hooks that are set up via the configuration system can now be set up to run in parallel, speeding execution overall.
  • More Lisp dialects are understood by the diff generator.
  • The "git url-parse" subcommand can be used to split out the components of a URL; this is useful because Git has a number of special additions to the URL format that other URL parsers do not understand.
  • The "--max-count-oldest" option to "git rev-list" and "git log" can be used to request the N oldest commits within the specified range.

Beyond that, of course, there have been many performance optimizations, various minor tweaks, and a long list of bug fixes. As of this writing, this release has 486 non-merge commits overall, and appears to have stabilized. The 2.55 release can thus be expected soon, and the Git community will move on to the 2.56 development cycle.

Comments (2 posted)

Flexible metaprogramming with Rhombus

By Daroc Alden
June 30, 2026

Lisp-like languages have historically led the world in metaprogramming and flexibility. While many modern languages have adopted the idea of macros, Lisp-like languages such as Racket have continued pushing the envelope, attempting to make macros as easy as possible to incorporate into everyday programs. On the other hand, Lisp's minimal, parenthesis-based syntax can be hard to adapt to — to the point that Lisp is sometimes said to stand for "Lots of Irritating Silly Parentheses". Rhombus is a new programming language that aims to have the best of both worlds, marrying Racket's metaprogramming capabilities to a simple Python-like syntax and reasonable standard-library defaults.

The project

The language is part of the broader Racket project, which is "rooted in academia". Of Rhombus's 43 contributors, the two most active are Matthew Flatt and Wing Hei Chan, of the University of Utah and the Chinese University of Hong Kong, respectively. Rhombus is used as a teaching tool at both of their universities the University of Utah; Chan contributes to Rhombus independently, and doesn't actually work in the Chinese University of Hong Kong's computer-science department. Despite that, the language aims to be more than just an academic exercise. Development is supported by the Racket Programming Language Foundation, which seeks to make Racket and Rhombus suitable for real-world professional use. Even though the language only celebrated its 1.0 release on June 22, there is already a set of tools for the Economancy card game partially written in it, among other non-academic uses.

The core of Rhombus is available under either the MIT or Apache 2.0 license, although it is built on top of the Racket runtime, which includes LGPL 3.0 code in some dynamic libraries. That reuse of much of Racket's infrastructure means that it already has a large number of usable libraries, and an optimizing compiler. Rhombus programs can be interpreted, compiled to bytecode, or compiled to native machine code.

One place that Rhombus differs from Racket, other than its syntax, is in its choice of default data structures. Lisp-like languages often use singly linked lists as a core data type, which comes with efficiency problems. Rhombus uses lists backed by an immutable tree structure that makes many operations take logarithmic time. Flat, mutable arrays, tree-based maps and sets, and hash-based maps and sets are also available in the standard library.

The syntax

Rhombus's syntax is fairly similar to Python in that it is indentation-based, and uses ":" to indicate the start of an indented block. One slight difference is that Rhombus uses the "|" symbol to separate branches in if expressions and similar contexts. The clearest way to explain is probably with an example (an implementation of the factorial function): 

    fun factorial(n):
      if n <= 1
      | 1
      | n * factorial(n - 1)

Programmers with a more imperative bent might prefer the version below that uses a for loop. Note the use of an inclusive range, 1..=n rather than the more common exclusive range 1..n. 

    fun factorial(n):
      def mutable p = 1
      for (i in 1..=n):
        p := p*i
      p

By default, variables are immutable, so the mutable binding operator is needed to let the loop alter the value of p. The example can be made shorter, however. Rhombus's for loops support a feature that is uncommon outside of Lisp-like languages: an optional "reducer" that is used to combine the result of each loop into a final value for the loop itself. The math.product reducer multiplies all of the values returned from the loop, allowing one to write: 

    fun factorial(n):
      for math.product (i in 1..=n):
        i

This ability means that Rhombus's equivalent of the list comprehensions found in other languages is just a for loop that uses the List reducer to collect results into a list. For loops can also produce maps, sets, or even boolean values using the all or any reducers. In a typical programming language, one might expect this kind of built-in syntax to work for the types provided by the standard library, but not for user-defined types. Rhombus's macros, however, can be used to extend more or less any part of the language, including creating new reducers. Most programs will probably not need to do so, but it is nice to have the option when it would make the program simpler.

Macros

Macros in Rhombus use single quotes to produce syntax objects that represent a fragment of Rhombus code, with "$" used to indicate placeholders. Unlike traditional Lisp-like languages that represent code with lists, Rhombus's syntax objects are their own data type. This lets them carry additional metadata such as line number and position, which in turn lets Rhombus produce helpful error messages, such as stack traces that take macros into account correctly. Syntax objects also carry metadata that controls how names are resolved, giving programmers control over when and how macros capture names from the environment. Both hygienic and non-hygienic macros are possible to write, although hygienic macros are the default.

As an example of a small macro, here is all of the code needed to implement Ruby's postfix if in terms of the built-in when macro: 

    import:
      rhombus/meta open // Needed for defining a macro

    expr.macro '$action if $test':
      'when $test
       | $action'

    println("Hi!") if (foo == bar)

In some ways, this kind of syntax object is reminiscent of the approach that TemplateHaskell uses. Unlike TemplateHaskell, however, Rhombus macros can be defined anywhere that a normal function could be, and respond to the grammatical context in which they are used. The example above is a macro that can be used anywhere that an expression is expected. Reducer macros are defined with reducer.macro, and there are similar constructs for macros that customize the handling of imports, pattern matches, and so on.

One might expect that the list of grammatical contexts in which macros can operate to be fixed. That isn't true in Rhombus, which exposes functions for manipulating grammatical contexts to the user. As long as the program uses Rhombus's basic indentation-based syntax, the programmer is free to define their own grammar and kinds of expressions, should they think it necessary.

Other forms of extension

Another example of that kind of flexibility is Rhombus's approach to type checking. Rhombus is, in some sense, not a statically typed language. It can look like it is, though, if one adds type annotations: 

    fun factorial(n :: Int) :: Int:
      def mutable p :: Int = 1
      for (i in 1..=n):
        p := p*i
      p

    // Calling factorial("foo") results in an error message:
    // factorial: argument does not satisfy annotation
    //  argument: "foo"
    //  annotation: Int

Rhombus allows programmers to attach arbitrary static information to expressions, and define rules for how that static information should be inferred, extended, checked, and used to generate machine code. By default, the language treats annotations as part of a gradual type system that infers types as much as possible, and then uses that to provide error messages and generate better machine code. But there is nothing stopping the programmer from attaching their own classes of static information to Rhombus programs. For example, it is possible to define a system of annotations for tracking the flow of sensitive data through a program, or for tracking the asymptotic run-time of a function. Macros can access this static information in order to compile expressions differently depending on the inferred value.

Rhombus's tendency to expose all of the implementation details of the language within the language itself is part of the project's commitment to language-oriented programming. For many tasks, users will have no need to reach for macros; the ordinary tools provided by the language are sufficient for every-day use. For those tasks where Rhombus is not already a good fit, for whatever reason, the language encourages the creation of miniature embedded domain-specific languages, to make expressing the core logic of the problem as simple as possible.

In many languages, a certain amount of boilerplate is necessary, especially for programs that are best described in terms of data structures or relationships that aren't supported as part of the standard library. Rhombus allows programmers to write that boilerplate once, in a macro, and then focus on expressing their program in whatever way makes the most sense to them, even when that requires looking deep into the semantics of loops or the action of the type system. Many such miniature language extensions can coexist within the same program, and the additional metadata attached to syntax objects allows for the creation of generic code formatters and highlighters, jump-to-definition support that handles custom binding macros, and the other conveniences expected of a modern language.

In support of its extensibility, Rhombus has extensive documentation covering all parts of the language, from parsing all of the way through to compilation. Rhombus inherits the Racket community's penchant for thorough documentation, which is a blessing when one needs to investigate the details of some part of the language, but which can be a bit verbose when one just needs a simple overview.

Rhombus's niche

Overall, Rhombus's best features are definitely its extensibility and documentation. In other areas such as compilation speed, speed of execution, package ecosystem, error messages, and so on it is solidly middle-of-the-road: good enough not to get in the way, but not so good that it outshines existing languages that focus on those areas. Rhombus code, even with full type annotations, is unlikely to challenge C or Rust in speed, for example — it typically has performance between JavaScript and Ruby, although the details vary between programs and benchmarking setups.

Where Rhombus is likely to be most useful is in those problem domains that have custom home-grown languages or that are awkward to express with existing approaches. Programmers have always had the ability to write new special-purpose programming languages, but the amount of work that goes into writing a traditional optimizing compiler is enormous. Writing a set of Rhombus macros is much easier, and gives one an existing compiler, existing libraries, usable syntax highlighting, error messages, and editor integration for free, while preserving the ability to customize the operation of the language at the deepest levels, should it prove necessary.

Comments (13 posted)

Hardening the kernel with allocation tokens and bootpatch-SLR

By Jonathan Corbet
June 25, 2026
There is a lot of work going into eliminating exploitable bugs from the kernel and preventing the addition of new ones. Even if this work is maximally successful, though, there is no chance that the kernel will be free of these bugs anytime soon. Thus, there is also ongoing interest in hardening the kernel to make the existing bugs more difficult to exploit. The upcoming 7.2 kernel release will include a change to how dynamically allocated structures are placed in memory to make them harder to overwrite, while a project to randomize structure layout at boot time has a rather longer timeline.

Memory partitioning with allocation tokens

The kernel's slab allocator handles memory management for small objects. Allocations come from buckets of fixed-size (mostly powers of two) objects, and many types of objects with the same bucket size can be allocated from the same slab. This arrangement allows efficient use of memory, but the intermingling of object types in this way can make the kernel more vulnerable to certain types of exploits. If the kernel can be convinced to overrun an object of a given type, it may end up accessing or corrupting other objects with entirely unrelated types. Additionally, heap-spraying attacks may be used to fill much of the kernel's memory space with known data, which can make other sorts of bugs (such as an erroneous pointer dereference) easier to exploit.

Back in 2023, a set of patches was merged in an attempt to harden the kernel against such attacks; this mechanism works by partitioning the memory used by the slab allocator to satisfy requests. Rather than use one set of slabs to provide (for example) 64-byte memory chunks, the allocator uses sixteen of them. The specific slab used for any given request is chosen randomly, but in such a way that the same slab is always used for allocations made at the same call site. In this way, the ability to fill memory with techniques like heap spraying is much reduced. The ability to overwrite a targeted object with a buffer overflow is also reduced; most object types will be located in distant slabs, and the specific mix of object types in any given slab will differ from one boot to the next.

Partitioning that is randomized in this way makes many attacks harder, but it is a probabilistic defense. It may separate a target object from the vulnerable object most of the time, but it will still put them into the same slab one boot out of sixteen. In multi-system cloud deployments, some systems will certainly end up with an attacker-friendly placement of vulnerable objects. Naturally, security-oriented kernel developers would like to do better than that.

One attempt to do better is type-based slab partitioning, by Marco Elver, which was merged for the 7.2 release. As its name would suggest, it works by separating allocations based on the type of the object being allocated rather than the address of the allocation call site.

To do so, this feature takes advantage of the allocation tokens feature that is available with the Clang 23 compiler. In short, this feature provides a new compiler built-in function, __builtin_infer_alloc_token(), which generates an integer token value from the type(s) of the argument(s) passed into it. That token, in turn, can be used to select the partition from which an object will be allocated. The result is that objects of the same type will always be allocated from the same partition, even if there are several call sites performing the allocations. A structure involved in a vulnerability will always be confined to a single partition, and will always be separated from most other structure types.

As an additional hardening feature, the generation of the token takes into account whether the type(s) in question are structures that contain pointers; the space for tokens representing pointer-containing types is disjoint from the space for all other types. As a result, types that do not contain pointers are kept separate from those that do, making any overrun vulnerabilities with those types harder to exploit for the purpose of overwriting pointers.

The potential downside of this approach is that the mapping from types to partitions is now deterministic and, thus, predictable by attackers. The older, randomized partitioning is still available as a configuration option for those who prefer it. Distributors will have to make a choice, though, regarding which hardening variant (if either) they wish to enable for their users.

Run-time structure-layout randomization

Attackers can benefit from any information they have about how the memory in a given system is laid out. That includes the layout of fields within structures; without that information, targets for attack are harder to locate in a running system. Structures are laid out in the source, and the C standard is fairly clear about how a structure declaration should map to the resulting representation in memory. Attackers will use that information, but may be thrown off if the in-memory layout differs from the source in unpredictable ways.

This not a new idea; the kernel has had support for the "randstruct" GCC plugin, which randomizes the order of fields within structures, for years. Randstruct, though, is a compile-time operation; it rearranges structure fields while the kernel is being built. For a site running a custom kernel, build-time randomization may be sufficient. For kernels shipped by distributors, though, it is not particularly helpful; an attacker can look at the kernel image and know how a structure will be laid out in all systems running that particular kernel.

York Jasper Niebuhr recently showed up with an early-stage patch set, called Bootpatch-SLR, that is meant to address that shortcoming. It performs structure randomization at boot time, meaning that every kernel will have a different layout, and that layout will change every time the system is rebooted. That should make life harder for anybody who is trying to target a specific structure field.

Bootpatch-SLR works by annotating structures to be randomized in the source with a set of special macros; this patch marking up struct task_struct shows how it works. In short, a set of fields to be randomized is annotated with markers like: 

    struct foo {
        spslr_struct_fields_start
	/* fields to be randomized go here */
	spslr_struct_fields_end
    };

These markers turn into special ELF sections that will be included in the resulting kernel binary; they mark not only the fields to rearrange, but also all of the references to those fields. When the kernel boots, it reads those sections, rearranges the indicated structure fields and, by way of a bunch of magic code-patching, updates all of the references to match.

Naturally, there are places where fields cannot be so easily rearranged. Many places in the kernel embed one structure as the first element of a containing structure, then assume that a pointer to the container can be cast to a pointer to the embedded structure. Relocating the embedded structure is likely to produce results that are rather more random than desired. The layout of other structures may be determined by protocol specifications or hardware. Structures that should not be changed at all can simply be left unannotated; others, though, may be able to tolerate the reordering of some fields while others are left untouched. For that case, there is a special marker, __spslr_field_fixed, that can be used to mark fields that need to keep their declared position within the structure.

This idea is appealing; once fully implemented, it could significantly increase the resistance of existing kernels to attack. That is a rather distant goal at the moment, though. Among other things, Bootpatch-SLR is implemented as a GCC plugin, and the long-term plan is to remove support for these plugins from the kernel's build system. An attempt to add a new one now is unlikely to be successful. There are a number of other details that need to be worked out as well; several of them are described in the "known issues" section of the extensive online documentation for Bootpatch-SLR.

Time will tell whether Bootpatch-SLR will reach a point where it can be merged into the mainline kernel; history is full of bright ideas and interesting prototypes that never reached that point. If it does get there, though, the security benefits could be significant.

Comments (5 posted)

Initiating writeback earlier

By Jake Edge
June 26, 2026
LSFMM+BPF

Writeback is the process of ensuring that dirty pages or folios in the page cache are flushed to the disk, so that changes to those files are made persistent. In a filesystem-track session at the 2026 Linux Storage, Filesystem, Memory Management, and BPF Summit, Jeff Layton wanted to discuss whether the writeback operation should be initiated earlier than it is today. The consensus seemed to be that it should be done earlier, but the path toward making that happen was less clear.

Background

In the last few months, Layton began, some new ioctl() commands were added to the debugfs interface for the NFS server (NFSD) that provided the ability to perform "dontcache" I/O (related to RWF_DONTCACHE, which was RWF_UNCACHED originally) and direct I/O (O_DIRECT). The controls were added in debugfs to give developers a chance to try various things before settling on a final interface. Mike Snitzer did most of the work on that, Layton said. The debugfs interface that was eventually added was somewhat different than what was proposed.

Various experiments were run with the new I/O modes to try to quantify which workloads would benefit from them. One thing became clear quickly: dontcache "was pretty awful for writes, at least under NFSD". There are a number of reasons for that, but the main one is that NFS clients send lots of writes in parallel, which end up being written by multiple threads in the server; that did not fit well with that implementation of dontcache for NFSD.

He has some patches in flight that fix the performance problem for RWF_DONTCACHE users; he thanked Jan Kara, Christoph Hellwig, and Ritesh Harjani "who helped me beat that into shape". Since the summit, those patches have been merged for 7.2. One of the characteristics of dontcache is that it immediately submits writes to the device, which was one of the problems encountered by NFSD; all of the threads woke up and submitted I/O, which caused them to queue waiting to be able to submit. The fix puts the data into the page cache until writeback completes, and moves the writeback operation to the flusher threads; that mode now performs better than direct I/O in many cases, Layton said.

[Jeff Layton]

That work started him thinking about doing writeback earlier in general. The number of dirty pages that accumulate is much lower after his fixes, which led him to a question: "are we waiting too long to kick off writes in regular buffered I/O?" Writeback is initiated for buffered I/O when the memory-management subsystem decides that the number of dirty pages is too high; it is also initiated periodically. But "modern memory sizes are huge", so the default dirty limits used are out of date; he thought they had not been updated for 20 years or more. That is really a separate problem and one that administrators "can tune around", but it may make sense to look at changing the defaults.

He wondered if relying on memory management to decide when to do writeback was really the right approach. Maybe the filesystem layer should be more proactive; some calculation based on the backing store and number of dirty pages bound for it could be used to determine when to initiate writeback. The Linux philosophy is that free memory is wasted memory, which is why the page cache, for example, exists, but it is also true that unused disk bandwidth is wasted.

He suggested having a per-superblock dirty limit that was a lot lower than what memory management would normally use. Starting writeback earlier "would help keep us out of the weeds as far as dirty pages go". Outside of the session, Kara had pointed out a potential problem: there are workloads that create lots of temporary files and then delete them. Those files are typically deleted before they get written today, so starting writeback earlier might cause them to be written unnecessarily. A lot of that kind of work is done on tmpfs these days, Layton thinks, so maybe the problem is less critical. Kara had suggested skipping writeback for inodes that have no directory entries (dentries), which might be a way to avoid much of the problem as well.

Discussion

Layton said that he was just putting those ideas out for discussion; he did not have any fixed views on where to go with them. "Any thoughts?"

Ted Ts'o said that he had some ideas, but that they might be somewhat contradictory. He wondered how important it was for the kernel to save battery power by not spinning up disks frequently; he noted that there are few laptops with those kinds of disks anymore so maybe laptop mode is a thing of the past. (It turns out that laptop mode was removed for the 7.0 kernel.)

There are also some kinds of files "where a certain amount of delay is good" because it allows the application to finish writing the file, which helps if the filesystem is doing delayed allocation. So maybe files that are open and still being written to should be deferred for writeback for a time. There are lots of policy questions that would need to be resolved for something like that, however.

Another idea, Ts'o said, might be to try to write at 50% of the backing-device bandwidth, if that can be calculated, to try to ensure that there is headroom so that fsync() latency is reasonably low. One could imagine an auto-tuning process that reserved more headroom for fsync()-heavy workloads. As he noted, some of his ideas "are in tension with one another", so he would prefer that the heuristics used are automatic. Relying on humans to change various parameters is not a good strategy: it "never happens". Layton noted that reserving too much backing-device bandwidth for writes might leave too little for reads, so that is another piece of the puzzle.

Boris Burkov said that he had encountered a problem on a huge-memory system that accumulated lots of dirty pages; "it piled up writeback until it was enormous and the resulting writeback was bad". On March 2, he tried a change that set lower fixed dirty limits, but had to back it all out the next day "because it broke everything", he said to laughter. He was not suggesting that changing the default was a bad idea, because the default is also bad, "but you're going to break something".

Kara asked what specific problem was encountered with the lower limits. Burkov said that it was a system which downloaded and installed packages; its performance regressed after the limits were changed. Kara suggested this might be the temporary-file problem he had raised with Layton earlier; maybe the installation process was using lots of temporary files that would not actually be written with higher limits.

Chuck Lever raised "a converse problem" related to NFSD. There are situations where the NFS clients are sending so many writes that NFSD simply cannot keep up "and there doesn't seem to be an effective pushback from the server to the clients". There are some ways to slow things down with NFSv4 or by adjusting the TCP window, but he thinks there needs to be a way for the virtual filesystem (VFS) layer to slow down writers. Neil Brown had told Lever that there already was a mechanism to do that, but that maybe it was not working correctly. "This room is full of experts who can tell me I'm wrong, go ahead", Lever said with a grin.

Kara said that he "was kind of right" because the feedback mechanism is geared toward local filesystems where the resources available for writes are bounded by the producer sharing the system with the writeback mechanism. For NFS, though, the number of writes that clients can send is only limited by memory. There are mechanisms to throttle writers when too much data is being written, but it is apparently broken for NFS. "Back-pressure from the server does not propagate properly" to the client. A fast-moving conversation between Kara, Layton, and Lever seemed to conclude that there are ways to provide the back-pressure.

Lever asked if there was any way to observe the back-pressure and resulting slowdown. Kara said that there wasn't but that it could be built; he had some suggestions on what kinds of information could be exported to help with that.

Ts'o said that there is decades of research on ways to predict the lifetime of files based on their name and other attributes, which might be useful for determining files that should have their writeback delayed. That would be a heuristic that either requires a decision from a system administrator, "which will never happen", or some kind of automatic determination possibly based on some of the research. It will be important to have some observability into that process as well, he said, "because debugging this is going to require us understanding which of our mysterious heuristics triggered—correctly or not so correctly".

Christian Brauner was concerned that any kind of automatic heuristic configuration in the kernel "that fits all kinds of workloads that exist, is just doomed to fail". He pointed to various control-group parameters that allowed the kernel "to make this user space's problem" and not have to come up with something that will cover everyone's needs. He thinks the mechanisms used by control groups and systemd provide a good model for how various problems like writeback limits should be handled. On the other hand, "we have fadvise(), though no one uses it", Ts'o said to knowing laughter.

Lever asked Layton for more information about why the original dontcache approach for NFSD did not perform well. The basic problem is that immediately performing the write from the thread that receives the client request blocks the thread until the write completes, Layton said. By moving that work to the flusher thread, the server thread can continue to handle requests while the writeback is happening in the flusher.

Lever also wondered how the page-cache entry was dropped once the writeback is completed, since that is what RWF_DONTCACHE is meant to do. There is a folio flag, PG_dropbehind, that tracks whether to keep the folio in the cache after its writeback completes, Layton said. The only real differences between RWF_DONTCACHE writes and buffered writes are the setting of that bit and initiating writeback as soon as possible for RWF_DONTCACHE.

After another minute or two of discussion on some other quick topics, the session ran out of time and concluded.

Comments (10 posted)

Efficient access to local storage for BPF programs

By Daroc Alden
July 1, 2026
LSFMM+BPF

When a BPF program is used to filter or redirect packets in the networking subsystem, the program will often want to associate data with each packet as it moves through the kernel. The kernel's local BPF storage API, which associates extra data with some kernel objects, provides a way to do that. (See also the BPF map types that end in STORAGE.) Amery Hung and Jakub Sitnicki led two sessions at the 2026 Linux Storage, Filesystem, Memory-Management, and BPF Summit about how to make accesses to local storage data more efficient. Hung spoke about general performance problems related to locking, while Sitnicki examined the use of local storage in the networking subsystem in particular.

There is a feature that Hung has been working on for the past eight months, using local storage to enable faster communication between the kernel and user space. This talk was not about that feature, because in the course of working on it, Hung noticed that the BPF self tests sometimes failed due to contention on the lock that protects local storage from deadlocks. Such contention can cause reading from or writing to local storage to fail, which is an obvious source of problems.

[Amery Hung]

Local storage is protected by two locks: a normal lock used to protect against concurrent accesses, and a per-CPU lock that exists to prevent deadlock. The latter lock is needed because a BPF program could potentially be attached to tracepoints that are triggered when the local storage is accessed. Without a per-CPU lock to make sure that the same CPU doesn't try to acquire the main lock twice, it would be possible for a BPF program attached to one of those tracepoints to attempt to access the local storage itself, and deadlock the kernel. In order to prevent that, the kfuncs that BPF uses to access local storage were made fallible, and the per-CPU lock ensures they return an error if two BPF programs try to access the local storage at the same time.

That is more conservative than necessary, however, because it means that two unrelated BPF programs could block each other's accesses even though there is no possibility of deadlock. To solve this problem, Hung would like to replace the main lock with a resilient queued spinlock (rqspinlock), a kind of lock that Kumar Kartikeya Dwivedi and Alexei Starovoitov developed to report deadlocks at run time. Since the main lock would prevent deadlocks, the per-CPU lock could be eliminated. With care, this approach could be used to fail the BPF operation only when there is an actual risk of a deadlock occurring.

But it is not as simple as just changing the type of lock used, Hung said. That is sufficient for most code paths, but there are some infallible operations that need to take the same lock, and rqspinlock can't handle that. For example, freeing a kernel data structure that has local storage should not fail just because the lock is contended. It's hard to make things fail gracefully.

Hung tried replacing some of the relevant allocations and deallocations with kmalloc_nolock(), but that did not work well either. The problem is that there are two allocators that can be used for local storage: the BPF allocator and the slab allocator. Using one or the other alone isn't acceptable for performance reasons; the BPF developers went through a lot of pain to decouple things so that either can be used.

At the end of the day, Hung gave up on solving the problem gracefully, and introduced an infallible freeing operation for local storage that leaks 176 bytes in the worst case. With a mostly working approach, the next step was to benchmark the change. A microbenchmark that created local storage allocations and then freed them in a loop saw a 1.5% increase in throughput after removing the per-CPU lock on x86_64. Arm systems didn't have a measurable performance difference. Microbenchmarks don't tell the whole story, however, since real-world performance is sensitive to the conditions of the rest of the system.

The change also unlocks some other potential performance improvements, including switching some uses of the slab allocator to be able to use sheaves, which gives a 5.1% speedup on another microbenchmark. One audience member asked whether Hung had any idea why there would be such a big performance difference between the two allocators. Hung wasn't sure — cache usage on x86 increased, that just didn't cause a performance regression.

The next steps are somewhat unclear; there remains some additional complexity around managing the lifetime of local storage objects, Hung said. Some kinds of kernel objects don't always fully initialize their local storage, which can result in kernel panics. Starovoitov had previously suggested using kernel object pointers as keys in a more general-purpose map, as an alternative to local storage, which was a potentially interesting solution.

Hung developed another benchmark comparing this approach (using hash tables 50,000 buckets in size) to the existing local storage implementation, and saw a speedup, but the BPF developers in attendance were skeptical. One audience member remarked that in their experience, smaller hash tables are faster and bigger hash tables are slower; a proper benchmark should test multiple sizes. Hung pointed out that rhashtable uses a dynamic number of buckets, and wondered how that would effect things.

Sitnicki said that on the systems he works with, local storage is used with around one million concurrent connections, a number that was met with some surprise. Hung agreed that the benchmarks probably needed to be extended. Another part of that is that different metrics matter for different kinds of kernel objects; local storage for sk_buff structures should be optimized for creation speed, etc., Hung said.

In the future, socket-local storage can also be optimized further by removing the need for dynamic allocations at all. The verifier may be able to do "helper fixups" to make it even faster, a claim on which Hung did not elaborate. At that point, the session devolved into an discussion of how, exactly, local storage performance ought to be benchmarked for different uses.

Metadata storage for packets

The next day, Sitnicki led a follow-up session dealing with storing metadata in sk_buff structures (SKBs) — a topic that had been discussed in 2025 as well. It is "not local storage, exactly, but the topic should feel familiar." BPF programs often need to store labels, timestamps, or other small amounts of data on packets, he said. His first and second attempts at enabling this were to expose the existing storage for express data path (XDP) and SKB metadata to BPF programs; that wasn't workable because that metadata can only be accessed from XDP and traffic control (TC) contexts, and not from the upper layers of the networking stack.

[Jakub Sitnicki]

Letting that metadata persist would require the networking subsystem to commit to a layout for it, which the networking maintainers do not wish to do. John Fastabend questioned why the networking folks would be so adamant about that. Was the problem that they wanted the metadata to be the same across different hardware, he asked. Sitnicki didn't think that was the problem — one can allocate space for metadata from XDP and later consume it in TC, regardless of hardware.

Sitnicki has considered a few alternatives; for example, an SKB extension could be used to hold a pointer to local storage. That would cause three allocations per packet, though, which is not really acceptable. Another alternative would be to have an SKB extension specifically for BPF metadata. The extension could even be located in the same allocation as the SKB. This would mean one allocation per packet, and fewer indirections to access the data. On the other hand, it requires buy-in from the networking maintainers, results in bigger SKBs, and that memory cost must be paid for even if it isn't used. Sitnicki intended to run that option by the networking maintainers at the Netdev conference in July.

Starovoitov suggested having a boot flag to set the size of the metadata; that way people who don't enable the boot flag don't see any memory overhead, and the people who do enable the boot flag presumably have some idea what they're doing. Andrii Nakryiko asked why Sitnicki wanted to locate the metadata next to the SKB in the first place, especially since accessing it would still cause a cache miss in practice. He suggested adding a separate hashmap for metadata and using that. Sitnicki agreed that that was a second possible alternative.

Daniel Borkmann asked Sitnicki to elaborate on the difference between making the existing SKB metadata accessible at higher levels of the networking stack, and adding BPF-specific metadata in an SKB extension. The two approaches would effectively both put metadata alongside the SKB. Sitnicki agreed that was the case, and that he would be fine with either alternative. The difference is that the approach using an SKB extension would have a pointer indirection, even if it's just one allocation. That's more flexible, because for packets that don't need metadata, it could be left out, which would save memory.

Using an SKB extension does introduce some new challenges, however. For one thing, it affects how SKBs should be cloned, since the extension needs to be copied as well — which is not how SKB extensions work currently. The existing SKB extensions are only copied when activating a new extension, Sitnicki said. Also, some SKB extensions are hard to compile out if they are not needed; IPSec support always requires having space for an SKB extension used by IPSec hardware offload, for example.

Starovoitov wasn't sure why all of the SKB extensions needed to live in a single allocation alongside the SKB. Sitnicki explained that that is just how SKB extensions are implemented. Any approach that tries to add a separate mechanism just for BPF is going to be refused by the networking maintainers, because they have been trying to make SKB extensions "not suck" for a long time. They want any improvements in this area to work with the existing code.

There is another problem to consider, though. Even if some memory is set aside for BPF metadata, how can the memory be divvied up between BPF programs that all want to store things there? One option would be to just configure each BPF program that an administrator intends to run to have its own range. Another option would be to allocate space in the metadata dynamically, so that BPF programs can declare how much metadata they need and then the kernel can transparently provide access to it. The second one is a nicer user experience, but more complicated to implement. There was some discussion about the pros and cons of each approach that failed to reach a consensus.

An alternative, Sitnicki said, would be to use a pointer to the SKB as a key in an existing BPF hashmap. That sounds like a good solution, but picking the correct size for the hashmap is a tricky problem. Maybe rhashtables, which are resizeable, are the right answer, but that needs to be tested under real-world load. Using a hashmap also moves the responsibility for cleaning up the metadata when the SKB is freed onto the BPF program. Hooking into a tracepoint to detect when an SKB is freed does have some overhead, which needs to be considered as part of the cost of the approach.

Starovoitov questioned why the BPF program that acts as the final consumer for the metadata couldn't do the cleanup, avoiding the overhead of a tracepoint. SKBs can disappear at many different points in the networking stack, Sitnicki explained. If a packet with metadata is dropped, that metadata needs to be cleaned up somehow. Starovoitov suggested putting a single bit in the SKB to indicate whether it has metadata, and then call the tracepoint conditionally, so that there is only a performance overhead for packets that have metadata and that are dropped before they can be cleaned up.

Nakryiko and Starovoitov encouraged Sitnicki to nail down the specific proportion of packets that need metadata, the size of the metadata, and the overall number of packets needed for his use case before deciding on a design. All of these things can affect what the best solution will look like, and it's better to be specific rather than attempting to design a general mechanism that may not even gain any other users. At that point, the discussion broke down into speculation about the impacts of different designs, and the session ran out of time.

Comments (none posted)

The rest of the 7.2 merge window

By Jonathan Corbet
June 29, 2026
Linus Torvalds released 7.2-rc1 and closed the 7.2 merge window on June 28; by that time, 13,412 non-merge commits had found their way into the mainline. That makes this the busiest merge window since the 6.7 development cycle in 2024 (15,418 commits, including 2,800 for the entire bcachefs development history). Just under half of those commits arrived after LWN's summary of the first half of the merge window was written. As usual, the commits in the latter part of the merge window were more heavily focused on fixes, but there were still a lot of new features and significant changes merged as well.

Some of the most interesting changes merged include:

Core kernel

  • The ongoing work to improve the kernel's swap subsystem (previously discussed in this article and this article) continues with the merging of this series unifying much of the code dealing with anonymous and shared-memory folios and reducing the memory usage of the swap subsystem itself. "The static metadata overhead is now close to zero, and workload performance is slightly improved". See our LSFMM+BPF 2026 coverage for more information on this work.
  • The khugepaged kernel thread can now create multi-size transparent huge pages (mTHPs) automatically. See this article for details on this work.
  • A separate option to create transparent huge pages in the page cache for read-only files — a workaround for filesystems that do not support large folios natively — has been removed. This change may slow performance for some filesystems until they gain large-folio support.

Filesystems and block I/O

  • The default block size for NFS transfers has increased to 4MB on systems with at least 16GB of RAM.
  • The SMB filesystem server has gained support for files that are stored in compressed format; it also now implements compression for data sent (or received) over the network.
  • The newly reinvigorated NTFS filesystem has been hardened against many types of on-disk metadata corruption and is now able to handle Windows-native symbolic links.
  • The fscache backend for the EROFS filesystem, which was merged for 5.19, has been deprecated for the last two years; it has now been removed.
  • The Ceph filesystem has gained the ability to reset clients manually. This feature is rigorously undocumented, but the patch series contained an informative cover letter that was not preserved when the series was applied.

Hardware support

  • Clock: Canaan Kendryte K230 clocks, Qualcomm IPQ9650 global clock controllers, Qualcomm Hawi TCSR clock controllers, Qualcomm X1P42100 video clock controllers, and Qualcomm X1P42100 camera clock controllers.
  • GPIO and pin control: Qualcomm IPQ9650 pin controllers, Qualcomm Nord pin controllers, Qualcomm SM6350 LPASS LPI pin controllers, Qualcomm Shikra pin controllers, Aspeed G7 SoC pin controllers, NVIDIA Tegra238 and Tegra264 pin controllers, and UltraRISC DP1000 SoC pin controllers.
  • Industrial I/O: Analog Devices AD5706R digital-to-analog converters, MEMSIC MMC5983 3-axis magnetic sensors, Broadcom APDS9999 ALS, RGB, and proximity sensors, Analog Devices AD4691 analog-to-digital converters, and Vishay VEML3328 RGBCIR light sensors.
  • Input: Rakk gaming peripherals, OneXPlayer handheld controllers, and Wacom W9000-series pen-abled touchscreens.
  • Media: AMD ISP4 image signal processors, AVMatrix HWS PCIe image-capture devices, and Intel CVS CSI-2 bridges.
  • Miscellaneous: Renesas R-Car multi-functional interfaces, NVIDIA Tegra114 external memory controllers, Verisilicon I/O memory-management units, TI LP5860 LED controllers, Samsung S2M series RGB and flash/torch LEDs, Maxim MAX25014 controllers, Microsoft Surface RT batteries, Samsung S2M series PMIC battery chargers, AMD Promontory 21 xHCI temperature sensors, Qualcomm SHIKRA, HAWI, and Nord interconnect providers, Qualcomm Hamoa/Glymur reference-device embedded controllers, Dell DW5826e PLDR reset controllers, and UltraRISC PCIe host controllers.
  • Networking: Virtio CAN interfaces.
  • PHY: Axiado eMMC PHYs, Mobileye EyeQ5 Ethernet PHYs, EcoNet PCIe PHYs, TI DS125DF111 2-Channel retimers, Freescale Layerscape Lynx 10G SerDes PHYs, and NXP TJA1145 CAN transceiver PHYs.
  • USB: Cadence USBSSP USB device controllers and devices supporting the USB4STREAM protocol.

Miscellaneous

  • The perf tool has, as usual, received a long list of improvements; see this merge commit for details.

Security-related

  • The integrity measurement architecture (IMA) has gained the ability to stage measurement data outside of the kernel, thus freeing (possibly large amounts of) kernel memory. See Documentation/security/IMA-export-delete.rst for more information.
  • The Landlock security module now has the ability to control the use of UDP sockets; this documentation commit shows what has changed. It is also now possible to suppress logging for some Landlock denials, this commit contains some more information.
  • After six years of effort, the strncpy() implementation has been removed from the kernel; according to this merge commit, this effort required 362 commits from 70 contributors. This commit lists the alternatives in use by the kernel now.
  • One notable thing that was not merged is the Hornet Linux security module, which was intended to provide an additional level of security around the loading of BPF programs. This module was rejected by the BPF developers in 2025, but was reworked in an attempt to satisfy the objections that had kept it out previously. That effort was not successful, though, and, prior to the beginning of the merge window, Torvalds let it be known that he would not be accepting a pull request containing that code.

    Where things go from here is not clear; Blaise Boscaccy and other developers in this area clearly feel that Hornet provides security guarantees that are not present with the in-kernel solution. Danial Borkmann has posted an alternative implementation that, he hoped, might constitute an acceptable compromise. That work is in an early state, though, and is not likely to go upstream in the near future.

Virtualization and containers

  • The KVM subsystem has gained support for Intel's "mode-based execution control" (MBEC) and AMD's "guest-mode execution trap" features, both of which give better control over execute permissions in guests. Among other things, this feature greatly reduces the number of times that guests must trap back into the host for permission-related operations. See this MBEC patch series (which was substantially reworked before inclusion) and this merge commit for more information.
  • There are no new KVM features for the Arm architecture this time around; from the KVM pull request: "This is a bit of an odd merge window on the KVM/arm64 front. There is absolutely no new feature in the pull request. It is purely fixes, because it is simply becoming too hard to review new stuff when so many AI-fueled fixes hit the list".

Internal kernel changes

  • The kernel build system has gained the ability to create a software bill of materials (SBOM) using the SPDX information that has been added to the kernel's source files. Only the files that are actually compiled under the current configuration are considered, so the SBOM is specific to the built kernel. The relevant command is "make sbom"; see Documentation/tools/sbom/sbom.rst for more information.

The 7.2 merge window removed 195 exported symbols and added 380 others; there were also 32 new kfuncs added. See this page for the full list.

Finally, the 7.2 merge window included contributions from 2,138 contributors, which is almost certainly a merge-window record. It is only the last three development cycles that have seen that many contributors for the entire cycle. Of the 7.2 merge-window contributors, 404 were first-timers. There were 706 commits (about 5% of the total) containing Assisted-by tags. It would seem that the LLM-fueled flood of kernel patches is showing no signs of slowing down.

Now all of those changes need to be stabilized for the 7.2 release, which is most likely to happen on August 16.

Comments (2 posted)

Secure Boot certificate expiration is here

July 1, 2026

This article was contributed by Brian "bex" Exelbierd

Linux users who have Secure Boot enabled on their systems rely on certificates issued by Microsoft to verify the software used to boot a system is trusted by the user. One of those certificates expired recently, but that will not cause systems that are able to boot to stop doing so. There are situations where the expiration may cause problems, however, and the window for relying on existing signed binaries is shorter than it might appear. Users and administrators will want to stay on top of these changes. Over the last year, part of my job at Microsoft has been to work on this problem. LWN wrote about the certificate expiration in July 2025, and this article follows up with where we are now.

How Linux boots under Secure Boot

UEFI Secure Boot requires firmware to refuse to execute boot code that has not been signed by a certificate in the firmware's trust database. The majority of computing hardware capable of Secure Boot is manufactured to meet Microsoft guidelines that include loading the Microsoft UEFI certificates into the firmware trust database for use as trust anchors.

Microsoft does not sign the GRUB bootloader. Instead, it signs the shim binary, which is the first-stage bootloader that then loads the distribution's own bootloader (typically GRUB), which then validates and loads the kernel.

From shim onward, the chain of trust runs through the distribution's own infrastructure. Distributions manage their own signing keys and can publish updates to GRUB and the kernel without involving Microsoft. Shim is designed to change infrequently, so that Microsoft's signing role does not become part of distribution-release or security-update processes, except in situations where shim itself needs to be signed.

The code for shim is open source. The community runs a shim-review process that serves as the primary gate to signing. A distributor, such as Debian or Red Hat, creates an issue in the GitHub repository that includes the shim.efi binary to be signed, the build logs, and additional information to review a request for a signature. After the community approves a submission, then the distributor may request the signature; Microsoft then verifies the submitter's relationship to the distribution, runs its own checks, and applies the cryptographic signature. This arrangement lets the community manage review without running signing infrastructure or requesting all of the firmware vendors to include their certificates. Part of my job has been to bridge the communication between the shim-review community and the team at Microsoft that signs the shim binary during this transition.

The Microsoft Corporation UEFI CA 2011 certificate expired on June 26, 2026 (or June 27, depending on time zone). It is being replaced by the Microsoft UEFI CA 2023 certificate, which does not expire until 2038. This will not cause existing systems (e.g., those that have booted successfully before the expiration) to stop booting; however, a system can fail to boot if it does not have the new certificate in its trust store and receives a new shim (via a system upgrade or new installation) that is signed with that certificate.

Note that there are multiple 2011 certificates used as trust anchors for various trust paths. As a family, the certificates begin expiring in June with the Windows Secure Boot certificates expiring last, in October. For Linux, the certificate that matters is the one that expired on June 26.

How expiration impacts Linux

Firmware is generally designed to ignore certificate expiration when evaluating whether a signature is valid. The UEFI specification's image-validation process bases the trust decision on whether the image's signing certificate is present in the authorized database (db) and absent from the forbidden database (dbx). It does not check a certificate's validity period. The intermediate certificates used to sign UEFI binaries have already expired without consequence. Any shim that is signed with the 2011 certificate will continue to work as it did before, barring a bug in a system's specific firmware implementation.

In October 2025, Microsoft began returning two signed binaries for each shim submission. One is signed with the 2011 certificate, and the other one is signed with the 2023 certificate. That overlap ended with the certificate expiration. Future submissions can only receive the 2023 signature, leaving distributors to decide whether to ship a dual-signed shim while they still can, or to move directly to a 2023-only shim. The latter choice is safe only for systems whose firmware already trusts the 2023 certificate.

The focus of this article is on shim, however, option ROMs—UEFI binaries that are loaded into peripherals such as graphics cards and executed during the preboot phase—have a similar exposure.

Forced update

The UEFI boot environment has attracted increasing security scrutiny. Vulnerabilities are occasionally discovered in shim, GRUB, and other boot-chain components just like other software. If a vulnerability is discovered in shim itself that requires a code change and a new binary, that new binary can only be signed with the 2023 certificate.

Therefore, the practical window for relying on the old 2011-signed shim is the time between now and the next security vulnerability or distribution release that forces a shim respin. Matthew Garrett has argued that the transition is less urgent than some descriptions suggest: in many cases, a system could boot older media, update its trust database, and then install or boot newer media. That path exists, but it is not sufficient for every environment. Systems with strict uptime requirements, restricted boot-media policies, or remote-only access may not have that option.

For most users running a maintained distribution on maintained hardware or a maintained virtualization layer, the distribution will manage this transition. The Linux Vendor Firmware Service (LVFS) and fwupd provide a mechanism for delivering firmware updates, including Secure Boot trust-database updates.

The systems that need attention are those where that path does not work: hardware where the vendor no longer supports the model or has stopped publishing LVFS updates, and virtual machines provisioned before cloud or virtualization providers enrolled with the 2023 certificate that have not received subsequent firmware updates. For those systems, mokutil can report whether the 2023 certificate is enrolled, and tools such as pesign or sbverify can show which certificate signed an installed shim. See this post for information on upgrading.

LVFS maintains its own compatibility data and can target updates to specific hardware configurations. Microsoft has published a dataset of device configurations where the 2023 certificate update has been confirmed to apply successfully, derived from Windows fleet telemetry and made available for Linux distributions and other non-Windows operating systems to use.

That compatibility work matters because forced trust database updates are not safe on all hardware. Forced updates have left some machines unbootable. On certain hardware, recovery requires physical access, and in some cases we have observed that systems were permanently damaged.

The distribution and the compute vendor are the best sources of current status and guidance. The shim-review community is not a support channel for individual systems, and Microsoft can only assist with its own compute platforms and operating systems.

Overall, the result is less an immediate, deadline-driven outage and more of a preventative-maintenance problem; system administrators need to take action to avoid running into a situation where a system may eventually stop booting, but the certificate expiry does not automatically mean systems will no longer boot the instant the certificate expired.

The systems most likely to have trouble are not the newest or most carefully managed systems; they are the ones stranded outside the normal firmware-update machinery when a future shim update becomes necessary.

Comments (21 posted)

A look at MinIO alternatives: Ceph and Garage

June 25, 2026

This article was contributed by Tyler Langlois

MinIO is a popular object-storage server that offered compatibility with the Amazon Simple Storage Service (S3) API. In December 2025, the company behind the project (also named MinIO) announced that the project was in maintenance mode and would not accept new changes; it was archived completely in February 2026. MinIO users have been hunting for alternatives since then, but the array of choices can be baffling. While many other projects aim to fill the space, their strengths and areas of focus tend to vary. Two of the alternatives—Ceph and Garage—are particularly compelling, and both offer solid S3 compatibility.

MinIO did not state its reasons for retiring the project, but it has a proprietary project with similar features that it recommended in place of the now-defunct project. The company has continued to publish vulnerability information that details security problems that affect the last version of MinIO, at least through April of this year, but it is no longer supplying updates to the open-source project.

Most users of MinIO have moved on to other projects that remain on open-source licenses. Ruohang Feng is maintaining a MinIO fork called Silo, but he has indicated that his plans are limited to bugs and security fixes; new feature development is not in scope. Its most recent release was on June 18, 2026.

Core Requirements

Object-store applications like MinIO offer a way to provide S3 capabilities while self-hosting the underlying infrastructure. That is a must for air-gapped systems which cannot rely on external hardware and management, but it is also beneficial for users who want to avoid proprietary services. However, without the global infrastructure that backs most commercial services, high availability can be difficult to achieve in smaller environments. Fortunately, many projects, such as MinIO, have built fault tolerance into their design from the start.

Ease of setup, modest hardware requirements, and S3 API support are fundamental requirements. MinIO became a popular way to provide object storage for environments that operate independently of cloud services but still rely on object-storage availability, often appearing as an add-on service in Kubernetes distributions like MicroK8s.

The S3 API enjoys widespread adoption due to its object-storage capabilities across a variety of use cases. S3 facilitates file-based use cases across many services via HTTP by implementing filesystem reads with GetObject calls and writes with PutObject calls.

For example, S3 storage is used with many Kubernetes environments to provide container image storage and shared storage for container volumes. Its usefulness isn't limited to container workloads, of course: object storage is often used for static web site hosting, backing storage for caching strategies, and more.

The distributed nature of MinIO servers helped lend it resilience in the case of disk or host failures. Fault tolerance is provided by either replication-based strategies across deployments (in which multiple copies of data are retained in separate clusters) or more advanced capabilities based on erasure encoding to more optimally use available space with parity checking within a cluster to reconstruct missing data.

MinIO's untimely retirement means that users need a new alternative, but what to choose? Resilience is often just as important as S3-compatibility to safeguard against data loss. However, solutions that are prohibitively complex or difficult to operate while meeting these requirements can be self-defeating for administrators looking for self-hosted options. Ensuring that deployments remain manageable is therefore important.

The quality of a project's S3 API implementation is one of the most important features to evaluate, but it is not the only consideration. Implementations must also support compatible authentication via a recognized signing method. The current standard is AWS Signature Version 4; Version 2 is deprecated, but some older clients may rely on it. Version 3 was never widely used or supported.

While nearly all object-storage solutions support basic operations like GetObject and PutObject, other features are worth evaluating in the context of individual needs. For example, object lifecycle rules that control whether an object may be deleted after a period of time may not be supported by every S3 alternative. Similarly, server-side object encryption (SSE) might be supported, but there are a number of different modes for SSE, such as user-provided keys included with each request versus server-managed keys.

While the S3 API tends to slowly add features over time, existing endpoints seldom change. Clients can usually rely on established APIs working indefinitely and new APIs appearing rarely. The S3 API user guide describes ongoing changes. Downstream projects like Ceph or Garage most often work by broadening compatibility with new capabilities as endpoints are added. Most libraries and command-line utilities that interact with S3 can accept other object-store endpoints with minimal configuration changes.

Ceph

Ceph is a stable and long-lived project with healthy governance. It is now stewarded by the Ceph Foundation, which is under the Linux Foundation. Its source is hosted on GitHub under a mix of open-source licenses, the most common being LGPL 2.1. Ceph is also one of the most longstanding S3-compatible solutions with many years of development history and stable financial support on record.

Support for Ceph was merged into the mainline Linux kernel back in 2010. Development remains steady with the latest release, 20.2.1, announced in April 2026. Ceph's distinguishing characteristic, in contrast to MinIO or Garage, is its capability for massive scale rather than smaller deployments.

The S3 object-storage API is only one interface to Ceph's storage capabilities: the Ceph Object Gateway built on top of librados provides the S3-compatibility layer, but Ceph's storage abstractions are exposed through other methods as well: Ceph has a POSIX-compliant filesystem (CephFS), and its block devices are used by other open-source projects like QEMU and libvirt to provide backing storage for virtual machines.

Distributed operation is native to Ceph's architecture to offer better fault tolerance and scalability. Ceph clusters operations into small, logical components that can be scaled independently depending on architectural needs. This lends Ceph significant flexibility at the cost of some operational complexity: ceph-osd daemons manage actual storage operations, ceph-mgr daemons coordinate cluster operations and management, ceph-rgw (the RADOS Gateway) provides the actual S3 API, and so on. For large deployments with dedicated teams, these tradeoffs may make sense: if a bottleneck arises in a subsystem's critical path, it can be scaled independently without impacting other systems.

Multiple Ceph monitors form a Paxos quorum, or majority consensus, to ensure consistency and coordinate cluster activity. The ceph-mon utility helps to manage the provisioning process with a reliance on knowledge of initial bootstrapping membership that is typical during initial setup for algorithms like Paxos. Tooling like ceph-deploy can help simplify the initial provisioning process.

As with other clustered services that rely on quorum-based reconciliation, Ceph monitors should run with an odd number of voting members to avoid split-brain situations. Three ceph-mon instances permit the loss of one member without degraded operations, while five allow two members to go offline, and so on. One ceph-mgr is active at any given time, and general guidance is to run one instance per ceph-mon daemon to accept potential failover duties. Other daemons are scaled alongside hardware: ceph-osd usually corresponds to one hardware storage device. Although Ceph can run as a single node, its default mode of operation is better suited for multiple hosts.

System hardware requirements are nuanced: because Ceph supports clusters of potentially large scale, requisite resources are a function of the overall amount of desired effective storage. Components like ceph-mds (metadata servers) can function with as little as 1GB of memory but nodes that function with ceph-mon and ceph-mgr roles may perform well with 64GB but requirements move upward to 128G when ceph-osd (storage daemon) count begins to exceed hundreds of instances. While some of these numbers may seem daunting, Ceph is designed to function capably at these sorts of scales.

Ceph's RADOS Gateway provides a mature S3-compatible API: it supports bucket lifecycles, encryption, and other concepts native to the S3 ecosystem. Administrators reliant on the most S3-like API available will likely find its implementation appealing, especially when coupled with operational tools like access-control lists for buckets (to fine-tune permissions) and bucket notifications (to react to bucket object activity). The project maintains a list that outlines compatibility with the S3 API, including support for both version 4 and version 2 signing.

Garage

At the other end of the longevity spectrum, Garage is a comparatively young AGPL-licensed project; it was started in 2020 by Deuxfleurs, a non-profit hosting company. The project is hosted on independent Forgejo infrastructure.

Written in Rust, Garage foregoes a large feature catalog in favor of a focused goal: distributed, fault-tolerant object storage (without any traditional filesystem or block device drivers.) The latest stable release at the time of writing was version 2.3.0 in April 2026. While relatively new, Garage is positioned as a middle ground between Ceph's non-trivial deployment architecture and simpler projects that lack distributed fault tolerance.

Garage runs homogeneous services and relies on concepts like conflict-free replicated data types (CRDTs) to reconcile consistency drift in the case of events like network partitions. Like delegating consensus to an external protocol such as Paxos, the primitives in play are often sound, but implementations may lack the operational track record drawn from years of practical use. For smaller environments or home labs with one administrator, radically simple configurations that still offer reliability guarantees are attractive.

Forming a Garage cluster is less involved than configuring Ceph Monitors: running nodes yield their identifiers and addresses with the "garage node id" command, after which peers negotiate connections with "garage node connect $node_id" given the target node ID. This allows for a degree of elasticity to Garage deployments, although operators should bear in mind that internal quorums are still consulted for some operations (its design documents refer to Amazon's Dynamo paper). Keeping a majority of Garage nodes online therefore remains important for overall cluster stability.

Garage encapsulates all of its functionality in a single daemon, making it well-suited for smaller or resource-constrained environments. Deployment topology usually follows one daemon that is capable of managing multiple physical disks to present to the overall cluster, per host. However, for large networks with frequent disk maintenance, singular ceph-osd daemons may be a more logical choice that does not require interrupting a singular process managing both cluster membership and storage devices. System requirements are notably minimal with support targeted at CPUs released within the past 10 years and a minimum of 1GB of memory.

The Garage S3-compatibility page is straightforward and maintains comparison tables against other S3 API implementations. While the project is evolving quickly, Garage's API support remains a smaller subset of the overall S3 API. In particular, some missing capabilities such as object versioning (e.g. PutBucketVersioning to implicitly create backup copies of objects) may be baseline requirements, and only version 4 authentication signatures are supported. Ceph offers broader S3 API support, but the operational cost may be worth simplicity tradeoffs that Garage can provide with more manageable requirements.

Despite MinIO's departure from the open-source landscape, alternatives offer mature implementations that can provide significant features without sacrificing many of S3's native capabilities. Ceph and Garage are capable replacements for in-house, self-hosted environments.

Development practices, particularly as they relate to use of large language models (LLMs), have also become a prominent question when considering project maintenance. The Ceph project is still debating its policy with regard to LLMs, but seems to be converging on something similar to the Linux kernel AI contribution policy. Garage recently merged a policy on contributions authored by LLMs and other coding assistants; it allows LLM-usage for "some tedious code generation tasks", but largely forbids their usage for documentation, writing bug reports, or writing most code to be submitted to the project. While the Garage repository has no commits on record either authored or co-authored by LLMs, Ceph's commit history includes code increasingly co-authored by Claude, ChatGPT, and Gemini.

Anecdotally, my experience moving from MinIO to Garage has been positive and without negative surprises. Cluster formation is easy, recovering from hardware failures is reliable, and its API has been compatible with all of my use cases. Garage is well-suited for my home lab, and other small-scale operators can likely benefit from multiple servers for failover without the mental burden of orchestrating relatively more complex deployments. In the case of both MinIO and Garage, my clusters have undergone rolling updates and the occasional dead disk while remaining operational.

Real-world experience

Total usable storage is a relatively simple calculation in the case of both Ceph and Garage. Without any replication configuration, either solution presents one logical view into all pooled devices: for example, three 1TB disks appear as 3TB of usable space. Replicating with a factor of two reserves one copy of managed data, which halves available space to 1.5TB. Ceph's ability to erasure code volumes offers even better capacity through the use of parity calculation and would offer roughly 2TB of usable space this in this imaginary scenario. My own Garage infrastructure spans six hosts across ten total physical disks.

Garage has yet to fail catastrophically, while I had been forced to rebuild my MinIO cluster on at least one occasion due to irreconcilable cluster problems. Overall I would characterize Garage as simpler to operate and easier to use than MinIO. Use cases differ, though, and large-but-capable solutions like Ceph are almost certainly better suited for environments with stricter needs, closer S3 API parity, or stronger stability guarantees.

Comments (21 posted)

Reports from OSPM 2026, day three

By Jonathan Corbet
June 26, 2026
The Power Management and Scheduling in the Linux Kernel Summit, which still goes by the historical acronym OSPM, was held in Cambridge, UK, in mid-April. As has become traditional, the presenters at that event have since written summaries of their sessions, and this work has kindly been made available to LWN for publication. The third day's sessions covered a wide range of topics, including GPU affinity, profile-guided scheduling, paravirtualization scheduling, quality of service, and more.

(See also: coverage from day 1 and day 2).

GPU-aware auto-affinitization with sched_ext — Andrea Righi and Balbir Singh

On systems with multiple GPUs and multiple NUMA nodes, CPU-to-GPU locality often becomes the dominant performance factor for AI and accelerator-heavy workloads. A task whose CPU threads run on one NUMA node while it drives a GPU attached to another pays a real cost on every transfer between the CPU and the GPU. Today, users work around this manually with numactl pinning and by disabling NUMA balancing, but this amounts to ad-hoc static partitioning and depends on the user knowing the system's topology. This talk described an experimental sched_ext-based approach that tries to do this automatically.

A prototype has been implemented in the scx_cosmos scheduler. A small user-space component, written in Rust, queries NVIDIA's NVML library to track per-task GPU memory and compute utilization. When both metrics exceed a threshold, the task is considered to be actively using a specific GPU, and an entry is added to a BPF map mapping the task to its preferred NUMA node. The BPF scheduler then consults this map during task rescheduling, migrating the task toward CPUs that are local to the GPU it is actively using.

Results on a four-GPU NVIDIA GB200 system running a RegNet image-processing workload were encouraging. The default fair scheduler reached around 56 frames per second (fps), while manual numactl pinning to the correct node pushed that to about 77fps. Scx_cosmos with GPU auto-affinitization slightly exceeded even manual pinning, reaching up to 80fps. The small extra gain came from a useful side effect: only the tasks actually touching the GPU were migrated, leaving auxiliary tasks free to spread across the other nodes and avoid overloading the CPUs that are local to the GPUs.

Several caveats remain. Migrating a task closer to its GPU does not move the memory it has already allocated, so accesses can remain remote unless NUMA balancing or an explicit numactl call follows. Multi-threaded workloads with shared state may be hurt by migrating only the GPU-active thread. And aggressive packing onto a single NUMA node can conflict with the scheduler's load balancer. Some of these can be addressed in user space (signalling numactl from the BPF side once a migration is decided, for example). For the rest, Peter Zijlstra suggested a much simpler kernel-side option: a per-task knob that fixes the preferred NUMA node and disables NUMA-balancing scans, which would generalize cleanly beyond GPUs to network interfaces, storage, and other devices.

A recurring theme in the discussion was that statistical inference from utilization counters is fundamentally post-facto: by the time the scheduler concludes that a task is using a specific GPU, the misplacement has already cost performance. The clear next step is to obtain hints from the user-space framework managing the device, CUDA being the obvious example, so that placement decisions can be made before the workload starts. Such hints can also be two-way: the kernel side can validate them against observed behavior and report back when a user-space framework is asking for something nonsensical.

The talk closed with several speculative directions: device-aware fairness would extend vruntime-style accounting beyond CPU time to also capture GPU (and more generally device) utilization, so that a task burning GPU cycles without much CPU usage does not appear "light" to the scheduler. Periodic GPU workloads, such as graphics frames, look like natural candidates for deadline-based scheduling. Embedded and mobile use cases bring thermal coordination between CPU and GPU into scope. And virtualization, with pass-through devices and paravirtualized scheduling, opens an entirely separate problem space that the sched_ext prototype has not yet touched. The unifying observation is that as accelerators become the primary consumers of CPU work, the scheduler needs a richer view of where devices live and what tasks are doing with them; sched_ext is a convenient place to experiment with that view.

Video: GPU-Aware Auto-Affinitization with sched_ext - Andrea Righi, Balbir Singh (OSPM26)

Profile-guided CPU scheduling — Kumar Kartikeya Dwivedi

This talk was centered around the premise that CPU schedulers often make workload-sensitive decisions with limited workload-specific information, leading to poor system efficiency. Scheduler heuristics, such as cache-aware placement or migration-cost heuristics, can work well for one workload but fail to generalize. The core problem is that the scheduler usually does not know whether threads share data, whether request phases have distinct locality, how much scheduling latency a task can tolerate, or how quickly useful cache state decays after a task stops running.

The proposed direction in this talk was profile-guided scheduling: collect offline and online signals about workload behavior, then use those profiles to parameterize scheduling decisions. The talk focuses on cache locality for illustrative purposes.

The main prototype shared in the talk augments a sched_ext scheduler, scx_layered, with a profiling tool that samples memory accesses with perf, clusters threads by similarity of accessed physical addresses, and feeds the resulting groups into the scheduler. Run-time classification avoids unstable identifiers like process or thread IDs and, instead, uses thread names plus application-provided metadata such as request phase or request type.

A central mechanism used to ensure locality is "soft partitioning": dynamically sized, topology-aware CPU sets for groups of threads that appear to share data. Unlike hard partitioning, these partitions can adapt to load and preserve work conservation within and across the soft partition. The scheduler assigns cache domains, especially L3/LLC domains, to groups while resizing allocations based on observed demand.

The main case study is Meta's web-serving backend running HHVM. The workload is sensitive to scheduling behavior, including work conservation, involuntary context switches, and cache locality. On multi-CCX AMD systems, the approach separates CPU-heavy worker threads, I/O threads, and management jobs on the machine, then uses locality-derived grouping and request-phase metadata to guide placement.

The evaluation shows about 3-4% throughput improvement over the scx_layered baseline, 5-8% lower average latency, 6-7% fewer L3 misses, and 2-3% better IPC. It also provides roughly 7% better throughput than EEVDF. Dwivedi noted that a 1% gain is already considered significant for this service, so these results are practically relevant for the evaluated workload.

Several technical insights were presented. First, average utilization at 100ms-1s granularity is often the wrong signal for partition sizing; tail utilization at finer time granularity better captures bursts and avoids undersized partitions. Second, locality decisions are load-dependent. At low load, taking any idle CPU is usually better than waiting for cache affinity to achieve better results. Near saturation, it may be worth waiting briefly for a CPU in the previous cache domain if the expected locality benefit exceeds the scheduling delay. Third, request phases can have distinct locality and latency importance, so separating early latency-critical request work into its own soft partition can reduce latency. However, these phase partitions should collapse again into a single soft partition without distinction once the system exceeds its service-level objective and maximizing bandwidth is the primary goal.

The future-work section of the talk focused on highlighting unresolved questions around temporal locality and cache decay. The current approach identifies spatial sharing, but not how long cached data remains useful or how likely a task is to reuse it. Dwivedi raised questions about whether miss rate, hit rate, reuse distance, memory-access samples, or run-time perturbation experiments are the right signals. L1 and L2 locality appeared hard to exploit robustly, while L3 looked more promising because useful locality persists longer relative to scheduler decision time.

The audience discussion explored these open problems in more detail. Questions focused on whether hit rate is a better signal than miss rate for temporal reuse, whether isolation experiments translate to production, whether page faults are too expensive for run-time profiling (yes), whether L2 accesses might better characterize pressure on L3, and whether hard memory/cache partitioning would be preferable. Other suggestions included using reuse-distance analysis from richer offline traces, deliberately perturbing scheduling to measure workload sensitivity, and using stack traces or program phases to improve persistent thread identity across runs.

Overall, the talk presented profile-guided scheduling as a way to make scheduler heuristics depend on measured workload behavior rather than fixed assumptions. The key idea is to learn when locality matters, which threads should be grouped or separated, and when the latency/throughput tradeoff changes with load.

Video: Profile-Guided CPU Scheduling — Kumar Kartikeya Dwivedi

A scheduler scorecard — Steven Rostedt

The idea behind the scheduler scorecard is to rate the characteristics of the scheduler and not to add just another benchmark. For example, Rostedt brought up the characteristic of how often a scheduler migrates a task. On some architectures, migration can be expensive, but if a system has a large L3 cache that is shared among several CPUs, the cost of migration may be minimal. A benchmark for the same scheduler on two different system configurations can show drastically different results; one may show the scheduler with a high performance rate and on the other system, it would be very slow. He brought up other characteristics, such as how often a task is blocked, CPU-frequency changes, etc.

Rostedt stated that benchmarks may show how well a scheduler behaves on a particular setup but do not explain why it behaved that way. After running a benchmark on a workload, one can guess why one scheduler algorithm worked better than another but, without seeing what the scheduler actually does, that guess may be wrong. Having a scorecard that shows the characteristics of a scheduler can help determine exactly why the scheduler performed the way it did.

To support the scheduler scorecard concept, Rostedt has written has a small utility that measures various metrics. It is based on his library libtraceeval which, he stated, is not quite ready for prime time as he is not comfortable with the current API. This utility records how long each CPU is idle rather than running a task, For each process, it reports the maximum, minimum, average, and standard deviation of the time spent running on the CPU, time spent being preempted (another task is running when the task is on the run queue), wakeup latency (time spent between being woken up until it runs on the CPU), time a task was blocked (it is in the TASK_UNINTERRUPTIBLE state), and the time a task was sleeping (it is in the TASK_INTERRUPTIBLE state). It also shows the count of times the task was in each of those states. It then shows the same metrics for each of the process's specific threads. For the process, it also shows how many times the process migrated.

A real-world example of benchmark confusion came about when a member of the Pixel team tried out PREEMPT_RT and ran benchmarks on it. They used Geekbench 6 to do the benchmark; PREEMPT_RT performed 13% worse than a kernel without PREEMPT_RT enabled. A record of trace-cmd was executed on the Pixel device while running Geekbench 6 with and without PREEMPT_RT; Rostedt then used his utility on the trace.dat files produced by trace-cmd. It showed that the PREEMPT_RT run had the tasks preempted more often and for longer than without realtime, which is expected due to the way PREEMPT_RT works. This also caused tasks to be scheduled in and out much more often. The wakeup latency was pretty much the same.

One of the biggest differences was that, with PREEMPT_RT, the tasks were blocked for a much longer time than without it. This is expected, as in PREEMPT_RT, spinlocks are converted to mutexes; a task would block on contention on a realtime kernel but would not block in non-realtime as it would simply spin. The utility showed the impact of spinlocks being converted to mutexes for this particular benchmark. With further analysis, the impact of contention with the converted spinlocks was proven to be the culprit of the performance degradation in the benchmark.

Rostedt then brought up questions to the audience about what else could be recorded. He gave a list, including CPU-frequency changes, NUMA mappings, cache misses, and wakeup chains (recording what tasks wake up other tasks). There are changes to ftrace to record perf events like cache misses into the trace buffer so that the cache-miss count can be displayed at every scheduler switch. But the interface for this is not ready to be submitted upstream. Juri Lelli brought up the use of timerlat. Rostedt stated that it could also be incorporated and is not mutually exclusive to the tracing he is working on. The trace is still required to keep track of hundreds or thousands of threads, which would not be something to do inside the kernel. Rostedt also mentioned the ability to do the analysis offline and not depend on the kernel performing all of the calculations.

The session ended with various discussions about overhead of the utility, what events can be used, and other various enhancements that can be made to the tracing subsystem.

Video: Scheduler score card - Steven Rostedt (OSPM26)

Paravirtualized scheduling: a framework for better CPU usage — Shrikanth Hegde and lya Leoshkevich

The discussion started with a brief description of problem that occurs in virtualized environments with multiple virtual machines (VMs), where there is an overcommitment of CPU resources and high CPU utilization in many VMs simultaneously. Due to this overcommitment, the host cannot meet the CPU requirements, leading to vCPU preemptions, which can have a high performance cost.

A quick glance at the proposed solution was provided and discussed. The idea is simple: "steal time" — the amount of time a runnable vCPU waits for the physical CPU to become available — is a well-known metric in the VM world that indicates CPU contention. When the guest detects high steal time, it reduces its vCPU request by using fewer vCPUs. This means the workload is dynamically adjusted to use a limited set of CPUs instead of all available ones.

The lack of existing methods to fully fix the issue was discussed, followed by implementation details. A new CPU state called cpu_preferred was introduced, and its design constructs and advantages were reviewed. The talk also covered the s390 perspective of integrating this work with existing mechanisms like HiperDispatch and warning track interrupts.

Performance numbers across PowerPC, s390, and x86 systems were presented, showing significant gains in real-life workloads and microbenchmarks without major regressions. The challenges regarding upstreaming this work were then discussed. There was a general consensus among the audience that this approach is viable, and patches will be reviewed. Suggestions regarding implementation were provided, which the authors will consider for subsequent versions to be sent out soon.

Current version: https://lore.kernel.org/all/20260407191950.643549-1-sshegde@linux.ibm.com/

Video: Paravirtualized scheduling: a framework for better CPU usage — Shrikanth Hegde and lya Leoshkevich

Platform QoS — Ionela Voinescu

The talk presented an RFC for integrating platform-specific resource prioritization into the Linux quality-of-service (QoS) subsystem, focusing on ACPI CPPC resource-priority registers and SCMI QoS. The main problem described was that firmware already makes platform-specific decisions about how power or thermal headroom is distributed, but Linux has limited ability to indicate which CPUs or domains are most important for the active workload.

ACPI CPPC resource prioritization provides per-logical-CPU priority controls for resources such as processor boost, processor throttle, cache access, and memory bandwidth. These priorities allow the operating system to indicate, for example, which CPUs should receive boost preferentially, or which CPUs should be throttled later under constrained conditions. SCMI QoS provides a similar mechanism through SCMI performance domains, with support for boost and throttle prioritization using either relative priorities or weights. Unlike CPPC, SCMI QoS is domain-based and does not cover cache or memory-bandwidth prioritization, which are expected to be handled through mechanisms such as resctrl.

The discussion points were mainly around the shape of the Linux interface. One option is an administrator-oriented interface, similar in spirit to resctrl, where privileged software configures priorities explicitly. This is more suitable for server-oriented use cases with pinned workloads and relatively stable policies. Another option is a more dynamic scheduler or task-driven model, where priorities are inferred from existing kernel signals such as control groups, uclamp, or future task attributes. This may be more suitable for edge use cases, but only if firmware transport and reaction latency are sufficiently low.

A key point raised in the discussion was that the interface should be motivated by concrete use cases rather than by the existence of new firmware controls. The clearest example discussed was a power or thermally constrained mobile-gaming scenario, where the system may need to protect the CPU running the main game thread from throttling, or direct available boost budget toward it.

There was broad agreement that cache and memory-bandwidth prioritization should not duplicate existing mechanisms such as resctrl. The more relevant gap is boost and throttle prioritization, where cpufreq can request performance levels but cannot express which CPU should receive opportunistic boost or be throttled last.

The main outcome of the discussion was that there is not yet enough justification for a rich, scheduler-facing, per-task interface. A scheduler-integrated model may still be relevant in the future, but it would require concrete use cases, clear semantics, and evidence that firmware can react quickly enough for task-following behavior to be useful. The current viable direction is therefore a simpler privileged user-space interface. This could either be an independent ABI for boost and throttle prioritization, or an extension to resctrl.

Video Platform QoS — Ionela Voinescu

A latency-focused QoS framework backend for kernel devices — Lukasz Luba and Chris Redpath

This talk presented an early proposal for a latency-focused quality-of-service framework aimed at improving coordination between kernel-managed devices such as CPUs, caches, memory, and interconnects. The motivation stems from the observation that modern systems rely on multiple governors, drivers, and firmware components independently inferring workload requirements and making performance decisions, often based on incomplete information and without awareness of the actions taken elsewhere in the system.

The speakers argued that many workloads ultimately care about latency rather than specific resource settings such as frequencies or performance states. Today, mechanisms such as scheduler-utilization signals, utilization clamping, cpufreq governors, and firmware-managed policies attempt to translate workload behavior into performance decisions, but much of the original intent can be lost as requests propagate through the stack. As a result, different devices may react inconsistently or redundantly to the same workload.

The proposed framework would treat latency as a first-class concept and provide a common mechanism for propagating latency requirements to registered devices. Rather than each subsystem independently attempting to infer application needs, devices could receive a more explicit representation of workload requirements and coordinate their responses. This could help avoid situations where CPUs, memory controllers, caches, and interconnects make separate policy decisions that are individually reasonable but collectively suboptimal.

A significant part of the discussion focused on how such a framework could coexist with existing kernel infrastructure. Participants explored the relationship with utilization-based scheduling signals, uclamp, operating performance points (OPPs), cpufreq, and firmware-controlled performance management. Questions were raised about the proper level of abstraction, how latency requirements should be represented, and whether the effort should be limited to backend infrastructure or eventually provide a frontend interface through which applications and middleware could express QoS requirements directly.

The audience generally agreed that current systems suffer from fragmented policy decisions and that preserving workload intent across subsystem boundaries is an important challenge. At the same time, several open questions remain regarding the exact interfaces, ownership of policy decisions, and integration with existing kernel mechanisms. The session concluded as a design discussion rather than a concrete implementation proposal, with future work to be focused on refining the architecture, identifying practical use cases, and evaluating whether coordinated latency propagation can provide measurable improvements in responsiveness and energy efficiency.

Video: Latency-focused QoS framework backend for kernel devices - Lukasz Luba and Chris Redpath (OSPM26)

Improving the SCHED_DEADLINE wakeup rule in presence of micro-sleeps — Tommaso Cucinotta and Luca Abeni

Cucinotta shared his progress (Abeni was not present) on refining the deadline scheduler (SCHED_DEADLINE) wakeup behavior for tasks that undergo brief suspension phases. The core of the presentation addressed a known edge case within the "revised wakeup rule" of the Linux constant bandwidth server (CBS) implementation, which triggers when a task resumes execution before the end of its current reservation window.

The issue manifests during "micro-sleeps": situations where a deadline task suspends for a negligible duration while still possessing a substantial portion of its run-time budget. The current CBS logic may respond by aggressively truncating the task's remaining budget to maintain the bandwidth ratio. Although this behavior upholds the theoretical isolation properties of the scheduler, Cucinotta argued that it is often overly pessimistic for real-world applications.

A simple scenario was presented to illustrate the problem: two deadline tasks competing for a single CPU. If the second task performs a momentary sleep shortly after it begins its work, the scheduler might slash its budget even though, had the task remained active, it would have finished its execution without causing any additional system interference. Consequently, a minor suspension results in an unwarranted penalty that reduces the work the task can actually complete.

The proposed solution involves an adjustment to the wakeup logic. Rather than strictly following the budget reduction mandated by the revised CBS rule, the scheduler would evaluate two alternatives — including the run time the task would have held had it never suspended — and select the maximum safe value. This approach aims to uphold temporal isolation while preventing the unnecessary loss of budget during transient inactivity.

Attendees questioned whether this optimization remains mathematically sound within the CBS framework. Cucinotta maintained that the refined rule preserves existing isolation guarantees while aligning more closely with practical user expectations. Attendees explored various execution paths and edge cases, particularly focusing on configurations where task deadlines do not match their periods, as these are the most sensitive to wakeup-rule variations.

This led to a broader exploration of the interface between applications and the deadline-scheduler policy. The discussion covered the fundamental semantics of run time, deadline, and period, as well as the alignment of reservation windows. Several participants sought clarification on how software can better anticipate the scheduler's internal decisions and the nuances of task resumption compared to application-level timing requirements.

A specific question was aimed at clarifying whether the revised wakeup rule that keeps the deadline but reduces the run time would be always better than the traditional CBS wakeup rule that resets the parameters to maximum run time and deadline one period apart. The traditional behavior is still useful because it provides SCHED_DEADLINE with a self-synchronizing ability: waking up a tiny bit before the programmed deadline, which is a common situation if the application uses its own timer or wakes up in response to external stimuli, causes a SCHED_DEADLINE task to start afresh with reset parameters, and this is what the user mostly expects.

Using the revised rule in such a case would force the task to keep its absolute deadline, slashing the remaining budget and quite likely causing a forced throttling of the task until its former deadline, causing an unexpected delay and de-synchronization of the task due to the in-kernel time accounting not matching the one used in user-space. Eventually, Cucinotta argued that an end user might want to choose among the two behaviors, so this could be done properly by adding another flag to the sched_setattr() API to explicitly request the revised rule (in the current API, you can force use of the revised wakeup rule by setting "period = deadline + 1ns", which seems a weird way to request that).

Then, the thread of the conversation revisited the need for better user-space observability. The authors discussed an earlier proposal to expose a task's current absolute deadline and instantaneous budget through an enhanced sched_getattr() system call. Current procfs entries were described as inadequate because they lack realtime updates and use internal kernel timestamps, whereas the new interface would provide actionable data that developers can correlate with their own timing logic.

The session also reviewed several advanced features of the subsystem, such as bandwidth reclamation via the GRUB flag, notifications for run-time overruns, and the constraints surrounding the creation of new deadline processes. These points were raised by audience members interested in the practicalities of deploying and debugging deadline-scheduled workloads in production environments.

The consensus among the attendees was that the current wakeup rule is indeed too conservative for workloads characterized by micro-sleeps. The proposed modification was viewed as a targeted usability fix that improves the experience for developers without altering the fundamental semantics of the CBS algorithm.

Moving forward, the authors plan to validate the new rule against a wider array of workloads and edge cases while continuing the review process on the mailing lists. The evaluation of new user-space interfaces remains a priority, reflecting a sustained interest in making the deadline scheduler more transparent and easier to integrate into complex application stacks while keeping its strong temporal guarantees intact.

Video: Improving the SCHED_DEADLINE wake-up rule in presence of micro-sleeps - Tommaso Cucinotta (OSPM26)

Comments (none posted)

Page editor: Joe Brockmeier

Brief items

Security

The "Akrites" vulnerability-mitigation project launches

The Linux Foundation, in a letter co-signed by a large range of organizations and companies, has announced the launch of "Akrites", a project to fast-track vulnerability fixes into projects.

As Akrites works upstream to fix projects at the source, we commit to support downstream efforts to secure critical infrastructure before it can be exploited. When patches are released to the public, adversaries are able to utilize AI to rapidly reverse engineer the underlying vulnerabilities, develop exploits, and launch attacks. The success of our efforts therefore will be measured in patch deployment, not publication. We will partner with critical infrastructure owners and operators, civil society efforts, and governments as they increase coordination to achieve these goals.

Confidentiality is non-negotiable: An undisclosed flaw in a widely deployed package is, in effect, a weapon, and the program is built first to prevent leaks. Fixes flow back into each project's own home, working with the maintainers. The engineering resources and other capabilities provided by Akrites participants contribute to this effort. Additionally, when a critical package has no one maintaining it, Akrites will stand as the maintainer of last resort so a fix can still reach everyone in a timely fashion. We will also align with government efforts so that public and private defenders move together, rather than in a disjointed fashion.

Comments (9 posted)

Security quote of the week

The fediverse and decentralized social networks in general are a counter-point to centralization. The thing is, when working on decentralized tech, I always believed it was important because we had serious risks from centralization, surveillance, etc from governments and corporations, potentially co-conspiring. But what I hadn't anticipated is that as things became more centralized, the will to fight for the internet as something in the public interest too would evaporate.

When I have conversations with family members and friends who haven't yet thought much about the age verification and similar bills and their consequences, they've said "well, someone has to hold corporations like Meta" responsible. To which I say, "but what about all the smaller, non-corporate parts of the internet?" To which, many people are surprised, because they've simply forgotten about those things.

When the internet and computing becomes five corporations to most people, they begin to treat it as the concerns of reigning in five corporations.

— Christine Lemmer-Webber

Comments (1 posted)

Kernel development

Kernel release status

The current development kernel is 7.2-rc1, released on June 28. Linus said: "So two weeks have passed, and the merge window is closed. Things look reasonably normal for this release (knock wood)."

This release has seen 13,412 non-merge changesets from 2,138 developers, 404 of whom were first-time kernel contributors. The release history looks like:

RCDateCommits
v7.2-rc1 2026-06-2814395 14395

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

Stable updates: 7.1.2, 7.0.14, and 6.18.37 were released on June 27. Note that 7.0.14 is the end of the 7.0.x series.

Comments (none posted)

Quotes of the week

The kernel is a memory manager first, a scheduler second, all else is commentary.
— H. Peter Anvin

Some filesystem people might have things to say about that. But increasingly the kernel is just the runtime for eBPF programs ;-)
— Matthew Wilcox

I consider Reviewed-by to be stronger than Acked-by. I suspect the latter sometimes means "cool changelog!".
— Andrew Morton

Comments (none posted)

Distributions

Mageia 10 released

Mageia 10 has been released with the 6.18 Linux kernel, DNF 5.4.0, RPM 4.20.1, and an increase in hardware requirements for x86 32-bit systems; users now need a CPU with SSE2 features. See the release notes for a full list of updates, and the errata page for known problems.

Comments (2 posted)

Distributions quote of the week

I still believe that the scenery surprises are not harmful, but I also take in consideration:

  • many people are worried about xsnow's behavior
  • some people are spending time on this issue, e.g. I noticed that Slackware distributes a patched version
  • the surprise is causing much more of a stir than intended

So I will create a new version of xsnow, without the offending surprises [...]

— Willem Vermin in response to a bug report about xsnow's behavior

Comments (none posted)

Development

Git 2.55.0 released

Git maintainer Junio Hamano has announced Git 2.55.0, which has non-merge commits from 100 people; 33 of those are first-time contributors to the project. LWN recently covered some of the noteworthy changes in 2.55, including new features for the experimental "git history" command, addition of the Git fsmonitor daemon for Linux systems, and more.

Comments (4 posted)

Open source maintainership in the age of AI (Kubernetes blog)

The Kubernetes project has published a blog post explaining its AI policy:

The main problem is that AI has made generating code fast but there has been very little improvement in maintaining code bases. In this post, we will highlight the ways the Kubernetes community is adapting to the world of AI assisted coding.

The first step of this journey was to develop an AI policy. This seems mundane and bureaucratic but there were many PRs that derailed into discussions around AI usage. The AI policy helps steer the conversation around the project's stance on AI and provides a clear signal to contributors on how to use these tools responsibly.

Of note, the project requires disclosure when AI tools have been used to assist in the creation of a contribution but forbids the use of listing AI as a co-author or including "assisted-by" or "co-developed" trailers to attribute work to an LLM tool.

Comments (13 posted)

Podman 6.0 released

Version 6.0.0 of the Podman container-management tool has been released. Notable new features include the ability to set multiple static IP addresses for containers, improvements in network isolation that make Podman more compatible with Docker, changes to the way Quadlet commands function, many new options for many existing podman commands, and a rewrite of Podman's configuration file handling. There are many breaking changes; see the release notes for a full list of all new features, changes, and bug fixes.

Comments (none posted)

Lots of stories about systemd v261

Lennart Poettering has posted a list of Mastodon posts about the changes in the systemd v261 release. The Mastodon format makes the reading harder, but there is a lot of useful information there.

Comments (12 posted)

Development quote of the week

I started out slightly optimistic about CRA [Cyber Resilience Act] being an avenue for companies to (financially) support the projects they rely on, but as I personally see a complete lack of interest in this from companies even though I can sell it to them and we're approaching the date CRA goes live for real, I can only conclude that the money for CRA compliance will, as usual, end up in some middle mens' pockets. Not in the open source projects'.
— Daniel Stenberg

Comments (none posted)

Miscellaneous

Creative Commons founders' fireside chat (Creative Commons blog)

Dee Harris has published a summary of the recent "fireside chat" featuring Creative Commons founders Hal Abelson, Lawrence (Larry) Lessig, Molly Van Houweling, and Glenn Otis Brown. The chat was to mark the 25th anniversary of Creative Commons and included a look back at its history as well as a look at the landscape today:

Twenty-five years ago, a small group of people made a bet. They believed that if you gave creators a simple set of tools and licenses in language that a lawyer, a machine, and a human could all read, millions of people might choose to share their work with the world instead of locking it down.

The video of the chat is available on YouTube.

Comments (none posted)

Page editor: Daroc Alden

Announcements

Newsletters

Kernel development

DAMON Release Newsletter for v7.2-rc1 June 28

Distributions and system administration

Asahi Linux Progress Report June 30
DistroWatch Weekly June 29
This week in F-Droid June 26
openSUSE Tumbleweed Review of the Week June 27
Ubuntu Weekly News June 22

Development

Emacs News June 29
GCC 14.4.1 Status Report June 26
GCC 16.1.1 Status Report July 1
What's cooking in git.git June 25
What's cooking in git.git June 29
This Week in GNOME June 26
GNU Tools Weekly News June 28
Golang Weekly June 26
Koha Community Newsletter June
Last Week in Kubernetes Development June 26
LLVM Weekly June 29
This Week in Matrix June 26
OCaml Weekly News June 30
Perl Weekly June 29
This Week in Plasma June 27
PyCoder's Weekly June 30
Weekly Rakudo News June 29
Ruby Weekly News June 25
This Week in Rust June 24
Wikimedia Tech News June 29

Meeting minutes

This week in the Perl Steering Committee June 25

Calls for Presentations

CFP Deadlines: July 2, 2026 to August 31, 2026

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

DeadlineEvent Dates EventLocation
July 3 September 28
September 30		 X.Org Developers Conference Toronto, Canada
July 14 September 17
September 18		 Git Merge Lisbon, Portugal
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 September 28
October 1		 Alpine Linux Persistence and Storage Summit Lizumerhütte, Tyrol, Austria
August 1 August 25
August 30		 MiniDebConf and MiniDebCamp Winterthur 2026 Winterthur, Switzerland

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

Upcoming Events

Events: July 2, 2026 to August 31, 2026

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

Date(s)EventLocation
July 13
July 19		 DebCamp 26 Santa Fe, Argentina
July 13
July 16		 Netdev Rome, Italy
July 13
July 19		 EuroPython Kraków, Poland
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
August 25
August 30		 MiniDebConf and MiniDebCamp Winterthur 2026 Winterthur, Switzerland

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

Security updates

Alert summary June 25, 2026 to July 1, 2026

Dist. ID Release Package Date
AlmaLinux ALSA-2026:29195 10 buildah 2026-06-25
AlmaLinux ALSA-2026:29455 9 buildah 2026-06-25
AlmaLinux ALSA-2026:29703 9 containernetworking-plugins 2026-06-29
AlmaLinux ALSA-2026:33124 10 coreutils 2026-06-30
AlmaLinux ALSA-2026:28911 9 coreutils 2026-06-25
AlmaLinux ALSA-2026:28998 8 evince 2026-06-25
AlmaLinux ALSA-2026:33412 10 galera and mariadb11.8 2026-06-30
AlmaLinux ALSA-2026:33502 10 giflib 2026-07-01
AlmaLinux ALSA-2026:30855 10 git-lfs 2026-06-30
AlmaLinux ALSA-2026:30853 8 git-lfs 2026-06-29
AlmaLinux ALSA-2026:30854 9 git-lfs 2026-06-30
AlmaLinux ALSA-2026:33092 10 glibc 2026-06-30
AlmaLinux ALSA-2026:33126 8 glibc 2026-06-30
AlmaLinux ALSA-2026:33226 9 glibc 2026-06-30
AlmaLinux ALSA-2026:20597 9 glibc 2026-06-30
AlmaLinux ALSA-2026:29980 10 golang 2026-06-27
AlmaLinux ALSA-2026:29981 9 golang 2026-06-29
AlmaLinux ALSA-2026:34109 10 httpd 2026-07-01
AlmaLinux ALSA-2026:30129 10 kernel 2026-06-27
AlmaLinux ALSA-2026:27288 10 kernel 2026-06-26
AlmaLinux ALSA-2026:30848 9 kernel 2026-06-30
AlmaLinux ALSA-2026:28233 10 libpng 2026-06-24
AlmaLinux ALSA-2026:29898 8 libpng 2026-06-26
AlmaLinux ALSA-2026:28255 9 libpng 2026-06-25
AlmaLinux ALSA-2026:28244 9 libpng15 2026-06-26
AlmaLinux ALSA-2026:28922 8 libreoffice 2026-06-25
AlmaLinux ALSA-2026:28236 10 libsolv 2026-06-24
AlmaLinux ALSA-2026:28235 10 libtasn1 2026-06-24
AlmaLinux ALSA-2026:28253 9 libtasn1 2026-06-25
AlmaLinux ALSA-2026:28234 10 libxml2 2026-06-24
AlmaLinux ALSA-2026:28254 9 libxml2 2026-06-25
AlmaLinux ALSA-2026:28584 10 libxslt 2026-06-24
AlmaLinux ALSA-2026:28243 9 libxslt 2026-06-25
AlmaLinux ALSA-2026:33093 10 mariadb10.11 2026-06-30
AlmaLinux ALSA-2026:30845 10 mod_md 2026-06-30
AlmaLinux ALSA-2026:30844 9 mod_md 2026-06-30
AlmaLinux ALSA-2026:29874 10 nginx 2026-06-26
AlmaLinux ALSA-2026:28973 9 nginx 2026-06-25
AlmaLinux ALSA-2026:28921 8 nginx:1.24 2026-06-25
AlmaLinux ALSA-2026:28212 9 nginx:1.24 2026-06-25
AlmaLinux ALSA-2026:29151 9 nginx:1.26 2026-06-25
AlmaLinux ALSA-2026:28256 9 opencryptoki 2026-06-26
AlmaLinux ALSA-2026:30857 10 perl-Archive-Tar 2026-06-30
AlmaLinux ALSA-2026:30852 8 perl-Archive-Tar 2026-06-29
AlmaLinux ALSA-2026:30856 9 perl-Archive-Tar 2026-06-30
AlmaLinux ALSA-2026:30860 10 perl-IO-Compress 2026-06-30
AlmaLinux ALSA-2026:30858 8 perl-IO-Compress 2026-06-29
AlmaLinux ALSA-2026:30859 9 perl-IO-Compress 2026-06-29
AlmaLinux ALSA-2026:30851 8 perl:5.32 2026-06-30
AlmaLinux ALSA-2026:28999 8 postgresql:12 2026-06-25
AlmaLinux ALSA-2026:28158 9 python-urllib3 2026-06-25
AlmaLinux ALSA-2026:32992 8 python3.12-urllib3 2026-06-29
AlmaLinux ALSA-2026:28159 9 python3.12-urllib3 2026-06-25
AlmaLinux ALSA-2026:28581 10 python3.14 2026-06-24
AlmaLinux ALSA-2026:28247 9 python3.14 2026-06-25
AlmaLinux ALSA-2026:28157 9 python3.14-urllib3 2026-06-25
AlmaLinux ALSA-2026:33731 10 rrdtool 2026-07-01
AlmaLinux ALSA-2026:33565 10 ruby 2026-07-01
AlmaLinux ALSA-2026:33540 10 ruby4.0 2026-07-01
AlmaLinux ALSA-2026:29702 9 runc 2026-06-29
AlmaLinux ALSA-2026:29035 10 skopeo 2026-06-25
AlmaLinux ALSA-2026:30846 10 thunderbird 2026-06-30
AlmaLinux ALSA-2026:33445 8 thunderbird 2026-06-30
AlmaLinux ALSA-2026:29940 9 thunderbird 2026-06-26
AlmaLinux ALSA-2026:28923 8 tigervnc 2026-06-25
AlmaLinux ALSA-2026:19342 9 tigervnc 2026-06-24
AlmaLinux ALSA-2026:29844 9 tigervnc 2026-06-29
AlmaLinux ALSA-2026:26323 9 tomcat 2026-06-25
AlmaLinux ALSA-2026:28210 10 vim 2026-06-24
AlmaLinux ALSA-2026:28209 9 vim 2026-06-25
Debian DLA-4654-1 LTS chromium 2026-06-27
Debian DSA-6364-1 stable chromium 2026-06-25
Debian DLA-4645-1 LTS cloud-init 2026-06-24
Debian DLA-4659-1 LTS debian-security-support 2026-06-30
Debian DSA-6367-1 stable dnsdist 2026-06-25
Debian DLA-4652-1 LTS gdcm 2026-06-26
Debian DLA-4650-1 LTS giflib 2026-06-26
Debian DSA-6370-1 stable incus 2026-06-26
Debian DLA-4649-1 LTS libdbi-perl 2026-06-26
Debian DLA-4655-1 LTS libhtml-parser-perl 2026-06-28
Debian DLA-4658-1 LTS librabbitmq 2026-06-30
Debian DSA-6365-1 stable libssh2 2026-06-25
Debian DLA-4648-1 LTS libtext-csv-xs-perl 2026-06-25
Debian DSA-6373-1 stable lxd 2026-06-28
Debian DLA-4660-1 LTS nginx 2026-06-30
Debian DSA-6374-1 stable nginx 2026-06-30
Debian DLA-4653-1 LTS openvpn 2026-06-27
Debian DSA-6369-1 stable pdns-recursor 2026-06-25
Debian DSA-6368-1 stable pdns 2026-06-25
Debian DLA-4646-1 LTS postgresql-13 2026-06-24
Debian DLA-4651-1 LTS python-urllib3 2026-06-26
Debian DLA-4657-1 LTS sogo 2026-06-29
Debian DSA-6366-1 stable sogo 2026-06-25
Debian DLA-4656-1 LTS tor 2026-06-28
Debian DSA-6372-1 stable tor 2026-06-28
Debian DSA-6370-1 stable xorg-server 2026-06-27
Debian DLA-4647-1 LTS yelp 2026-06-25
Fedora FEDORA-2026-ddd87cb1db F43 chromium 2026-06-28
Fedora FEDORA-2026-7f29bc3622 F43 chromium 2026-07-01
Fedora FEDORA-2026-148601cd51 F44 chromium 2026-06-29
Fedora FEDORA-2026-504709cab7 F44 chromium 2026-06-27
Fedora FEDORA-2026-7f36ec4c65 F43 collectd 2026-07-01
Fedora FEDORA-2026-1a714d39b0 F43 docker-buildkit 2026-06-27
Fedora FEDORA-2026-1e00728616 F44 docker-buildkit 2026-06-27
Fedora FEDORA-2026-3cca6f41d4 F43 docker-buildx 2026-06-27
Fedora FEDORA-2026-105f7df940 F44 docker-buildx 2026-06-27
Fedora FEDORA-2026-a424c1061e F43 dotnet10.0 2026-06-28
Fedora FEDORA-2026-dec081126f F44 dotnet10.0 2026-06-28
Fedora FEDORA-2026-2f80369c73 F43 dotnet8.0 2026-06-28
Fedora FEDORA-2026-041785a779 F44 dotnet8.0 2026-06-28
Fedora FEDORA-2026-2954cd11bd F43 dotnet9.0 2026-06-28
Fedora FEDORA-2026-0dce096c13 F44 dotnet9.0 2026-06-28
Fedora FEDORA-2026-08bb036c3e F43 goose 2026-06-25
Fedora FEDORA-2026-00021c7c91 F44 goose 2026-06-25
Fedora FEDORA-2026-37947358ea F43 httpd 2026-06-25
Fedora FEDORA-2026-45b342f7c1 F43 krita 2026-06-28
Fedora FEDORA-2026-3bb1c72ffd F44 krita 2026-06-28
Fedora FEDORA-2026-b33ba1aa06 F43 ldns 2026-06-27
Fedora FEDORA-2026-454722e3d8 F43 librabbitmq 2026-06-26
Fedora FEDORA-2026-ca858b3ed8 F44 libssh2 2026-06-29
Fedora FEDORA-2026-79d9e34e36 F44 liferea 2026-06-27
Fedora FEDORA-2026-d7d472853a F43 lighttpd 2026-06-27
Fedora FEDORA-2026-1907dd9339 F44 lighttpd 2026-06-27
Fedora FEDORA-2026-7726bdbcf1 F44 maradns 2026-07-01
Fedora FEDORA-2026-efc64a64ec F43 mariadb10.11 2026-06-29
Fedora FEDORA-2026-3fdd0e930d F44 mariadb11.8 2026-06-29
Fedora FEDORA-2026-0feb6e4967 F43 moby-engine 2026-06-28
Fedora FEDORA-2026-d8e03bae55 F44 moby-engine 2026-06-28
Fedora FEDORA-2026-9d7328702e F43 nginx 2026-06-27
Fedora FEDORA-2026-b8e751787c F44 nginx 2026-06-27
Fedora FEDORA-2026-9d7328702e F43 nginx-mod-brotli 2026-06-27
Fedora FEDORA-2026-b8e751787c F44 nginx-mod-brotli 2026-06-27
Fedora FEDORA-2026-9d7328702e F43 nginx-mod-fancyindex 2026-06-27
Fedora FEDORA-2026-b8e751787c F44 nginx-mod-fancyindex 2026-06-27
Fedora FEDORA-2026-9d7328702e F43 nginx-mod-headers-more 2026-06-27
Fedora FEDORA-2026-b8e751787c F44 nginx-mod-headers-more 2026-06-27
Fedora FEDORA-2026-b8e751787c F44 nginx-mod-js-challenge 2026-06-27
Fedora FEDORA-2026-9d7328702e F43 nginx-mod-modsecurity 2026-06-27
Fedora FEDORA-2026-b8e751787c F44 nginx-mod-modsecurity 2026-06-27
Fedora FEDORA-2026-9d7328702e F43 nginx-mod-naxsi 2026-06-27
Fedora FEDORA-2026-b8e751787c F44 nginx-mod-naxsi 2026-06-27
Fedora FEDORA-2026-9d7328702e F43 nginx-mod-vts 2026-06-27
Fedora FEDORA-2026-b8e751787c F44 nginx-mod-vts 2026-06-27
Fedora FEDORA-2026-da7e499416 F43 openbao 2026-06-27
Fedora FEDORA-2026-84ff0044db F44 openbao 2026-06-27
Fedora FEDORA-2026-6a4bfb1309 F43 pacemaker 2026-06-27
Fedora FEDORA-2026-2c31df81dc F44 pacemaker 2026-06-27
Fedora FEDORA-2026-7ecfdcf0e3 F44 perl-Compress-Raw-Bzip2 2026-06-26
Fedora FEDORA-2026-d74dd170ab F43 perl-DBI 2026-06-30
Fedora FEDORA-2026-134fcb8549 F44 perl-DBI 2026-06-26
Fedora FEDORA-2026-7ecfdcf0e3 F44 perl-IO-Compress 2026-06-26
Fedora FEDORA-2026-7df6c5acad F43 perl-Socket 2026-06-30
Fedora FEDORA-2026-91d6cb99f7 F44 perl-Socket 2026-06-26
Fedora FEDORA-2026-5938be3b09 F43 pgadmin4 2026-06-28
Fedora FEDORA-2026-c248414214 F44 pgadmin4 2026-06-28
Fedora FEDORA-2026-ac94948c8a F43 podman-tui 2026-06-29
Fedora FEDORA-2026-c55ec73fe2 F44 podman-tui 2026-06-29
Fedora FEDORA-2026-460749ef95 F43 prometheus-podman-exporter 2026-06-29
Fedora FEDORA-2026-3c6643b33a F44 prometheus-podman-exporter 2026-06-29
Fedora FEDORA-2026-2c5cde060d F44 python-django-allauth 2026-06-26
Fedora FEDORA-2026-1d2c7eaa2f F43 python-django-haystack 2026-07-01
Fedora FEDORA-2026-3e10194134 F44 python-django-haystack 2026-07-01
Fedora FEDORA-2026-9536c7cb79 F43 python-jupyter-server 2026-06-27
Fedora FEDORA-2026-31e6b85f4e F43 python-jupytext 2026-07-01
Fedora FEDORA-2026-db770b7d7a F44 python-jupytext 2026-07-01
Fedora FEDORA-2026-c52d83db89 F43 python-mistune 2026-06-28
Fedora FEDORA-2026-3b027683d8 F44 python-mistune 2026-06-28
Fedora FEDORA-2026-c2b475c5f1 F43 python-postorius 2026-06-27
Fedora FEDORA-2026-ef34f94241 F44 python-postorius 2026-06-27
Fedora FEDORA-2026-ade10efd88 F43 python-pydantic-settings 2026-06-29
Fedora FEDORA-2026-6b7571be30 F44 python-pydantic-settings 2026-06-28
Fedora FEDORA-2026-b17b2a984a F43 python3-docs 2026-06-28
Fedora FEDORA-2026-b17b2a984a F43 python3.14 2026-06-28
Fedora FEDORA-2026-a04e445b3f F43 rsync 2026-06-26
Fedora FEDORA-2026-67a9805962 F43 strongswan 2026-06-25
Fedora FEDORA-2026-cda0c20ce0 F44 thunderbird 2026-06-27
Fedora FEDORA-2026-ad10afa9cd F43 tigervnc 2026-06-27
Fedora FEDORA-2026-77f1ca9c8f F43 tinyproxy 2026-06-27
Fedora FEDORA-2026-efbe094630 F44 tinyproxy 2026-06-27
Fedora FEDORA-2026-a7ff7017ee F43 util-linux 2026-06-27
Fedora FEDORA-2026-7f36ec4c65 F43 varnish 2026-07-01
Fedora FEDORA-2026-7f36ec4c65 F43 varnish-modules 2026-07-01
Fedora FEDORA-2026-7f36ec4c65 F43 vmod-querystring 2026-07-01
Mageia MGASA-2026-0233 9 krb5 2026-06-27
Mageia MGASA-2026-0232 9 nats-server 2026-06-25
Oracle ELSA-2026-25222 OL9 .NET 10.0 2026-06-24
Oracle ELSA-2026-21297 OL9 .NET 10.0 2026-06-26
Oracle ELSA-2026-25220 OL9 .NET 8.0 2026-06-24
Oracle ELSA-2026-21293 OL9 .NET 8.0 2026-06-26
Oracle ELSA-2026-25221 OL9 .NET 9.0 2026-06-24
Oracle ELSA-2026-21296 OL9 .NET 9.0 2026-06-26
Oracle ELSA-2026-26455 OL9 389-ds-base 2026-06-25
Oracle ELSA-2026-24367 OL9 bind 2026-06-26
Oracle ELSA-2026-24368 OL9 bind9.18 2026-06-24
Oracle ELSA-2026-29455 OL9 buildah 2026-06-25
Oracle ELSA-2026-21468 OL9 cockpit 2026-06-24
Oracle ELSA-2026-22313 OL9 compat-openssl11 2026-06-24
Oracle ELSA-2026-29703 OL9 containernetworking-plugins 2026-06-25
Oracle ELSA-2026-28911 OL9 coreutils 2026-06-25
Oracle ELSA-2026-19373 OL9 dnsmasq 2026-06-24
Oracle ELSA-2026-19364 OL9 dovecot 2026-06-24
Oracle ELSA-2026-26533 OL9 dracut 2026-06-26
Oracle ELSA-2026-28998 OL8 evince 2026-06-24
Oracle ELSA-2026-27819 OL9 evince 2026-06-25
Oracle ELSA-2026-23230 OL9 expat 2026-06-24
Oracle ELSA-2026-26206 OL9 fence-agents 2026-06-25
Oracle ELSA-2026-19355 OL9 fence-agents 2026-06-26
Oracle ELSA-2026-24983 OL7 firefox 2026-07-01
Oracle ELSA-2026-26551 OL7 firefox 2026-07-01
Oracle ELSA-2026-27734 OL9 firefox 2026-06-26
Oracle ELSA-2026-19370 OL9 firefox 2026-06-30
Oracle ELSA-2026-21378 OL9 firefox 2026-06-30
Oracle ELSA-2026-20574 OL9 firefox 2026-06-30
Oracle ELSA-2026-21755 OL9 flatpak 2026-06-24
Oracle ELSA-2026-19358 OL9 freerdp 2026-06-24
Oracle ELSA-2026-19349 OL9 freerdp 2026-06-29
Oracle ELSA-2026-24371 OL9 frr 2026-06-26
Oracle ELSA-2026-24370 OL9 frr10 2026-06-26
Oracle ELSA-2026-19367 OL9 giflib 2026-06-25
Oracle ELSA-2026-19362 OL9 gimp 2026-06-24
Oracle ELSA-2026-30853 OL8 git-lfs 2026-06-30
Oracle ELSA-2026-19350 OL9 git-lfs 2026-06-25
Oracle ELSA-2026-30854 OL9 git-lfs 2026-07-01
Oracle ELSA-2026-19361 OL9 glib2 2026-06-26
Oracle ELSA-2026-20597 OL9 glibc 2026-06-26
Oracle ELSA-2026-20612 OL9 gnutls 2026-06-26
Oracle ELSA-2026-22121 OL9 golang 2026-06-24
Oracle ELSA-2026-29981 OL9 golang 2026-06-26
Oracle ELSA-2026-19352 OL9 grafana 2026-06-24
Oracle ELSA-2026-19351 OL9 grafana-pcp 2026-06-24
Oracle ELSA-2026-26297 OL9 hplip 2026-06-25
Oracle ELSA-2026-21391 OL9 httpd 2026-06-24
Oracle ELSA-2026-20568 OL9 jmc 2026-06-24
Oracle ELSA-2026-19365 OL9 jq 2026-06-24
Oracle ELSA-2026-50353 OL7 kernel 2026-07-01
Oracle ELSA-2026-27811 OL8 kernel 2026-06-24
Oracle ELSA-2026-50353 OL8 kernel 2026-07-01
Oracle ELSA-2026-50353 OL8 kernel 2026-07-01
Oracle ELSA-2026-50352 OL8 kernel 2026-07-01
Oracle ELSA-2026-27789 OL9 kernel 2026-06-26
Oracle ELSA-2026-50352 OL9 kernel 2026-07-01
Oracle ELSA-2026-24381 OL9 kernel 2026-07-01
Oracle ELSA-2026-25217 OL9 kernel 2026-07-01
Oracle ELSA-2026-50352 OL9 kernel 2026-07-01
Oracle ELSA-2026-50351 OL9 kernel 2026-07-01
Oracle ELSA-2026-19357 OL9 krb5 2026-06-25
Oracle ELSA-2026-19346 OL9 libcap 2026-06-25
Oracle ELSA-2026-22553 OL9 libexif 2026-06-25
Oracle ELSA-2026-29898 OL8 libpng 2026-06-26
Oracle ELSA-2026-28255 OL9 libpng 2026-06-26
Oracle ELSA-2026-28244 OL9 libpng15 2026-06-26
Oracle ELSA-2026-28922 OL8 libreoffice 2026-06-26
Oracle ELSA-2026-19610 OL9 libsndfile 2026-06-24
Oracle ELSA-2026-24722 OL7 libsoup 2026-06-30
Oracle ELSA-2026-19356 OL9 libsoup 2026-06-24
Oracle ELSA-2026-28253 OL9 libtasn1 2026-06-25
Oracle ELSA-2026-19363 OL9 libtiff 2026-06-24
Oracle ELSA-2026-22420 OL7 libxml2 2026-06-30
Oracle ELSA-2026-28254 OL9 libxml2 2026-06-26
Oracle ELSA-2026-28243 OL9 libxslt 2026-06-26
Oracle ELSA-2026-27862 OL9 memcached 2026-06-25
Oracle ELSA-2026-25057 OL9 mod_http2 2026-06-24
Oracle ELSA-2026-22551 OL9 mod_http2 2026-06-26
Oracle ELSA-2026-30844 OL9 mod_md 2026-06-30
Oracle ELSA-2026-23332 OL9 mysql 2026-06-29
Oracle ELSA-2026-25919 OL8 mysql:8.0 2026-06-24
Oracle ELSA-2026-25052 OL9 mysql:8.4 2026-06-26
Oracle ELSA-2026-19374 OL9 nginx 2026-06-24
Oracle ELSA-2026-28921 OL8 nginx:1.24 2026-06-24
Oracle ELSA-2026-19371 OL9 nginx:1.24 2026-06-24
Oracle ELSA-2026-28212 OL9 nginx:1.24 2026-07-01
Oracle ELSA-2026-19372 OL9 nginx:1.26 2026-06-26
Oracle ELSA-2026-29151 OL9 nginx:1.26 2026-06-26
Oracle ELSA-2026-28256 OL9 opencryptoki 2026-06-25
Oracle ELSA-2026-19359 OL9 openexr 2026-06-24
Oracle ELSA-2026-25239 OL9 openssl 2026-06-26
Oracle ELSA-2026-22312 OL9 openssl 2026-07-01
Oracle ELSA-2026-30852 OL8 perl-Archive-Tar 2026-06-30
Oracle ELSA-2026-30856 OL9 perl-Archive-Tar 2026-07-01
Oracle ELSA-2026-30858 OL8 perl-IO-Compress 2026-06-30
Oracle ELSA-2026-30859 OL9 perl-IO-Compress 2026-07-01
Oracle ELSA-2026-22143 OL9 php:8.2 2026-06-24
Oracle ELSA-2026-22142 OL9 php:8.3 2026-06-26
Oracle ELSA-2026-26447 OL9 podman 2026-06-25
Oracle ELSA-2026-26445 OL9 podman 2026-06-26
Oracle ELSA-2026-18722 OL9 podman 2026-06-26
Oracle ELSA-2026-25058 OL9 poppler 2026-06-24
Oracle ELSA-2026-26205 OL9 postfix 2026-06-25
Oracle ELSA-2026-22304 OL9 postgresql-jdbc 2026-06-26
Oracle ELSA-2026-28999 OL8 postgresql:12 2026-06-25
Oracle ELSA-2026-28208 OL8 postgresql:13 2026-06-25
Oracle ELSA-2026-28037 OL9 postgresql:15 2026-06-25
Oracle ELSA-2026-26203 OL9 postgresql:16 2026-06-25
Oracle ELSA-2026-50324 OL9 pyOpenSSL 2026-06-24
Oracle ELSA-2026-19589 OL7 python 2026-06-30
Oracle ELSA-2026-19366 OL9 python-markdown 2026-06-24
Oracle ELSA-2026-28158 OL9 python-urllib3 2026-06-25
Oracle ELSA-2026-32992 OL8 python3.12-urllib3 2026-06-30
Oracle ELSA-2026-28159 OL9 python3.12-urllib3 2026-06-25
Oracle ELSA-2026-28247 OL9 python3.14 2026-06-26
Oracle ELSA-2026-28157 OL9 python3.14-urllib3 2026-06-25
Oracle ELSA-2026-18693 OL9 python3.9 2026-06-25
Oracle ELSA-2026-23229 OL9 redis 2026-06-26
Oracle ELSA-2026-25219 OL9 redis:7 2026-06-24
Oracle ELSA-2026-26410 OL9 rsync 2026-06-26
Oracle ELSA-2026-19368 OL9 rsync 2026-06-30
Oracle ELSA-2026-29702 OL9 runc 2026-06-25
Oracle ELSA-2026-25049 OL9 samba 2026-06-24
Oracle ELSA-2026-28074 OL9 skopeo 2026-06-25
Oracle ELSA-2026-21381 OL9 thunderbird 2026-06-24
Oracle ELSA-2026-29940 OL9 thunderbird 2026-06-26
Oracle ELSA-2026-19348 OL9 thunderbird 2026-06-29
Oracle ELSA-2026-28923 OL8 tigervnc 2026-06-24
Oracle ELSA-2026-19342 OL9 tigervnc 2026-06-25
Oracle ELSA-2026-29844 OL9 tigervnc 2026-06-25
Oracle ELSA-2026-26323 OL9 tomcat 2026-06-26
Oracle ELSA-2026-18916 OL9 tomcat 2026-06-30
Oracle ELSA-2026-50351 uek-kernel 2026-07-01
Oracle ELSA-2026-24369 OL9 unbound 2026-06-24
Oracle ELSA-2026-25925 OL9 valkey 2026-06-26
Oracle ELSA-2026-28553 OL8 vim 2026-06-24
Oracle ELSA-2026-28209 OL9 vim 2026-06-25
Oracle ELSA-2026-22717 OL9 vim 2026-06-26
Oracle ELSA-2026-25927 OL9 webkit2gtk3 2026-06-25
Oracle ELSA-2026-26610 OL9 xorg-x11-server 2026-06-25
Oracle ELSA-2026-19343 OL9 xorg-x11-server 2026-06-30
Oracle ELSA-2026-26590 OL9 xorg-x11-server-Xwayland 2026-06-25
Oracle ELSA-2026-19344 OL9 xorg-x11-server-Xwayland 2026-06-29
Red Hat RHSA-2026:33722-01 EL8 container-tools:rhel8 2026-07-01
Red Hat RHSA-2026:29898-01 EL8 libpng 2026-06-25
Red Hat RHSA-2026:29900-01 EL8.8 libpng 2026-06-25
Red Hat RHSA-2026:29022-01 EL8.4 libpng12 2026-06-25
Red Hat RHSA-2026:29018-01 EL8.8 libpng12 2026-06-25
Red Hat RHSA-2026:29021-01 EL8.4 libpng15 2026-06-25
Red Hat RHSA-2026:29019-01 EL8.6 libpng15 2026-06-25
Red Hat RHSA-2026:29016-01 EL8.8 libpng15 2026-06-25
Red Hat RHSA-2026:32991-01 EL9.4 osbuild-composer 2026-06-29
SUSE openSUSE-SU-2026:21011-1 oS16.0 389-ds 2026-06-30
SUSE SUSE-SU-2026:2696-1 SLE15 oS15.4 7zip 2026-06-30
SUSE openSUSE-SU-2026:21038-1 oS16.0 7zip 2026-06-30
SUSE SUSE-SU-2026:2625-1 SLE15 oS15.6 GraphicsMagick 2026-06-24
SUSE openSUSE-SU-2026:11115-1 TW GraphicsMagick 2026-06-27
SUSE openSUSE-SU-2026:11127-1 TW ImageMagick 2026-06-28
SUSE openSUSE-SU-2026:11104-1 TW NetworkManager-applet-openvpn 2026-06-26
SUSE openSUSE-SU-2026:11128-1 TW agama-web-ui 2026-06-28
SUSE SUSE-SU-2026:22291-1 SLE-m6.2 alsa 2026-06-29
SUSE openSUSE-SU-2026:21075-1 oS16.0 alsa 2026-06-30
SUSE openSUSE-SU-2026:21013-1 oS16.0 amazon-ecs-init 2026-06-30
SUSE openSUSE-SU-2026:21079-1 oS16.0 amazon-ssm-agent 2026-06-30
SUSE SUSE-SU-2026:2680-1 SLE15 oS15.4 ansible-core 2026-06-29
SUSE openSUSE-SU-2026:21097-1 oS16.0 ansible-core 2026-06-30
SUSE SUSE-SU-2026:2642-1 SLE15 apache-commons-configuration2, apache-commons-text 2026-06-26
SUSE SUSE-SU-2026:2641-1 SLE12 apache2 2026-06-26
SUSE SUSE-SU-2026:2717-1 SLE12 apache2 2026-07-01
SUSE SUSE-SU-2026:2686-1 SLE15 oS15.4 apache2 2026-06-30
SUSE openSUSE-SU-2026:21115-1 oS16.0 apache2 2026-06-30
SUSE SUSE-SU-2026:2609-1 SLE15 oS15.6 apptainer 2026-06-24
SUSE openSUSE-SU-2026:11106-1 TW asn1c 2026-06-26
SUSE openSUSE-SU-2026:11129-1 TW assimp-devel 2026-06-28
SUSE openSUSE-SU-2026:0223-1 osB15 assimp 2026-06-29
SUSE openSUSE-SU-2026:21152-1 oS16.0 atril 2026-06-30
SUSE SUSE-SU-2026:22258-1 SLE-m6.2 avahi 2026-06-29
SUSE openSUSE-SU-2026:21014-1 oS16.0 avahi 2026-06-30
SUSE SUSE-SU-2026:2643-1 MP4.3 SLE15 aws-iam-authenticator 2026-06-26
SUSE SUSE-SU-2026:2673-1 SLE15 bind 2026-06-29
SUSE SUSE-SU-2026:2616-1 SLE15 SLE5.5 SLE-m5.5 oS15.5 bind 2026-06-24
SUSE SUSE-SU-2026:2617-1 SLE15 oS15.4 bind 2026-06-24
SUSE SUSE-SU-2026:2676-1 SLE15 oS15.6 bind 2026-06-29
SUSE openSUSE-SU-2026:21123-1 oS16.0 bind 2026-06-30
SUSE openSUSE-SU-2026:21149-1 oS16.0 bitcoin 2026-06-30
SUSE SUSE-SU-2026:2706-1 SLE15 oS15.4 buildah 2026-06-30
SUSE openSUSE-SU-2026:11130-1 TW calibre 2026-06-28
SUSE openSUSE-SU-2026:21062-1 oS16.0 capnproto 2026-06-30
SUSE openSUSE-SU-2026:11139-1 TW chromedriver 2026-06-29
SUSE openSUSE-SU-2026:21135-1 oS16.0 chromium 2026-06-30
SUSE SUSE-SU-2026:2700-1 SLE12 cifs-utils 2026-06-30
SUSE SUSE-SU-2026:2699-1 SLE15 SLE5.3 SLE5.4 SLE5.5 SLE-m5.3 SLE-m5.4 SLE-m5.5 oS15.4 cifs-utils 2026-06-30
SUSE SUSE-SU-2026:0906-2 SLE15 clamav 2026-06-26
SUSE SUSE-SU-2026:2640-1 SLE12 containerd 2026-06-26
SUSE SUSE-SU-2026:2639-1 SLE15 SLE5.3 SLE5.4 SLE5.5 SLE-m5.3 SLE-m5.4 SLE-m5.5 containerd 2026-06-26
SUSE openSUSE-SU-2026:11121-1 TW corepack24 2026-06-27
SUSE openSUSE-SU-2026:21036-1 oS16.0 cosign 2026-06-30
SUSE SUSE-SU-2026:22247-1 SLE-m6.1 crun 2026-06-25
SUSE SUSE-SU-2026:2703-1 SLE12 curl 2026-06-30
SUSE openSUSE-SU-2026:21084-1 oS16.0 distribution 2026-06-30
SUSE openSUSE-SU-2026:21015-1 oS16.0 dnsdist 2026-06-30
SUSE SUSE-SU-2026:22285-1 SLE-m6.2 docker 2026-06-29
SUSE SUSE-SU-2026:2692-1 SLE15 SLE5.3 SLE5.4 SLE5.5 SLE-m5.3 SLE-m5.4 SLE-m5.5 docker 2026-06-30
SUSE SUSE-SU-2026:2645-1 SLE12 dovecot22 2026-06-26
SUSE openSUSE-SU-2026:21109-1 oS16.0 dovecot24 2026-06-30
SUSE SUSE-SU-2026:22273-1 SLE-m6.2 dracut 2026-06-29
SUSE openSUSE-SU-2026:21054-1 oS16.0 dracut 2026-06-30
SUSE SUSE-SU-2026:2704-1 oS15.4 exiv2-0_26 2026-06-30
SUSE SUSE-SU-2026:2663-1 SLE12 exiv2 2026-06-26
SUSE openSUSE-SU-2026:21043-1 oS16.0 firefox 2026-06-30
SUSE SUSE-SU-2026:22263-1 SLE-m6.2 firewalld 2026-06-29
SUSE openSUSE-SU-2026:21032-1 oS16.0 firewalld 2026-06-30
SUSE SUSE-SU-2026:22243-1 SLE-m6.0 freeipmi 2026-06-25
SUSE SUSE-SU-2026:22246-1 SLE-m6.1 freeipmi 2026-06-25
SUSE SUSE-SU-2026:2679-1 SLE12 freeipmi 2026-06-29
SUSE openSUSE-SU-2026:21088-1 oS16.0 freeipmi 2026-06-30
SUSE openSUSE-SU-2026:21116-1 oS16.0 freerdp 2026-06-30
SUSE SUSE-SU-2026:2644-1 SLE15 oS15.3 frr 2026-06-26
SUSE openSUSE-SU-2026:11083-1 TW ghc-crypton-x509-store 2026-06-24
SUSE openSUSE-SU-2026:11084-1 TW ghc-crypton-x509-system 2026-06-24
SUSE SUSE-SU-2026:2667-1 SLE12 giflib 2026-06-26
SUSE SUSE-SU-2026:2666-1 SLE15 giflib 2026-06-26
SUSE openSUSE-SU-2026:21076-1 oS16.0 giflib 2026-06-30
SUSE openSUSE-SU-2026:21171-1 oS16.0 gimp 2026-06-30
SUSE openSUSE-SU-2026:11122-1 TW glances-common 2026-06-28
SUSE openSUSE-SU-2026:21143-1 oS16.0 gleam 2026-06-30
SUSE openSUSE-SU-2026:21130-1 oS16.0 glib-networking 2026-06-30
SUSE openSUSE-SU-2026:11140-1 TW glibc 2026-06-29
SUSE openSUSE-SU-2026:21134-1 oS16.0 glycin-loaders 2026-06-30
SUSE openSUSE-SU-2026:21136-1 oS16.0 golang-github-prometheus-alertmanager 2026-06-30
SUSE openSUSE-SU-2026:21157-1 oS16.0 golang-github-prometheus-alertmanager 2026-06-30
SUSE SUSE-SU-2026:2682-1 MP4.3 SLE15 google-cloud-sap-agent 2026-06-29
SUSE SUSE-SU-2026:2683-1 SLE12 google-cloud-sap-agent 2026-06-29
SUSE openSUSE-SU-2026:21010-1 oS16.0 google-cloud-sap-agent 2026-06-30
SUSE SUSE-SU-2026:2612-1 MP4.3 SLE15 SLE5.5 SLE-m5.5 google-guest-agent 2026-06-24
SUSE openSUSE-SU-2026:21069-1 oS16.0 google-guest-agent 2026-06-30
SUSE SUSE-SU-2026:2611-1 MP4.3 SLE15 SLE5.5 SLE-m5.5 google-osconfig-agent 2026-06-24
SUSE SUSE-SU-2026:22242-1 SLE-m6.0 google-osconfig-agent 2026-06-25
SUSE SUSE-SU-2026:22249-1 SLE-m6.1 google-osconfig-agent 2026-06-25
SUSE SUSE-SU-2026:2665-1 SLE12 google-osconfig-agent 2026-06-26
SUSE openSUSE-SU-2026:21124-1 oS16.0 graphite2 2026-06-30
SUSE openSUSE-SU-2026:21004-1 oS16.0 gsasl 2026-06-30
SUSE openSUSE-SU-2026:11088-1 TW gstreamer-plugins-bad 2026-06-24
SUSE openSUSE-SU-2026:11114-1 TW gvim 2026-06-27
SUSE openSUSE-SU-2026:11089-1 TW hamlib 2026-06-24
SUSE openSUSE-SU-2026:21155-1 oS16.0 hamlib 2026-06-30
SUSE SUSE-SU-2026:2651-1 MP4.3 SLE15 SLE5.3 SLE5.4 SLE5.5 SLE-m5.3 SLE-m5.4 SLE-m5.5 oS15.4 haproxy 2026-06-26
SUSE SUSE-SU-2026:2652-1 SLE15 oS15.6 haproxy 2026-06-26
SUSE openSUSE-SU-2026:20994-1 oS16.0 helm 2026-06-30
SUSE openSUSE-SU-2026:21111-1 oS16.0 himmelblau 2026-06-30
SUSE openSUSE-SU-2026:11131-1 TW hydra 2026-06-28
SUSE openSUSE-SU-2026:21108-1 oS16.0 ignition 2026-06-30
SUSE openSUSE-SU-2026:21071-1 oS16.0 imagemagick 2026-06-30
SUSE SUSE-SU-2026:2620-1 SLE5.3 SLE5.4 SLE5.5 SLE-m5.3 SLE-m5.4 SLE-m5.5 oS15.4 iproute2 2026-06-24
SUSE openSUSE-SU-2026:11141-1 TW istioctl 2026-06-29
SUSE openSUSE-SU-2026:11132-1 TW jackson-databind 2026-06-29
SUSE SUSE-SU-2026:2624-1 SLE12 java-1_8_0-openjdk 2026-06-24
SUSE openSUSE-SU-2026:11133-1 TW jq 2026-06-29
SUSE openSUSE-SU-2026:11138-1 TW jupyter-jupyterlab-templates 2026-06-29
SUSE openSUSE-SU-2026:11123-1 TW jupyter-nbclassic 2026-06-28
SUSE SUSE-SU-2026:2638-1 MP4.3 SLE15 SLE5.3 SLE5.4 SLE-m5.3 SLE-m5.4 oS15.4 kernel 2026-06-26
SUSE SUSE-SU-2026:2631-1 SLE15 SLE5.3 SLE5.4 SLE-m5.3 SLE-m5.4 kernel 2026-06-25
SUSE SUSE-SU-2026:2630-1 SLE15 SLE5.5 SLE-m5.5 oS15.5 kernel 2026-06-25
SUSE SUSE-SU-2026:2658-1 SLE15 SLE5.5 SLE-m5.5 oS15.5 kernel 2026-06-26
SUSE SUSE-SU-2026:2632-1 SLE15 oS15.6 kernel 2026-06-25
SUSE openSUSE-SU-2026:21025-1 oS16.0 keylime 2026-06-30
SUSE SUSE-SU-2026:22255-1 SLE-m6.2 krb5 2026-06-29
SUSE openSUSE-SU-2026:21021-1 oS16.0 krb5 2026-06-30
SUSE openSUSE-SU-2026:11091-1 TW kubevirt1 2026-06-24
SUSE openSUSE-SU-2026:21093-1 oS16.0 ldns 2026-06-30
SUSE openSUSE-SU-2026:21061-1 oS16.0 libaom 2026-06-30
SUSE SUSE-SU-2026:22241-1 SLE-m6.0 libarchive 2026-06-25
SUSE SUSE-SU-2026:22248-1 SLE-m6.1 libarchive 2026-06-25
SUSE openSUSE-SU-2026:21101-1 oS16.0 libcaca 2026-06-30
SUSE SUSE-SU-2026:22270-1 SLE-m6.2 libgcrypt 2026-06-29
SUSE openSUSE-SU-2026:21047-1 oS16.0 libgcrypt 2026-06-30
SUSE SUSE-SU-2026:2622-1 SLE15 libheif 2026-06-24
SUSE SUSE-SU-2026:2681-1 oS15.4 libheif 2026-06-29
SUSE openSUSE-SU-2026:21091-1 oS16.0 libinput 2026-06-30
SUSE openSUSE-SU-2026:21100-1 oS16.0 libjxl 2026-06-30
SUSE openSUSE-SU-2026:21055-1 oS16.0 libnfs 2026-06-30
SUSE openSUSE-SU-2026:11094-1 TW libnilfs3 2026-06-25
SUSE openSUSE-SU-2026:11146-1 TW libonnxruntime1 2026-06-30
SUSE openSUSE-SU-2026:11096-1 TW libopenbabel8 2026-06-25
SUSE SUSE-SU-2026:2619-1 SLE12 libpng15 2026-06-24
SUSE openSUSE-SU-2026:11134-1 TW libslirp-devel 2026-06-29
SUSE SUSE-SU-2026:2674-1 MP4.3 SLE15 SLE5.3 SLE5.4 SLE-m5.3 SLE-m5.4 oS15.4 libsolv, libzypp, zypper 2026-06-29
SUSE SUSE-SU-2026:2702-1 SLE12 libsoup 2026-06-30
SUSE SUSE-SU-2026:2669-1 oS15.4 libsoup 2026-06-29
SUSE SUSE-SU-2026:2654-1 SLE15 oS15.6 libsoup2 2026-06-26
SUSE SUSE-SU-2026:2670-1 SLE5.3 SLE5.4 SLE5.5 SLE-m5.3 SLE-m5.4 SLE-m5.5 oS15.4 libsoup2 2026-06-29
SUSE openSUSE-SU-2026:11109-1 TW libssh2-1 2026-06-26
SUSE SUSE-SU-2026:22284-1 SLE-m6.2 libssh2_org 2026-06-29
SUSE openSUSE-SU-2026:21057-1 oS16.0 libssh2_org 2026-06-30
SUSE openSUSE-SU-2026:11092-1 TW libtar 2026-06-25
SUSE openSUSE-SU-2026:21118-1 oS16.0 libvncserver 2026-06-30
SUSE openSUSE-SU-2026:21113-1 oS16.0 libyang 2026-06-30
SUSE SUSE-SU-2026:2628-1 SLE12 libzypp 2026-06-25
SUSE openSUSE-SU-2026:21146-1 oS16.0 lldpd 2026-06-30
SUSE openSUSE-SU-2026:11135-1 TW logback 2026-06-29
SUSE openSUSE-SU-2026:21074-1 oS16.0 loupe 2026-06-30
SUSE openSUSE-SU-2026:11093-1 TW lrzip 2026-06-25
SUSE openSUSE-SU-2026:21145-1 oS16.0 mbedtls-2 2026-06-30
SUSE openSUSE-SU-2026:0213-1 osB15 mbedtls-2 2026-06-25
SUSE openSUSE-SU-2026:21144-1 oS16.0 mbedtls 2026-06-30
SUSE openSUSE-SU-2026:0214-1 osB15 mbedtls 2026-06-25
SUSE openSUSE-SU-2026:21120-1 oS16.0 mcphost 2026-06-30
SUSE openSUSE-SU-2026:21114-1 oS16.0 mozjs128 2026-06-30
SUSE openSUSE-SU-2026:21016-1 oS16.0 mutt 2026-06-30
SUSE openSUSE-SU-2026:11120-1 TW nano 2026-06-27
SUSE openSUSE-SU-2026:21166-1 oS16.0 nano 2026-06-30
SUSE openSUSE-SU-2026:21107-1 oS16.0 nginx 2026-06-30
SUSE SUSE-SU-2026:2695-1 SLE15 nodejs22 2026-06-30
SUSE SUSE-SU-2026:2647-1 SLE15 oS15.6 nodejs22 2026-06-26
SUSE SUSE-SU-2026:2633-1 SLE15 nodejs24 2026-06-25
SUSE openSUSE-SU-2026:11136-1 TW ocaml 2026-06-29
SUSE openSUSE-SU-2026:11095-1 TW ofono 2026-06-25
SUSE openSUSE-SU-2026:21154-1 oS16.0 ofono 2026-06-30
SUSE SUSE-SU-2026:22293-1 SLE-m6.2 openCryptoki 2026-06-29
SUSE SUSE-SU-2026:2685-1 SLE12 openCryptoki 2026-06-29
SUSE openSUSE-SU-2026:0220-1 osB15 openbabel 2026-06-28
SUSE openSUSE-SU-2026:21059-1 oS16.0 opencryptoki 2026-06-30
SUSE SUSE-SU-2026:2678-1 SLE12 opensc 2026-06-29
SUSE SUSE-SU-2026:2657-1 SLE15 SLE5.3 SLE5.4 SLE5.5 SLE-m5.3 SLE-m5.4 SLE-m5.5 oS15.4 opensc 2026-06-26
SUSE SUSE-SU-2026:2697-1 SLE15 oS15.6 opensc 2026-06-30
SUSE SUSE-SU-2026:22268-1 SLE-m6.2 openssh 2026-06-29
SUSE openSUSE-SU-2026:21044-1 oS16.0 openssh 2026-06-30
SUSE SUSE-SU-2026:2614-1 SLE15 SLE5.3 SLE5.4 SLE-m5.3 SLE-m5.4 oS15.4 openssl-1_1 2026-06-24
SUSE SUSE-SU-2026:22251-1 SLE-m6.2 openssl-3 2026-06-29
SUSE SUSE-SU-2026:2648-1 SLE15 openssl-3 2026-06-26
SUSE openSUSE-SU-2026:21005-1 oS16.0 openssl-3 2026-06-30
SUSE SUSE-SU-2026:2701-1 SLE15 oS15.5 pacemaker 2026-06-30
SUSE SUSE-SU-2026:2716-1 SLE15 oS15.6 pacemaker 2026-07-01
SUSE openSUSE-SU-2026:11111-1 TW pacemaker 2026-06-26
SUSE openSUSE-SU-2026:21106-1 oS16.0 papers 2026-06-30
SUSE SUSE-SU-2026:2709-1 SLE12 perl-Config-IniFiles 2026-06-30
SUSE SUSE-SU-2026:2710-1 SLE15 perl-Config-IniFiles 2026-06-30
SUSE SUSE-SU-2026:22257-1 SLE-m6.2 perl-DBI 2026-06-29
SUSE openSUSE-SU-2026:0217-1 osB15 perl-Net-Dropbox-API 2026-06-26
SUSE openSUSE-SU-2026:21142-1 oS16.0 perl-compress-raw-zlib 2026-06-30
SUSE openSUSE-SU-2026:21012-1 oS16.0 perl-config-inifiles 2026-06-30
SUSE openSUSE-SU-2026:21140-1 oS16.0 perl-cpanel-json-xs 2026-06-30
SUSE openSUSE-SU-2026:21137-1 oS16.0 perl-crypt-passwdmd5 2026-06-30
SUSE openSUSE-SU-2026:21029-1 oS16.0 perl-dbi 2026-06-30
SUSE openSUSE-SU-2026:21126-1 oS16.0 perl-html-parser 2026-06-30
SUSE openSUSE-SU-2026:21119-1 oS16.0 perl-http-daemon 2026-06-30
SUSE openSUSE-SU-2026:21045-1 oS16.0 perl-libwww-perl 2026-06-30
SUSE openSUSE-SU-2026:21125-1 oS16.0 perl-protocol-http2 2026-06-30
SUSE SUSE-SU-2026:2636-1 SLE15 SES7.1 oS15.3 podman 2026-06-25
SUSE SUSE-SU-2026:2693-1 SLE15 SLE5.3 SLE5.4 SLE-m5.3 SLE-m5.4 oS15.4 podman 2026-06-30
SUSE SUSE-SU-2026:2715-1 SLE15 SLE5.5 SLE-m5.5 oS15.5 podman 2026-06-30
SUSE openSUSE-SU-2026:21020-1 oS16.0 postfix 2026-06-30
SUSE openSUSE-SU-2026:21102-1 oS16.0 postgresql14 2026-06-30
SUSE openSUSE-SU-2026:21103-1 oS16.0 postgresql15 2026-06-30
SUSE openSUSE-SU-2026:21104-1 oS16.0 postgresql16 2026-06-30
SUSE SUSE-SU-2026:2664-1 SLE12 python, python-base, python-doc 2026-06-26
SUSE SUSE-SU-2026:2626-1 MP4.3 SLE15 oS15.4 python-PyJWT 2026-06-25
SUSE SUSE-SU-2026:22238-1 SLE-m6.0 python-PyJWT 2026-06-25
SUSE SUSE-SU-2026:2627-1 SLE15 SLE5.5 SLE-m5.5 python-PyJWT 2026-06-25
SUSE openSUSE-SU-2026:21098-1 oS16.0 python-aiohttp 2026-06-30
SUSE openSUSE-SU-2026:21169-1 oS16.0 python-biopython 2026-06-30
SUSE openSUSE-SU-2026:0215-1 osB15 python-biopython 2026-06-25
SUSE SUSE-SU-2026:22254-1 SLE-m6.2 python-click 2026-06-29
SUSE openSUSE-SU-2026:21017-1 oS16.0 python-click 2026-06-30
SUSE openSUSE-SU-2026:21078-1 oS16.0 python-ecdsa 2026-06-30
SUSE SUSE-SU-2026:22271-1 SLE-m6.2 python-idna 2026-06-29
SUSE openSUSE-SU-2026:21048-1 oS16.0 python-idna 2026-06-30
SUSE openSUSE-SU-2026:21063-1 oS16.0 python-markdown, python-joblib, 2026-06-30
SUSE openSUSE-SU-2026:21127-1 oS16.0 python-paramiko 2026-06-30
SUSE openSUSE-SU-2026:21161-1 oS16.0 python-pdm 2026-06-30
SUSE SUSE-SU-2026:2634-1 MP4.3 SLE15 oS15.4 python-pip 2026-06-25
SUSE openSUSE-SU-2026:20993-1 oS16.0 python-pip 2026-06-30
SUSE openSUSE-SU-2026:21159-1 oS16.0 python-py7zr 2026-06-30
SUSE openSUSE-SU-2026:21173-1 oS16.0 python-pydata-sphinx-theme 2026-06-30
SUSE openSUSE-SU-2026:21095-1 oS16.0 python-pyjwt 2026-06-30
SUSE openSUSE-SU-2026:21066-1 oS16.0 python-python-multipart 2026-06-30
SUSE openSUSE-SU-2026:21053-1 oS16.0 python-starlette 2026-06-30
SUSE SUSE-SU-2026:22286-1 SLE-m6.2 python-tornado6 2026-06-29
SUSE openSUSE-SU-2026:21067-1 oS16.0 python-tornado6 2026-06-30
SUSE openSUSE-SU-2026:11097-1 TW python311-aiohttp 2026-06-25
SUSE openSUSE-SU-2026:11137-1 TW python311-jupyter-ydoc 2026-06-29
SUSE openSUSE-SU-2026:11098-1 TW python311-nltk 2026-06-25
SUSE openSUSE-SU-2026:11124-1 TW python311-pdm 2026-06-28
SUSE openSUSE-SU-2026:11112-1 TW python311-py7zr 2026-06-27
SUSE openSUSE-SU-2026:11113-1 TW python311-pypdf 2026-06-27
SUSE openSUSE-SU-2026:11099-1 TW python311-python-multipart 2026-06-25
SUSE openSUSE-SU-2026:11100-1 TW python312 2026-06-25
SUSE openSUSE-SU-2026:11101-1 TW python315 2026-06-25
SUSE SUSE-SU-2026:2655-1 SLE12 python36 2026-06-26
SUSE SUSE-SU-2026:22259-1 SLE-m6.2 rpcbind 2026-06-29
SUSE openSUSE-SU-2026:21019-1 oS16.0 rpcbind 2026-06-30
SUSE SUSE-SU-2026:22256-1 SLE-m6.2 sed 2026-06-29
SUSE openSUSE-SU-2026:21024-1 oS16.0 sed 2026-06-30
SUSE SUSE-SU-2026:22266-1 SLE-m6.2 sg3_utils 2026-06-29
SUSE SUSE-SU-2026:2689-1 SLE12 sg3_utils 2026-06-30
SUSE SUSE-SU-2026:2687-1 SLE15 sg3_utils 2026-06-30
SUSE SUSE-SU-2026:2691-1 SLE15 SLE5.3 SLE5.4 SLE5.5 SLE-m5.3 SLE-m5.4 SLE-m5.5 oS15.4 sg3_utils 2026-06-30
SUSE SUSE-SU-2026:2690-1 SLE15 oS15.3 sg3_utils 2026-06-30
SUSE SUSE-SU-2026:2688-1 SLE15 oS15.6 sg3_utils 2026-06-30
SUSE openSUSE-SU-2026:21040-1 oS16.0 sg3_utils 2026-06-30
SUSE openSUSE-SU-2026:11151-1 TW socat 2026-06-30
SUSE openSUSE-SU-2026:21090-1 oS16.0 sqlite3 2026-06-30
SUSE openSUSE-SU-2026:21092-1 oS16.0 strongswan 2026-06-30
SUSE SUSE-SU-2026:22289-1 SLE-m6.2 tar 2026-06-29
SUSE SUSE-SU-2026:2615-1 SLE12 tar 2026-06-24
SUSE SUSE-SU-2026:2714-1 SLE15 SLE5.3 SLE5.4 SLE5.5 SLE-m5.3 SLE-m5.4 SLE-m5.5 tar 2026-06-30
SUSE openSUSE-SU-2026:11125-1 TW tar 2026-06-28
SUSE openSUSE-SU-2026:21070-1 oS16.0 tar 2026-06-30
SUSE openSUSE-SU-2026:21168-1 oS16.0 thunderbird 2026-06-30
SUSE SUSE-SU-2026:2675-1 SLE15 tomcat 2026-06-29
SUSE openSUSE-SU-2026:21117-1 oS16.0 tomcat 2026-06-30
SUSE openSUSE-SU-2026:21122-1 oS16.0 tomcat10 2026-06-30
SUSE openSUSE-SU-2026:21121-1 oS16.0 tomcat11 2026-06-30
SUSE SUSE-SU-2026:2713-1 SLE12 tracker 2026-06-30
SUSE openSUSE-SU-2026:11102-1 TW trivy 2026-06-26
SUSE openSUSE-SU-2026:21072-1 oS16.0 trivy 2026-06-30
SUSE openSUSE-SU-2026:21083-1 oS16.0 unbound 2026-06-30
SUSE SUSE-SU-2026:22260-1 SLE-m6.2 util-linux 2026-06-29
SUSE SUSE-SU-2026:2653-1 SLE5.3 SLE5.4 SLE-m5.3 SLE-m5.4 oS15.4 util-linux 2026-06-26
SUSE openSUSE-SU-2026:21151-1 oS16.0 warewulf4 2026-06-30
SUSE SUSE-SU-2026:2623-1 SLE12 webkit2gtk3 2026-06-24
SUSE openSUSE-SU-2026:21129-1 oS16.0 webkit2gtk3 2026-06-30
SUSE openSUSE-SU-2026:21153-1 oS16.0 xar 2026-06-30
SUSE SUSE-SU-2026:2712-1 SLE15 oS15.6 xdg-desktop-portal 2026-06-30
SUSE SUSE-SU-2026:2668-1 SLE12 xen 2026-06-29
SUSE SUSE-SU-2026:2613-1 SLE15 SLE5.3 SLE5.4 SLE-m5.3 SLE-m5.4 oS15.4 xen 2026-06-24
SUSE openSUSE-SU-2026:0221-1 osB15 xtrabackup 2026-06-29
SUSE openSUSE-SU-2026:21112-1 oS16.0 xwayland 2026-06-30
SUSE openSUSE-SU-2026:21163-1 oS16.0 yt-dlp 2026-06-30
SUSE openSUSE-SU-2026:21096-1 oS16.0 zypper, libzypp, libsolv 2026-06-30
Ubuntu USN-8474-1 16.04 18.04 20.04 22.04 24.04 26.04 NSD 2026-06-25
Ubuntu USN-8475-1 24.04 25.10 amd64-microcode 2026-06-25
Ubuntu USN-8471-1 16.04 18.04 20.04 22.04 24.04 26.04 containerd 2026-06-25
Ubuntu USN-8472-1 20.04 22.04 24.04 25.10 26.04 containerd-app 2026-06-25
Ubuntu USN-8473-1 25.10 26.04 containerd-stable 2026-06-25
Ubuntu USN-8470-1 22.04 24.04 25.10 26.04 cpp-httplib 2026-06-25
Ubuntu USN-8487-1 14.04 16.04 18.04 20.04 22.04 24.04 25.10 26.04 curl 2026-07-01
Ubuntu USN-8469-1 20.04 22.04 24.04 26.04 ffmpeg 2026-06-24
Ubuntu USN-8483-1 22.04 24.04 25.10 26.04 hplip 2026-06-30
Ubuntu USN-8468-1 14.04 16.04 18.04 20.04 22.04 24.04 imagemagick 2026-06-25
Ubuntu USN-8466-1 14.04 16.04 18.04 20.04 22.04 24.04 25.10 26.04 libdbi-perl 2026-06-24
Ubuntu USN-8484-1 22.04 24.04 25.10 26.04 libgd-perl 2026-06-30
Ubuntu USN-8479-1 25.10 26.04 libheif 2026-06-29
Ubuntu USN-8486-1 24.04 25.10 26.04 libssh2 2026-06-30
Ubuntu USN-8485-1 25.10 26.04 libyang 2026-06-30
Ubuntu USN-8465-1 22.04 24.04 26.04 mina2 2026-06-25
Ubuntu USN-8452-1 18.04 20.04 22.04 24.04 node-pbkdf2 2026-06-25
Ubuntu USN-8481-1 22.04 24.04 25.10 26.04 nss 2026-06-29
Ubuntu USN-8467-1 14.04 16.04 18.04 20.04 perl 2026-06-24
Ubuntu USN-8412-3 20.04 qemu 2026-06-29
Ubuntu USN-8482-1 26.04 roundcube 2026-06-30
Ubuntu USN-8478-1 20.04 22.04 24.04 26.04 ruby2.7, ruby3.0, ruby3.2, ruby3.3 2026-06-30
Ubuntu USN-8480-1 22.04 24.04 25.10 26.04 sqlite3 2026-06-29
Ubuntu USN-8477-1 14.04 16.04 18.04 20.04 22.04 24.04 26.04 tar 2026-06-30
Ubuntu USN-8476-1 18.04 20.04 22.04 24.04 25.10 xrdp 2026-06-25
Full Story (comments: none)

Kernel patches of interest

Kernel releases

Linus Torvalds Linux 7.2-rc1 Jun 28
Greg Kroah-Hartman Linux 7.1.2 Jun 27
Greg Kroah-Hartman Linux 7.0.14 Jun 27
Greg Kroah-Hartman Linux 6.18.37 Jun 27

Architecture-specific

Kameron Carr arm64: hyperv: Add Realm support for Hyper-V Jun 25
Jinjie Ruan arm64/riscv: Add support for crashkernel CMA reservation Jun 29
Jinjie Ruan arm64: entry: Convert to Generic Entry Jun 29
Kiryl Shutsemau arm64: cross-CPU NMI via SDEI Jun 29
Linu Cherian Add BBML3 cpu feature Jul 01
Bibo Mao LoongArch: KVM: Harden interrupt injection Jun 29
Tiezhu Yang Optimize BPF tailcall for LoongArch Jun 30
Shivani Nittor powerpc/perf: Add Device Tree based PMU description framework Jun 29
Drew Fustini riscv: Add Ssqosid and initial CBQRI resctrl support Jun 24
Varun R Mallya Add BPF Exceptions support for RISC-V Jun 28
Wang Han riscv: Add reliable stack unwinding for livepatch Jun 29
Inochi Amaoto RISC-V: KVM: Add Svadu/Zicfiss/Zicfilp FWFT support Jul 01
Yunhui Cui riscv: improve percpu helpers and PIO mapping Jul 01
Atish Patra Add Counter delegation ISA extension support Jul 01
Wang Yechao Implement Eager Page Splitting for RISC-V Jul 01
Guodong Xu riscv: hwprobe: Expose RVA23U64 base behavior Jul 01
Anthony Krowiak s390/vfio-ap: Add live guest migration support Jun 30
Eric Biggers x86: Remove cpu_has_xfeatures() and add AVX-512 xor_gen() Jun 25
Sairaj Kodilkar Add support for AMD IOMMU GAPPI Jun 26
Juergen Gross x86/msr: Inline rdmsr/wrmsr instructions Jun 29
Juergen Gross x86/msr: Drop 32-bit MSR interfaces Jun 29
Vishal Moola Convert x86 pgd_lists to ptdescs Jun 29
Ashish Kalra Add RMPOPT support. Jun 30
Reinette Chatre x86,fs/resctrl: Improve resctrl quality and consistency Jun 30
Qi Liu perf/x86/amd/uncore: Add common helpers and Hygon support Jul 01

Build system

Breno Leitao bootconfig: embed kernel.* cmdline at build time Jun 26

Core kernel

Jianyong Wu sched: Extend cache-aware scheduling into topology-aware scheduling Jun 25
Masami Hiramatsu (Google) tracing/probes: Add more typecast features Jun 25
Shrikanth Hegde sched: Introduce cpu_preferred_mask and steal-driven vCPU backoff Jun 25
Chenghao Duan luo support for preserving eventfd Jun 25
Frederic Weisbecker timers/migration: Prioritize lower capacity CPUs as migrators Jun 25
Waiman Long cgroup/cpuset: Support multiple source/destination cpusets for cpuset_*attach() Jun 26
Leon Hwang bpf: Disallow interpreter fallback for interpreter-unsupported insns Jun 26
Eric W. Biederman Short circuit delivery for coredump signals Jun 26
David Laight Improvements to ftrace comm[] handling Jun 26
Xu Kuohai bpf: Introduce static-defined tracing probe for BPF Jun 27
Jiri Olsa bpf: tracing_multi link info support Jun 29
Leon Hwang bpf: Introduce global percpu data Jun 29
K Prateek Nayak futex: Use runtime constants for futex_hash computation Jun 30
Chuyi Zhou Allow preemption during IPI completion waiting to improve real-time performance Jun 30
Renzo Davoli ptrace_set_syscall_info: add support for seccomp syscall skipping and instruction pointer modification Jul 01

Development tools

Gabriele Monaco rv: Add selftests to tools and KUnit tests Jun 25
Sean Christopherson KVM: selftests: Add eventfd+VFIO IRQ test Jun 26
Leonardo Bras KVM: selftests: Improvements on dirty-ring Jun 29
Yosry Ahmed KVM: selftests: Stress save+restore and #PF (ft. nested) Jun 29
Alexis Lothoré (eBPF Foundation) bpf: add support for KASAN checks in JITed programs Jul 01

Device drivers

Frank.Li@oss.nxp.com media: add new API simple 1to1 subdev register and add imx parallel camera support Jun 24
Daniel Lezcano Lenovo ThinkPad T14s EC thermal monitoring and thermal zone integration Jun 24
Rama devi Veggalam Add support for Versal Xilsem edac Jun 25
Fenglin Wu input: misc: Add an initial driver for haptics inside Qcom PMIH010x PMIC Jun 24
Joey Lu phy: nuvoton: extend MA35D1 USB2 PHY driver for dual-port OTG support Jun 25
hehuan1@eswincomputing.com Add driver support for ESWIN EIC7700 PVT controller Jun 25
Boris Brezillon drm/panthor: Reduce dma_fence signalling latency Jun 25
Svyatoslav Ryhel mfd: Add support for Asus Transformer embedded controller Jun 25
Neil Armstrong drm: panel: support the R63419 based dual-DSI video mode Display Panels Jun 25
Richard Cheng Support zero-sized HDM decoders Jun 25
Joey Lu drm/verisilicon: add Nuvoton MA35D1 DCU Lite support Jun 25
Luca Leonardo Scorcia pinctrl: mediatek: mt8516-mt8167: Convert to Paris driver Jun 25
Chi-Wen Weng iio: adc: Add Nuvoton MA35D1 EADC support Jun 25
Anisa Su DCD: Add support for Dynamic Capacity Devices (DCD) Jun 25
Muralidhara M K platform/x86/amd/hsmp: ACPI/platform HSMP concurrency and lifecycle hardening Jun 25
Heikki Krogerus drm/xe/i2c: alerts and controller enabling modifications Jun 25
Atanas Filipov Add Qualcomm JPEG V4L2 encoder for SM8250 Jun 25
Sean Wang wifi: mt76: add mt7925 NAN support Jun 24
Chris Morgan Add Invensense ICM42607 Jun 24
Maarten Lankhorst drm/i915/display: All patches to make PREEMPT_RT work on i915 + xe. Jun 24
George Moussalem via B4 Relay Add support for IPQ5018 Bluetooth Jun 25
Shenwei Wang Enable Remote GPIO over RPMSG on i.MX Platform Jun 25
mhonap@nvidia.com vfio/pci: Add CXL Type-2 device passthrough support Jun 25
Saravanakrishnan Krishnamoorthy crypto: cmh - add CRI CryptoManager Hub driver Jun 25
Sebastian Reichel phy: rockchip: usbdp: Fixes, DP 1-lane support and cleanups Jun 25
David Lechner iio: adc: new ti-ads112c14 driver Jun 25
Vincent Cloutier media: i2c: Add Samsung S5K3L6 and Librem 5 rear camera Jun 25
Xianwei Zhao via B4 Relay Add Amlogic general DMA Jun 26
Matti Vaittinen Support ROHM BD127x0 hot-swap controllers Jun 26
peter.wang@mediatek.com reset: mediatek: add syscon-based reset controller Jun 26
Sumit Garg firmware: qcom: Add OP-TEE PAS service support Jun 26
Binbin Zhou ASoC: Add Loongson-2K0300 I2S controller and sound card support Jun 26
Kristian Mide Input: ilitek_ts: add stylus support for 0x0c reports Jun 26
Louis Chauvet VKMS: Introduce multiple configFS attributes Jun 27
Surabhi Gogte nvme-rdma: parallelize I/O queue setup Jun 26
Jacopo Mondi media: mali-c55: Add support for CCM and Gamma Jun 27
Rodnei Cilto Add keyboard LED support for Lenovo IdeaPad 83RR/83SR Jun 28
Kurt Borja iio: adc: Add TI ADS126X ADC family support Jun 28
James Calligeros ASoC: apple: mca: support simultaneous I2S capture on the frontend Jun 28
Rodrigo Alencar via B4 Relay New features for the AD5686 IIO driver Jun 28
Mikhail Kshevetskiy pinctrl: airoha: split on shared and SoC drivers, add more SoCs Jun 28
Viken Dadhaniya Add Qualcomm I2C slave controller driver Jun 28
Jinseob Kim iio: add Open Sensor Fusion IIO driver Jun 29
Stefan Dösinger ZTE zx297520v3 clock bindings and driver Jun 28
Wadim Mueller counter: add GPIO-based counter driver Jun 28
Jonas Jelonek net: pse-pd: add Realtek/Broadcom PSE MCU support Jun 28
javen r8169: add support for phylink Jun 29
javen Add support for RTL8261C_CG Jun 29
Hal Feng Add OpenCores PTC PWM support Jun 29
javen r8169: add RSS support for RTL8127 Jun 29
pankaj.gupta@oss.nxp.com firmware: imx: driver for NXP secure-enclave Jun 29
tze.yee.ng@altera.com hwmon: add Altera SoC FPGA hardware monitoring support Jun 29
Fan Gong net: hinic3: PF initialization Jun 29
Kate Hsuan Add Sony IMX471 camera sensor driver Jun 29
joakim.zhang@cixtech.com Add Cix Sky1 AUDSS clock and reset support Jun 29
Yicong Yang New vendor support and optimizations for DWC PCIe PMU Jun 29
Kim Seer Paller Add support for AD3532R/AD3532 Jun 29
Wayne Chang Enable USB host functions on Jetson AGX Thor Jun 29
Bartosz Golaszewski nvmem: rework nvmem core and allow unbinding with active consumers Jun 29
Bartosz Golaszewski crypto/dmaengine: qce: introduce BAM locking and use DMA for register I/O Jun 29
Benjamin Mugnier media: i2c: vd55g1: Add vd55g4 support and various fixes Jun 29
Ioana Ciornei dpaa2-switch: add support for LAG offload Jun 29
Bartosz Golaszewski net: stmmac: qcom-ethqos: add support for SCMI power domains Jun 29
Alexandre Courbot gpu: nova-core: consolidate and streamline GSP boot process Jun 29
Yongxing Mou drm/msm/dp: Add MST support for MSM chipsets Jun 29
Markus Probst Introduce Synology Microp driver Jun 29
Markus Stockhausen net: mdio: realtek-rtl9300: Add RTL83xx support Jun 29
Dennis Dalessandro Migrate to hfi2 driver Jun 27
Suravee Suthikulpanit iommu/amd: Introduce AMD Hardware-accelerated Virtualized IOMMU (vIOMMU) Support Jun 29
hoff.benjamin.k@gmail.com media: hws: add HDMI audio capture support Jun 29
Selvamani Rajagopal via B4 Relay Support for onsemi's S2500 10Base-T1S MAC-PHY Jun 29
Satish Kharat enic: SR-IOV V2 admin channel and MBOX protocol Jun 29
David Yang net: dsa: motorcomm: Add LED support Jun 30
Loic Poulain leds: pca963x: Add multicolor support and enable Monza RGB LEDs Jun 29
Prabhakar Add PCIe support for RZ/V2H(P) SoC Jun 29
illusion.wang nbl driver for Nebulamatrix NICs Jun 30
Zi-Yu Chen i2c: ma35d1: Add support for MA35D1 I2C controller Jun 30
Jian Hu via B4 Relay clk: amlogic: Add A9 peripherals clock controller Jun 30
Pengyu Luo drm/panel: Add Novatek NT36536 panel driver Jun 30
Ratheesh Kannoth Switch support Jun 30
han.junyang@zte.com.cn Add ZTE DingHai Ethernet PF driver Jun 30
Eli Billauer char: xillybus: Harden driver and improve code quality Jun 30
Li Chen nvdimm: virtio_pmem: fix flush/request failure paths Jun 30
Prasad Kumpatla ASoC: qcom: add AudioReach TDM backend support Jun 30
Varshini Rajendran Add thermal management support for sama7d65 Jun 30
Eric Lin rvtrace: Add SiFive pre-ratified trace device support Jun 30
Chris Lu Bluetooth: btmtk: Add MT7928 support Jun 30
Khristine Andreea Barbulescu gpio: siul2-s32g2: add initial GPIO driver Jun 30
Michael Reeves via B4 Relay Add support for Apple Silicon DockChannel internal keyboards Jun 30
Ivan Vecera dpll: add NCO pin type and zl3073x support Jun 30
Parvathi Pudi Introduce HSR/PRP HW offload support for PRU-ICSSM Ethernet driver Jun 30
Michael Chan bnxt_en: Add kTLS TX offload support Jun 29
Nikhil P. Rao pds_core: Add PLDM firmware update and host backed memory support Jun 29
Richard Fitzgerald Cirrus Logic CS2600 clock device Jun 30
Sriman Achanta HID: steelseries: split out Arctis driver and add Nova 7 Gen2 support Jun 30
Gregory Price dax/kmem: atomic whole-device hotplug via sysfs Jun 30
Amit Sunil Dhamne via B4 Relay Add support for Battery Status AMS Jul 01
dongxuyang@eswincomputing.com Update designware pwm driver Jul 01
Mikko Perttunen Tegra264 PWM support Jul 01
Crescent Hsieh serial: 8250: add Moxa MUEx50 PCIe board support Jul 01
Birger Koblitz ax88179_178a: Add support for AX88179A-based chips Jul 01
Songwei Chai Provide support for Trigger Generation Unit Jun 30
Jaspinder Budhal Add NPAC driver to accel subsystem Jul 01
Zhi Wang gpu: nova-core: boot GSP with vGPU enabled Jul 01
Janani Sunil iio: dac: Add support for AD5529R DAC Jul 01
Ryan Chen Add AST2700 USB3.2 PHY driver Jul 01
Lakshay Piplani Add support for NXP P3H2x4x I3C hub driver Jul 01
Tariq Toukan devlink and mlx5: Support cross-function rate scheduling Jul 01
hang.suan.wang@altera.com Add Altera SoCFPGA Crypto Service (FCS) driver Jul 01
Niklas Söderlund ptp: Add driver for R-Car Gen4 gPTP timer Jul 01
joy.zou@oss.nxp.com add runtime suspend/resume support Jul 01
Vijendar Mukunda ASoC: SOF: amd: add support for ACP7.B/7.F platforms Jul 01
Rakesh Kota regulator: qcom_usb_vbus: add pm4125 VBUS regulator support Jul 01
Kishore Batta Qualcomm Sahara protocol enhancements Jul 01
Harendra Gautam ASoC: qcom: Add QAIF driver for Shikra audio platform Jul 01
AngeloGioacchino Del Regno PHY: Add support for MT8196 DSI PHY Jul 01
AngeloGioacchino Del Regno drm/mediatek: Add DSC, WDMA, MT8189/96 DSI support Jul 01
AngeloGioacchino Del Regno PHY: MediaTek DP PHY refactor and MT8196 eDP Jul 01
AngeloGioacchino Del Regno pmdomains: Fixes and add support for HFRP Direct Jul 01
AngeloGioacchino Del Regno drm/mediatek: The Huge Restructuring and MT8196 support Jul 01
Matti Vaittinen Support ROHM BD73800 Jul 01
Pavitrakumar Managutte crypto: spacc - Add SPAcc Crypto Driver Jul 01
Philip Radford Add support for SCMIv4.0 Powercap Extensions Jul 01
Louis-Alexis Eyraud MT8189: Add support for system and base clock controllers Jul 01
Chen Yu Introduce MMIO-based CMT access for Enhanced RDT Jul 01
Xing Loong tee: add MbedTEE driver Jul 01
Prasad Kumpatla ASoC: add Qualcomm WSA885X codec support Jul 01
Mingming Cao ibmveth: Add multi-queue RX Support Jun 30
Lorenzo Bianconi airoha: add the capability to configure GDM3/GDM4 as WAN/LAN on demand Jul 01
Michael Margolin Introduce Completion Counters Jul 01
Prabhakar Add RTC support for Renesas RZ/T2H and RZ/N2H SoCs Jul 01
Théo Lebrun net: macb: implement context swapping Jul 01
Thierry Reding dma-buf: heaps: Add support for Tegra VPR Jul 01
Matt Evans vfio/pci: Add mmap() for DMABUFs Jul 01

Device-driver infrastructure

Mario Limonciello Add support for a DRM backlight capability Jun 24
Gary Guo rust: I/O type generalization and projection Jun 26
Jacopo Mondi media: v4l2-isp: Add support for extensible statistics Jun 26
Brian Masney clk: implement sync_state support Jun 26
Danilo Krummrich rust: drm: Higher-Ranked Lifetime private data Jun 28
Markus Probst rust: leds: add led classdev abstractions Jun 29
Zhi Wang rust: introduce abstractions for fwctl Jun 29
SeungJong Ha via B4 Relay rust: dma: bridge zerocopy-derived types into the transmute byte-safety bound Jun 28
Bartosz Golaszewski software node: provide support for fw_devlink Jun 29
Maxime Ripard drm: Implement state readout support Jun 26
Maxime Chevallier net: phy_port: SFP modules representation and phy_port listing Jul 01
David Jeffery shut down devices asynchronously Jul 01
Aneesh Kumar K.V (Arm) dma-mapping: Track shared DMA state through direct, pool and swiotlb paths Jul 01
Philipp Stanner drm/sched: Introduce the miracle of locking to entity Jul 01

Filesystems and block layer

Artem Blagodarenko Data in direntry (dirdata) feature Jun 24
Pankaj Raghav add FALLOC_FL_WRITE_ZEROES support to xfs Jun 25
Keith Busch block: validate direct I/O memory alignment Jun 24
Joanne Koong iomap: convert to in-iter ->iomap_next() model Jun 24
Yun Zhou ext4: deferred iput framework for EA inodes Jun 25
Baokun Li ext4: allow more DIO writes under shared i_rwsem Jun 26
Breno Leitao fs/pipe: unify the page pools into a single per-pipe pool Jun 26
Loic Poulain Support for block device NVMEM providers Jun 29
John Ericson fs: support tasks with a null root or cwd Jun 29
Fengnan Chang iomap: add simple dio path for small direct I/O Jun 29
Jori Koolstra vfs: add O_CREAT|O_DIRECTORY to open*(2) Jun 29
Qu Wenruo btrfs: simplify the stripe buffer handling Jun 30
Joanne Koong iomap: convert to in-iter iomap_next() model Jun 30

Memory management

Rik van Riel mm: __access_remote_vm with per-VMA lock Jun 24
Zhen Ni mm/page_owner: add per-fd filter infrastructure for print_mode and NUMA filtering Jun 25
Yitao Jiang mm/mmu_notifier, drm/amdgpu: block THP for GPU user mappings Jun 25
Alexandre Ghiti per-memcg-per-node kmem accounting Jun 26
Usama Arif mm/vmscan: reduce lru_lock contention via vmstat-derived scan-balance cost Jun 26
Matthew Wilcox (Oracle) Simplify filemap faults Jun 25
Breno Leitao mm/memory-failure: add panic option for unrecoverable pages Jun 26
Gladyshev Ilya mm: improve folio refcount scalability Jun 26
Qi Zheng Introducte Reserved THP Jun 27
xu.xin16@zte.com.cn KSM: performance optimizations for rmap_walk_ksm Jun 29
Hao Jia mm/zswap: Implement per-cgroup proactive writeback Jun 29
Kiryl Shutsemau userfaultfd: working set tracking for VM guest memory Jun 29
Lorenzo Stoakes mm: make VMA page offset handling more consistent Jun 29
Brendan Jackman mm: Some cleanups for page allocator APIs Jun 29
Lorenzo Stoakes mm/rmap: index MAP_PRIVATE file-backed folios by virt pgoff Jun 29
Shivank Garg Accelerate page migration with batch copying and hardware offload Jun 30
Usama Arif mm/vmpressure: reduce CPU, memory and code overhead on cgroup v2 Jun 30
Stanislav Kinsburskii mm/hmm: Add mmap lock-drop support for userfaultfd-backed mappings Jun 30
Usama Arif mm: preparatory patches for PMD level swap entries Jun 30
Li Zhe mm: optimize zone-device memmap initialization Jul 01
wang lian mm/damon: add mTHP collapse and split actions Jul 01

Networking

Mahe Tardy bpf: add icmp_send kfunc Jun 24
Andrey Drobyshev vhost/vsock: add support for VHOST_RESET_OWNER and CPR migration Jun 25
Stefano Garzarella vsock/virtio: collapse receive queue under memory pressure Jun 26
Daniel Pawlik netfilter: nf_flow_table_path: L2 bridge offload Jun 29
Shuhao Tan Reuse threaded NAPI kthread across napi_del()/napi_add(). Jun 29
Jori Koolstra af_unix: useful handling of LSM denials on SCM_RIGHTS Jun 29
Mark Bloch evlink: Add boot-time eswitch mode defaults Jun 29
Kuniyuki Iwashima net: fib_rules: RTNL-less RTM_NEWRULE and RTM_DELRULE. Jun 29
Jeremy Kerr net: mctp: usb: Add support for MCTP-over-USB v1.1 Jun 30
Vladimir Vdovin xdp: RX checksum metadata hint and checksum assertion over redirect Jun 30

Security-related

Daniel Borkmann Verify BPF signed loader at load time Jun 24
cem@kernel.org Introduce capable_noaudit Jun 26
Xiang Mei mm/vmalloc: widen guard region to defeat ENTER-based stack pivot Jun 26
Cong Wang seccomp: non-cooperative pinned-memfd argument redirect Jun 26
Leonid Ravich crypto: skcipher - multi-data-unit dispatch as a template Jun 30

Virtualization and containers

Paolo Bonzini KVM: apply chainsaw to struct kvm_mmu Jun 24
Zide Chen KVM: x86/pmu: Add hardware Topdown metrics support Jun 24
Fuad Tabba KVM: arm64: Rework pKVM vCPU state synchronisation Jun 26
Sebastian Ene KVM: arm64: Forward FFA_NOTIFICATION* calls to TrustZone Jun 26
Yong-Xuan Wang KVM: RISC-V: Add CPU PM notifier for non-retention idle states Jun 26
Leonardo Bras KVM Dirty-bit cleaning hw accelerator (HACDBS) Jun 29
Amit Machhiwal KVM: PPC: Expose CPU compatibility modes for nested guests Jul 01

Miscellaneous

Andreas Hindborg rust: add `Ownable` trait and `Owned` type Jun 25
Jiebin Sun perf c2c: add a function view Jun 26
Nika Krasnova rust: kernel: add cfg_select! and use it for config-based selection Jun 29
Tomas Glozar rtla: Allow unsetting non-list custom-callback CLI options Jun 29
Alison Schofield ndctl v85 Jun 29

Page editor: Joe Brockmeier


Copyright © 2026, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds