If Kernel Lockdown is enabled, a zero-day exploit is required to bypass module restrictions without a reboot.
Unfortunately, threat actors tend to have a stash of them and the initial entry vector often involves one (container or browser sandbox escape), and once you have that, you are in ring 0 already and one flipped bit away from loading the module.
The Linux kernel is not really an effective privilege boundary.
Once you have memory write as ring0, all protections are dubious at best.
Why bother loading a module when you can inject code into any function you want.
The encrypted page memory manager hardware in some ancient Sun systems prevented a lot of these context isolation problems. However, the modern IT landscape chose consumer grade processor architecture and bodged GPUs as the cloud infrastructure foundation.
Thus, there currently is economic inertia entrenching vulnerable system design. I don't think there is a company large enough to change the situation anytime soon, as the market has spoken. =3
Rule #3: popularity is not an indication of utility.
Or only allow signed kernel modules. Aka secure boot.
This doesn't solve all vectors but afaics this will prevent non signed modules from loading.
echo 1 > /proc/sys/kernel/modules_disabled
Which is supposed to block dynamic loading modules until a reboot.
It would be interesting if the PoC can get around that trick too. =3