The kernel is able to run a few types of executable files, including native binaries in the ELF format and interpreted programs that begin with the #! marker. It also, however, has a mechanism, called binfmt_misc, that can be configured from user space to enable the transparent execution of programs in just about any format. This feature has been relatively static for years, but it seems likely to receive some significant updates in the near future, including the ability to load BPF programs that can decide how to run a given program.

Konstantin Ryabitsev has announced the release of version 0.16.0 of the b4 software-development tool. The biggest change is the addition of bug-tracking support:

The new "b4 bugs" command integrates with git-bug to let you track bug reports alongside your git repository. Bugs are stored as git objects inside the repo, so they travel with the code and can be shared via git push/pull without any external service.

There are also a lot of improvements to b4 review (which was covered here in March), better conflict resolution in b4 shazam, improved history rewriting, and more.

Jynn Nelson describes the Rust language team's new LLM policy on the Inside Rust blog.

No one except the author is required to read LLM output unless they choose to: LLM output isn't allowed in public docs, PR descriptions, or Github comments unless it's clearly marked; reviewers aren't required to look at LLM PRs if they don't want to.

No one is required to use LLMs to contribute to rust-lang/rust: policies must be written first for humans, and only summarized for machines; LLM reviews cannot substitute for human review or self-review.

You are allowed to generate LLM content that only you see, without disclosure, as long as you do not post it anywhere that you expect us to read or review.

The AI Security Institute has released a detailed report on an security incident of its own making. The Institute set some LLM agents loose on the Internet with a security challenge; soon they were creating malware-laden pull requests and sock-puppet accounts to promote them.

The agent opened a malicious pull request (PR) to ⟨REPO_A⟩ and pursued a number of strategies to get it merged:

1. Repeatedly commented on the PR with sockpuppet accounts to manufacture consensus and pressure the maintainer into approving with minimal review.
2. Opened a GitHub Issue in another repository (also owned by ⟨PERSON_A⟩) containing a prompt injection for other coding agents. The malicious instructions were addressed to issue-triage AI coding agents and invisible to humans viewing the website.
3. Sent multiple emails to ⟨PERSON_A⟩ and ⟨PERSON_B⟩, with different pretexts to get them to run malicious code. Over the course of the sample, the agent sent five emails, some containing malware, others aimed at persuading a maintainer to accept the pull request.

It would be surprising if this were the only incident of this type; the only real difference here is that the people involved are documenting what happened.

The recent discussion on "spawn templates" raised questions about whether it was time to provide an alternative to the classic Unix fork()/exec() pattern for process creation. One idea that was raised there was to shift the template pattern into an interface that could be used to efficiently assemble new processes from bare cloth, without duplicating the parent process. Preferably, that interface would be able to implement posix_spawn(). Li Chen, the author of the spawn-template work, has now responded with a patch series (written with significant LLM assistance) showing what a process-builder API for Linux might look like.

For those of us with a long memory: John Goerzen has announced the release of C-Kermit 11, the first release of this file-transfer utility in 15 years.

As Debian maintainer of Kermit, I noticed some areas where it wasn't matching modern expectations. One area was, not surprising for a project of its age, security. Another area was that its character set or line-ending conversions are usually not desired now; we are used to byte-identical binary transfers, and the defaults caused confusion and even some rare instances of data corruption. So I started making a few patches last year.

See the changelog for details on the work that has been done.

Most of us probably haven't thought about C-Kermit in years (if ever), but there was a time when it was an essential tool for moving files between machines.

The JFrog blog examines some reported vulnerabilities in SQLite, some of which made their way into high-profile vulnerability databases, that turned out to be entirely fabricated by LLMs.

These LLM slop CVEs can cause organizations to waste time investigating and patching vulnerabilities that do not actually exist, as well as polluting vulnerability databases. In environments where Critical vulnerabilities are automatically prioritized or tickets are opened based on vulnerability scores, such fabricated CVEs can turn into a real burden.

In environments where AI is used to automate vulnerability triage and remediation this becomes even more concerning. An AI agent that encounters a fabricated CVE may attempt to locate the vulnerable function, generate a patch, or recommend changes based on code that does not even exist. Instead of helping security teams remediate real vulnerabilities, it can lead them down a completely wrong path, potentially introducing unnecessary changes and wasting time.

