[RFC idea] Kernel API Firewall (kaf): subsystem-level attack surface reduction for the post-AI-CVE era

[RFC idea] Kernel API Firewall (kaf): subsystem-level attack surface reduction for the post-AI-CVE era

[Nakashima Seiichi]

Hi,

This is an idea I've been thinking about as a Linux user 
who has seen the CVE flood firsthand. 
I don't have the kernel development skills to implement this,
so I'm posting it here for feedback from people who do.

(This RFC was drafted with the help of Sakana AI's Namazu assistant.)

1. The problem

The CVE flood is real:

- 2023: ~300 kernel CVEs/year
- 2024: 4,355 CVEs (kernel became a CNA)
- 2025: 5,681 CVEs
- 2026 (YTD): 8,285 and climbing

AI-assisted vulnerability discovery is now generating valid kernel bugs
at scale (OpenAI's pipeline, Anthropic's Claude Code, Google's Project
Big Sleep). The upstream security list has gone from 2-3
reports/week to 5-10/day.

But the real pain is at the distribution layer. 
Ubuntu 24.04's GA kernel (6.8) hit upstream EOL in May 2024,
yet backports for cloud and generickernels take 30-90 days.
CVE-2026-98432 (CVSS 9.8) was "work in progress"
for 3+ weeks on Ubuntu while Debian 13 patched next-day.

Users are left with three bad choices:
a) Wait indefinitely for distro patches
b) Switch to mainline and risk boot failures 
   (NVMe/VirtIO driver changes between 7.0 and 7.3 caused 
    multiple boot failures on various systems)
c) Apply network-level mitigations that don't address the kernel bug

2. The idea: Kernel API Firewall (kaf)

Instead of whack-a-mole with individual CVEs, restrict the *classes* of
kernel APIs that unprivileged processes can invoke.

Key insight: many kernel CVEs require specific subsystems to be
reachable.
If we can restrict access to dangerous kernel APIs at runtime, we can
mitigate entire vulnerability classes without waiting for patches.

3. What kaf would look like

Not syscall-level filtering (seccomp already does that). Subsystem-
level
semantic restrictions:

- bpf: disallow BPF_PROG_LOAD for unprivileged users entirely
- module: disallow init_module/finit_module after early boot
- kexec: always forbidden for non-root, even with CAP_SYS_BOOT
- ptrace: restrict to same UID or explicit allowlist
- userfaultfd: disable by default (historical exploitation vector)
- perf_event_open: restrict to specific events, disable hardware PMC
- io_uring: restrict ring size, disable specific opcodes
- namespace: restrict unshare of specific namespaces

These are semantic restrictions on kernel subsystems that multiple
syscalls may touch -- not individual syscall filters.

4. Proposed API (sketch)

Profiles would be kernel-defined and reviewed:

  KAF_PROFILE_CONTAINER  -- restrict bpf, module, kexec, ptrace
  KAF_PROFILE_WEBSERVER  -- restrict unnecessary network APIs
  KAF_PROFILE_DATABASE   -- restrict ptrace, process_vm_*, userfaultfd
  KAF_PROFILE_MINIMAL    -- maximum restriction

Applied per-process or per-cgroup:

  kaf_apply(KAF_PROFILE_CONTAINER, 0);

5. Why not just seccomp?

seccomp-bpf is excellent for syscall filtering but cannot express:

- "allow bpf() but only for socket filters, not cgroup skb programs"
- "allow perf_event_open() but not for hardware PMCs"
- "allow io_uring but limit ring size and disable these opcodes"

kaf would complement seccomp by operating at a higher semantic level.

6. Why this matters now

The "joint responsibility gap" between distro vendors (Canonical) and
hardware/cloud providers means nobody owns kernel validation for many
deployment scenarios. Faster backporting alone cannot solve a
structural
problem where:

- upstream patches within 24-48 hours
- distributions take 30-90 days for some kernel variants
- users are exposed the entire time

