Dirty-frag mitigation: Usage of kernel.modules_disabled causes boot to fail

As part of the dirty-frag mitigation I tried to use the parameter kernel.modules_disabled=1 into a .conf file and put it in the directory /etc/sysctl.d/. This will disable loading of kernel modules at run time. Thus it will eliminate all the cases similar to dirty-frag. This is because the modules for IPv4 IPSec as well as IPv6 IPSec are not loaded by default into the kernel in EOS. Unless off course EOS has been configured to start a VPN connection at boot.

Setting kernel.modules_disabled=1 is apparently a well known linux hardening setting. The problem is that this setting disables the loading of the Kernel module responsible for FAT/VFAT/NTFS file system. I am using GRUB2 with the ESP partition, i.e. /boot/efi mounted as a VFAT file system. Setting this value causes an issue during boot. I get the error message

FAILED: Failed to mount /boot/efi
see systemctl status boot-efi.mount
Depend: Dependency fialed for Local file-system

So when I ran the command systemctl status boot-efi.mount. The error message that was displayed while trying to mount the boot-efi service was

mount: /boot/efi: unknown file system type `vfat`

This can only occur if the kernel module for FAT/VFAT/NTFS file system could not be loaded. Removing the entry kernel.modules_disabled=1 caused the error to go away.

So how do I prevent the kernel setting kernel.modules_disabled to come into effect so early in the boot process? I would prefer that this setting is applied once the boot process is completed but before the Display Manager/Login prompt on TTY is displayed.

Reference: Another vulnerability that gives root access: dirty-frag

The best mitigation for Dirty Harry Frag: install the latest patched kernels

Why are you trying to mitigate in the first place?

I’m guessing you aren’t using EOS on production work related systems (because, honestly, you probably shouldn’t), so I’m guessing it’s a home personal computer. Is it shared with other people?

Usually you only need to care about independently and manually mitigating RCE vulnerabilities, not local ones. As long as you are otherwise using your system with sanity of course…

The latest Linux mainline kernel in Arch repos 7.0.3.arch1-2. The patch has not been released to general public.

The latest Linux LTS kernel in Arch repos is 6.18.26-2. I do not think that it is patched too.

Also I would like to keep this hardening setting enabled. It would obviate similar types of problems.

6.18.28-1 is patched. It’s already in core repo.

The latest LTS is 6.18.28-1 and that has been patched. The default kernel is in testing with the patch.