The Linux Kernel CVE Avalanche

The Linux Kernel cyber security team struggles every day with a growing number of software security issues. In 2020 the Linux Kernel saw only 120 new software security bugs published in the Common Vulnerabilities and Exposures (CVEs) database, a list of publicly disclosed computer security flaws. The following years saw a slight increase of those to a factor of roughly 3. But by the year 2024 we saw a tenfold increase to around 3600 new CVEs. Think about it: that’s 10 such new security bugs discovered every day. And 2025 doesn’t look to be slowing down. Another 10 per day in the first six months of the year already.

The Logistical Nightmare of Vulnerability Management

Every time a new CVE is published, cyber security organizations must analyse it, make a risk assessment and decide whether it is a security issue for their code and the array of applications using it. They need to provide a documented response and track such responses for auditors to be able to review. Then they need to decide to remediate or fix the issue or decide to not care for a specific trackable and justifiable reason. After fixing the issue, they now need to prepare a software update, or patch, and manage the distribution of a new software release to all of their internal or external customers. To mitigate against the problem customers must download/update their software and apply the patch or new release and then test that it both fixes the issue and doesn’t affect any other part of their system. Sometimes they need to reboot the system afterwards which can have other side effects.

Software security updates used to be once every few months, or maybe once a month. But once a day? Or several times a day? There is a general sentiment of being overwhelmed by the sheer volume of cyber-security vulnerabilities in the software industry. And one can easily understand why.

Security vulnerability assessment reports that organizations must publish for compliance purposes can be hundreds of pages long and keep growing. Software security teams can no longer keep up with the pace at which newly discovered CVEs are published and need to be analysed and prioritized before being fixed. Software security analysis tools and testing teams take longer to process and to test existing software against all the new potential threats. Software development teams can no longer keep up with the pace at which security upgrades need to be released to their customers. Software update/upgrade cycles are no longer appropriate for the industry. Not even mentioning special cases like the critical national infrastructure industry for which any such exploitable vulnerability would be fatal were it to remain in the code. The world has changed, and the software security industry is globally outpaced.

May 2025: for the first time in history, OpenAI’s ChatGPT O3 discoverd a new (zero-day) security vulnerability in the Linux Kernel (CVE-2025-37899). And it also concludes that the proposed fix remains insecure. Now imagine throwing O3 at all production software and potentially collecting new CVEs at an even faster pace than before. Perhaps it took a couple of weeks or a month to find the first CVE in this manner. But in a few months or maybe a year, we’ll be finding CVEs every minute, or every second. And we are not yet at a stage where AI can also automatically resolve all of them, let alone distribute corrective patches to the entire planet instantaneously.

How do we fix this?

The sheer volume of new vulnerabilities makes our current situation unsustainable. We can no longer hope to fix every issue after it's been discovered, and we certainly cannot eliminate every bug at the source. Writing perfectly secure software is a monumentally difficult, time-consuming, and almost impossible task that simply doesn't scale for the vast number of applications we need for our modern, digitised world.

However, it turns out that a significant proportion of these vulnerabilities—around 70%—are tied to a specific class of errors known as memory safety bugs, including the one recently identified by ChatGPT O3 in the Linux Kernel. These include common issues like buffer overflows, use-after-free, and null pointers. These programming mistakes can be exploited by an attacker to gain unauthorised access to memory, allowing them to inject malicious code and potentially take over a system entirely.

So, instead of a losing battle of patching bugs, what if we addressed the problem at its very foundation? Why not build systems that are inherently resistant to memory safety bugs? By making simple changes to the hardware and updating the instruction set architecture (ISA) of a chip to be able to interpret instructions in a memory safe way, the security threat posed by those CVEs essentially becomes obsolete. We are not trying to eliminate all the CVEs in all code, we are containing the harm that they can do and limiting the impact on the rest of the system. We are isolating every piece of code within compartments and making sure pointers to memory cannot be misused for harmful purposes. We are associating pointers to memory with specific bounds and permissions to control what someone can do with the pointer. And we rely on the hardware to enforce everything and to not let any rogue software take over. We are cutting the ground under the attacker’s feet. And the solution is future-proof.

The Solution: Hardware-Enforced Security with CHERI

The technology we are describing here already exists. It is called CHERI: Capability Hardware Enhanced RISC Instructions. It was invented in Cambridge, UK about 15 years ago and has been thoroughly vetted by security experts since then. It is now readily available and being commercialized for the first time in SCI’s ICENI devices. Together with the CHERIoT RTOS these devices offer a development platform that will let the industry get rid of the threats to memory safety altogether. It is easy to write new code for them using the online programmer’s guide, and existing code can simply be recompiled using available open source tools.

Find out more about ICENI – Contact Us now.