Linux 7.0: one Bash script, one weekend, 23 years of kernel bugs

Twenty-three years. And one evening.

A Bash script is running in a loop on Nicholas Carlini's laptop. It's not doing anything clever. It simply opens a file with the kernel source code, feeds it to the Claude Opus 4.6 model, asks it to pretend it’s participating in a CTF competition (Capture the Flag), and inquires what can be broken. Then it opens the next file. And the next.

Carlini isn't even monitoring the process. He has run similar tasks before. He has run them for months. And he always received nothing but white noise in response.

And then the result comes... And makes him stop typing.

The model found a hole in the code that Linux uses for file sharing over the network. That same code runs on the file server in your company, in your hospital's storage, on shared drives in your child's school, and on a considerable portion of backends in AWS, Google Cloud, and Azure.

Thanks to this bug, an intern on their first day at work can simply connect to the guest Wi-Fi in the office, run a short script, and take over the file server. "Take over" means: read the salary table from the HR department, delete the salary archive, copy the backups of the CEO's email, and set up a permanent backdoor that will survive the next three reboots. No admin password. No stolen accounts. No chain of other vulnerabilities. This hole was present in every Linux-based file server released from March 2003 to April 2026.

Carlini digs into the commit history. The hole was introduced into the kernel in March 2003. That is, even before git itself appeared (it was released in April 2005). This bug exists in every Linux-based data storage system sold over the last two decades.

For some time, he just stares at the screen. Later he will tell the audience at the AI security conference [un]prompted: "I have never found anything like this in my life. Doing this is very, very, very difficult."

I have been working with Linux systems since 2004. Telecom, digital medicine, deep-tech. I have run xfs_repair at midnight in production more often than I would like to remember. And I have seen a failing NFS server deprive an entire team of a full workday.

Carlini's script is not some genius creation. It's just cheap.
A week of computations and one person. Simple economics.

And three weeks later, Linus Torvalds tagged the release of Linux 7.0, leaving a line in the email announcement that sounded like a shrug: "I suspect AI tools will still be finding such corner cases for us for some time, so perhaps this is our 'new normal' — at least for a while."

Linus Torvalds released Linux 7.0 on Sunday, April 12, 2026. This is the story of what came with this release and those who contributed to it.

And this is the release with which that very "new normal" has finally arrived.

February morning when AI slop ended

Greg Kroah-Hartman leads the stable branch of the Linux kernel. He is the number two person after Linus. He is also responsible for the kernel's security inbox. For years, upon opening his email, he mainly saw junk. "AI slop," as he calls it. Generated reports with no real bugs, mixed-up files, lines — just everything. He even created a separate folder for this.

But one day, on a February morning, the folder stopped filling up.

Real bug reports started coming in. With specific line numbers. With reproducer cases that actually reproduce the bug. With root causes that are confirmed. In March, he told The Register: "Months ago, we were getting what we called AI slop. Then, a month ago, something happened, and the world turned upside down. Now we have real reports." He added, "We don't know why. Nobody seems to understand."

Either all advanced models learned to read C at the same time in one month, or a critical mass of researchers decided in the same week to unleash their AIs on legacy code. Or perhaps both.

Greg does what a maintainer is supposed to do: he writes documentation. Before the release of Linux 7.0-rc7, he pushes an update to security-bugs.rst — a file that explains to security folks how to submit vulnerabilities. Now this update is written for language models. It explains which maintainer is responsible for which subsystem, what a properly formatted report looks like, and what fields an automated pipeline should include. The kernel security inbox now operates in dual mode: people and AI agents are traveling in the same lane.

Meanwhile, the second team is monitoring commits, not finished CVEs. Roman Gushchin from Google launches the Sashiko project (named after the Japanese embroidery technique and written in Rust — you'll understand the irony shortly). Sashiko reads every patch sent to LKML (the Linux kernel developers' mailing list). In a benchmark of 1000 real patches, it catches 53% of the bugs that eventually surfaced later. And each of these bugs was missed by live reviewers.

When Gushchin was asked about this figure, he replied, “Some might say that 53% is not that impressive. But 100% of these issues were missed by human reviewers.”

Somewhere in the LKML archive right now lies a patch that would wake your on-call SRE at midnight next Tuesday. Sashiko caught it last month. You will never know what that patch was.

This is what the "new normal" feels like from the inside.

Rust has won. Both sides have surrendered.