The 7.2-rc6 kernel prepatch is out for testing. Quoth Linus: "Hmm. This rc is huge. Even by the "new normal" standards this is a big rc, and I think it's the biggest rc6 we've had in years at least by commit count." There were 537 non-merge commits applied between 7.2-rc5 and 7.2-rc6.

Linux provides a system call (mkdir()) to create a directory, and a few variants of open() that can open a directory. There is, however, no system call in Linux that can create and open a directory in a single, race-free call. Jori Koolstra has been working on remedying that situation, most recently by repurposing a set of open() flags that currently return an error. There are, however, concerns that show just how hard it can be to create user-space interfaces that do not present traps for application developers.

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

The 7.2-rc5 kernel prepatch is out for testing. Linus said: "So it's a bit too big for my liking, but nothing in there strikes me as particularly strange or scary".

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

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

Security updates have been issued by AlmaLinux (compat-openssl11, java-1.8.0-openjdk, java-17-openjdk, kernel, kernel-rt, and sssd), Debian (exim4), Fedora (chromium, dotnet10.0, mbedtls, mupdf, netatalk, python-django5, skopeo, sssd, and wget1), Mageia (libevent and transmission), Oracle (.NET 8.0, 389-ds-base, aardvark-dns, acl, buildah, cifs-utils, dovecot, dracut, galera and mariadb11.8, glibc, hplip, kernel, libxml2, nginx, openexr, podman, postgresql18, rsync, thunderbird, and vim), and SUSE (389-ds, afterburn, agama, alsa, apache-commons-compress, apache-ivy, brotli-java, zstd-jni, avahi, aws-nitro-enclaves-cli, cockpit, cockpit-machines, cockpit-packages, cockpit- podman, cockpit-repos, cockpit-subscriptions, container-suseconnect, containerd, cosign, cryptsetup, curl, dash, dnsmasq, docker, docker-compose, ffmpeg, firefox, freetype2, gawk, gh, glib-networking, glib2, go1.25, go1.25-openssl, go1.26, go1.26-openssl, google-guest-agent, google-osconfig-agent, gpg2, gsasl, gstreamer-plugins-bad, gzip, haproxy, hauler, helm, helm3, ImageMagick, imagemagick, iproute2, java-11-openjdk, java-26-openjdk, jline3, joe, jq, kernel, kernel-devel, krb5, kubevirt, libgcrypt, libpng12, libqt4, libssh2_org, libXfont2, libxml2, mariadb-connector-c, microcode_ctl, multipath-tools, nasm, net-tools, nghttp2, nmap, ntfs-3g_ntfsprogs, openexr, packagekit, pam, patch, perl, perl-DBI, perl-dbi, perl-http-date, perl-libwww-perl, perl-xml-bare, php8, prometheus-ha_cluster_exporter, python-aiohttp, python-cryptography, python-dulwich, python-idna, python-maturin, python-mistune, python-msgpack, python-paramiko, python-Pillow, python-pyasn1, python-soupsieve, python-sqlparse, python-tornado, python-tornado6, python-urllib3, python313, python313-pandas, python314, qemu, radvd, rootlesskit, rpcbind, ruby3.4, runc, s390-tools, shibboleth-sp, sssd, systemd, systemd, systemd-mini, terraform-provider-aws, terraform-provider-azurerm, terraform-provider-external, terraform-provider-google, terraform-provider-helm, terraform-provider-kubernetes, terraform-provid, terraform-provider-susepubliccloud, tiff, tomcat, tomcat10, tomcat11, uriparser, vim, vorbis-tools, wget, wpa_supplicant, xwayland, and yelp).

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

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

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

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

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

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

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

Like many development communities, the kernel community has been struggling to determine how large language models will be used in its development process. The news has been dominated recently by a strongly worded missive from Linus Torvalds on the subject, but the discussion has been rather more wide-ranging and nuanced than that. Topics that have been considered recently include the LLM attribution requirement, code-review tools, dependence on proprietary tools, and whether there is a place for concerns about the ethics of LLMs.