@forest So how much does that improve the security of userns?

Depends on what modules are already loaded.

It improves it a fair bit, but unpriv userns is still shit.

I assume there is plenty of attack surface still exposed that normally isn't?

Yup. All turning off module autoloading does is make it so that attack surface area that's present in some obscure kernel module isn't always exploitable.

(If anyone can help)

Trying to mitigate CVE-2022-2590 with livepatch but I can't just hook the vulnerable function and make it return an error or it could result in the calling function triggering BUG(), so I've got to make it kill the process by force.

But do_exit() stopped being exported since 2021. And I haven't done any real kernel hacking in years.

I wonder what real kernel hacking is by your standards...

Something more serious than trivial kernel modules and the occasional addition of simple interfaces.

The fruits of my pointless labor:

#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/livepatch.h>

static int livepatch_ni_syscall(void)
{
	dump_stack();
	return -ENOSYS;
}

static void livepatch_exit_process(void)
{
	dump_stack();
	do_exit(SIGKILL);
}

static struct klp_func funcs[] = {
	{
		.old_name = "io_uring_setup",
		.new_func = livepatch_ni_syscall,
	}, {
		.old_name = "posix_cpu_timer_create",
		.new_func = livepatch_ni_syscall,
	}, {
		.old_name = "shmem_mfill_atomic_pte",
		.new_func = livepatch_exit_process,

Mitigates CVE-2022-2585, CVE-2022-2590, and CVE-2022-29582 for those too lazy to apply patches and upgrade.

Had to use do_exit() when hooking shmem_mfill_atomic_pte() because of elixir.bootlin.com/linux/latest/source/mm/shmem.c#L2341

if (!shmem_inode_acct_block(inode, 1)) {
	/*
	 * We may have got a page, returned -ENOENT triggering a retry,
	 * and now we find ourselves with -ENOMEM. Release the page, to
	 * avoid a BUG_ON in our caller.
	 */
	if (unlikely(*pagep)) {
		put_page(*pagep);
		*pagep = NULL;
	}
	return -ENOMEM;
}

Otherwise I'd just force it to return -ENOSYS, but I have kernel.panic_on_oops=1 so having the caller BUG_ON() would suck.

So... I'm just having it kill the process.

(This is yet another reason why distros should unset CONFIG_USERFAULTFD)

@nobody I second that thought

@J-- Interesting. So how far have you gotten yet?

Are you making progress though?

@J-- the name vaguely rings a bell

that's riot's isn't it?

@J-- Nice

ah, good, my brain isn't completely swiss cheese

@JourneymanGeek then which cheese is it?

@nobody well, I suspect its.. de brie

rather soft, and mushy

@JourneymanGeek Well, now I see where zombies came from

Just folks who liked cheese...

lol

On the bright side

@J-- what's a lifter?

I handed in my notice and my last day's the end of the month

so I'll get some decent sleep, and time to upskill while I look for another job

@J-- Lol lost track of this here. What does the virtualisation obfuscation compiler do? Create object code for the VM that the driver implements?

@J-- Ok, got that

So lifter is basically a bit akin to a disassembler for the obfuscated assembly?

So where do you get the lifter from? Write it yourself?

Wait, wouldn't you need a separate lifter for every flavor/version of the obfuscation? Or is the obfuscation used by the vanguard so well known that there already are lifters available for it?

I see

What's with @UndercoverDog suggesting lots of minor and incomplete edits to old, unanswered posts?

That's something I really need to pick up myself. As is, I think you know a lot more about RE than I do. :P

@J-- Do you have any exploit RE experience?

If I have find kernel oops from an interesting exploit in the wild, you want me to send you a copy of the kdump?