Hector Martin

having a tough time explaining people that no, even if there's a component referred to as a "driver" inside, a piece of userspace software can not ultimately be at fault for a kernel panic

Now I feel compelled to try and prove that wrong somehow. Though all the obvious ideas start with mmap /dev/kmem...

yeah, that's a potential caveat, but you'd pretty much have to be deliberately trying to fuck shit up

I _have_ fucked shit up by mapping /dev/kmem (on an RPi), but at that point I was getting exactly what I was asking for

/dev/mem too. Also, say hi to iopl(2). Then there's kexec. You can also make PID 1 exit with various shenanigans. Or just load a broken kernel module.

yeah, if you really try you can come up with all sorts of ways to do it, sure here, the issue is "the machine reboots", so you could just straight-up write 'b' to /proc/sysrq-trigger if you had the right perms

but this is running as a user whose only significant privilege is membership in the video group, and the allegation is "the new builds of the userspace video-transcode acceleration driver are making the machine reboot" (the driver's source has not changed in the new builds)