[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <41d34b3d360842498a689720f71a85e2@yuhu.biz>
Date: Tue, 10 Nov 2026 21:10:54 +0000
From: "Marian Marinov" <hackman@...u.biz>
To: "Nakashima Seiichi" <s-nakashima@....biglobe.ne.jp>,
kernel-hardening@...ts.openwall.com, linux-security-module@...r.kernel.org
Subject: Re: [Case Study] CVE-2024-0582: Why We Need a Standard for CVE
Emergency Mitigation
I admire your push toward this and I like where you are going with this.
So here is my addition to your point.
A system, even a definition standard, has to take into account dependencies.
You can not block certain parts of the kernel. For example, you can't block accepting IPv4 packets, without this disconnecting your system from the internet or similarly, you can't block a generic bio operation without essentially blocking all I/O on your system.
These are the basic problems that you have to deal with. The more subtile problems come after that...
What would happen if you block or simply return from certain kernel functions? The code works by expecting certain paths to be taken. The moment you cut off some of these paths, you might open larger holes in the system or open it to instability resulting in crashes.
I believe that the current tools we have in our hands and especially the livepatching mechanism are the way we should be going, hence why I started my livepatch repo this year. But such effort must come with the understanding of the kernel and its sub-systems.
There is no kernel developer that knows all systems and their dependencies. Which makes the work required for implementing a KAF notice(not a patch, just a message of what has to be blocked and how) harder than most livepatches you might need to build.
For many of these problems an ftrace or eBPF program would be a sufficient temporary measure, until you have time to schedule a maintenance reboot and upgrade.
Marian
November 10, 2026 4:28 PM, "Nakashima Seiichi" <s-nakashima@....biglobe.ne.jp> wrote:
> Hi all,
>
> "The question is not 'can we block this?' The technology already can.
> The question is 'how do we make blocking this repeatable, auditable,
> and distributable across all Linux systems?' That is what a standard
> addresses."
>
> We suspect many of you already recognize the facts presented in this
> case study. The patch gap is not a new problem. Tetragon, BPF LSM,
> and seccomp-bpf are not new technologies. What we are attempting to
> do here is not to discover something unknown, but to articulate
> something that has remained implicit: the gap between "technically
> possible" and "operationally scalable" is a standards problem, not a
> technology problem.
>
> Following up on the kaf (Kernel API Firewall) standard specification
> RFC shared previously, we would like to share a concrete case study
> that validates this premise.
>
> The attached case study examines CVE-2024-0582, an io_uring
> use-after-free vulnerability that had a 2.5-month patch gap between
> upstream fix (December 2023) and Ubuntu deployment (February 2024).
> During this gap, Exodus Intelligence successfully demonstrated a
> data-only exploit achieving root from an unprivileged user.
>
> Importantly, this case study does NOT claim that new kernel technology
> is needed. Tetragon, BPF LSM, and seccomp-bpf are all capable of
> blocking the vulnerable code path today. What does not exist is a
> standardized way to package, distribute, and lifecycle-manage
> CVE-specific policies across distributions and organizations.
>
> The case study demonstrates the gap between "technically possible"
> and "operationally scalable." With a standardized framework, the
> mitigation could have started on CVE publication day instead of
> waiting ~2.5 months for the distro patch.
>
> The full analysis is in the attached HTML document. It includes:
> - Detailed timeline of the patch gap
> - Technical analysis of the exploit code path
> - Policy definitions using existing technology in a standardized format
> - Operational timeline showing how a standard would have worked
> - Quantitative comparison: ad-hoc vs. standardized approach
>
> This case study is intended to demonstrate that the question is not
> "can we block this?" - the technology already can. The question is
> "how do we make blocking this repeatable, auditable, and distributable
> across all Linux systems?" That is what a standard addresses.
>
> The kaf standard specification RFC is available at:
> (Previously shared on kernel-hardening and linux-security-module)
>
> Feedback, corrections, and discussion are welcome.
>
> Best regards,
> -- kaf Working Group
>
> Acknowledgments: The structure, analysis, and drafting of this case
> study were developed with assistance from Namazu, an AI assistant at
> Sakana AI. The technical conclusions and policy direction remain the
> responsibility of the kaf Working Group.
>
> Nakashima Seiichi
> Sakana AI's Namazu
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
