|
|
Log in / Subscribe / Register

killswitch for short-term emergency vulnerability mitigation

It seems that we are in for an extended period of the disclosure of vulnerabilities before fixes become available. One possible way of coping with this flood might be the killswitch proposal from Sasha Levin. In short, killswitch can immediately disable access to specific functionality in a running kernel, essentially blasting a vulnerable path (and its associated functionality) out of existence until a fix can be installed. "For most users, the cost of 'this socket family stops working for the day' is much smaller than the cost of running a known vulnerable kernel until the fix land."

to post comments

Shouldn’t this also prevent self-destruction?

Posted May 8, 2026 14:17 UTC (Fri) by songmaster (subscriber, #1748) [Link] (10 responses)

echo "engage killswitch_engage -1" \
        > /sys/kernel/security/killswitch/control
I’m not a kernel dev, but I didn’t see any obvious attempt in the code to detect such an attempt.

Shouldn’t this also prevent self-destruction?

Posted May 8, 2026 14:30 UTC (Fri) by NAR (subscriber, #1313) [Link]

Only the admin (root) can issue this command, so the wannabe hacker will get back an EPERM (or something like that).

Shouldn’t this also prevent self-destruction?

Posted May 8, 2026 14:57 UTC (Fri) by sashal (✭ supporter ✭, #81842) [Link] (8 responses)

The control file is writable only by root.

Why should it stop root from shooting itself in the foot?

Shouldn’t this also prevent self-destruction?

Posted May 8, 2026 15:11 UTC (Fri) by mb (subscriber, #50428) [Link] (6 responses)

Well, I'm not so sure about this feature.

I would prefer if we would continue go the route to restrict what root can do.
This patch is pretty much the opposite.
It cannot only be used to mitigate security problems, but also to create them.
I understand that root already has lots of ways to do this, but do we really want to add another one?

I see that this can be useful in certain scenarios, but I hope this will not be picked up as =y by general purpose distributions.

What about adding a KILLSWITCH_SYSCTL boolean option, so distributions can at least disable the runtime switch, if they want to provide a boot time kill switch?

Shouldn’t this also prevent self-destruction?

Posted May 8, 2026 15:36 UTC (Fri) by sashal (✭ supporter ✭, #81842) [Link] (5 responses)

Adding in lockdown support like Jon suggested would address this concern?

Shouldn’t this also prevent self-destruction?

Posted May 8, 2026 15:46 UTC (Fri) by mb (subscriber, #50428) [Link] (4 responses)

Yes, partially, and in addition to that:

What about a killswitch for the killswitch? A one-way switch that once written permanently disables the killswitch functionality.
Just so that admins can disable this feature permanently at boot, if they use distro kernels that ship it but do not want to have this feature.
I could live with that.

Having a root-feature that can override any kernel function is a *very* big hammer. I'd rather like to not have it.

Shouldn’t this also prevent self-destruction?

Posted May 8, 2026 16:11 UTC (Fri) by sashal (✭ supporter ✭, #81842) [Link] (3 responses)

> Having a root-feature that can override any kernel function is a *very* big hammer. I'd rather like to not have it.

We already have pretty much the same functionality with livepatch, bpf, or heck, the good old tracing infra. Lockdown is supposed to be the "killswitch" for any of these potentially self-harming things, no?

Shouldn’t this also prevent self-destruction?

Posted May 8, 2026 16:53 UTC (Fri) by mb (subscriber, #50428) [Link] (2 responses)

Yes, I know that we already have many of these things and now we are adding another one.
This is the wrong direction. We should reduce what root is able to do and reduce the attack surface of the kernel.

> Lockdown is supposed to be the "killswitch" for any of these potentially self-harming things, no?

Right. But is this really a practical solution? If I need one of these things, I have to enable all of them.
There is basically no use case for killswitch, livepatch and tracing on a desktop, but bpf is still useful. Can't use lockdown, and get a free livepatch/killswitch.

Shouldn’t this also prevent self-destruction?

Posted May 8, 2026 17:00 UTC (Fri) by sashal (✭ supporter ✭, #81842) [Link]

This sounds like you've listed another usecase for killswitch: use it to remove all the functionality you don't want, followed by killswitching ks_attr_open (or something like that) to disable killswitch itself :)

Shouldn’t this also prevent self-destruction?

Posted May 9, 2026 6:21 UTC (Sat) by pabs (subscriber, #43278) [Link]

livepatch is very useful on a desktop, I don't want to have to reboot for security updates their either.

Shouldn’t this also prevent self-destruction?

Posted May 8, 2026 19:29 UTC (Fri) by songmaster (subscriber, #1748) [Link]

If a cracker already has a permanent route to root installed in a Linux system and their vulnerability has just been discovered, they might killswitch the killswitch like this to prevent the sysadmins from disabling that entrance-route until they can find/install another way in.

nf_tables

Posted May 8, 2026 14:51 UTC (Fri) by 5fdb1f (guest, #156654) [Link] (3 responses)

The commit message casually mentions nf_tables among rarely used features. I was under the impression that they're the future and are used by most distributions even if you use the iptables command. So which is it?

nf_tables

Posted May 8, 2026 15:02 UTC (Fri) by sashal (✭ supporter ✭, #81842) [Link] (2 responses)

This is very usecase dependent. On my laptop (running debian), for example, nothing uses nf_tables right now.

Would some packages and usecases break if I we killswitch nf_tables? sure.

Would it affect my current day-to-day work? nope.

nf_tables

Posted May 9, 2026 11:54 UTC (Sat) by kleptog (subscriber, #1183) [Link] (1 responses)

Are you sure? I thought I didn't use nf_tables, but then I was wondering why iptables no longer had packet counts. Asking Copilot said I should check iptables:

$ iptables --version
iptables v1.8.10 (nf_tables)

It's a side-effect of the compatibility layer. So I was actually using nf_tables all along. Anyone using for example docker or libvirt since Debian 10+ is probably using it.

nf_tables

Posted May 9, 2026 13:03 UTC (Sat) by sashal (✭ supporter ✭, #81842) [Link]

So it's definitely installed and enabled on my laptop, however:

$ sudo nft list tables | wc -l
0
$ sudo nft list ruleset | wc -l
0

Is that not the LLM guy?

Posted May 8, 2026 14:53 UTC (Fri) by mirabilos (subscriber, #84359) [Link] (30 responses)

I hope that patch doesn’t introduce any new problems…

Is that not the LLM guy?

Posted May 8, 2026 15:17 UTC (Fri) by csamuel (✭ supporter ✭, #2624) [Link]

Jon has already spotted one issue (which will be addressed from the follow up): https://lwn.net/ml/all/87v7cz8cus.fsf@trenco.lwn.net/

Is that not the LLM guy?

Posted May 8, 2026 16:59 UTC (Fri) by Wol (subscriber, #4433) [Link] (28 responses)

> I hope that patch doesn’t introduce any new problems…

Read the patch. It does!

It's quite open about it - "this is a footgun - BE CAREFUL!"

But as it says, the purpose is to blow a vulnerable path out of existence. It's a bomb, with a blast radius. It's down to the user to make sure it doesn't blow other important stuff out of existence at the same time.

Cheers,
Wol

Is that not the LLM guy?

Posted May 8, 2026 18:35 UTC (Fri) by mirabilos (subscriber, #84359) [Link] (27 responses)

I meant, besides the obvious. (Turns out it does, see the other comment. Who knows what else. Why Levin is still not persona nōn grata, I don’t get.)

Is that not the LLM guy?

Posted May 8, 2026 18:41 UTC (Fri) by rahulsundaram (subscriber, #21946) [Link] (19 responses)

Other people clearly don't share your views on LLM. Not confusing really especially since https://docs.kernel.org/process/coding-assistants.html clearly documents the views of the project itself

Is that not the LLM guy?

Posted May 8, 2026 19:37 UTC (Fri) by IanKelling (subscriber, #89418) [Link] (5 responses)

(mostly sarcasm) Confusion abounds. Is there a correlation between the LLM assistance in this patch and the KILL terminology in this patch? Would a less amoral / llm unassisted contributor have named it differently?

Is that not the LLM guy?

Posted May 11, 2026 1:03 UTC (Mon) by cypherpunks2 (guest, #152408) [Link] (4 responses)

Is there actually a problem with the name killswitch? I didn't see any criticism of that on LKML.

Is that not the LLM guy?

Posted May 13, 2026 0:25 UTC (Wed) by IanKelling (subscriber, #89418) [Link] (3 responses)

Use your own mind and emotions! To have an LLM listed as co-author for a function called killX, where X is just about anything, that seems pretty ripe for a joke at least. I said "mostly", well, because humans doing killing of other living beings is an ordinary fact of life, automated killing using llms seems likely be an inhumane horror worthy of global attention, so, LLM listed as coauthor/"Assisted-by" on this seems maybe just a little thoughtless or distasteful in a strange way, which also seems to be one of the biggest problems with LLM generated content in general.

Is that not the LLM guy?

Posted May 13, 2026 0:48 UTC (Wed) by sashal (✭ supporter ✭, #81842) [Link] (1 responses)

Some folks on this thread got it, but in case you missed it, it was a reference to https://en.wikipedia.org/wiki/Killswitch_Engage

Is that not the LLM guy?

Posted May 13, 2026 17:21 UTC (Wed) by IanKelling (subscriber, #89418) [Link]

I missed it. Thanks for clarifying and please excuse my wondering from the peanut gallery, I'm happy to learn it was just my imagination.

Is that not the LLM guy?

Posted May 13, 2026 5:17 UTC (Wed) by zdzichu (subscriber, #17118) [Link]

Is Poe Law active here?

Is that not the LLM guy?

Posted May 8, 2026 21:06 UTC (Fri) by mirabilos (subscriber, #84359) [Link] (12 responses)

Oh, but that document says…

> * All code must be compatible with GPL-2.0-only

… which clearly excludes LLM-regurgitated slop.

After all, it is a plagiate of other works under conflicting licences and, in ipso, unlicenced.

Is that not the LLM guy?

Posted May 8, 2026 22:28 UTC (Fri) by intelfx (subscriber, #130118) [Link] (9 responses)

>> * All code must be compatible with GPL-2.0-only
> … which clearly excludes LLM-regurgitated slop.
> After all, it is a plagiate of other works under conflicting licences and, in ipso, unlicenced.

It must be noted that this (both the premise and the conclusion you made from this premise) is your opinion only, which is not necessarily shared neither by the majority of the community, nor by the law and/or legal precedent so far.

Is that not the LLM guy?

Posted May 8, 2026 23:15 UTC (Fri) by mirabilos (subscriber, #84359) [Link] (8 responses)

At least the second half is confirmed by the copyright office of the USA.

Is that not the LLM guy?

Posted May 9, 2026 0:56 UTC (Sat) by intelfx (subscriber, #130118) [Link]

> At least the second half is confirmed by the copyright office of the USA.

Which one specifically? And [citation needed].

Is that not the LLM guy?

Posted May 11, 2026 20:13 UTC (Mon) by JoeBuck (subscriber, #2330) [Link] (6 responses)

Are you sure? The US Copyright Offfice has said that AI generated works aren't protected by copyright, which basically means public domain. So if a patch is partly AI-generated and partly human-written, and the human contributor wants to use GPL 2.0, then the combined work is GPL plus public domain code. So, legal to distribute under the GPL.

Of course, IANAL.

Is that not the LLM guy?

Posted May 11, 2026 20:28 UTC (Mon) by farnz (subscriber, #17727) [Link] (1 responses)

Have you a link for this?

The last I saw, the US Copyright Office had said that the AI cannot be a copyright holder on an AI generated work, and thus that where the attempt at registering a work explicitly states that the AI is the sole author, there is no copyright.

However, this does not mean that AI generated works aren't protected by copyright; where the AI is used as a tool by a human, there's room for the human input to be enough to reach the bar needed to make the work protected by copyright.

It's essentially, in law, the same position as Emacs; if you claim that the work is purely produced by Emacs, then it can't be protected by copyright (since Emacs is a tool, not a human), but if you claim that the work is produced with Emacs driven by a human being, the resulting work can be protected by copyright. Substitute "AI" for "Emacs", and you get the answer the US Copyright Office came to, last time I looked.

Is that not the LLM guy?

Posted May 11, 2026 20:55 UTC (Mon) by mirabilos (subscriber, #84359) [Link]

> The last I saw, the US Copyright Office had said that the AI cannot be a
> copyright holder on an AI generated work

That, yes (that much is obvious, it has to be human creativity), but they did NOT rule out that copyright from authors of “training data” applies.

Is that not the LLM guy?

Posted May 11, 2026 20:30 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link] (3 responses)

It's likely that we'll see the protection applied to the _prompt_.

So if you ask the LLM to "fix this issue", then the result is not going to be copyrightable. But if you provide a detailed step-by-step spec for the fix, the result might be protected.

Is that not the LLM guy?

Posted May 12, 2026 10:17 UTC (Tue) by stijn (subscriber, #570) [Link] (2 responses)

Prompts do not deterministically lead to the same result every time, so the detailed step-by-step spec is not a spec; I have doubts that the code resulted from the prompt is thus copyrightable. The rules in this new world are very unclear to me.

Is that not the LLM guy?

Posted May 12, 2026 19:25 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]

Sure. And in photography you'll never get two identical pictures. Yet you can still copyright specific arrangements of items in a photo.

This is going to be a case-by-case issue.

Is that not the LLM guy?

Posted May 12, 2026 21:27 UTC (Tue) by rgmoore (✭ supporter ✭, #75) [Link]

The question is whether the LLM is the thing doing the work or if it's a tool being used by a human. Deterministic results aren't necessary to show human creativity was involved. Plenty of artists use techniques that incorporate some degree of randomness, like Jackson Pollack's splatter paintings or works including found objects. As long as the artist is making substantial creative choices, the work still qualifies for copyright. The same thing should be true of using an LLM as a programming tool. If the programmer is providing the ideas and the LLM is only handling implementation details, there would probably be enough creativity to qualify.

Is that not the LLM guy?

Posted May 9, 2026 13:19 UTC (Sat) by jejb (subscriber, #6654) [Link]

> > * All code must be compatible with GPL-2.0-only
>
> … which clearly excludes LLM-regurgitated slop.
>
> After all, it is a plagiate of other works under conflicting licences and, in ipso, unlicenced.

Well, that's a whole load of confused statements. As long as a model output isn't derivative of its training data (as court cases have so far mostly confirmed) the US copyright office maintains that machine authored code is uncopyrightable. So that means public domain and combinable with any licence including GPL-2.0.

Is that not the LLM guy?

Posted May 11, 2026 14:49 UTC (Mon) by rahulsundaram (subscriber, #21946) [Link]

> * All code must be compatible with GPL-2.0-only

>> … which clearly excludes LLM-regurgitated slop.

Does it? I understand you wish it was so but so far there hasn't been any clear rulings that have indicated that. If anything it looks like the opposite situation in practice. Refer to https://lwn.net/Articles/1061534/

Is that not the LLM guy?

Posted May 11, 2026 1:09 UTC (Mon) by cypherpunks2 (guest, #152408) [Link] (6 responses)

I hate vibe coded slop as much as the next guy, but this kind of patch seems simple enough that an LLM would do well at it and it wouldn't be a nightmare to review or maintain. I would never trust a filesystem driver or any complex parser in the kernel written by an LLM but this is the sort of things even I was able to do when I was completely new to kernel development (although in my case it was just support of dynamically disabling individual syscalls for hardening - this was before mode 2 seccomp), so I'm sure an LLM could do something equally simple too, if this patch was written with LLM assistance.

Is that not the LLM guy?

Posted May 11, 2026 12:58 UTC (Mon) by mirabilos (subscriber, #84359) [Link] (5 responses)

cypherpunks2 wrote:

“I hate the Torment Nexus as much as the next guy, but this kind of activity seems simple enough that a Torment Nexus would be suitable, and it would not be a nightmare for the person operating the Torment Nexus. I would never trust a Torment Nexus to be used on my important filesystems, but to operate a Torment Nexus is the sort of thing even I was able to do…”

Respect?

Posted May 11, 2026 16:31 UTC (Mon) by karath (subscriber, #19025) [Link] (3 responses)

When I read this kind of comment, I feel that the author is accusing me of being a torturer.

LLMs should not get a free pass just because they are new and shiny.
* Some of the LLM creators appear to have stolen copyrighted materials (by downloading torrents of copyrighted materials that were not freely available). I would love to see one or more of those culprits bankrupted after being found guilty.
* Many of the LLM creators or their agents have ignored robots.txt and brought the servers of freely available copyrighted materials to their knees (and non copyrighted material too). It seems that none of the culprits will face any noticeable consequences.
* Some LLM creators have fed so many duplicated copies of copyrighted materials into their training that, with careful prompting, the LLM can regurgitate derivative material. However some of that prompting likely would be considered entrapment if done by police authorities to a human.
* Many people believe that LLMs deprive us all of reasonably priced water and/or electricity and that they create massive pollution. Honestly, I’m sceptical of many of these claims. I believe that there is massive overbuilding of datacentres, however it’s not clear that these datacenters are all built for AI. Much of the overbuilding seems to be speculative by 3rd parties that hope to get AI or cloud customers.
* Many people worry that AI will take their job, and I think that some will. However the consensus in the thoughtful press seems to be that the current wave of redundancies is driven by the consequences of overhiring during the COVID period. Of course, CEOs would prefer to have it known that it was AI rather than their mismanagement,

On the other hand, the only case ruling on the copyright status of LLM output that I know about seems to have carefully crafted to state that the specific LLM was not capable being a copyright holder, while allowing that a future tool might be.

Governments and courts in Europe, China, and the USA, largely seem to support the concept that the output of an LLM should be held to the same burden of proof for copyright infringement as a human person. That is: can the output be shown to infringe the expression of a specific work rather than the concepts and ideas.

In summary, I’d request that the virulently anti-LLM commenters treat others with respect and specifically not tag me as a monster because I start from a different place than you.

LLMs don’t respect anything either

Posted May 14, 2026 0:18 UTC (Thu) by mirabilos (subscriber, #84359) [Link] (2 responses)

Since you ride so much on the copyright part of this:

“whenever the legal status of LLM training data is brought up I can't help but think of Aaron Swartz and how he was treated like he did the heist of the decade for trying to release some academic papers to the public”
-- https://fedi.catto.garden/objects/4f4cb118-6231-485c-9d2d...

“I'm genuinely astonished how many defenses of LLM contributions are a flat "you can't enforce this and you can't actually stop us". Just completely steamrolling past consent and comfort and forcing themselves on people who don't want them. Feels like some serious masks-off kind of shit.”
-- https://social.treehouse.systems/@TheEntity/1164994313517...

***It’s stolen, Jim.***

That is, if the racism, land grabs, polluted water, higher power bills, creating an addicted population that can't think, pollution from building new power plants and data centres, water grabs (“Project Excalibur” et al.), exploitation of humans in the global south, etc. don’t already get to you.

LLMs don’t respect anything either

Posted May 14, 2026 9:23 UTC (Thu) by kleptog (subscriber, #1183) [Link]

A lot of people still hold that what happened to Aaron Swart was wrong. Even later Supreme Court rulings (van Buren vs US (2021)) agree that misusing legitimate access to resources should not be considered a federal crime.

But of course, Congress had their chance to deal with the problem and they didn't.

The world has changed, it isn't 2011 anymore.

LLMs don’t respect anything either

Posted May 15, 2026 17:54 UTC (Fri) by cypherpunks2 (guest, #152408) [Link]

If you presuppose that LLMs are evil, then of course you won't be able to understand why someone might reference "responsible use of LLMs" when after all there's no such thing as responsible use of evil. But they are not fundamentally evil, no more than the transistor is at least.

There is a lot wrong with the use of LLMs and the companies behind many popular LLMs that is valid to criticize but it seems like you're against the technology itself. There's no need to bring things like racism or exploitation (which one could say is associated with <i>any</i> computer technology) when there are valid criticisms of its use.

Neural networks (of which LLMs are a subset) have a great amount of good use. They can simulate protein confirmations with high accuracy and can be used for improving medication and curing disease. They can be used to detect cancer by analyzing medical images. They can scan PRs to find vulnerabilities before they get merged that would otherwise be exploited by genuinely evil state actors (NSA, GRU etc). They can assist people speaking underrepresented languages to communicate better with other cultures.

But they can also be used to trick people into forming parasocial relationships. They can be used to spread customized misinformation. They can be used to target people for military strikes or for surveillance. They can be used to flood art sites with regurgitated low-effort slop. And of course in their insatiable need for information, they can DDoS websites with their spiders as they try to find new training material. But "assist in generating a patch and review it" is not evil. It's responsible, depending on the quality (and ease of maintainability) of the patch itself.

Is that not the LLM guy?

Posted May 15, 2026 19:07 UTC (Fri) by cypherpunks2 (guest, #152408) [Link]

> but to operate a Torment Nexus is the sort of thing even I was able to do…

To be clear, I didn't mean that I used an LLM. I meant that it was something that I, at the time new to kernel development, could do on my own without "vibe coding". Thus if a newbie could do it without an LLM, surely an expert with an LLM could do it just fine without running into the usual slop problems that happen when you ask one "make a patch that does $ill_defined_vaguely_worded_thing kthx".

The nice thing about neural networks is that, once the hardware is built, the only continuous resource they require is power, and power can be supplied by renewable energy. After the AI bubble bursts, I suspect many of the surviving companies that were previously disregarding ethics in favor of aggressive competition will start switching to renewable energy in order to get contracts from companies that want "green" resources.

Do we really want more runtime patching?

Posted May 8, 2026 15:47 UTC (Fri) by MarcB (subscriber, #101804) [Link] (5 responses)

For servers and other "well defined systems", disabling modules, after all the needed ones are loaded, seems like a better choice.

This would also obviously clash with lockdown, but it might make sense for systems that truly need dynamic module loading.

I also wonder why something like AF_ALG is even enabled on any non-hardware-specific kernel. Absent old crypto accelerators, everything it does can be done equally well (or better) in user space.

Do we really want more runtime patching?

Posted May 8, 2026 17:42 UTC (Fri) by gus3 (guest, #61103) [Link] (2 responses)

> For servers and other "well defined systems", disabling modules, after all the needed ones are loaded, seems like a better choice.

Not just disable modules. Unmount them as well.

There are more options than just the usual ones that you read about.

Do we really want more runtime patching?

Posted May 8, 2026 18:43 UTC (Fri) by MarcB (subscriber, #101804) [Link] (1 responses)

With disabling modules, I mean /sbin/sysctl -w kernel.modules_disabled = 1, as soon as all relevant modules are loaded at boot.

For what it's worth, we now reconfigured some test systems that way. We had to explicitly load some modules early (before, they were loaded on demand). It seems viable, at least in a virtualized environment.

Do we really want more runtime patching?

Posted May 9, 2026 5:24 UTC (Sat) by PlaguedByPenguins (subscriber, #3577) [Link]

FWIW our HPC systems have disabled module loads for years. maybe a decade.
# no more module loads...
echo 1 > /proc/sys/kernel/modules_disabled

# there's also no point in khelper calling out to modprobe
echo > /proc/sys/kernel/modprobe

Do we really want more runtime patching?

Posted May 8, 2026 20:54 UTC (Fri) by DemiMarie (subscriber, #164188) [Link] (1 responses)

Lockdown could be preserved by creating an allowlist of safe patches.

Do we really want more runtime patching?

Posted May 11, 2026 0:55 UTC (Mon) by cypherpunks2 (guest, #152408) [Link]

There's no such thing as a list of "safe patches". You don't know what functions need to be disabled until a new vulnerability is made public.

Lockdown is preserved simply by disabling killswitch when lockdown is enabled.

I see what you did there

Posted May 8, 2026 16:44 UTC (Fri) by intelfx (subscriber, #130118) [Link]

> int killswitch_engage(const char *symbol, long retval)

Nice. :-)

Containers

Posted May 8, 2026 19:04 UTC (Fri) by npws (subscriber, #168248) [Link]

It seems an obviously useful feature would be to prevent unpriviledged users from even load things like xfrm, esp and whatever was required for the last exploit. I realize this is most likely done to support containers, but well, I guess those are less commonly used than, let's say, nf_tables.

New times requires new ideas

Posted May 8, 2026 19:16 UTC (Fri) by cyperpunks (subscriber, #39406) [Link]

It seems clear the modern times with AI and fast development in general requires a new, fresh approach on secuirty and how softtware is deployed and maintained.

The role of distribution is now opposite of what it was: for years it has been to provide as much software and features as possible to users, these
days the core of distribution work is to remove and disable features to create a sane and maintainable set of packages.

No flags?

Posted May 9, 2026 2:35 UTC (Sat) by edgewood (subscriber, #1123) [Link] (1 responses)

Aren't kernel APIs supposed to have flags arguments?

No flags?

Posted May 11, 2026 8:00 UTC (Mon) by cypherpunks2 (guest, #152408) [Link]

No, that's new syscalls. Internal kernel functions can use whatever prototype they want.

"Breaking" kernelspace is not a problem because Linus can just demand that all callers to adapt to any change to the API.

Potential for attacker misuse

Posted May 9, 2026 16:03 UTC (Sat) by iabervon (subscriber, #722) [Link]

This seems worryingly easy to misuse if you've got any sort of confused deputy problem with a CAP_SYS_ADMIN program or a vulnerability that could substitute a struct file_operations or call its write member. It's not directly a problem, but it does seem like it would make a lot of defense-in-depth measures ineffective if you can just make "capable()" return 1 unconditionally for a little while with relatively little complexity.

I think it would be a lot safer to have something that makes all of a struct file_operations return ENOSYS, and similar for other kinds of object, where the killed functionality is a coherent unit with defined behavior for not being present.

But we already have fault injection

Posted May 11, 2026 5:43 UTC (Mon) by lorddoskias (guest, #95746) [Link]

So 800+ lines to duplicate what fault injection is already doing rather than spending time actually assessing current state of play and utilising/adapting the existing infrastructure...


Copyright © 2026, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds