On Fri, May 08, 2026 at 05:47:04PM -0400, Sasha Levin wrote: > On Fri, May 08, 2026 at 01:56:30PM -0700, Andrew Morton wrote: > > On Thu, 7 May 2026 03:05:45 -0400 Sasha Levin <[email protected]> wrote: > > > > > When a (security) issue goes public, fleets stay exposed until a patched > > > kernel > > > is built, distributed, and rebooted into. > > > > > > For many such issues the simplest mitigation is to stop calling the buggy > > > function. Killswitch provides that. An admin writes: > > > > > > echo "engage af_alg_sendmsg -1" \ > > > > /sys/kernel/security/killswitch/control > > > > It certainly sounds useful, but what would I know. How do we hunt down > > suitable operations people (aka "target audience") to find out how > > useful this is to them? > > I'm not entierly sure here... If folks have suggestions on folks to loop in, > that'll be great!
I work with these issues at Meta, and this approach would address a real need we have. While livepatch could theoretically solve this problem, it's less suited for rapid mitigation for a couple of reasons: 1) Livepatch rollout is inherently slower due to the blast radius if a bug exists in the livepatch mechanism itself. 2) It's common to run hundreds of different kernel versions across a fleet. Since livepatch is kernel-specific, a single CVE suddenly requires building and deploying hundreds of individual livepatches— far less practical than a simple sysfs write.