On the release day, Miguel Oheda submitted his last pull request for Rust-for-Linux for version 7.0 with a one-liner in the description:
“The experiment is over, meaning Rust is here to stay.”

Four years ago, he would have been yelled at for such a phrase. Rust first appeared in Linux 6.1 at the end of 2022 as an experiment — and was integrated there despite protests from maintainers who considered it a quirk, a political project, or worse. After six releases, the "experiment" label is removed. Rust is a full-fledged language in the kernel. Individual subsystems still decide whether to accept Rust code, and the overwhelming majority of the kernel remains in C, but the debate is over.

The Nova driver (an open-source replacement for NVIDIA's nouveau for the Turing architecture) is released in version 7.0 with Rust code. The Rust DRM infrastructure that Danilo Krummrich has been building for the past two years is now in the mainline.

But the people who spent four years making this happen are no longer in the room.

Wadson Almeida Filho, who led the Rust implementation at Microsoft, after four years of disputes with the C maintainers (who didn’t want to see his code anywhere near their subsystems), submitted his resignation, citing "non-technical nonsense," and slammed the door. His co-lead Alex Gaynor left the same week Rust received official status. The victory lap went on without them.

On the other hand — Christoph Hellwig. He was a maintainer of the DMA (Direct Memory Access) subsystem for 20 years — a part of the kernel so fundamental that most engineers don’t even know who owns it because they’ve never had to touch it. A year earlier, Hellwig publicly referred to mixing Rust with C as "cancer." When the maintainers agreed to allow Rust drivers to call C's DMA APIs through a thin abstraction, Hellwig resigned. Marek Szyprowski took his place.

20 years of maintaining code that allows every driver in the kernel to communicate with hardware. This is not a chapter in a career. This is an entire career. The last dispute was over whether a new language could call your functions through a wrapper. He lost. And he left.

Safe Rust makes entire categories of bugs structurally impossible. Buffer overflows. Use-after-free. Dereferencing null pointers. That 23-year-old bug in NFSv4 found by the Carlin script — that’s something that simply cannot exist by design in Safe Rust.

Now the kernel has a language in which it's outright impossible to write the CVE from the beginning of this article. And the people who fought for this are gone. And the person who fought against it is gone.

And Linux 7.0 still came out.

AI Rules: Assisted-by Tag

Along with the release, a new set of rules was introduced. Any patch written with the help of AI must now contain the Assisted-by: tag, specifying the model and tools used. AI agents cannot use the Signed-off-by signature because the Developer Certificate of Origin is a legal statement that can only be made by a human. Responsibility for bugs remains with the human developer who clicked the "Submit" button.

This rule came about not because the community sat down and calmly discussed everything. It emerged because Sasha Levin, an engineer from NVIDIA, submitted a patch to kernel 6.15, almost entirely generated by a language model (including the changelog), and didn't tell anyone about it. The code compiled. It passed the initial review. Moreover, it contained a performance regression that made it into the stable branch and ruined a whole week for someone.

The scandal was so loud that Linus, who has no patience for long procedural meetings, abruptly cut off the debates. He called calls for total bans “meaningless posturing.” AI is a tool. The responsibility lies with the person. We are implementing a policy.

Red Hat (which has been supplying commercial Linux longer than most developers in this story can even code) raised a more complex question that currently has no answer. Language models trained on code under the GPL license make it structurally difficult to verify the provenance of any commit. Whose copyright is in this generation?

This problem is unresolved in Linux 7.0. And it’s not going anywhere.

Your Saturday. Your bank. Your 2035.

In the data center, the RAID controller initiates the nightly SCRUB cycle—a routine integrity check on each disk in the array. Inside the filesystem metadata, a single bit flips. A zero has become a one where the kernel least wanted it to happen.

If you’re running XFS (the default filesystem on RHEL, Rocky, AlmaLinux, and Oracle Linux), historically, you would learn about this in one of two ways. Either the service would start acting up. Or the next morning, you would read the output of xfs_repair on the unmounted disk. Both scenarios guarantee a lousy Monday.

In January 2026, Darrick J. Wong sent the 6th version of his patch set for self-healing XFS, and it made it into release 7.0. Before this release, if a file server in a company lost one byte of metadata over the weekend, the on-call engineer would receive an alert, drive to the office, power down the server, run xfs_repair, and bring everything back up. In the best case—4 hours of downtime. In the worst case—the repair wouldn’t fit within the maintenance window, and the Monday meeting would start with apologies.

Linux 7.0 cancels these Saturday trips to the office. The background daemon xfs_healer detects a bad sector, repairs it on the fly while the server continues to serve files, and simply writes a log. Users notice nothing. The pager is silent. Monday starts on time.
Multiply this by the scale of the clouds (XFS is the default on RHEL images in AWS, GCP, and Azure). Most of the enterprise fleet on the planet just became more peaceful.

Meanwhile in Frankfurt: somewhere in a bank, the SPARC M7 server is conducting a transaction. The software was written in 1998. The contract with Oracle states that this piece of hardware cannot be touched. On April 12, this server received a new kernel code. The SPARC architecture (a hello from the early 90s from Sun Microsystems) got a fork/clone bug fix, support for the new system call clone3, and an API cleanup.

DEC Alpha, which mainly lives in scientific labs, received a memory corruption fix in user space. The Motorola 68000 also received its patches. However, support for Intel i486 was removed. The 486 series processor was released in 1989. Code for 32-bit x86 is still in use, but dropping compatibility with i486 allows it to run faster on everything else. SPARC was retained because someone cares and is willing to take responsibility for it. The 486 was discarded for the same reason: no one cares.

The latest AMD server chips (EPYC 9005) now work with encrypted virtual machines even more efficiently thanks to the updated KVM path in 7.0. Encrypted virtual machines (SEV-SNP) are the very feature for which banks and hospitals pay extra to cloud providers so that the provider cannot read their data. For AWS or Azure, this is the difference between a profitable "confidential computing" rate and just a pretty slide in a presentation.

Post-quantum security: The ML-DSA algorithm has been added to the kernel at three security levels. Why? Every time a Linux machine loads a driver, it checks the cryptographic signature. Today's signatures can be forged by a quantum computer. Such computers do not exist yet. The problem is that hostile intelligence agencies are already recording encrypted logs today, betting on ten years of patience. When the necessary computer appears in 2035, they will forge a kernel update (which will look legitimate), send it to the target laptop, and turn it into a listening device.

ML-DSA closes this door in 2026 while it is still easy to close. And the signing of modules with the SHA-1 key (which would collapse in minutes before the machine of the future) has been completely removed in this release.

The Copilot button was Microsoft’s. These three are common.

Three new scan codes appeared in the input subsystem. They were added by Google in a pull request for 7.0, and they also wrote the specification for USB-IF (HUTRR119).

• KEY_ACTION_ON_SELECTION (0x254) — triggers an AI action on the selected content (explain, summarize, find).

• KEY_CONTEXTUAL_INSERT (0x255) — opens an overlay for text generation directly in the active field.

• KEY_CONTEXTUAL_QUERY (0x256) — offers suggestions related to the selected item.

Unlike Microsoft’s Copilot button (which in 2024 was permanently tied to a specific vendor's assistant), these three keys are first-class values of the HID protocol, and they are agent-agnostic. The laptop vendor can map them to Claude, Gemini, a local instance of llama.cpp, or your own bash script. Your next ThinkPad, Dell XPS, or Framework will come with them.

The next 23-year bug

One release. Four paradigm shifts.
AI reviews patches in the mailing list with an efficiency of 53%. AI finds kernel bugs that have been hidden for 23 years. AI receives official recognition as a co-author under a new tag. And support for three physical buttons for communicating with AI agents grows in the kernel.

Infrastructure built for AI, and infrastructure made safer thanks to AI — all in one week.

If one person with one bash script found kernel vulnerabilities over a long weekend... how many did the internal Google team find? How many did your hardware vendor's team find? How many have government hackers already found, archived, and not told anyone about?

Linus called it "the new normal." OpenSSL. GCC. Python. Postgres. Chromium. And that 10-year-old microservice in your repository that no one has touched since its author quit. They all sit somewhere with a buffer of 112 bytes and a write attempt of 1056 bytes, which no one thought to check.

They are just waiting for the bash script that has yet to be written.

If you are running NFS — you should have already applied the patch for CVE-2026–31402. If you have RHEL with XFS — test the self-healing daemon on staging.

But the main thing is: if you have anything running in production that was written before 2010, this week ask your security lead what your plan is for the day when someone directs a conditional Claude at this code.

The answer "we have code review" is no longer accepted.
Code reviews have missed this bug for twenty-three years.

When your codebase gets its CVE from a stupid bash script, what will be written in your postmortem?