On Thu, May 07, 2026 at 03:05:45AM -0400, Sasha Levin 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
>
> After this, af_alg_sendmsg() returns -EPERM on every call without
> running its body. The mitigation takes effect immediately, and is dropped on
> the next reboot.
>
> A lot of recent kernel issues sit in code paths most installs only have
> enabled
> to support a relative minority of users: AF_ALG, ksmbd, nf_tables, vsock,
> ax25,
> and friends.
>
> 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.
>
> Assisted-by: Claude:claude-opus-4-7
> Signed-off-by: Sasha Levin <[email protected]>
This is kind of funny, but understandable. Odds are a distro would want
to pick this up so that they can enable this for when their kernel
updates do not get out to users quick enough.
One question:
> +struct ks_attr {
> + struct list_head list;
> + struct kprobe kp;
> + atomic_long_t retval;
Why is this an atomic value? Shouldn't it be whatever the userspace
return type is?
> + /* false once disengaged; per-fn file ops then return -EIDRM. */
> + bool engaged;
> + unsigned long __percpu *hits;
> + struct dentry *dir;
> + /* engaged_list holds one ref; each open per-fn fd holds one. */
> + refcount_t refcnt;
Why is a refcnt needed? Why not use a kref instead?
thanks,
greg k-h
