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

This edition contains the following feature content:

• Progress in modernizing kernel cryptography: Eric Biggers shares his work on making the kernel's cryptographic APIs simpler.
• The kernel's iomap layer: an overview of the kernel's iomap layer.
• Continued coverage from the 2026 Linux Storage, Filesystem, Memory Management, and BPF Summit:
• Limiting negative dentries: a discussion about the role of negative directory cache entries and their impacts on performance.
• Faster RCUs and lockless memory allocation: two sessions touching on improvements to memory allocation and freeing, in the kernel and specific to BPF.
• Two LLM-assisted memory-management patch sets: a discussion about different approaches to the use of LLMs in kernel development.

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)

Progress in modernizing kernel cryptography

At the 2026 Linux Security Summit North America, Eric Biggers spoke about some of the problems with the kernel's cryptography framework, as well as the recent progress in adding library APIs to allow developers to use cryptographic functions without using the traditional crypto API. He walked through a couple of examples to demonstrate the frailty of the original API and showed how the new library API made life easier for developers and kernel maintainers.

Biggers began by introducing himself. He is a maintainer of the crypto and cyclic redundancy check (CRC) library code in the Linux kernel, as well as of the fscrypt library and fs-verity support layer. He said that he was grouping CRCs in with crypto because "they are very similar from an implementation perspective" and the code was for the kernel itself to use—user space has its own code. "It's for all the kernel features that use these algorithms and need to execute them in kernel mode." The use cases, he said, range from storage or network encryption to generating random numbers, checking firmware integrity, protecting against denial-of-service attacks, and more.

Traditional API

The Linux kernel has had what Biggers called the traditional crypto API, found in the top-level crypto directory in the kernel tree, since 2002. It includes cryptographic algorithms as well as some non-cryptographic algorithms such as CRC. Unfortunately, he said, "this traditional crypto API is not working well. It's complex, it's hard to use, and it's often quite slow". That has always been true, he said, but it has gotten worse over time.

The traditional API does not match what most kernel developers want, he said, and has not kept up with hardware: "Specifically, it isn't well optimized for the CPU-based acceleration that modern systems use." He also said that the framework was outdated and that the API does not work well for newer algorithms and implementation strategies.

