A new CVE with some serious bite has been made public knowledge: https://copy.fail/
tl;dr can use logic bug in kernel module algif_aead to modify memory pages - the example given is running su as non root - however this could easily affect any other memory mapped file (e.g. /etc/shadow)
i note in our linuxkit VMs - using kernel image linuxkit/kernel:6.6.71 that the particular kernel config flag in question (CONFIG_CRYPTO_USER_API) is compiled directly into the kernel:
my-linuxkit-vm:~# zcat /proc/config.gz | grep CONFIG_CRYPTO_USER_API
CONFIG_CRYPTO_USER_API=y
and
so we cannot use the immediate mitigation of denylisting the algif_aead module.
the "true" fix is at torvalds/linux@a664bf3
is there any effort currently in place to fix this?
I can get a MWE later today.
For us, most of our VMs are heavily locked down, so we're partially protected by dropped CAPs, razor thin containers, etc.
A new CVE with some serious bite has been made public knowledge: https://copy.fail/
tl;dr can use logic bug in kernel module
algif_aeadto modify memory pages - the example given is running su as non root - however this could easily affect any other memory mapped file (e.g./etc/shadow)i note in our linuxkit VMs - using kernel image
linuxkit/kernel:6.6.71that the particular kernel config flag in question (CONFIG_CRYPTO_USER_API) is compiled directly into the kernel:and
linuxkit/kernel/6.6.x/config-x86_64
Line 4615 in 3bf33c3
so we cannot use the immediate mitigation of denylisting the
algif_aeadmodule.the "true" fix is at torvalds/linux@a664bf3
is there any effort currently in place to fix this?
I can get a MWE later today.
For us, most of our VMs are heavily locked down, so we're partially protected by dropped CAPs, razor thin containers, etc.