The Linux kernel has turned 35 since that message Linus Torvalds sent to a Usenet forum on August 25, 1991. What began as a student hobby at the University of Helsinki, tired of the limitations of MINIX, has become a component that powers 100% of supercomputers , nearly 70% of Android mobile phones, and a significant portion of the internet and the public cloud. Version 7.2 has just been released , and the project's code now exceeds 40 million lines, of which around 30 million are actual code.
Behind that scale lies a decision that is more legal than technical. In its early days, Torvalds used his own license that prohibited commercial redistribution, thus stifling any sustainable business. In early 1992, he adopted the GPLv2 , effective from February 1st, and version 0.95 was the first released under those terms. This formula allowed the use, modification, and redistribution of the code, provided that the modifications were published under the same license. This led to the birth of companies like Red Hat and SUSE, and Torvalds himself later summarized that making Linux GPL-only was, by far, the best thing he had ever done. The kernel remains GPL-2.0-only: in 2007, he refused to migrate to GPLv3 because of its clause against tivoization.
A project that started with very little and went very far
The first code, version 0.01, appeared on September 17, 1991, with a mere 10.239 lines and couldn't even run on its own: it required MINIX to compile. Version 0.02 arrived on October 5 and is considered the first "official" version, while in December, version 0.11 made the definitive leap by being able to compile itself while running on Linux. The community responded quickly: by 1993, there were already more than a hundred developers, and two distributions that are still around today, Slackware and Debian, were born.
Not everyone saw it that way. On January 29, 1992, Andrew Tanenbaum published a message titled "Linux is obsolete," arguing that monolithic kernels were a 70s design compared to microkernels and that a system tied to the Intel 386 would never reach other architectures. Events proved Tanenbaum wrong on both counts: version 1.2, released in March 1995, added support for Alpha, SPARC, and MIPS , and since then the kernel has been ported to dozens of architectures.
Torvalds is tired of trivial patches created with AI
That Linus Torvalds is still active is nothing new, although he himself admits that he no longer contributes as many lines of code as before. What has changed is his unease with the excessive use of artificial intelligence tools to locate and fix bugs. He's not opposed to AI as a support tool, but he is against its misuse. In kernel version 7.1 , currently in its fifth Release Candidate of the usual seven, he has observed an excess of fixes for insignificant bugs that consume time and resources.
As he explained to the contributors, many of these fixes arrive at inappropriate times. Most of the fixes included in RC5 should have been proposed in the early stages of the project. Torvalds said that RC5 was quite large compared to previous versions at the same stage and that he wasn't entirely happy with it: most of it consisted of trivial issues with common drivers. His idea is that these kinds of tweaks should be included in a Linux-next tree and unified during the merge period, not at a later stage.
The problem isn't just that the patches are minor, but that they're creating a bottleneck. There have been cases of multiple people finding and fixing the same bugs, but reporting them separately. This patch overlap is confusing and inefficient for the actual maintainers. Torvalds has warned that he will be stricter and will start rejecting pointless pull requests with minor fixes.
There's also a technical risk. Using AI agents to fix a bug can inadvertently create a new one, adding more work and potentially even introducing a more serious vulnerability than the original. Torvalds summed it up with a simple idea: trivial fixes may be insignificant and have a low probability of causing problems, but "low probability" is not the same as zero probability . If someone wants to collaborate on the kernel, it's best to avoid using AI for minor bugs in later stages.
Containers are no longer a safe cage.
The security firm Depthfirst has published an analysis arguing that Docker and Kubernetes-style containers are no longer a sufficiently robust security barrier. Their argument is that an attacker can easily escape a container whenever they want. A container gives the impression of being its own machine, but it doesn't include a complete operating system: all containers on a server run through the same Linux kernel as the host , which manages memory, processor, and network resources.
Many CTF organizers and other environments blindly trust and host multiple tests on the same server, each in its own container, relying solely on the host's security. This creates a false sense of security. As evidence, Depthfirst cites an AWS bulletin dated November 2025 in which the company no longer considers containers a security barrier and therefore does not use them to isolate clients from each other.
What has changed in recent months is the entry cost of finding vulnerabilities. With cutting-edge AI models, an attacker with modest resources can create an exploit against unpatched machines as soon as a vulnerability is published, something that previously required significant expertise. Depthfirst's figures illustrate this acceleration: 249 CVEs for the Linux kernel were published in January, and 1.650 in August . Of the 36 CVEs disclosed through Google's kernelCTF, 13 can be exploited using ordinary interfaces, such as the local sockets that a container receives by default.
On July 24th, Depthfirst secured a spot on the kernelCTF with a zero-day exploit, before any patch was released, and today the proof of concept is available on GitHub. The patch for the Linux kernel was released on August 6th, but on Ubuntu, the update as of September 24th still listed the 26.04 kernel as "Vulnerable, work in progress" and the 24.04 kernel as "Vulnerable ." Finding vulnerabilities has become quick; fixing them across all releases and machines takes time.
How to protect yourself? Depthfirst proposes directly abandoning kernel sharing and migrating untrusted workloads to microVMs, lightweight virtual machines where each workload has its own kernel. This is where projects like Firecracker and Kata Containers come in. If an attacker breaks one of these kernels, in theory, they only compromise their own instance and not the entire host. However, Firecracker relies on KVM, the virtualization component of the host Linux kernel, and KVM has also had vulnerabilities. Januscape allowed escape from the physical machine if the host supported nested virtualization. The attack surface is smaller, but not nonexistent. Meanwhile, on Ubuntu 24.04 or 26.04, it's advisable to keep an eye on the arrival of the next kernel; Canonical has announced a weekly kernel release to try to compensate for this pace.
Specter v2 reappears with Branch Target Reuse
VUSec has described Branch Target Reuse (BTR), a Spectre v2 attack that exploited the cBPF JIT compiler in Linux to retrieve a root password hash. The group also reports that kernel developers incorporated an x86 mitigation to address code region reuse. BTR exploits indirect branch predictions that can persist after code generated by a JIT compiler is released and another block reuses its address. The CPU can then speculate toward an obsolete position within the new code.
VUSec describes two complete end-to-end exploits against the cBPF JIT compiler on Linux: one with the default configuration and another that worked with constant obfuscation enabled. The demonstration recovered a root password hash from the memory of a `su` process. It's important to remember that a hash is not the password in plaintext: to obtain it, you would have to attempt to crack the hash, and the chances of success depend on the algorithm and the strength of the password. VUSec estimates the leak at eight bytes per second and explains that pointer tracing reduces the amount of data that needs to be extracted to reach the secret.
Processors predict the destination of indirect jumps to execute instructions in advance. BTR exploits the fact that this prediction can become outdated compared to the code currently occupying a memory address. In the Linux demonstration, cBPF programs are installed as seccomp filters. The technique worked with classic BPF programs available to unprivileged processes; VUSec distinguishes this from eBPF, whose JIT, according to the group, is restricted to privileged users. The results were not the same across all engines: on Linux cBPF, there were two successful exploits; on Firefox SpiderMonkey, a proof of concept was obtained with outdated predictions after code reuse, but not a full browser exploit; on Oracle GraalVM, an attack was unsuccessful because internal compilation and garbage collection erased the prediction entries. Oracle mitigates reuse by randomizing the locations of the JIT code cache. The reported averages were three minutes on Raptor Cove and five minutes on Lion Cove.
The kernel-integrated mitigation imposes an IBPB barrier, which clears the indirect branch predictor, on all kernels when a cBPF program reuses a previously executed cBPF or eBPF region. This measure also discourages such reuse. VUSec links the identifiers CVE-2026-64507 and CVE-2026-64508 to Linux issues and recommends installing operating system and software updates as soon as vendors release patches. The group states that it observed the behavior on all the Intel, AMD, and Arm CPUs it tested, although the hash recovery demonstration was performed on Intel Raptor Cove and Lion Cove processors. The research paper on BTR was accepted for ACM CCS 2026 and was scheduled for publication in November 2026.
What to look for if you manage Linux systems
While the anniversary and evolution of the kernel are cause for celebration, the practical side still requires work. In enterprise and public administration environments, especially in Spain and the rest of Europe, it's important not to assume that a container provides sufficient isolation. If untrusted workloads are running, it makes more sense to use microVMs with their own kernels, review host patches, and avoid mixing critical services on the same server without additional layers of protection.
It's also important to closely monitor the update cycle. Canonical's weekly kernel releases help, but they don't eliminate the need to check if a specific Ubuntu version is still marked as vulnerable. In development, AI can be useful for heavy-duty tasks, although Torvalds has made it clear that he doesn't want it to become a factory for minor patches during critical times. Kernel security depends on reviewing, prioritizing, and patching judiciously, not on accumulating changes simply because a tool can easily generate them.
The Linux kernel reaches its 35th anniversary with enormous scale, over 40 million lines of code, and a presence in supercomputers, mobile devices, and the cloud. At the same time, it faces internal debate about the use of AI in development, attacks like BTR that exploit hardware, and a fundamental problem with containers: they share the kernel and are no longer sufficient as a sole defense. The history of free software remains strong, but maintaining it requires timely patches, stronger isolation , and sound technical decisions without shortcuts.