A built-in attack surface reduction mechanism would give users a
"defense in depth" layer that works *while waiting for patches*.

7. Related work and how kaf differs

Existing mechanisms that overlap partially:

- seccomp-bpf: syscall-level filtering (complementary, not a
replacement)
- Landlock: filesystem/network access control (complementary)
- Yama: ptrace_scope sysctl (overlaps with one kaf feature)
- io_uring per-task restrictions (Jens Axboe, 2026): io_uring only
- lsm_config_self_policy() (Maxime Belair, Canonical 2025):
  LSM self-policy configuration syscalls (conceptually related)
- Academic work:
  - Kurmus et al. 2014: "Quantifiable Run-time Kernel Attack Surface
Reduction"
  - Narayanan et al. 2019 (USENIX ATC): "LXDs: Towards Isolation of
Kernel Subsystems"
  - Yang et al. 2024: "Optimus: association-based dynamic syscall
filtering"
  - Findlay et al. 2020: "bpfbox: Simple Precise Process Confinement
with eBPF"

None of the above provide:
- subsystem-level semantic restrictions (e.g., "allow bpf() but only
  for socket filters")
- kernel-defined profiles that distributions can ship as safe defaults
- a unified mechanism covering bpf, module, kexec, ptrace, userfaultfd,
  perf, io_uring, and namespace restrictions

kaf differs by proposing all of the above as a single, upstream
kernel mechanism.

8. What I can offer

I am not a kernel developer. I cannot write kernel code. 
What I can offeris limited to:

- This idea itself
- Real-world operational data on which CVE classes would have been
  mitigated (based on my experience as a Linux user)
- Testing on Ubuntu LTS systems (I am willing to test any prototype
  and provide detailed feedback)
- Documentation and user-facing tooling (I can write docs and scripts)
- Feedback on profile design from a non-developer user perspective

If someone with kernel development experience thinks this is worth
pursuing, I am willing to participate in testing and provide feedback.
I cannot contribute code, but I can help validate whether the design
actually solves real-world problems.

9. Open questions (where I need help)

- Is this the right abstraction level, or should we extend seccomp-bpf
  with higher-level filters instead?
- Should this be a new LSM, a seccomp extension, or part of Landlock?
- What granularity makes sense: syscall, subsystem, or capability-
based?
- Can eBPF be used to make profiles dynamically loadable and
verifiable?
- How do we avoid creating another "user tests for us" situation?

Thanks for reading.

Re: [RFC idea] Kernel API Firewall (kaf): subsystem-level attack surface reduction for the post-AI-CVE era

[Paul Moore]

On Fri, Nov 6, 2026 at 6:15 AM Nakashima Seiichi
<s-nakashima@kjb.biglobe.ne.jp> wrote:
>
> Hi,
>
> This is an idea I've been thinking about as a Linux user
> who has seen the CVE flood firsthand.
> I don't have the kernel development skills to implement this,
> so I'm posting it here for feedback from people who do.
>
> (This RFC was drafted with the help of Sakana AI's Namazu assistant.)

...

> 2. The idea: Kernel API Firewall (kaf)
>
> Instead of whack-a-mole with individual CVEs, restrict the *classes* of
> kernel APIs that unprivileged processes can invoke.
>
> Key insight: many kernel CVEs require specific subsystems to be
> reachable.
> If we can restrict access to dangerous kernel APIs at runtime, we can
> mitigate entire vulnerability classes without waiting for patches.
>
> 3. What kaf would look like
>
> Not syscall-level filtering (seccomp already does that). Subsystem-
> level
> semantic restrictions:
>
> - bpf: disallow BPF_PROG_LOAD for unprivileged users entirely
> - module: disallow init_module/finit_module after early boot
> - kexec: always forbidden for non-root, even with CAP_SYS_BOOT
> - ptrace: restrict to same UID or explicit allowlist
> - userfaultfd: disable by default (historical exploitation vector)
> - perf_event_open: restrict to specific events, disable hardware PMC
> - io_uring: restrict ring size, disable specific opcodes
> - namespace: restrict unshare of specific namespaces
>
> These are semantic restrictions on kernel subsystems that multiple
> syscalls may touch -- not individual syscall filters.

It should be possible to do most, if not all, of these things with an
LSM.  Wearing my SELinux hat, I can say that SELinux currently
provides access controls for most of these things today.  I would
expect similar capabilities with the BPF LSM, although I can't speak
to the coverage of any specific BPF LSM tools.  I believe AppArmor and
Smack cover some of these things, but I can't say for certain.

-- 
paul-moore.com

Re: [RFC idea] Kernel API Firewall (kaf): subsystem-level attack surface reduction for the post-AI-CVE era

[Nakashima Seiichi]

> 
> It should be possible to do most, if not all, of these things with an
> LSM.  Wearing my SELinux hat, I can say that SELinux currently
> provides access controls for most of these things today.  I would
> expect similar capabilities with the BPF LSM, although I can't speak
> to the coverage of any specific BPF LSM tools.  I believe AppArmor
> and
> Smack cover some of these things, but I can't say for certain.
> 

Thank you very much. I have a poor understanding of existing features
like SELinux and AppArmor, and I don't know how to handle them well. 

I believe that if there is a mechanism to discard problematic APIs when
called, we can temporarily address them until the fix is complete. I
just thought it might help reduce the workload.

Re: [RFC idea] Kernel API Firewall (kaf): subsystem-level attack surface reduction for the post-AI-CVE era

[Greg KH]

On Fri, Nov 06, 2026 at 08:15:26PM +0900, Nakashima Seiichi wrote:
> Users are left with three bad choices:
> a) Wait indefinitely for distro patches

Pick a better distro.  Seriously, if the distro you are paying for isn't
keeping it up to date and secure, what are you paying them for?  Seems
like an odd choice to stick with them given you have a contract saying
they need to abide by it...

good luck!

greg k-h

Re: [RFC idea] Kernel API Firewall (kaf): subsystem-level attack surface reduction for the post-AI-CVE era

[Nakashima Seiichi]

> 
> Pick a better distro.  Seriously, if the distro you are paying for
> isn't
> keeping it up to date and secure, what are you paying them for? 
> Seems
> like an odd choice to stick with them given you have a contract
> saying
> they need to abide by it...
> 
> good luck!
> 
> greg k-h


Thank you for your comment. Given the high volume of vulnerability-
related issues lately, I simply shared some ideas in the hope that they
might help with improvements.

Re: [RFC idea] Kernel API Firewall (kaf): subsystem-level attack surface reduction for the post-AI-CVE era

[hackman]

[-- Attachment #1: Type: text/plain, Size: 1316 bytes --]

The users can also use the livepatch kernel infrastructure for rapid patching.
A lot of these issues are solved with small and not very complex patches, that do come quite fast with the release of the CVEs. Converting a patch to a live patch is not that hard these days.

So the users(admins) actually have more than they need to protect them self.
On the other hand, if they want to directly disable certain kernel subsystems, they can build their custom kernel by basing it on the distro kernel they currently use.
So my argument here is that these knobs that you want to add to the kernel are already there. Just there is no runtime configuration for all of them, but there is build configuration for them.

Marian

Nov 6, 2026 2:07:59 p.m. Nakashima Seiichi <s-nakashima@kjb.biglobe.ne.jp>:

> 
>> 
>> Pick a better distro.  Seriously, if the distro you are paying for
>> isn't
>> keeping it up to date and secure, what are you paying them for? 
>> Seems
>> like an odd choice to stick with them given you have a contract
>> saying
>> they need to abide by it...
>> 
>> good luck!
>> 
>> greg k-h
> 
> 
> Thank you for your comment. Given the high volume of vulnerability-
> related issues lately, I simply shared some ideas in the hope that they
> might help with improvements.

[-- Attachment #2: Type: text/html, Size: 2454 bytes --]

Re: [RFC idea] Kernel API Firewall (kaf): subsystem-level attack surface reduction for the post-AI-CVE era

[Boris Lukashev]

[-- Attachment #1: Type: text/plain, Size: 1920 bytes --]

@Nakashima Seiichi: To be fair it's actually "pick a better kernel" such as
one with a security model starting at the execution and MMU layers since
the fundamental problem with doing this at higher-levels comes down to
mutable, type-confused, and improperly accessible memory (on-stack or via
alloc) atop which the rest of what you describe has to be built. Castles
built on sand with the added twist of ML tech adding grandfather worms
straight from Dune.

@Greg KH:  there is no practical choice for using anything but what's
prescribed by the vendor and contractually supported in the commercial
world (further complicated by binary blobs/device trees/intellectual
property concerns/etc). You cant ask the hotel to change the kiosk
distribution to a safer one in order to check you in despite them having
your PII and payment data running through it any more than the rest of us
despite your undeniable awareness of the threat involved. It would be far
more realistic and practical for the Linux Foundation to assign its
seasoned talent to work on downstream distributions of economic relevance
to its member entities than to swap out the OS' in the clustered engine of
today's economy.

-Boris

On Fri, Nov 6, 2026 at 2:07 PM Nakashima Seiichi <
s-nakashima@kjb.biglobe.ne.jp> wrote:

>
> >
> > Pick a better distro.  Seriously, if the distro you are paying for
> > isn't
> > keeping it up to date and secure, what are you paying them for?
> > Seems
> > like an odd choice to stick with them given you have a contract
> > saying
> > they need to abide by it...
> >
> > good luck!
> >
> > greg k-h
>
>
> Thank you for your comment. Given the high volume of vulnerability-
> related issues lately, I simply shared some ideas in the hope that they
> might help with improvements.
>


-- 
Boris Lukashev
Systems Architect
Semper Victus <https://www.sempervictus.com>

[-- Attachment #2: Type: text/html, Size: 2610 bytes --]

Re: [RFC idea] Kernel API Firewall (kaf): subsystem-level attack surface reduction for the post-AI-CVE era

[Nakashima Seiichi]

> @Nakashima Seiichi: To be fair it's actually "pick a better kernel"
> such as
> one with a security model starting at the execution and MMU layers
> since
> the fundamental problem with doing this at higher-levels comes down
> to
> mutable, type-confused, and improperly accessible memory (on-stack or
> via
> alloc) atop which the rest of what you describe has to be built.
> Castles
> built on sand with the added twist of ML tech adding grandfather
> worms
> straight from Dune.
> 
> @Greg KH:  there is no practical choice for using anything but what's
> prescribed by the vendor and contractually supported in the
> commercial
> world (further complicated by binary blobs/device trees/intellectual
> property concerns/etc). You cant ask the hotel to change the kiosk
> distribution to a safer one in order to check you in despite them
> having
> your PII and payment data running through it any more than the rest
> of us
> despite your undeniable awareness of the threat involved. It would be
> far
> more realistic and practical for the Linux Foundation to assign its
> seasoned talent to work on downstream distributions of economic
> relevance
> to its member entities than to swap out the OS' in the clustered
> engine of
> today's economy.
> 
> -Boris
> 

Thank you, Greg KH and Boris Lukashev, for your comments.

I am aware of options such as using the latest kernel or employing
tools like LivePatch. I also understand that programs execute in memory
and that those memory regions can be configured for various purposes.

In our actual production environment, we have a large number of virtual
machines running across many physical hosts, with numerous individual
applications operating on top of them. Simply applying kernel patches
in such an environment is a major undertaking.

My approach is straightforward: we handle network security using `ufw`
and web application security via a WAF. It occurred to me that if we
could use a "KAF" (Kernel API Firewall), we might be able to manage the
process of addressing and applying fixes in a more planned and
systematic way.

That said, I am not sure how difficult it would be to actually
implement such a KAF. I shared this idea simply because I thought it
could be a valuable solution if it were feasible.That is all.

Re: [RFC idea] Kernel API Firewall (kaf): subsystem-level attack surface reduction for the post-AI-CVE era

[Greg KH]

On Fri, Nov 06, 2026 at 04:00:48PM -0500, Boris Lukashev wrote:
> @Greg KH:  there is no practical choice for using anything but what's
> prescribed by the vendor and contractually supported in the commercial
> world (further complicated by binary blobs/device trees/intellectual
> property concerns/etc). You cant ask the hotel to change the kiosk
> distribution to a safer one in order to check you in despite them having
> your PII and payment data running through it any more than the rest of us
> despite your undeniable awareness of the threat involved. It would be far
> more realistic and practical for the Linux Foundation to assign its
> seasoned talent to work on downstream distributions of economic relevance
> to its member entities than to swap out the OS' in the clustered engine of
> today's economy.

So, it's not enough that the kernel developers and stable maintainers
provide a free feed of 75 fixes a day in a tested and released kernel,
and 55 documented CVE fixes a day, they then are required to, for free,
take those patches and integrate them into for-profit company's kernels
for them because that for-profit company doesn't want to pay for that
effort to meet the contractual requirements that their customers pay for
them to meet?

If you take the "pure numbers" point of view, that means that we should
do this only for Debian and Yocto as those distros hold the huge
majority of all of the server and embedded systems numbers in the world,
everything else is just a tiny percent.  Oh wait, the LF already does
this for you, for Yocto, and Debian is also free and up to date with all
of these security issues for you to rely on.

So again, why not hold the companies that you feel are worth paying for
this service, responsible for meeting their own self-defined
contractural requirements?  Given that the community is giving all of
this to them for free, it's odd that anyone would ask for us to do more
work than that, don't you agree?

greg k-h

Re: [RFC idea] Kernel API Firewall (kaf): subsystem-level attack surface reduction for the post-AI-CVE era

[Boris Lukashev]

[-- Attachment #1: Type: text/plain, Size: 5670 bytes --]

I try not to get into the politics involved so please don't put me in the
position of having to rebuke facile deflections predicated on evoking a
feeling shame in those of us managing the downstream effects by referencing
the nonexistent plight of overworked unpaid developers - devs are paid and
nobody at the top of the organization is taking a bus anywhere unless its a
shuttle between airport terminals connecting two first class flights.
That's an old and disingenuous argument which hasn't gotten any more
effective in the years its been made. Offhand we can look at the ongoing
convert proto_ops_bind callbacks situation: paid amazon employee so not
free, fixing regression in stable backports so not tested, and the rest of
the argument flies in its own face when 55 CVEs a day mean testing didn't
cover those previously (very naively) bringing the 75 fixes a day to 20 not
being for prior misses of which some are regressions themselves and some
fixes for the regressions. Linux maintenance isn't a gratis service done
out of the good of anyone's hearts for the world at large - as documented
here https://projects.propublica.org/nonprofits/organizations/460503801 it
takes in money, it pays people, and it participates in the commercial
ecosystem like any other vendor (producing profit as evidenced by a fair
deal of publications claiming 7f personal income for at least one of the
maintainers from the work - not exactly the image your stipulation seems
meant to evoke). There is nothing wrong with making money, it makes life
and enjoyment of it possible but please don't pretend there are noble and
altruistic motivations driving a commercial operation branding itself a
non-profit in 2026 - we live in an age when childrens cancer charities are
slush funds for politicians, its a thin veil at best. The GPL wall is still
used to prevent defense contractors and other innovators who harden linux
in a small closed space from taking that work commercial and directly
profitting from their forks despite upstream using non GPL code extracted
from LLMs; really puts the "care about security of the users" and "freedom"
premises into question. Finally, the ops engineer having to patch 10k
systems every 2d without losing revenue for the business takes home far
less than the maintainers but that person is the one who's job is on the
line/health getting trainwrecked when the patches themselves do not meet
muster/cause loss of revenue to the org. Mechanically, LF gets
compensated/early access to advanced LLMs from various providers, tools to
proactively find/remedy pathologies and classes of concern, and the
aforementioned contributions of cash and code from those same commercial
entities - that is monetary value which needs to come back as ROI to the
stake/shareholders of the companies providing it per the fiduciary
responsibility of executives signing off on the outflow, don't you agree?

To the point i was making before that unfortunate reiteration of what
industry already knows: the proposed approach isn't to send some heroic
contributors preloaded with tech debt into indentured corporate servitude
but to redirect commercial resources (however branded for legal purposes)
paid for by the revenue those downstream companies generate and put back
into LF as cash or tools to improve the products and services which they
sell.

-Boris

On Sat, Nov 7, 2026 at 7:04 AM Greg KH <gregkh@linuxfoundation.org> wrote:

> On Fri, Nov 06, 2026 at 04:00:48PM -0500, Boris Lukashev wrote:
> > @Greg KH:  there is no practical choice for using anything but what's
> > prescribed by the vendor and contractually supported in the commercial
> > world (further complicated by binary blobs/device trees/intellectual
> > property concerns/etc). You cant ask the hotel to change the kiosk
> > distribution to a safer one in order to check you in despite them having
> > your PII and payment data running through it any more than the rest of us
> > despite your undeniable awareness of the threat involved. It would be far
> > more realistic and practical for the Linux Foundation to assign its
> > seasoned talent to work on downstream distributions of economic relevance
> > to its member entities than to swap out the OS' in the clustered engine
> of
> > today's economy.
>
> So, it's not enough that the kernel developers and stable maintainers
> provide a free feed of 75 fixes a day in a tested and released kernel,
> and 55 documented CVE fixes a day, they then are required to, for free,
> take those patches and integrate them into for-profit company's kernels
> for them because that for-profit company doesn't want to pay for that
> effort to meet the contractual requirements that their customers pay for
> them to meet?
>
> If you take the "pure numbers" point of view, that means that we should
> do this only for Debian and Yocto as those distros hold the huge
> majority of all of the server and embedded systems numbers in the world,
> everything else is just a tiny percent.  Oh wait, the LF already does
> this for you, for Yocto, and Debian is also free and up to date with all
> of these security issues for you to rely on.
>
> So again, why not hold the companies that you feel are worth paying for
> this service, responsible for meeting their own self-defined
> contractural requirements?  Given that the community is giving all of
> this to them for free, it's odd that anyone would ask for us to do more
> work than that, don't you agree?
>
> greg k-h
>


-- 
Boris Lukashev
Systems Architect
Semper Victus <https://www.sempervictus.com>

[-- Attachment #2: Type: text/html, Size: 6512 bytes --]

Re: [RFC idea] Kernel API Firewall (kaf): subsystem-level attack surface reduction for the post-AI-CVE era

[John Johansen]

On 11/6/26 09:08, Greg KH wrote:
> On Fri, Nov 06, 2026 at 08:15:26PM +0900, Nakashima Seiichi wrote:
>> Users are left with three bad choices:
>> a) Wait indefinitely for distro patches
> 
> Pick a better distro.  Seriously, if the distro you are paying for isn't
> keeping it up to date and secure, what are you paying them for?  Seems

no argument there

> like an odd choice to stick with them given you have a contract saying
> they need to abide by it...
> 
the "wait for ever" is an exaggeration, at least on the Ubuntu side. There
is a new kernel every week, rebased on current upstream kernels.

Where it can take longer if you make the choice to stay on a kernel no
longer supported by upstream, and then you have to wait for some of the
patches to be backported.