To prove the point, he said he would show a couple of examples of using a crypto algorithm in the kernel and "why the traditional crypto API isn't all that great". He began with computing a message authentication code (MAC) with a key and some data using HMAC-SHA256, "one of the most common MAC algorithms". The code is from on slides five and six in his presentation.

    static int calc_hmac(const u8 *key, size_t keylen, const u8 *data, size_t datalen, u8 out[32])
    {
    	struct crypto_shash *tfm;
    	int err;
    
    	tfm = crypto_alloc_shash("hmac(sha256)", 0, 0);
    	if (IS_ERR(tfm)) {
    	   pr_err("Failed to allocate hmac(sha256): %ld\n", PTR_ERR(tfm));
    	   return PTR_ERR(tfm);
    	}

To use the traditional crypto API to get the MAC value, he explained, the first thing to do is to dynamically allocate a crypto_shash object for HMAC-SHA256 by passing the name of the algorithm as a string. Then, one has to check for errors, "since this step can and often does fail".

	err = crypto_shash_setkey(tfm, key, keylen);
	if (!err) {
	        SHASH_DESC_ON_STACK(desc, tfm);

		desc->tfm = tfm;
		err = crypto_shash_digest(desc, data, datalen, out);
		shash_desc_zero(desc);
	}
	if (err)
		pr_err("Failed to calculate HMAC-SHA256 value: %d\n", err);
	crypto_free_shash(tfm);
	return err;

The next step is to set the key on the crypto_shash object. That step can also fail, so more error-checking code is required. Then it is necessary to allocate a synchronous hash descriptor; he said that the easiest way to do that is to use the SHASH_DESC_ON_STACK() macro. After that, initialize the hash descriptor by setting the pointer to the crypto_shash. After all that, then it's time to call the function that actually computes the MAC value. Once that is done, clear sensitive data from the stack by zeroizing the hash descriptor, check for errors, and free the crypto_shash.

Biggers said that this code "sort of works" but it is common for bugs to be found after such code is merged because allocating the crypto_shash fails on some systems. The fix for that is to make sure that CRYPTO_HMAC and CRYPTO_SHA256 are enabled in the Kconfig options. "This part is often overlooked because the algorithms are loaded by name, so there's no link-time dependency on them." The code builds fine, but fails at run time and only on some systems. And if a developer wants the code to run in an early init call? "They're still out of luck; there's no way to do that with the traditional API because the crypto API has to initialize itself first."

Performance suffers as well, he said. He had benchmarked the operation on an x86_64 system running the 6.12 kernel, which predates some recent optimizations. "It turns out only 38% of the time was spent actually doing the core SHA-256 computation. Most of the time was actually spent on the overhead of the traditional crypto API".

The better way, he said, was to just add a library function that directly implements HMAC-SHA256 without going through the traditional API. "It's much easier to use and much more efficient too." The example (from slide 11) is shown below:

    hmac_sha256_usingrawkey(key, key_len, data, data_len, out);

He said that he had added this function in the 6.17 kernel, and that the new APIs were already being used in quite a few places in the kernel. The functions always succeed, he said, and callers don't need to handle errors. "They also work in all contexts in the kernel, and they just use standard link-time dependencies so that they don't fail at run time." In addition, it's also faster, particularly with shorter inputs. About 2.5 times as fast as the same operation he had mentioned previously. "I also added a FIPS-140 cryptographic algorithm self-test, so it should work fine with FIPS certifications".

This is not a new approach, he said; for example, crypto libraries were added in 2019 for the algorithms used by WireGuard. Libraries have also been the norm outside the crypto subsystem; he used memcpy() as an example. "It's just a function that does the thing you want, you don't have to dynamically allocate a memory copier object by name and then call several additional functions".

He briefly showed another example of encrypting data using ChaCha20-Poly1305, an authenticated encryption with associated data (AEAD) algorithm. It takes a key, a nonce, plain text, and associated data as input, and produces a ciphertext.

Using the traditional crypto API, the caller has to start by allocating an AEAD transformation object and setting a key: "as usual, both can fail, so you have to write error-handling code, and I hope you remember to test your error-handling code, too. I'm sure everyone does that". He noted that it was also necessary to put data in scatter-gather lists instead of standard buffers; he displayed the example code (slide 15) of setting up the scatter list:

    struct scatterlist src_sg[2], dst_sg[2];
    sg_init_table(src_sg, ARRAY_SIZE(src_sg));
    sg_init_table(dst_sg, ARRAY_SIZE(dst_sg));
    // The below assumes that none of ad, src, and dst points to vmalloc memory
    sg_set_buf(&src_sg[0], ad, ad_len);
    sg_set_buf(&src_sg[1], src, data_len);
    sg_set_buf(&dst_sg[0], ad, ad_len);
    sg_set_buf(&dst_sg[1], dst, data_len + crypto_aead_authsize(tfm));

That was the simplest case where the input and output addresses were already in the kernel's direct mapping. "However, if any of your data is in the stack or elsewhere in the vmalloc region, good luck: because in those cases you'd actually need much more complex code to set up the scatter lists correctly." Biggers said that he had yet to see a single case where someone actually submitted the correct code on the first try without needing fixes.

He added that the request may complete asynchronously, so callers needed to ensure they waited to free their data after submitting the request to complete, lest they create a use-after-free vulnerability.

The library example, once again, was a much simpler endeavor:

    chacha20poly1305_encrypt(dst, src, src_len, ad, ad_len, nonce, key);

All that is required is to call a function that directly implements the algorithm the caller wanted. "As before, it's synchronous, returns void, and it works in any context." He noted that this function was added in 2019 to support WireGuard, so it was not new. His recent work has been focused on hashing and MACs instead, but this function provided a great example because it demonstrated that the traditional API suffered from a lot of complexity that was no longer needed.

Where we are today

As of the 7.1 kernel, the crypto and CRC libraries support a lot of algorithms, he said, and displayed a impressive list (slide 19) that are now supported. Roughly half were added in the last year and a half. But there are still some important ones that are missing, such as the AES encryption modes. "But I'm working on that."

The libraries provide a separate set of functions for each algorithm, which allows them to provide a good API for each one: "just whatever is simplest, easiest to use, and the most efficient". That means that the library works best for in-kernel users who need a single algorithm, he said, which is the most common case. If a kernel feature needs support for multiple algorithms, "you just dispatch to the different functions". That might sound inconvenient, but it is still significantly better than the traditional API. But that API remains available, and has been reimplemented using the libraries where possible.

In the last year and a half, Biggers said, he (along with co-maintainers Ard Biesheuvel and Jason Donenfeld) had adopted KUnit testing, added documentation, simplified how the architecture-optimized code is integrated, and enabled optimizations by default. He had migrated many algorithms into the libraries, and had re-implemented algorithms used by the traditional crypto API to use the libraries. "All this has resulted in lots of negative diffs, both in the crypto subsystem and in code that uses the crypto code, as well as performance improvements and even some bugs fixed too."

He displayed a list of kernel code that is now using the libraries instead of the crypto API (slide 22) that included apparmor, btrfs, dm-verity, fscrypt, bluetooth, and many others.

In addition, he said that some new features had been added to the crypto library that had not existed in the traditional API. For instance, he added support for ML-DSA verification, along with a function for doing so. Support for SHAKE128 and SHAKE256 extendable-output functions (XOF) was added in 6.19. These did not fit into the traditional API, he said, because it assumes fixed-length values. "In fact, I think the traditional crypto API actually predates cryptographers coming up with the concept of XOFs."

Biggers said that he had added support for SHA-256 interleaved hashing to accelerate dm-verity and fs-verity. "Again, that's something that didn't really fit into the traditional crypto API". He mentioned a few other improvements, such as optimizing CRC for arm64, RISC-V, and x86_64; in one case, he said, "I actually improved performance by 12,400%". The performance increase was for CRC64 throughput with 16K messages on one of the latest AMD processors.

With regard to testing and code quality, his priority is correctness. That should be pretty self explanatory, he said. "Crypto code has to be correct, but even non-cryptographic algorithms like CRCs have to be correct too, since people rely on those for data integrity." He welcomed optimizations, but they had to be worthwhile and testable, and added that he had introduced 18 KUnit test suites for the crypto library and one for the CRC library in the 7.1 kernel.

One of the advantages of KUnit is that it's easier to run the tests now; the tests are already enabled in several continuous-integration (CI) systems, including KernelCI. "This wasn't easily possible before because the traditional crypto API uses a custom testing system." He would like to reach 100% code coverage; the library is already closer to reaching that goal than the traditional API.

There is still work to do, however; architecture-optimized code poses a problem. He said he had been testing about 50 combinations in QEMU, and was requiring QEMU support for new code as well to ensure that it was actually tested. "I know that Linux doesn't have this policy from most device drivers, but for crypto code, I do think it's the right policy."

When?

So, when should those working on kernel code that uses crypto or CRC algorithms use the library functions? "The answer is basically whenever you can. In most cases, I think you'll find the library functions are clearly better." There were two exceptions, Biggers said: the first was when the crypto library was missing a function that the traditional API has. He cited AES-GCM as an example. "I'm working on that."

The other exception was when a kernel feature allowed user space to specify an arbitrary algorithm from the traditional crypto API by name. "These features generally have to keep using the traditional API for backwards compatibility."

He advised that anyone adding new kernel features that use cryptography should choose a specific algorithm or, at most, support a small set of algorithms. Historically, he said, there has been a tendency to "just support every algorithm by accepting an arbitrary string from user space and passing it to the traditional crypto API". That was a problem, because it allowed use of algorithms that were insecure, obsolete, or make no sense for the feature in question. "For example, MD5. And also MD4, just in case you thought MD5 was a bit too cutting edge."

He called supporting every algorithm in every kernel feature "a huge footgun for users and a maintenance burden for kernel developers" that increases the attack surface and causes vulnerabilities. He strongly recommended being thoughtful and opinionated about choosing just one good algorithm for new features. "Keep in mind that you can always add more later if ever needed. Also, if you need help choosing algorithms, you can reach out to the Linux crypto mailing list."

AF_ALG

He said that he wanted to call attention to "yet another exciting problem" with the traditional API: the algorithm address family, or AF_ALG. It was added 16 years ago, he said, "and it was a mistake". It exposes almost all of the traditional crypto API to user-space programs, in a bug-prone way, which has resulted in "a continuous stream of security vulnerabilities". What is worse, those vulnerabilities were becoming easier to find and exploit. He did not elaborate on why that was, but the obvious answer is the use of LLM tools to scan for security vulnerabilities.

He said that the audience had probably heard of Copy Fail, but there were an additional four AF_ALG bugs in the past year with working privilege-escalation exploits. The good news, he said, was that AF_ALG had not been commonly used "because it does not provide much that can't be done in user space". That meant that it could be disabled by Linux distributions once a few programs were fixed to use user-space code.

However, Biggers acknowledged that breaking a user-space API in Linux "is kind of a big deal, and it needs to be a community effort". He said he was issuing a call for action to help harden and deprecate AF_ALG; for example, people could help by migrating user-space programs away from AF_ALG or by turning it off on their systems and helping to fix anything that breaks when doing so. On that positive note, he said a bit wryly, it was the end of the talk.

There was one question from the audience about how Biggers actually went about improving performance; did he do it on the assembly language level? He answered that most of the architecture-optimized code and CRC code was written in assembly language, but there were some cases where compiler intrinsics were used instead. With that, the session was out of time.

[I would like to thank the Linux Foundation, LWN's travel sponsor, for supporting my trip to Minneapolis for the Linux Security Summit.]

Comments (18 posted)

The kernel's iomap layer

Conversations about the kernel's filesystem implementations often involve a layer called "iomap", but relatively few people can reliably say what iomap actually is. That is just the kind of gap that LWN exists to fill. In short, iomap handles the mapping between data in the filesystem space (identified by a file of interest, and an offset within that file) and in the storage space (which may be a memory location, or a set of blocks on a storage device). Using that mapping, iomap handles a long list of common, filesystem-related tasks, allowing a lot of boilerplate code to be removed from individual filesystem implementations.

The iomap code was first introduced as such by Christoph Hellwig for the 4.8 kernel release in late 2016, but much of that functionality was based on an earlier implementation by Dave Chinner in the XFS filesystem. It has grown over the years as filesystems have been converted over and new functionality has been added. The current implementation consists of a dozen files in the fs/iomap directory. It is implemented as two broad layers, a low-level mapping between files and their backing store, which is used by higher-level code to implement much of the functionality that a filesystem needs.

The storage mapping

Every file implemented by a filesystem, with few exceptions, is a representation of a series of bytes stored on a persistent medium somewhere. Much of the work a filesystem comes down to implementing operations expressed in terms of files and offsets by moving data between memory and that persistent media. A key part of this task is managing the mapping between those two domains.

In the earlier days of Linux, this mapping was represented by buffer heads, but they suffer from a number of problems. As a direct mapping between a disk block and an equally sized region of memory, buffer heads are not designed for today's large files and extent-based filesystems. It is difficult to generate large, efficient I/O operations when the data involved is represented by buffer heads. A single contiguous extent on disk might require hundreds of buffer heads, each managing a single block, which must be reassembled into a small number of I/O operations.

With iomap, a mapping that might have involved a large number of buffer heads can, instead, be expressed with a single iomap structure:

    struct iomap {
	u64			addr; 		/* disk offset of mapping, bytes */
	loff_t			offset;		/* file offset of mapping, bytes */
	u64			length;		/* length of mapping, bytes */
	u16			type;		/* type of mapping */
	u16			flags;		/* flags for mapping */
	struct block_device	*bdev;		/* block device for I/O */
	struct dax_device	*dax_dev; 	/* dax_dev for dax operations */
	void			*inline_data;
	void			*private;	/* filesystem private */
	u64			validity_cookie; /* used with .iomap_valid() */
    };

To simplify things a bit, an instance of this structure says that the range of a file starting at offset bytes and continuing for length bytes is stored at addr on the underlying device which, in turn, is identified by bdev (for normal block devices), dax_dev (for persistent-memory DAX devices), or the memory range at inline_data. The type field describes what kind of mapping is actually represented:

• IOMAP_MAPPED indicates a normal mapping from the file to space on the persistent storage device.
• IOMAP_INLINE, instead, is a mapping between the file and the memory pointed to by inline_data. This sort of mapping might be used for tiny files where the file data can be stored in the file inode itself.
• IOMAP_HOLE means that the underlying storage has not been allocated — that there is no mapping at all. It is only valid for read operations, and the result is that a read from this range will return zeroes.
• IOMAP_DELALLOC also says that the mapping does not exist, but that it will be created at a future time.
• IOMAP_UNWRITTEN says that the mapping exists, but that the backing store has not been written and may contain random (or sensitive) data. Reads from this range will return zeros rather than going to the backing store.

There is an extensive set of flags that can be set by the filesystem to affect how the I/O is done, mark a shared mapping that must be copied on write, and more.

These iomap structures must be filled in by the filesystem implementation in response to requests from the iomap layer. Those requests will be received by way of a couple of callbacks supplied by the filesystem:

    struct iomap_ops {
	/*
	 * Return the existing mapping at pos, or reserve space starting at
	 * pos for up to length, as long as we can do it as a single mapping.
	 * The actual length is returned in iomap->length.
	 */
	int (*iomap_begin)(struct inode *inode, loff_t pos, loff_t length,
			unsigned flags, struct iomap *iomap,
			struct iomap *srcmap);
	/*
	 * Commit and/or unreserve space previous allocated using iomap_begin.
	 * Written indicates the length of the successful write operation which
	 * needs to be commited, while the rest needs to be unreserved.
	 * Written might be zero if no data was written.
	 */
	int (*iomap_end)(struct inode *inode, loff_t pos, loff_t length,
			ssize_t written, unsigned flags, struct iomap *iomap);
    };

Before an operation starts, iomap_begin() will be called to inform the filesystem that the indicated region of the file is about to be read or written. The file involved is identified by inode, with pos and length indicating the range of the file that the operation will affect. The flags parameter has a number of options describing what is about to happen, including:

• IOMAP_WRITE: the given range will be written to, so space must be allocated (if not already present). The absence of this flag implies a read operation.
• IOMAP_ZERO: zero out a range of the file.
• IOMAP_DIRECT: a direct-I/O operation, avoiding the page cache, is called for.

The iomap_begin() function must fill in the provided iomap structure with a suitable mapping for at least the first byte of the requested operation; obviously, it is better to map a much larger range if that can be done with a single mapping. The srcmap parameter exists for cases where data for the operation (imagine a small write that requires reading a block before writing a portion of it) must be read from a different device.

The iomap_end() function will be called when the operation completes; the written parameter will contain the number of bytes that were actually written. This callback is to allow filesystems to clean up after an operation, account for allocated blocks, and release any blocks that were not actually written.

Filesystem I/O

The mappings as described above are only useful if the kernel can use them to actually perform I/O and implement filesystem functionality in general. Iomap provides a lot of functions that can help in this regard; they are, as a general rule, immaculately undocumented, requiring filesystem developers to dig through the source to discover them and figure out how to use them. Whether this state of affairs might have slowed the iomap conversion is left for the reader to conclude.

Filling in all of that documentation is rather beyond the scope of what this article can achieve, but an example can be illustrative. Consider the case of buffered reads. If an application calls read() on a file, there are a number of things that need to happen, including allocating space in the page cache, locating the data on disk, reading the data into the page cache, and copying it to the user-space buffer. The kernel's virtual filesystem layer handles many of those details, but there are pieces that the filesystem must implement.

For buffered I/O, the filesystem must provide a struct address_space_operations with a number of callbacks to implement specific operations. One of those, used for read operations, is read_folio():

    int (*read_folio)(struct file *file, struct folio *folio);

The folio structure describes the memory into which the data should be read; it also contains the details of the file that the folio maps, the folio's offset within the file, and its length. The filesystem should respond by performing the actual read and marking the folio as being current. That might involve performing several I/O operations if the folio spans multiple, non-contiguous blocks on the backing device.

A filesystem implementation can implement most of the work of read_folio() with a call to iomap_read_folio(), but it is not quite that simple; there is a certain amount of glue that must be applied in the filesystem's read_folio() callback first. That includes the definition of an iomap_read_ops structure:

    struct iomap_read_ops {
	int (*read_folio_range)(const struct iomap_iter *iter,
				struct iomap_read_folio_ctx *ctx, size_t len);
	void (*submit_read)(const struct iomap_iter *iter,
			    struct iomap_read_folio_ctx *ctx);
        /* ... */
    };

The read_folio_range() operation will do the work of creating a single read operation, perhaps only covering a portion of a larger request. If read_folio_range() is synchronous, there is no need for a submit_read() callback; otherwise that function should be provided to actually start the read operations. The arguments to both functions are an iomap_iter structure that contains, among other things, the current read position, and the ctx argument, which is an instance of this structure type:

    struct iomap_read_folio_ctx {
	const struct iomap_read_ops *ops;
	struct folio		*cur_folio;
	struct readahead_control *rac;
	void			*read_ctx;
	loff_t			read_ctx_file_offset;
    };

This structure should be created in the filesystem's read_folio() implementation; cur_folio should be set to the folio argument passed in, and ops to the filesystem's iomap_read_ops structure. Happily, many filesystems do not actually have to create their own iomap_read_ops; the iomap layer has implementations of its own for the common cases. So, for example, a disk-based filesystem could use iomap_bio_read_ops rather than supplying its own.

With the appropriate structures in place, a read_folio() implementation comes down to a call to iomap_read_folio():

    void iomap_read_folio(const struct iomap_ops *ops,
	  		  struct iomap_read_folio_ctx *ctx,
			  void *private);

Here, the ops structure is, finally, the set of mapping operations that were described some time back. The iomap layer will use those operations to map the read onto one or more ranges in the file's backing store, then use the provided read operations to read those ranges into the provided folio.

The above sequence of calls looks something like this:

The iomap layer hides a lot of the complexity that comes with implementing a filesystem, but a fair amount still leaks through; much of it has been craftily glossed over here. For example, the readahead_control structure in struct iomap_read_folio_ctx provides the parameters for readahead operations, which may bring in a set of blocks speculatively in the hope of accelerating future reads.

Buffered-write operations are implemented, in struct address_space_operations, by the writepages() callback. There is a similar impedance-matching task to be done here. The iomap_writeback_ops structure provides a set of low-level callbacks to implement writes; that should be stored in an iomap_writepage_ctx structure, then passed to iomap_writepages().

Many other filesystem operations have iomap support; these include direct I/O, DAX I/O, seeking within files, handling page faults, file truncation, swap-file activation, and more. The above snide comments notwithstanding, there is some documentation for iomap included with the kernel; it was added to the 6.11 release by Darrick Wong, who was drawing on work from a number of developers.

In conclusion

The iomap subsystem is far from complete, with new work being merged in almost every development cycle. Recent changes include support for files with fs-verity integrity protection, the ability to generate and verify T10 protection information, better readahead support, and more. There is, of course, also the occasional security fix to take care of. There is work underway that may cause the iomap_begin() and iomap_end() callbacks described above to be replaced with an iterator-based API and to improve direct-I/O performance. Filesystem conversions continue, with work on converting the exfat and minix filesystems to use iomap under consideration now. In other words, iomap is a fairly typical busy core-kernel subsystem.

All told, implementing a filesystem involves a certain amount of complexity that cannot be abstracted away entirely. The iomap layer does, however, handle a lot of the low-level details that every filesystem must take care of. Use of iomap also makes features like large-folio support work with little additional effort. So it is not surprising that, over the years, most actively maintained filesystems have, at least partially, transitioned to iomap.

(Thanks to Steinar H. Gunderson for suggesting this topic.)

Comments (1 posted)

Limiting negative dentries

A number of problems related to negative directory entries (dentries) were the topic of a filesystem-track session at the 2026 Linux Storage, Filesystem, Memory Management, and BPF Summit. Negative dentries are used to indicate that a file of a given name does not exist in a directory; it is an optimization that short-circuits the lookup of the file name when the answer is already known. Miklos Szeredi led a session that discussed some problems that come from having too many negative dentries for a directory.

He began by noting that Ian Kent had reported a problem with hundreds of millions of negative dentries for a directory; in that case, the fsnotify_set_children_dentry_flags() call was made, which will iterate over all of the dentries in the directory and cause a soft lockup. A related issue is that the reference count field of the d_lockref lock in struct dentry can overflow if enough dentries are created, Szeredi said. It is not negative-dentry-specific, but it would be hard to create two-billion positive dentries for a directory. Kent had also mentioned that the hash chains may grow too long when there are so many negative dentries, but Szeredi is not sure that is a real problem.

Amir Goldstein had previously suggested moving the negative dentries to the end of the d_children list in struct dentry, Szeredi said. That would allow iterators like fsnotify_set_children_dentry_flags() to stop when they reach the first negative dentry. Chuck Lever was concerned that the order of child dentries might be exposed via getdents(), thus moving the negative dentries might cause reordering in a way that would break users of getdents(); Szeredi did not think that would be a problem, however. An alternative might be to add calls to cond_resched() into the code that walks the d_children list, Szeredi said; that would be more complex but would also address any soft lockups that are caused by positive dentries, not just those from negative dentries.

Jan Kara was also concerned that moving negative dentries to the end might cause ordering problems if one of those dentries is changed to a positive dentry when a file is created. Some of the child-walking iterators depend on not missing any entries, he believes, so there could be problems inserting the updated dentry into the d_children list. "I am not saying it's impossible, I am just not sure whether there will not be some catch." Szeredi said that he thought the iterators' locking would prevent those kinds of problems as long as the dentry update also used that lock.

David Howells raised the idea of switching the data structure used to track the children to something more suited to handling massive numbers of negative dentries. He did not have a concrete suggestion for what that data structure might be, however. Christian Brauner said that "in principle there is nothing stopping us from changing the data structure", though it would require agreement from others.

Brauner asked about a patch set from Kent that would limit the number of dentries that could accumulate for the children of a directory. Brauner thinks that some kind of heuristic limit on dentries should be explored, separate from possible limits on negative dentries. That could perhaps lead to a "meaningful heuristic that isn't just a sysfs file" to better manage negative dentries. The problem with the accumulation of too many negative dentries has been around for ten years or more, he said; it is time to fix it.

There is an opportunity to add to the existing sysfs knob (dentry-negative), Brauner said. The current default is "we will swamp your RAM with all of the dentries that we want", which is fine for some workloads. Other users have complained about accumulating negative dentries, which is why dentry-negative can be set to one to cause unlink() to remove the dentry rather than turn it into a negative one. That does not solve the negative-dentry problem for everyone, however, so more options may be needed.

Szeredi pointed out that user space would have to be in charge of managing that. "Yes, that's my solution for everything", Brauner said to laughter. It is often the case that user space is better placed to determine these kinds of things, he continued. "Pushing everything out to user space, a la BPF, isn't a great solution always, but for a lot of that stuff we see that it actually works." He pointed to the out-of-memory (OOM) killer as an example where the kernel really cannot make a sensible choice for all workloads so user space is better placed to do so.

Jeff Layton agreed that policy choices should be left to user space. However, Ted Ts'o noted that doing so is in tension with "decades of experience that users never change the defaults"; he suggested that sophisticated users have a knob available, but that the default work well for the common case. He thought that perhaps a limit of 1,000 negative dentries per directory would be sufficient for "all sane workloads", but surely "my imagination is failing me". He would like to find out about workloads where that limit would be a problem in order to understand what other options might make sense.

The overflow of the reference count for the per-dentry lock, which came up as part of the too-many-dentries problem, is serious, Brauner said. It requires two-billion dentries, Kara said, so it is hard to hit. Brauner wondered if there could be some kind of built-in limit so that it could not happen. Layton asked if the count was actually overflowing, but Szeredi said it was a theoretical problem, not one that has been reported.

Goldstein asked whether the superblock shrinkers prioritized negative dentries for eviction and reclaiming. Layton said that they probably do not since the dentries are maintained on a least-recently used (LRU) basis. Goldstein wondered if that should change. While Kara thought that perhaps it should, Szeredi pointed out that the problems occur on systems with too much memory so that the shrinkers are not being run at all.

There was some unfocused talk about ways to limit the count and avoid the overflow as time ran out on the session.

Comments (22 posted)

Faster RCUs and lockless memory allocation

Puranjay Mohan shared some of the work he's been doing recently on improving the performance of read-copy-update (RCU) at the 2026 Linux Storage, Filesystem, Memory-Management, and BPF Summit; his talk would have been nice context to have earlier in the day when Harry Yoo and Alexei Starovoitov led a session about the new kmalloc_nolock() function that allows for lockless allocation from any kernel context, and which interacts with the RCU subsystem to allow that. This article therefore covers the two sessions together and in the reverse order, to provide that missing context.

Faster RCU periods

The idea for Mohan's performance work began, as so many RCU-related ideas do, while chatting with Paul McKenney. RCU works to protect data behind a pointer by having writers create a new copy with any changes they wish to make, and then atomically swapping the pointer to point to the new copy. Readers may still be reading the old version, so the writer cannot free the old version until it can be sure that all of the readers have moved on.

That happens whenever the kernel reaches a "quiescent state": every CPU has gone through a context switch, idle, return to user space, or other transition that ensures no reader can still exist. The RCU subsystem counts these events. When the old version of an RCU-protected resource needs to be freed, the subsystem waits until the counter is high enough (two more than the value of the counter when the new copy was swapped in, so that at least one full period is guaranteed to have elapsed) before freeing the memory. This wait is called the RCU grace period. The work that is waiting on a grace period is managed using a linked list of callbacks.

But there are two different kinds of grace period. A call to synchronize_rcu() passively waits for CPUs to report that they have reached a quiescent state, which can take tens of milliseconds. A call to synchronize_rcu_expedited() sends inter-processor interrupts (IPIs) to force CPUs to reach and report quiescent states faster than normal. The second kind of grace period is, naturally, used in places where the kernel does not want to wait as long.

The problem is that these mechanisms run concurrently and don't know about each other. A callback waiting for the end of a normal RCU grace period is not necessarily run when an expedited grace period ends, and vice versa. The idea that came up in Mohan's discussion with McKenney is to fix this — allow normal RCU callbacks to be executed as soon as an expedited grace period ends. Expedited grace periods happen frequently in some workloads, especially when the system is under memory pressure, so this change could result in RCU-protected resources being freed much more quickly.

The fix is conceptually simple: have the callback list track both the non-expedited grace-period number and the expedited grace-period number, and consider callbacks eligible to run as soon as either is high enough. Alas, the details are a bit more complicated, especially because RCU is a performance-critical part of the kernel. There were three internal kernel functions — rcu_exp_wait_wake(), rcu_pending(), and rcu_core() — that needed adjustments to their logic to handle the change.

Once it was working, Mohan ran a series of benchmarks to evaluate what the actual impact of the change would be. He set up fifteen threads to create and destroy sockets in a loop, which use RCU to free the memory. Other threads deliberately triggered expedited grace periods. Then he measured how the rate of expedited grace periods impacted the memory usage and latency of socket destruction. Overall, he saw 33%-41% less allocated memory (since memory was being freed earlier), across all tested expedited grace period rates. The latency of synchronize_rcu() calls also went down, although in a way that was more sensitive to the actual rate of expedited grace periods.

Yoo asked whether it made sense to ask for an expedited grace period even when there is no particular need for one, just to reclaim memory. Mohan agreed that his patch set would make that possible, but Starovoitov objected that general best practice is to not use expedited grace periods unless they're really needed, since IPIs are expensive. During an out-of-memory situation, it is often too late for an expedited grace period to make a difference. Jakub Sitnicki suggested that an expedited grace period could be used as part of direct reclaim; Starovoitov directed people to ask McKenney and the memory-management folks about the consequences.

Another member of the audience asked whether Mohan knew how often expedited grace periods were triggered in real workloads. Mohan didn't have production data for that, but expected it to vary significantly depending on the workload, and particularly on whether any BPF programs perform "map-in-map" updates, which consistently trigger expedited grace periods. That last question marked the end of the session.

Lock-free memory allocation

In the past, programs that used BPF maps were required to preallocate the memory for those maps, Yoo explained as he opened the session on kmalloc_nolock(). This let the programs access the maps without needing to take the locks needed by the normal memory allocator, but it also wasted memory in the case that the program doesn't fill the map. The BPF allocator was added to the kernel to allocate that memory on demand, but it introduced its own challenges. For one thing, inventing a new memory allocator is not fun. It introduces a maintenance burden that the BPF subsystem could do without. As originally designed, the BPF allocator also couldn't be used outside the BPF subsystem. The goal of the recent work on kmalloc_nolock() is to remove the BPF allocator without bringing back preallocation of BPF maps.

The tricky part is that there are both sleepable and non-sleepable BPF programs that can access this memory. Non-sleepable programs can even access it from inside RCU critical sections. So, to provide a viable replacement for the BPF allocator, any solution needs to support allocating memory from both sleepable and non-sleepable contexts and potentially having that memory accessed from the other kind of context. It also needs to support having that memory be immediately freed, or even recycled using the typesafety-by-RCU mechanism.

After an RCU writer has swapped the pointer to an RCU-protected object, while it is waiting to be able to free the old version, there is the possibility that it will need to allocate another object of the same type. Normally, it would need to create a new allocation, since existing readers could still be referring to the old object. In some cases, however, it can be safe to reuse the existing allocation, even though readers may still be accessing it. Because using the allocation for a different type of object could lead to undefined behavior, this is only safe when any readers will expect the object to be of the exact same type. That it will be the same type, and not just an allocation of the same size, is guaranteed by the RCU subsystem, hence the name "typesafety by RCU".

One place that this technique is used is in BPF hashmaps. In the kernel, almost all hashmaps use linked lists for hash buckets, where each element in the linked list contains a copy of the key and some associated data. The actual structure definition is more complicated, but it can be thought of as:

    struct node {
        long key;
        void *data;
        struct node *next;
    };

When removing an element from a hash bucket, the writer knows that any readers will need to check whether the key stored in the element is the one they're interested in. Therefore, after the object has been unlinked from the hash bucket, the writer can atomically change the key to something else, then update the data, before finally adding the object back to the appropriate bucket of the hashmap. Readers need to load the data pointer, followed by the key, and then validate that the key matches the object they wanted before using the data pointer. Since the writer updates the key first and the reader fetches the data pointer first, as long as appropriate memory ordering is used, the reader never reads incorrect data. They can read incorrect next pointers, however, which sends them traversing the wrong hash bucket. Therefore, each hash bucket ends with a structure saying which bucket this is the end of; if the reader reaches the end marker for a different bucket, it knows that it ran into this case, and needs to re-scan the correct bucket. This whole careful dance avoids needing to wait for the object to be returned to the kernel's general memory pool, reducing latency, memory churn, and memory usage.

One audience member asked why the allocator would need to support memory being freed immediately. Starovoitov explained that some BPF iterators and helper functions can do that under some circumstances. Yoo's slides had included a mention of a kfree_nolock() to accompany kmalloc_nolock(). Amery Hung pointed out that it is already possible to use kfree() in these contexts, so there was probably no need for a separate kfree_nolock(). Yoo explained that the separate function is needed to support typesafety-by-RCU's caching, which is important for performance.

Starovoitov elaborated by saying that "back in the tracing days" people would add elements to BPF maps and then remove them within nanoseconds. That was an especially common pattern for latency profiling — adding and removing a timestamp from a map. Freeing them using free_rcu() would go through a full RCU cycle, potentially much longer than the object had been needed in the first place. Using typesafety-by-RCU avoids that overhead, but the exact mechanism used to recycle freed memory doesn't really matter as long as there is some way to do this instant reuse, Starovoitov said.

That prompted a digression about how this interacted with having different CPUs running BPF programs; in short, there's a potential for BPF programs to have race-condition-related correctness bugs here, but not in a way that impacts the kernel.

Eventually, Yoo brought the topic back to kmalloc_nolock() and acknowledged that there would probably also need to be a kfree_rcu_nolock() to handle some cases. Starovoitov then asked about handling failure: kmalloc_nolock() succeeds "pretty much all of the time", but sometimes there is just no memory that is available without taking a lock. Yoo said that falling back to the buddy allocator and asking for a new slab might be a reasonable approach, but Starovoitov noted that that too can fail. He asked whether there was any way to handle failure in that case.

Another round of discussion eventually produced a design that should be more robust to allocation failures, and support the ability to attach destructors to objects, but that was not able to completely avoid the possibility of allocation failure. Nevertheless, Starovoitov was pleased with the discussion, saying: "I'm glad we talked it through." The new design will, presumably, be a great improvement over the existing allocator all around.

Comments (none posted)

Two LLM-assisted memory-management patch sets

The kernel community (like many other free-software projects) has recently seen a large influx of patches developed with the assistance of large language models (LLMs). Those patches tend to come from developers who were previously unknown to the community. At the moment, though, the memory-management developers are evaluating two large patch sets, developed with LLM assistance, that were submitted by established and well-respected developers. The rather different reception accorded to that work may give insights into how LLM-generated contributions will be handled going forward.

Reliable 1GB allocations

As a Linux system runs, it tends to fragment its memory, making the allocation of large, physically contiguous chunks of memory difficult. Much work has been done over the years to improve this situation; the kernel tries hard to avoid fragmentation, and to actively defragment memory as needed. Larger allocations are more reliable than they once were. Still, allocation challenges can, for example, make it harder for the system to provide 2MB PMD-level huge pages than would be ideal.

Given that difficulty, it might seem that reliable allocation of PUD-level (1GB) huge pages is an impossible goal. But, as Rik van Riel said in the cover letter to a 40-part patch series, there are workloads that can gain significant performance benefit from the use of 1GB huge pages, if they can succeed in obtaining them. The only way to reliably allocate regions of that size in current kernels is to use the hugetlbfs subsystem, which reserves memory for this purpose at boot time. Hugetlbfs is inflexible, though; its reserved pages cannot be used for other purposes, and it cannot reserve additional pages if the workload needs them. The system administrator can only hope that the reservation set up at boot time is suitable for all workloads the system may subsequently run.

Van Riel's patch set attempts to make 1GB allocations more reliable without the need for the hugetlbfs reservation. It takes a number of approaches to reach that goal, but the core idea is the management of memory in units known as "super page blocks". The kernel breaks memory into page blocks now, and it manages them in ways designed to combat fragmentation. One of the key techniques is to segregate allocations that can be moved from those that cannot. For example, most user-space memory is movable, it is just a matter of changing all of the relevant page-table entries to match. On the other hand, allocations for the kernel's own use generally cannot be moved. By keeping the two types separate, the kernel maximizes its chances of creating entire free page blocks by moving the pages within them elsewhere.

Page blocks work reasonably well when it comes to helping the page allocator provide PMD-level huge pages. But they are much smaller than the 1GB target that Van Riel is trying to hit; on the system used to write this article, page blocks are configured to be 4MB in size. In a typical system, some page blocks will be used for movable allocations, while others will hold unmovable allocations. The movable blocks can, at need, be emptied out to create more PMD-level huge pages. But it only takes a single unmovable page block to render its entire containing 1GB huge page unmovable and, as a result, permanently fragmented.

The addition of super page blocks gives the page allocator another level of visibility into the use of memory. If a request comes in to allocate an unmovable page, the allocator will attempt to allocate from an unmovable page block as before. Should there be no such page blocks with free memory available, though, the allocator will need to pick a new page block to allocate from. Van Riel's patch set will cause the allocator to attempt to select that page block from a super page block that already holds other unmovable allocations. In other words, the segregation of movable and unmovable allocations is now done at the 1GB scale, increasing the chances that 1GB huge pages can be created and allocated at need.

There are a number of other techniques that are employed to help this overall policy succeed. Consider, for example, a virtually mapped kernel-space allocation (as might be obtained with kvmalloc()) requiring several pages. This allocation is not movable, and thus should be put into an unmovable super page block. If there are no such blocks with that many contiguous pages available, the allocator would naturally pick a new super page block, thus "tainting" it and making it unmovable. If, however, the allocation can be satisfied from existing unmovable super page blocks by splitting it into smaller chunks, the allocator will do that.

The patches in this series carry an Assisted-by tag indicating that the Claude Opus LLM was used in their creation. As noted above, though, van Riel is not a new developer needing LLM assistance to be able to put together a kernel patch. His first mention in LWN was with regard to a discussion on memory fragmentation — in 1998; he proposed the addition of a zoned memory allocator, which subsequently came to be. He is the sort of developer who is likely to get the benefit of the doubt when it comes to choices of tools.

This particular patch series has not been entirely well received, though, despite the fact that its goal — reliable allocation of 1GB huge pages — is widely supported. The most pointed criticism was surely this lengthy message from Lorenzo Stoakes, who took issue with the organization of the series and the code within it. "The series is completely unmergeable as it stands. Not even close." Other parts of the series were described as "code war crimes against __rmqueue_smallest()" or "something you expect to see on a 1990's PHP website, not in core mm code". He concluded with:

OK with all that said - to be absolutely clear - I respect you a great deal, and I KNOW you're (much, much) better than this.

And, to repeat, this idea is very exciting and I _want_ to see this land.

But I feel you've rather let the LLM run amok and it's selling you (very, very) short, given just how smart and capable you are.

Van Riel answered that he never expected the code to be merged in its current form, and that he had really been hoping for feedback on the overall design before reimplementing it in a form that could be considered for merging. The massive dump of LLM-generated code has gotten in the way of that process, though. Developers want to look at the implementation of a design to understand how it works in practice, and that has proved difficult for them to do in this case. This work will have to be redone, with more human attention paid, before it can be seriously considered, even at the design level.

Working-set tracking for virtual-machine guest memory

Virtual machines (VMs) are subject to two levels of memory management. They handle their own memory internally, but there is also host-level management that tries to ensure that the system's physical memory is used efficiently by all of the running VMs. The host-level task is easier if the VM manager (hypervisor) has visibility into which pages a given VM is actually using; that information can be used to reclaim the colder pages (or to move them to slower memory). But that information tends to be locked away inside the VM itself.

This patch series from Kiryl Shutsemau is meant to make that usage information more readily available to VM managers. It adds a new registration mode to the userfaultfd() system call that will cause the protections (at the host level) on the indicated range of pages to be marked as "no access". At registration time, it is possible to choose between two alternatives for what happens when the virtual machine does access one of those pages. If the synchronous mode has been selected, the VM manager will receive a message from the kernel and, after having noted the fault, can resolve it with another request back to the kernel. In the asynchronous mode, the kernel resets the permissions without notification to the VM manager. At a later time, the manager can scan the page range to see which pages have been accessed. This documentation patch describes the feature in more detail.

These patches, too, include an Assisted-by tag naming Claude Opus. Shutsemau does not have Van Riel's longevity in the kernel community; having made his first contribution to the 2.6.25 kernel in 2008, he is a relative newcomer. Still, his track record is long enough to make it clear that, once again, he is entirely capable of understanding the work that he is submitting to the community.

This series has been through seven revisions and significant changes resulting from the reviews that were received. In contrast to how Van Riel's work was received, none of those reviews was the role of the LLM in the creation of the work raised as a concern. In response to the second revision, though, Andrew Morton did ask for information about how the LLM was used; Shutsemau responded in detail. Much of the tool's role was in validating ideas:

For this particular project there was quite a bit of path-finding. I had a phase where I bounced ideas off Claude. It helped me understand the problem space better and formulate possible solutions. Rubber ducking on steroids.

Once it's clear _what_ to do, we formulate a plan on _how_. It also involves back and forth.

Once the plan was done, I gave the go-ahead on executing it.

The most time-consuming part of the process, he said, was reviewing the resulting code; that involved restarting the process from the beginning more than once. It took "maybe between 8 and 10" rounds to obtain code that he was happy with — before then feeding the whole series, along with a different set of prompts, to an LLM for review.

This workflow has seemingly produced a viable patch set that makes significant changes to the core memory-management code. The key to success, relative to the work previously described above, would appear to be the investment of substantial amounts of human time to get the tool to do the job properly, and in dealing with the remaining problems afterward. The care seemingly taken to ensure that the patches were up to the level of quality that the community expects by the time they hit the mailing lists appears to have made all the difference.

Shutsemau did not say whether that whole process was more efficient than simply doing the job without LLM assistance, but he does seem inclined to use that process again in the future.

The end of Shutsemau's message was a request for other developers to share their process for working with LLMs, but there were no responses. In truth, when it comes to significant work on the core kernel, he would appear to be one of the pioneers. The path toward success that he described, though, does not seem to be an easy one; anybody who is hoping to use an LLM as a quick way to become a kernel developer would do well to take note of what is likely to become the biggest success story (for kernel code) so far.

Comments (22 posted)

Four vulnerabilities in Guix

The GNU Guix project has announced three vulnerabilities in the guix substitute utility as well as a fourth that affects the guix pull and guix time-machine commands. The impact of the vulnerabilities ranges from remote privilege escalation to local disclosure of sensitive files.

The remote exploitation of guix substitute only requires that the vulnerable system attempt to download a binary substitute. Any configured substitute server, including ones discovered using guix-daemon's --discover option, can exploit this, and so can a man-in-the-middle (MITM), regardless of whether https is used in the substitute server urls.

The local exploitation of guix substitute only requires the ability to connect to guix-daemon's socket, which by default any user can do.

Separately, another security issue (CVE ID pending) was identified in guix pull and guix time-machine, which enables anyone who can control the channels file used by these commands to cause a file to be created or overwritten wherever the user running the command in question has permission to create them.

The project is recommending that all users upgrade guix and guix-daemon immediately. See the announcement for instructions, how to test for the vulnerabilities, the disclosure timeline, and more.

Comments (2 posted)

OpenSSH 10.4 released

OpenSSH 10.4 has been released. In addition to a number of security and bug fixes, there are a few notable changes; this release adds experimental support for a composite post-quantum signature scheme combining ML-DSA 44 and Ed25519 as described in this IETF draft. With 10.4, if OpenSSH is compiled with sandbox support it will fail on Linux systems that have not enabled SECCOMP or NO_NEW_PRIVS; prior to this release, sshd would log an error but continue operation. See the release notes for a full list of changes.

Comments (none posted)

Woodruff: You shouldn't trust trusted publishing

William Woodruff, better known online as "yossarian", has published a blog post to make the case that users should not place their trust in trusted publishing:

Trusted Publishing is a mechanism for establishing trust between an external machine identity (like a CI/CD workflow) and one or more projects on a package index/registry. The "trust" in "Trusted Publishing" refers to that trust relationship, and not to anything else.

It is not, and cannot be, a signal for package trust or quality. You cannot use it to determine whether a package is safe or "good," and PyPI consciously stymies attempts to misuse it for that purpose by not rendering it as a "green checkmark" or anything else of the sort.

Or as another framing: Trusted Publishing is just a form of authentication. It doesn't tell you anything other than that an upload was authenticated, which all uploads to PyPI are.

LWN covered trusted publishing in June.

Comments (57 posted)

Security quote of the week

Computerization has long allowed data collectors to track our locations, collect lists of whom we communicate with, and monitor our spending habits – unless we use cash. What's new is an unprecedented fusion of each of these mechanisms, persistent and unrelenting. AI brings an analytical ability to spy on the contents of our communications, and to answer sophisticated questions about our whereabouts and activities: actions that previously required human analysts are now automated. The result will be a kind of supercharged societal level of chilling effects where fear, self-censorship and groupthink reign, and dissent, creativity and innovation become increasingly rare.

In this atmosphere of fear and conformity, risky ideas, social activism and self-reinvention – especially by disfavored groups and targeted populations – are also chilled. This will have long-term effects on social progress.

— Bruce Schneier and Jon Penney

Comments (none posted)

Kernel release status

The current development kernel is 7.2-rc2, released on July 6. Linus said: "It's Sunday afternoon, and rc2 is out. Things look very normal - it's not a small rc2, but it's in line with recent releases, and slightly smaller than rc2 was in 7.1. Let's see how that all continues, but so far so good."

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

RC	Date	Commits
v7.2-rc1	2026-06-28	14395	14395
v7.2-rc2	2026-07-05	433	433

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

Stable updates: 7.1.3, 6.18.38, 6.12.95, 6.6.144, 6.1.177, 5.15.211, and 5.10.260 were released on July 4.

Comments (none posted)

Kernel archive /pub tree restoring

A few astute observers have noticed that some content on kernel.org had disappeared and were understandably concerned. Konstantin Ryabitsev has provided an update via social.kernel.org:

There was an unfortunate error while changing the kernel.org primary/secondary mirroring infrastructure, which resulted in the /pub tree suddenly becoming empty. No data was lost, just public mirror copies. Everything is now being restored, but deletes are fast and restores are slow, so thank you for your patience!

The incident is being tracked on the Linux Foundation's IT status page.

Comments (4 posted)

Quote of the week

As with other subsystems we see a lot of AI generated patches and bug reports (publicly and off-list) where the submitter functions like the Mouth of Sauron. This is not acceptable and such patches will either be ignored or heavily deprioritized.

In general, over-the-wall, vibe-coded, complex RFC submissions can never be expected to get lengthy, in-depth reviews especially if the submitter shows clear signs of not having actually spent the time to think things through or doesn't understand what they are working on. This is just taking up valuable development and review time.

Throwing mountains of code or an endless firehose of tiny patches over the wall to get your name into the kernel is not a success story.

— Christian Brauner

Comments (none posted)

CalyxOS is back

In August 2025, the CalyxOS privacy-focused Android distribution announced that it was pausing all releases while it reworked its release process, security protocols, and changed its signing keys following the departure of one of its founders. The project has now announced that it is "officially back from the hiatus" with the 7.2.2.0 release.

CalyxOS 7.2.2.0 is signed by us using a new HSM-based, open-source signing solution we designed to enhance the security of the entire signing process, ensure redundancy, and remove single points of failure. You can verify CalyxOS 7.2.2.0 and future builds following these instructions. For anyone who is interested, the security audit report of the HSM provisioning ceremony script can be found here.

In addition, we also went through significant infrastructure improvements. In particular, we have set up a cleaner server structure to streamline each release. In response to Google's less frequent AOSP source code releases, our team developed scripts to reduce the overhead in applying monthly patches and updates. Please keep in mind, additional manual steps are still needed to compensate for AOSP changes, such as requesting and storing kernel sources with each update. Currently, our lead engineer is continuing the maintenance of the base device trees for both LineageOS and CalyxOS to bridge the gap created by the absence of Google Pixel device trees.

Comments (none posted)

Fedora Council proposes pausing Community Initiatives

Aoife Moloney has, on behalf of the Fedora Council, posted an announcement that the Fedora Council is "proposing we pause the Community Initiatives process as an official project process" because it has decided the current process is ineffective. It is also closing discussion regarding the AI developer desktop initiative covered by LWN in May.

The Fedora Objectives/Initiatives framework was never intended as a mandatory prerequisite to do the work in Fedora. It supposed to help by focusing the community on a certain work when needed, not to decide what is allowed. The AI developer desktop initiative proposal highlighted that the Community Initiatives process has failed to serve as a good framework in Fedora where new ideas can surface, receive respectful feedback, and gain Council support for work that fits the project's present and/or future. This is something that the Council must address.

As a first step, we would like to halt the community initiative process immediately. Existing initiatives in flight (Fedora Forge, Atomic, and Fedora Docs 2026) will continue with full Council backing. Their underlying work will be completed as planned in their current timeboxed state, though the administrative framework around them may evolve. As a second step, we would like to work out a new mechanism to allow Council to set strategic direction in an open, transparent way that more intentionally includes the community voice. We recognise that we have to be better at being more open in our discussions and decision making.

The council is considering the "sandbox" proposal as an alternative or supplement to a process that replaces the Community Initiatives.

Comments (3 posted)

OpenMandriva: Statement regarding attempted distribution sabotage

Over on the OpenMandriva forum, the Linux distribution has reported sabotage of its repositories by a disgruntled contributor with administrative credentials. According to "AngryPenguin", an abusive incident in a distribution Matrix chat led to a user being kicked out of the chat; that "triggered a cascade of events", which led to people resigning from the distribution. Eventually, one of those people used their administrative privileges to delete part of the distribution's GitHub repository and to "publish an empty package in the cooker repository, which obsoleted all gnome and cosmic packages, which could have damaged the systems of people using gnome or cosmic".

We are currently working to restore the deleted repositories and restore the functionality of the obsolete packages.

[...] We performed a full system audit and, aside from the removed packages, we found no other violations.

Comments (3 posted)

Development quote of the week

Firmware's just software with a funny name and typically a harder to fix API

— Matthew Garrett

Comments (none posted)

CFP Deadlines: July 9, 2026 to September 7, 2026

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

Deadline	Event Dates	Event	Location
July 14	September 17 September 18	Git Merge	Lisbon, Portugal
July 15	July 15 July 22	BornHack 2026	Funen, Denmark
July 15	September 19 September 20	Nextcloud Community Conference 2026	Berlin, Germany
July 20	November 14 November 15	Capitole du Libre 2026	Toulouse, France
July 31	October 14 October 17	PyCon South Africa	Cape Town, South Africa
July 31	October 1 October 2	embedded Linux for Safe and Secure Applications	Göttingen, Germany
July 31	September 25 September 27	PostmarketOS and Alpine Linux Conference	Aachen, Germany
August 1	September 28 October 1	Alpine Linux Persistence and Storage Summit	Lizumerhütte, Tyrol, Austria
August 1	August 25 August 30	MiniDebConf and MiniDebCamp Winterthur 2026	Winterthur, Switzerland
August 11	October 6	Yocto Project Developer Day 2026	Prague, Czechia
August 31	October 2 October 4	GNU Tools Cauldron	Prague, Czechia
August 31	October 3 October 4	Linux Days 2026	Prague, Czechia

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

Events: July 9, 2026 to September 7, 2026

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

Date(s)	Event	Location
July 13 July 16	Netdev	Rome, Italy
July 13 July 19	DebCamp 26	Santa Fe, Argentina
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 14 August 16	Hackers on Planet Earth	New York, NY, US
August 25 August 30	MiniDebConf and MiniDebCamp Winterthur 2026	Winterthur, Switzerland
August 30 September 5	FOSS4G Hiroshima 2026	Hiroshima, Japan

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

Alert summary July 2, 2026 to July 8, 2026

Dist.	ID	Release	Package	Date
AlmaLinux	ALSA-2026:26455	9	389-ds-base	2026-07-02
AlmaLinux	ALSA-2026:24368	9	bind9.18	2026-07-02
AlmaLinux	ALSA-2026:33722	8	container-tools:rhel8	2026-07-03
AlmaLinux	ALSA-2026:35833	8	container-tools:rhel8	2026-07-07
AlmaLinux	ALSA-2026:27819	9	evince	2026-07-02
AlmaLinux	ALSA-2026:26206	9	fence-agents	2026-07-02
AlmaLinux	ALSA-2026:19358	9	freerdp	2026-07-02
AlmaLinux	ALSA-2026:24371	9	frr	2026-07-02
AlmaLinux	ALSA-2026:24370	9	frr10	2026-07-02
AlmaLinux	ALSA-2026:33503	8	giflib	2026-07-01
AlmaLinux	ALSA-2026:33501	9	giflib	2026-07-01
AlmaLinux	ALSA-2026:19362	9	gimp	2026-07-02
AlmaLinux	ALSA-2026:20612	9	gnutls	2026-07-02
AlmaLinux	ALSA-2026:35830	8	grafana	2026-07-06
AlmaLinux	ALSA-2026:35831	8	grafana-pcp	2026-07-06
AlmaLinux	ALSA-2026:26297	9	hplip	2026-07-02
AlmaLinux	ALSA-2026:20568	9	jmc	2026-07-02
AlmaLinux	ALSA-2026:33685	10	kernel	2026-07-02
AlmaLinux	ALSA-2026:34911	10	kernel	2026-07-06
AlmaLinux	ALSA-2026:33743	8	kernel	2026-07-01
AlmaLinux	ALSA-2026:33285	9	kernel	2026-07-01
AlmaLinux	ALSA-2026:36049	8	kernel-rt	2026-07-07
AlmaLinux	ALSA-2026:35839	8	libreoffice	2026-07-07
AlmaLinux	ALSA-2026:33464	8	mariadb:10.11	2026-07-01
AlmaLinux	ALSA-2026:33481	9	mariadb:11.8	2026-07-02
AlmaLinux	ALSA-2026:34355	10	mod_http2	2026-07-02
AlmaLinux	ALSA-2026:25052	9	mysql:8.4	2026-07-02
AlmaLinux	ALSA-2026:35842	10	nodejs22	2026-07-06
AlmaLinux	ALSA-2026:35841	10	nodejs24	2026-07-06
AlmaLinux	ALSA-2026:35892	9	nodejs:22	2026-07-07
AlmaLinux	ALSA-2026:35891	9	nodejs:24	2026-07-07
AlmaLinux	ALSA-2026:34357	10	opentelemetry-collector	2026-07-07
AlmaLinux	ALSA-2026:34359	9	opentelemetry-collector	2026-07-07
AlmaLinux	ALSA-2026:36188	8	perl-HTTP-Daemon	2026-07-07
AlmaLinux	ALSA-2026:33449	9	php	2026-07-01
AlmaLinux	ALSA-2026:34354	8	php:7.4	2026-07-02
AlmaLinux	ALSA-2026:22304	9	postgresql-jdbc	2026-07-02
AlmaLinux	ALSA-2026:28037	9	postgresql:15	2026-07-02
AlmaLinux	ALSA-2026:26203	9	postgresql:16	2026-07-02
AlmaLinux	ALSA-2026:19366	9	python-markdown	2026-07-07
AlmaLinux	ALSA-2026:34155	8	rrdtool	2026-07-01
AlmaLinux	ALSA-2026:34156	9	rrdtool	2026-07-01
AlmaLinux	ALSA-2026:33512	9	ruby	2026-07-01
AlmaLinux	ALSA-2026:33514	8	ruby:2.5	2026-07-03
AlmaLinux	ALSA-2026:33515	8	ruby:3.3	2026-07-03
AlmaLinux	ALSA-2026:33576	9	ruby:3.3	2026-07-01
AlmaLinux	ALSA-2026:33577	9	ruby:4.0	2026-07-01
AlmaLinux	ALSA-2026:25925	9	valkey	2026-07-02
AlmaLinux	ALSA-2026:26610	9	xorg-x11-server	2026-07-02
AlmaLinux	ALSA-2026:26590	9	xorg-x11-server-Xwayland	2026-07-02
Debian	DSA-6379-1	stable	bird3	2026-07-05
Debian	DLA-4672-1	LTS	chromium	2026-07-06
Debian	DSA-6378-1	stable	chromium	2026-07-05
Debian	DLA-4673-1	LTS	dpkg	2026-07-08
Debian	DSA-6375-1	stable	fastnetmon	2026-07-02
Debian	DSA-6383-1	stable	imagemagick	2026-07-07
Debian	DLA-4662-1	LTS	jq	2026-07-01
Debian	DLA-4661-1	LTS	jq	2026-07-01
Debian	DLA-4665-1	LTS	kernel	2026-07-03
Debian	DLA-4664-1	LTS	kernel	2026-07-03
Debian	DSA-6381-1	stable	kernel	2026-07-05
Debian	DLA-4671-1	LTS	linux-6.1	2026-07-05
Debian	DSA-6380-1	stable	mediawiki	2026-07-05
Debian	DLA-4667-1	LTS	nginx	2026-07-03
Debian	DLA-4663-1	LTS	node-lodash	2026-07-02
Debian	DLA-4653-2	LTS	openvpn	2026-07-06
Debian	DLA-4666-1	LTS	openvpn	2026-07-04
Debian	DSA-6376-1	stable	openvpn	2026-07-03
Debian	DLA-4670-1	LTS	php-phpseclib	2026-07-05
Debian	DLA-4669-1	LTS	php8.2	2026-07-04
Debian	DSA-6377-1	stable	php8.4	2026-07-04
Debian	DSA-6382-1	stable	postfix	2026-07-07
Debian	DLA-4668-1	LTS	sympa	2026-07-04
Fedora	FEDORA-2026-7eaa63bea6	F43	7zip	2026-07-04
Fedora	FEDORA-2026-948b74882b	F44	7zip	2026-07-03
Fedora	FEDORA-2026-f8ab642466	F43	apptainer	2026-07-03
Fedora	FEDORA-2026-ca1825e29e	F44	apptainer	2026-07-03
Fedora	FEDORA-2026-97d351d54e	F43	betterleaks	2026-07-08
Fedora	FEDORA-2026-6f573784e6	F44	betterleaks	2026-07-08
Fedora	FEDORA-2026-be3238ba3e	F43	buildah	2026-07-04
Fedora	FEDORA-2026-3dc324bd9a	F43	caddy	2026-07-02
Fedora	FEDORA-2026-950cac64f2	F44	caddy	2026-07-02
Fedora	FEDORA-2026-88eee44bfb	F43	chromium	2026-07-05
Fedora	FEDORA-2026-94bb57e96c	F44	chromium	2026-07-05
Fedora	FEDORA-2026-144f87ee92	F43	clamav	2026-07-07
Fedora	FEDORA-2026-69c55ea36c	F44	clamav	2026-07-05
Fedora	FEDORA-2026-1d4bd0354a	F43	cpp-httplib	2026-07-03
Fedora	FEDORA-2026-1b15ac058b	F44	cpp-httplib	2026-07-03
Fedora	FEDORA-2026-5584d573ed	F44	docker-compose	2026-07-08
Fedora	FEDORA-2026-410580270b	F43	firefox	2026-07-08
Fedora	FEDORA-2026-78a12ffec8	F43	freerdp	2026-07-04
Fedora	FEDORA-2026-5b642da12e	F44	helm	2026-07-08
Fedora	FEDORA-2026-7d23917d90	F43	hplip	2026-07-07
Fedora	FEDORA-2026-d9b508b972	F44	hplip	2026-07-06
Fedora	FEDORA-2026-32113d4817	F43	hut	2026-07-02
Fedora	FEDORA-2026-ed208f5337	F44	hut	2026-07-02
Fedora	FEDORA-2026-00901a5e8f	F44	ipp-usb	2026-07-02
Fedora	FEDORA-2026-35e2185559	F43	kernel	2026-07-02
Fedora	FEDORA-2026-c3e2e91b4d	F43	kernel	2026-07-07
Fedora	FEDORA-2026-7ae597d1d2	F44	kernel	2026-07-02
Fedora	FEDORA-2026-75653cf1c2	F44	kernel	2026-07-07
Fedora	FEDORA-2026-c3e2e91b4d	F43	kernel-headers	2026-07-07
Fedora	FEDORA-2026-75653cf1c2	F44	kernel-headers	2026-07-07
Fedora	FEDORA-2026-a72f110dcd	F44	leptonica	2026-07-04
Fedora	FEDORA-2026-436ef78874	F43	librabbitmq	2026-07-07
Fedora	FEDORA-2026-0b7d84b1d6	F44	mariadb10.11	2026-07-05
Fedora	FEDORA-2026-c39d84e105	F43	mariadb11.8	2026-07-05
Fedora	FEDORA-2026-6666907a26	F43	mingw-expat	2026-07-06
Fedora	FEDORA-2026-3cb1034453	F44	mingw-expat	2026-07-06
Fedora	FEDORA-2026-b25dca4806	F44	mir	2026-07-06
Fedora	FEDORA-2026-280245e2ea	F43	mysql8.4	2026-07-03
Fedora	FEDORA-2026-8c7f5e32c5	F44	mysql8.4	2026-07-03
Fedora	FEDORA-2026-5afe6630dc	F43	nextcloud	2026-07-05
Fedora	FEDORA-2026-ee50c21f92	F44	nextcloud	2026-07-05
Fedora	FEDORA-2026-3b30fa1da4	F44	nmap	2026-07-03
Fedora	FEDORA-2026-2843bb1cc8	F43	nsd	2026-07-05
Fedora	FEDORA-2026-dd3a7926a3	F44	nsd	2026-07-05
Fedora	FEDORA-2026-a72f110dcd	F44	openqa	2026-07-04
Fedora	FEDORA-2026-89f19dcfa6	F43	openvpn	2026-07-04
Fedora	FEDORA-2026-117dbc031b	F44	openvpn	2026-07-04
Fedora	FEDORA-2026-12d4cde449	F43	opkssh	2026-07-02
Fedora	FEDORA-2026-7794729685	F44	opkssh	2026-07-02
Fedora	FEDORA-2026-a72f110dcd	F44	os-autoinst	2026-07-04
Fedora	FEDORA-2026-5ce1370aca	F43	pdns	2026-07-04
Fedora	FEDORA-2026-f6ac0db764	F44	pdns	2026-07-04
Fedora	FEDORA-2026-34cca3d390	F43	pdns-recursor	2026-07-04
Fedora	FEDORA-2026-088b60c071	F44	pdns-recursor	2026-07-04
Fedora	FEDORA-2026-fb1f15ce04	F43	perl-Compress-Raw-Bzip2	2026-07-08
Fedora	FEDORA-2026-b244acadbe	F44	perl-Crypt-ScryptKDF	2026-07-05
Fedora	FEDORA-2026-fb1f15ce04	F43	perl-IO-Compress	2026-07-08
Fedora	FEDORA-2026-ab8bc1220a	F43	perl-Imager	2026-07-07
Fedora	FEDORA-2026-adbe03cd7a	F44	perl-Imager	2026-07-07
Fedora	FEDORA-2026-629b796808	F43	perl-JavaScript-Minifier-XS	2026-07-08
Fedora	FEDORA-2026-634b594205	F44	perl-JavaScript-Minifier-XS	2026-07-08
Fedora	FEDORA-2026-be3238ba3e	F43	podman	2026-07-04
Fedora	FEDORA-2026-1842aaea5d	F43	podman-tui	2026-07-07
Fedora	FEDORA-2026-d5c6299162	F44	podman-tui	2026-07-07
Fedora	FEDORA-2026-a96d4ee174	F43	prometheus-podman-exporter	2026-07-07
Fedora	FEDORA-2026-f366154bec	F44	prometheus-podman-exporter	2026-07-07
Fedora	FEDORA-2026-07ef57edc0	F43	python-cramjam	2026-07-08
Fedora	FEDORA-2026-ed6d2b806a	F44	python-cramjam	2026-07-08
Fedora	FEDORA-2026-0f558e63db	F43	python-fastar	2026-07-08
Fedora	FEDORA-2026-b1bcd1a48c	F44	python-fastar	2026-07-08
Fedora	FEDORA-2026-275d2ecbbd	F43	python-jupyter-server	2026-07-05
Fedora	FEDORA-2026-dd1d19e58b	F44	python-jupyter-server	2026-07-05
Fedora	FEDORA-2026-75b3256794	F43	python-pillow-jxl-plugin	2026-07-08
Fedora	FEDORA-2026-8c2e409ea5	F44	python-pillow-jxl-plugin	2026-07-08
Fedora	FEDORA-2026-8a19b048cc	F43	python-rignore	2026-07-08
Fedora	FEDORA-2026-b77adbb5ea	F44	python-rignore	2026-07-08
Fedora	FEDORA-2026-93da8dcc2c	F44	python-rpds-py	2026-07-06
Fedora	FEDORA-2026-4d6aae2d33	F43	python-streamlink	2026-07-05
Fedora	FEDORA-2026-b9232006bb	F44	python-streamlink	2026-07-05
Fedora	FEDORA-2026-e1d1b349cd	F43	rclone	2026-07-02
Fedora	FEDORA-2026-6145ae14ca	F44	rclone	2026-07-02
Fedora	FEDORA-2026-b25dca4806	F44	rust-ashpd	2026-07-06
Fedora	FEDORA-2026-ffaebbf2f0	F43	rust-busd	2026-07-06
Fedora	FEDORA-2026-b25dca4806	F44	rust-busd	2026-07-06
Fedora	FEDORA-2026-b25dca4806	F44	rust-gtk4-macros	2026-07-06
Fedora	FEDORA-2026-ffaebbf2f0	F43	rust-inferno	2026-07-06
Fedora	FEDORA-2026-b25dca4806	F44	rust-inferno	2026-07-06
Fedora	FEDORA-2026-ffaebbf2f0	F43	rust-quick-xml	2026-07-06
Fedora	FEDORA-2026-b25dca4806	F44	rust-quick-xml	2026-07-06
Fedora	FEDORA-2026-ffaebbf2f0	F43	rust-reqsign-aws-v4	2026-07-06
Fedora	FEDORA-2026-b25dca4806	F44	rust-reqsign-aws-v4	2026-07-06
Fedora	FEDORA-2026-ffaebbf2f0	F43	rust-wayland-scanner	2026-07-06
Fedora	FEDORA-2026-b25dca4806	F44	rust-wayland-scanner	2026-07-06
Fedora	FEDORA-2026-ffaebbf2f0	F43	sandogasa	2026-07-06
Fedora	FEDORA-2026-b25dca4806	F44	sandogasa	2026-07-06
Fedora	FEDORA-2026-2fb5ca48a2	F43	thunderbird	2026-07-02
Fedora	FEDORA-2026-aa3e7e6d5b	F43	tor	2026-07-08
Fedora	FEDORA-2026-309b0bc463	F44	tor	2026-07-08
Fedora	FEDORA-2026-0ed2011b62	F43	transmission	2026-07-02
Fedora	FEDORA-2026-0c067e5040	F44	transmission	2026-07-02
Mageia	MGASA-2026-0235	10	mariadb	2026-07-05
Mageia	MGASA-2026-0234	10, 9	yt-dlp	2026-07-04
Oracle	ELSA-2026-33722	OL8	container-tools:rhel8	2026-07-06
Oracle	ELSA-2026-20546	OL7	freerdp	2026-07-02
Oracle	ELSA-2026-33503	OL8	giflib	2026-07-02
Oracle	ELSA-2026-33501	OL9	giflib	2026-07-02
Oracle	ELSA-2026-19566	OL7	glib2	2026-07-02
Oracle	ELSA-2026-33226	OL9	glibc	2026-07-02
Oracle	ELSA-2026-35828	OL9	grafana	2026-07-07
Oracle	ELSA-2026-35831	OL8	grafana-pcp	2026-07-07
Oracle	ELSA-2026-35829	OL9	grafana-pcp	2026-07-07
Oracle	ELSA-2026-50374	OL7	kernel	2026-07-06
Oracle	ELSA-2026-50374	OL8	kernel	2026-07-07
Oracle	ELSA-2026-50373	OL8	kernel	2026-07-06
Oracle	ELSA-2026-50374	OL8	kernel	2026-07-06
Oracle	ELSA-2026-18587	OL9	kernel	2026-07-02
Oracle	ELSA-2026-19568	OL9	kernel	2026-07-02
Oracle	ELSA-2026-21556	OL9	kernel	2026-07-02
Oracle	ELSA-2026-50373	OL9	kernel	2026-07-06
Oracle	ELSA-2026-50372	OL9	kernel	2026-07-06
Oracle	ELSA-2026-50373	OL9	kernel	2026-07-06
Oracle	ELSA-2026-28290	OL9	libreoffice	2026-07-02
Oracle	ELSA-2026-18748	OL9	libvirt	2026-07-02
Oracle	ELSA-2026-33464	OL8	mariadb:10.11	2026-07-02
Oracle	ELSA-2026-33482	OL9	mariadb:10.11	2026-07-06
Oracle	ELSA-2026-33481	OL9	mariadb:11.8	2026-07-06
Oracle	ELSA-2026-28973	OL9	nginx	2026-07-06
Oracle	ELSA-2026-30851	OL8	perl:5.32	2026-07-06
Oracle	ELSA-2026-33449	OL9	php	2026-07-06
Oracle	ELSA-2026-34354	OL8	php:7.4	2026-07-06
Oracle	ELSA-2026-27741	OL9	postgresql	2026-07-02
Oracle	ELSA-2026-18957	OL9	python3.11	2026-07-02
Oracle	ELSA-2026-18958	OL9	python3.12	2026-07-02
Oracle	ELSA-2026-34155	OL8	rrdtool	2026-07-06
Oracle	ELSA-2026-34156	OL9	rrdtool	2026-07-02
Oracle	ELSA-2026-33514	OL8	ruby:2.5	2026-07-06
Oracle	ELSA-2026-33515	OL8	ruby:3.3	2026-07-07
Oracle	ELSA-2026-33576	OL9	ruby:3.3	2026-07-06
Oracle	ELSA-2026-20596	OL9	ruby:4.0	2026-07-06
Oracle	ELSA-2026-33577	OL9	ruby:4.0	2026-07-07
Oracle	ELSA-2026-33445	OL8	thunderbird	2026-07-02
Oracle	ELSA-2026-50372		uek-kernel	2026-07-06
Red Hat	RHSA-2026:34192-01	EL9.4	buildah	2026-07-03
Red Hat	RHSA-2026:27731-01	EL10.0	kernel	2026-07-07
Red Hat	RHSA-2026:36018-01	EL9	kernel	2026-07-07
Red Hat	RHSA-2026:27735-01	EL9.4	kernel	2026-07-07
Red Hat	RHSA-2026:27708-01	EL9.6	kernel	2026-07-07
Red Hat	RHSA-2026:34357-01	EL10	opentelemetry-collector	2026-07-07
Red Hat	RHSA-2026:34359-01	EL9	opentelemetry-collector	2026-07-07
Red Hat	RHSA-2026:34196-01	EL9.4	podman	2026-07-03
Red Hat	RHSA-2026:9031-01	EL7	python-urllib3	2026-07-07
Red Hat	RHSA-2026:34197-01	EL9.4	skopeo	2026-07-03
Slackware	SSA:2026-187-01		c-ares	2026-07-06
Slackware	SSA:2026-182-01		libevent	2026-07-04
Slackware	SSA:2026-183-01		libseccomp	2026-07-04
Slackware	SSA:2026-182-02		mozilla	2026-07-04
Slackware	SSA:2026-186-01		mutt	2026-07-05
Slackware	SSA:2026-187-02		openssh	2026-07-06
Slackware	SSA:2026-186-02		php82	2026-07-05
Slackware	SSA:2026-188-01		tftp	2026-07-07
SUSE	SUSE-SU-2026:22333-1	SLE16.0	389-ds	2026-07-01
SUSE	SUSE-SU-2026:22347-1	SLE16.0	7zip	2026-07-01
SUSE	SUSE-SU-2026:22378-1	SLE16.0	ImageMagick	2026-07-01
SUSE	openSUSE-SU-2026:11165-1	TW	alloy	2026-07-02
SUSE	SUSE-SU-2026:22381-1	SLE16.0	alsa	2026-07-01
SUSE	SUSE-SU-2026:22320-1	SLE16.0	amazon-ecs-init	2026-07-01
SUSE	SUSE-SU-2026:2759-1	SLE15	apache2	2026-07-06
SUSE	SUSE-SU-2026:2735-1	SLE15 oS15.6	apache2	2026-07-03
SUSE	SUSE-SU-2026:22338-1	SLE16.0	avahi	2026-07-01
SUSE	SUSE-SU-2026:2779-1	SLE15 oS15.3	bind	2026-07-06
SUSE	SUSE-SU-2026:2733-1	SLE15 oS15.5	buildah	2026-07-03
SUSE	openSUSE-SU-2026:11166-1	TW	c3p0	2026-07-02
SUSE	openSUSE-SU-2026:0224-1	osB15	cadvisor	2026-07-01
SUSE	openSUSE-SU-2026:11184-1	TW	chromedriver	2026-07-06
SUSE	SUSE-SU-2026:22424-1	SLE-m6.0	containerd	2026-07-03
SUSE	SUSE-SU-2026:22443-1	SLE-m6.1	containerd	2026-07-03
SUSE	SUSE-SU-2026:22344-1	SLE16.0	cosign	2026-07-01
SUSE	SUSE-SU-2026:22395-1	SLE-m6.0	crun	2026-07-03
SUSE	SUSE-SU-2026:2777-1	SLE15	cryptsetup, s390-tools	2026-07-06
SUSE	SUSE-SU-2026:2718-1	SLE12	cups	2026-07-01
SUSE	SUSE-SU-2026:2732-1	SLE15 SLE5.2 SLE5.3 SLE5.4 SLE5.5 SLE-m5.2 SLE-m5.3 SLE-m5.4 SLE-m5.5	cups	2026-07-03
SUSE	openSUSE-SU-2026:21220-1	oS16.0	dhcpcd	2026-07-03
SUSE	SUSE-SU-2026:22319-1	SLE16.0	dnsdist	2026-07-01
SUSE	SUSE-SU-2026:22454-1	SLE-m6.1	dnsmasq	2026-07-03
SUSE	SUSE-SU-2026:22496-1	SLE16.0	dnsmasq	2026-07-06
SUSE	openSUSE-SU-2026:21192-1	oS16.0	dnsmasq	2026-07-03
SUSE	SUSE-SU-2026:22456-1	SLE-m6.1	docker	2026-07-03
SUSE	SUSE-SU-2026:22367-1	SLE16.0	docker	2026-07-01
SUSE	openSUSE-SU-2026:21205-1	oS16.0	docker-stable	2026-07-03
SUSE	SUSE-SU-2026:22431-1	SLE-m6.0	dracut	2026-07-03
SUSE	SUSE-SU-2026:22446-1	SLE-m6.1	dracut	2026-07-03
SUSE	SUSE-SU-2026:2720-1	SLE15 SLE5.3 SLE5.4 SLE-m5.3 SLE-m5.4 oS15.4	dracut	2026-07-01
SUSE	SUSE-SU-2026:2721-1	SLE15 SLE5.5 SLE-m5.5 oS15.5	dracut	2026-07-01
SUSE	SUSE-SU-2026:22358-1	SLE16.0	dracut	2026-07-01
SUSE	SUSE-SU-2026:2731-1	SLE15 oS15.6	editorconfig-core-c	2026-07-03
SUSE	openSUSE-SU-2026:21211-1	oS16.0	ffmpeg-7	2026-07-03
SUSE	SUSE-SU-2026:22351-1	SLE16.0	firefox	2026-07-01
SUSE	SUSE-SU-2026:22343-1	SLE16.0	firewalld	2026-07-01
SUSE	SUSE-SU-2026:2745-1	SLE15 oS15.6	firewalld-legacy	2026-07-03
SUSE	SUSE-SU-2026:2739-1	SLE15	fontforge	2026-07-03
SUSE	openSUSE-SU-2026:11185-1	TW	gi-docgen	2026-07-07
SUSE	SUSE-SU-2026:22382-1	SLE16.0	giflib	2026-07-01
SUSE	SUSE-SU-2026:2756-1	SLE15 oS15.4	gimp	2026-07-06
SUSE	SUSE-SU-2026:22297-1	SLE16.0	glib-networking	2026-07-01
SUSE	SUSE-SU-2026:22523-1	SLE-m6.0	glibc	2026-07-08
SUSE	SUSE-SU-2026:22453-1	SLE-m6.1	glibc	2026-07-03
SUSE	openSUSE-SU-2026:21228-1	oS16.0	glibc	2026-07-04
SUSE	SUSE-SU-2026:22302-1	SLE16.0	glycin-loaders	2026-07-01
SUSE	SUSE-SU-2026:2740-1	SLE5.3 SLE5.4 SLE-m5.3 SLE-m5.4	golang-github-docker-libnetwork	2026-07-03
SUSE	SUSE-SU-2026:22328-1	SLE16.0	google-cloud-sap-agent	2026-07-01
SUSE	SUSE-SU-2026:22423-1	SLE-m6.0	google-guest-agent	2026-07-03
SUSE	SUSE-SU-2026:22442-1	SLE-m6.1	google-guest-agent	2026-07-03
SUSE	SUSE-SU-2026:22376-1	SLE16.0	google-guest-agent	2026-07-01
SUSE	openSUSE-SU-2026:21210-1	oS16.0	google-osconfig-agent	2026-07-03
SUSE	openSUSE-SU-2026:21207-1	oS16.0	graphicsmagick	2026-07-03
SUSE	SUSE-SU-2026:22313-1	SLE16.0	gsasl	2026-07-01
SUSE	SUSE-SU-2026:2743-1	SLE15 oS15.5	gstreamer-plugins-bad	2026-07-03
SUSE	SUSE-SU-2026:2744-1	SLE15 oS15.6	gstreamer-plugins-bad	2026-07-03
SUSE	openSUSE-SU-2026:21204-1	oS16.0	gstreamer-plugins-bad	2026-07-03
SUSE	SUSE-SU-2026:2727-1	SLE12	gstreamer-plugins-good	2026-07-02
SUSE	openSUSE-SU-2026:11154-1	TW	hauler	2026-07-01
SUSE	SUSE-SU-2026:22432-1	SLE-m6.0	helm	2026-07-03
SUSE	SUSE-SU-2026:22455-1	SLE-m6.1	helm	2026-07-03
SUSE	SUSE-SU-2026:22305-1	SLE16.0	helm	2026-07-01
SUSE	openSUSE-SU-2026:11186-1	TW	helm	2026-07-07
SUSE	openSUSE-SU-2026:11187-1	TW	helm3	2026-07-07
SUSE	SUSE-SU-2026:22504-1	SLE16.0	jackson-annotations, jackson-core, jackson-databind	2026-07-06
SUSE	openSUSE-SU-2026:21201-1	oS16.0	jackson-annotations, jackson-core, jackson-databind	2026-07-03
SUSE	openSUSE-SU-2026:21221-1	oS16.0	jline3	2026-07-03
SUSE	openSUSE-SU-2026:11188-1	TW	json-c-devel	2026-07-07
SUSE	SUSE-SU-2026:2722-1	SLE15	kernel	2026-07-01
SUSE	SUSE-SU-2026:22394-1	SLE6.0 SLE-m6.0	kernel	2026-07-03
SUSE	SUSE-SU-2026:22393-1	SLE6.0 SLE-m6.0	kernel	2026-07-03
SUSE	SUSE-SU-2026:22436-1	SLE6.0 SLE-m6.0	kernel	2026-07-03
SUSE	SUSE-SU-2026:22433-1	SLE6.0 SLE-m6.0	kernel	2026-07-03
SUSE	SUSE-SU-2026:22440-1	SLE6.0 SLE-m6.0 SLE-m6.1	kernel	2026-07-03
SUSE	SUSE-SU-2026:22460-1	SLE6.0 SLE-m6.0 SLE-m6.1	kernel	2026-07-03
SUSE	SUSE-SU-2026:22458-1	SLE6.0 SLE-m6.0 SLE-m6.1	kernel	2026-07-03
SUSE	openSUSE-SU-2026:11175-1	TW	kernel-devel	2026-07-03
SUSE	openSUSE-SU-2026:21230-1	oS16.0	keybase-client	2026-07-04
SUSE	SUSE-SU-2026:22326-1	SLE16.0	keylime	2026-07-01
SUSE	openSUSE-SU-2026:11176-1	TW	kitty	2026-07-03
SUSE	SUSE-SU-2026:22450-1	SLE-m6.1	krb5	2026-07-03
SUSE	SUSE-SU-2026:22322-1	SLE16.0	krb5	2026-07-01
SUSE	openSUSE-SU-2026:11177-1	TW	krb5	2026-07-03
SUSE	openSUSE-SU-2026:11167-1	TW	kubectl-cnpg	2026-07-02
SUSE	SUSE-SU-2026:2783-1	SLE15	kubevirt-1.6	2026-07-08
SUSE	SUSE-SU-2026:22506-1	SLE16.0	lcms2	2026-07-06
SUSE	openSUSE-SU-2026:21202-1	oS16.0	lcms2	2026-07-03
SUSE	SUSE-SU-2026:22369-1	SLE16.0	libaom	2026-07-01
SUSE	SUSE-SU-2026:2747-1	SLE12	libarchive	2026-07-03
SUSE	SUSE-SU-2026:22324-1	SLE16.0	libexif	2026-07-01
SUSE	SUSE-SU-2026:22355-1	SLE16.0	libgcrypt	2026-07-01
SUSE	SUSE-SU-2026:22447-1	SLE-m6.1	libnfs	2026-07-03
SUSE	SUSE-SU-2026:2760-1	SLE15	libnfs	2026-07-06
SUSE	SUSE-SU-2026:22363-1	SLE16.0	libnfs	2026-07-01
SUSE	openSUSE-SU-2026:11193-1	TW	librpmbuild10	2026-07-07
SUSE	SUSE-SU-2026:22452-1	SLE-m6.1	libslirp	2026-07-03
SUSE	openSUSE-SU-2026:21216-1	oS16.0	libslirp	2026-07-03
SUSE	SUSE-SU-2026:22438-1	SLE-m6.0	libssh2_org	2026-07-03
SUSE	SUSE-SU-2026:22364-1	SLE16.0	libssh2_org	2026-07-01
SUSE	openSUSE-SU-2026:11163-1	TW	libxreaderdocument3	2026-07-02
SUSE	SUSE-SU-2026:22380-1	SLE16.0	loupe	2026-07-01
SUSE	openSUSE-SU-2026:21179-1	oS16.0	lrzip	2026-07-01
SUSE	SUSE-SU-2026:22340-1	SLE16.0	mutt	2026-07-01
SUSE	SUSE-SU-2026:22294-1	SLE16.0	ncurses	2026-07-01
SUSE	openSUSE-SU-2026:0228-1	osB15	nilfs-utils	2026-07-03
SUSE	SUSE-SU-2026:22368-1	SLE16.0	nodejs22	2026-07-01
SUSE	SUSE-SU-2026:2757-1	SLE15	openCryptoki	2026-07-06
SUSE	SUSE-SU-2026:22365-1	SLE16.0	openCryptoki	2026-07-01
SUSE	openSUSE-SU-2026:11178-1	TW	openQA	2026-07-03
SUSE	openSUSE-SU-2026:21190-1	oS16.0	openbabel	2026-07-02
SUSE	SUSE-SU-2026:22352-1	SLE16.0	openssh	2026-07-01
SUSE	SUSE-SU-2026:22437-1	SLE-m6.0	openssl-3	2026-07-03
SUSE	SUSE-SU-2026:22449-1	SLE-m6.1	openssl-3	2026-07-03
SUSE	SUSE-SU-2026:22315-1	SLE16.0	openssl-3	2026-07-01
SUSE	SUSE-SU-2026:2742-1	MP4.3 SLE15 oS15.4	pacemaker	2026-07-03
SUSE	SUSE-SU-2026:2719-1	SLE15	pacemaker	2026-07-01
SUSE	SUSE-SU-2026:22493-1	SLE15 SLE16.0 SLE-m6.1 SLE-m6.2	pacemaker	2026-07-06
SUSE	SUSE-SU-2026:22510-1	SLE16.0	pacemaker	2026-07-06
SUSE	openSUSE-SU-2026:21196-1	oS16.0	pacemaker	2026-07-03
SUSE	SUSE-SU-2026:22459-1	SLE-m6.1	pcr-oracle	2026-07-03
SUSE	openSUSE-SU-2026:11168-1	TW	perl-CGI-Session	2026-07-02
SUSE	openSUSE-SU-2026:11157-1	TW	perl-CSS-Minifier-XS	2026-07-01
SUSE	SUSE-SU-2026:22329-1	SLE16.0	perl-Config-IniFiles	2026-07-01
SUSE	SUSE-SU-2026:2782-1	SLE15	perl-Cpanel-JSON-XS	2026-07-07
SUSE	openSUSE-SU-2026:0230-1	osB15	perl-Crypt-SaltedHash	2026-07-07
SUSE	SUSE-SU-2026:2748-1	SLE12	perl-DBI	2026-07-03
SUSE	SUSE-SU-2026:2750-1	SLE15	perl-DBI	2026-07-03
SUSE	SUSE-SU-2026:2749-1	SLE15 oS15.6	perl-DBI	2026-07-03
SUSE	SUSE-SU-2026:22330-1	SLE16.0	perl-DBI	2026-07-01
SUSE	openSUSE-SU-2026:11158-1	TW	perl-JavaScript-Minifier-XS	2026-07-01
SUSE	openSUSE-SU-2026:11179-1	TW	perl-List-SomeUtils-XS	2026-07-03
SUSE	SUSE-SU-2026:22353-1	SLE16.0	perl-libwww-perl	2026-07-01
SUSE	openSUSE-SU-2026:21218-1	oS16.0	perl-list-someutils-xs	2026-07-03
SUSE	SUSE-SU-2026:22451-1	SLE-m6.1	podman	2026-07-03
SUSE	SUSE-SU-2026:2780-1	SLE12	postfix	2026-07-06
SUSE	SUSE-SU-2026:2781-1	SLE15 oS15.6	postfix	2026-07-06
SUSE	SUSE-SU-2026:22335-1	SLE16.0	postfix	2026-07-01
SUSE	SUSE-SU-2026:22370-1	SLE16.0	python-Markdown, python-joblib, python-handy-archives, python-apache-libcloud, python-WebOb, python-PyGithub, python-soupsieve	2026-07-01
SUSE	SUSE-SU-2026:22321-1	SLE16.0	python-click	2026-07-01
SUSE	SUSE-SU-2026:22356-1	SLE16.0	python-idna	2026-07-01
SUSE	SUSE-SU-2026:2728-1	SLE12	python-lxml	2026-07-03
SUSE	SUSE-SU-2026:2729-1	SLE15 oS15.4	python-lxml	2026-07-03
SUSE	SUSE-SU-2026:22495-1	SLE16.0	python-mistune	2026-07-06
SUSE	SUSE-SU-2026:2758-1	SLE12	python-pip	2026-07-06
SUSE	SUSE-SU-2026:22300-1	SLE16.0	python-pip	2026-07-01
SUSE	openSUSE-SU-2026:21231-1	oS16.0	python-pydata-sphinx-theme	2026-07-04
SUSE	openSUSE-SU-2026:21176-1	oS16.0	python-pytest-html	2026-07-01
SUSE	SUSE-SU-2026:2724-1	SLE15 oS15.4	python-python-dotenv	2026-07-02
SUSE	SUSE-SU-2026:22372-1	SLE16.0	python-python-multipart	2026-07-01
SUSE	SUSE-SU-2026:22360-1	SLE16.0	python-starlette	2026-07-01
SUSE	SUSE-SU-2026:2726-1	SLE15 SLE5.3 SLE5.4 SLE5.5 SLE-m5.3 SLE-m5.4 SLE-m5.5	python-tornado	2026-07-02
SUSE	SUSE-SU-2026:22430-1	SLE-m6.0	python-tornado6	2026-07-03
SUSE	SUSE-SU-2026:22445-1	SLE-m6.1	python-tornado6	2026-07-03
SUSE	SUSE-SU-2026:2725-1	SLE15 oS15.4	python-tornado6	2026-07-02
SUSE	SUSE-SU-2026:22373-1	SLE16.0	python-tornado6	2026-07-01
SUSE	openSUSE-SU-2026:21175-1	oS16.0	python-zeroconf	2026-07-01
SUSE	SUSE-SU-2026:2752-1	SLE12	python3-lxml	2026-07-06
SUSE	SUSE-SU-2026:2754-1	SLE15 SLE5.5 SLE-m5.5 oS15.5	python3-lxml	2026-07-06
SUSE	openSUSE-SU-2026:11169-1	TW	python3-onionshare	2026-07-02
SUSE	SUSE-SU-2026:2723-1	MP4.3 SLE15 oS15.4	python311	2026-07-02
SUSE	openSUSE-SU-2026:11159-1	TW	python311-jupyter-server	2026-07-01
SUSE	openSUSE-SU-2026:11180-1	TW	python311-mistune	2026-07-03
SUSE	openSUSE-SU-2026:11170-1	TW	python311-python-engineio	2026-07-02
SUSE	openSUSE-SU-2026:11190-1	TW	python313-dulwich	2026-07-07
SUSE	openSUSE-SU-2026:11183-1	TW	python313-joserfc	2026-07-05
SUSE	openSUSE-SU-2026:11191-1	TW	python313-lxml_html_clean	2026-07-07
SUSE	openSUSE-SU-2026:11192-1	TW	python313-openapi-spec-validator	2026-07-07
SUSE	openSUSE-SU-2026:21225-1	oS16.0	rmt-server	2026-07-04
SUSE	SUSE-SU-2026:22331-1	SLE16.0	rpcbind	2026-07-01
SUSE	openSUSE-SU-2026:11194-1	TW	sdbootutil	2026-07-07
SUSE	SUSE-SU-2026:22325-1	SLE16.0	sed	2026-07-01
SUSE	SUSE-SU-2026:22429-1	SLE-m6.0	sg3_utils	2026-07-03
SUSE	SUSE-SU-2026:22441-1	SLE-m6.1	sg3_utils	2026-07-03
SUSE	SUSE-SU-2026:22349-1	SLE16.0	sg3_utils	2026-07-01
SUSE	openSUSE-SU-2026:21222-1	oS16.0	systemd	2026-07-04
SUSE	SUSE-SU-2026:22377-1	SLE16.0	tar	2026-07-01
SUSE	openSUSE-SU-2026:11164-1	TW	thunderbird	2026-07-02
SUSE	SUSE-SU-2026:22306-1	SLE16.0	tiff	2026-07-01
SUSE	SUSE-SU-2026:2751-1	oS15.4	tracker-miners	2026-07-03
SUSE	openSUSE-SU-2026:21189-1	oS16.0	transmission	2026-07-02
SUSE	openSUSE-SU-2026:11162-1	TW	trivy	2026-07-02
SUSE	SUSE-SU-2026:22332-1	SLE16.0	util-linux	2026-07-01
SUSE	SUSE-SU-2026:2755-1	SLE15 oS15.6	xdg-dbus-proxy	2026-07-06
Ubuntu	USN-8496-1	22.04 24.04 25.10 26.04	cifs-utils	2026-07-02
Ubuntu	USN-8496-2	22.04 24.04 25.10 26.04	cifs-utils	2026-07-03
Ubuntu	USN-8502-1	16.04 18.04 20.04	gnutls28	2026-07-06
Ubuntu	USN-8512-1	22.04 24.04 26.04	gzip	2026-07-06
Ubuntu	USN-8501-1	14.04	kernel	2026-07-02
Ubuntu	USN-8490-1	25.10	kernel	2026-07-01
Ubuntu	USN-8488-1	26.04	kernel	2026-07-01
Ubuntu	USN-8494-1	22.04 24.04 25.10 26.04	libvncserver	2026-07-02
Ubuntu	USN-8493-1	20.04 22.04	linux, linux-aws, linux-aws-5.15, linux-aws-fips, linux-azure, linux-azure-5.15, linux-azure-fde-5.15, linux-fips, linux-gcp, linux-gcp-fips, linux-gke, linux-gkeop, linux-hwe-5.15, linux-ibm, linux-ibm-5.15, linux-intel-iot-realtime, linux-intel-iotg, linux-kvm, linux-lowlatency, linux-lowlatency-hwe-5.15, linux-nvidia, linux-nvidia-tegra, linux-nvidia-tegra-5.15, linux-nvidia-tegra-igx, linux-oracle, linux-realtime	2026-07-01
Ubuntu	USN-8492-1	22.04 24.04	linux, linux-aws, linux-aws-fips, linux-gcp, linux-gcp-fips, linux-ibm, linux-nvidia, linux-nvidia-6.8, linux-oracle, linux-realtime, linux-realtime-6.8	2026-07-01
Ubuntu	USN-8492-2	22.04 24.04	linux-aws-6.8, linux-gcp-6.8, linux-gke, linux-gkeop, linux-ibm-6.8, linux-nvidia-lowlatency, linux-oracle-6.8	2026-07-02
Ubuntu	USN-8497-1	22.04 24.04	linux-lowlatency, linux-lowlatency-hwe-6.8	2026-07-02
Ubuntu	USN-8507-1	26.04	linux-nvidia	2026-07-06
Ubuntu	USN-8508-1	24.04	linux-nvidia-6.17	2026-07-06
Ubuntu	USN-8498-1	24.04	linux-nvidia-tegra	2026-07-02
Ubuntu	USN-8491-1	24.04	linux-oem-6.17	2026-07-01
Ubuntu	USN-8489-1	26.04	linux-oem-7.0	2026-07-01
Ubuntu	USN-8493-2	20.04	linux-oracle-5.15	2026-07-02
Ubuntu	USN-8488-2	26.04	linux-raspi	2026-07-02
Ubuntu	USN-8492-3	24.04	linux-raspi-realtime	2026-07-06
Ubuntu	USN-8499-1	24.04	linux-xilinx	2026-07-02
Ubuntu	USN-8503-1	14.04 16.04 18.04 20.04	ncurses	2026-07-06
Ubuntu	USN-8495-1	22.04 24.04 25.10 26.04	nghttp2	2026-07-02
Ubuntu	USN-8398-4	14.04 16.04 18.04 20.04	nginx	2026-07-02
Ubuntu	USN-8514-1	16.04	openssh	2026-07-06
Ubuntu	USN-8467-2	25.10	perl	2026-07-03
Ubuntu	USN-8513-1	16.04	php7.0	2026-07-06
Ubuntu	USN-8505-1	24.04	python-parsl	2026-07-06
Ubuntu	USN-8509-1	22.04 24.04 26.04	python3.10, python3.12, python3.14	2026-07-06
Ubuntu	USN-8506-1	22.04 24.04 26.04	request-tracker5	2026-07-06
Ubuntu	USN-8515-1	16.04 18.04 20.04 22.04 24.04 26.04	ruby-addressable	2026-07-07
Ubuntu	USN-8511-1	24.04 26.04	socat	2026-07-06
Ubuntu	USN-8504-1	16.04 18.04 20.04 22.04 26.04	sogo	2026-07-06
Ubuntu	USN-8510-1	22.04 24.04 26.04	tar	2026-07-06
Ubuntu	USN-8500-1	14.04 16.04 18.04 20.04 22.04 24.04 25.10 26.04	vim	2026-07-02

Full Story (comments: none)