Dangerous interrupts
The malicious user has to first get the malicious code into kernel space somehow. User and kernel address spaces often look contiguous under linux and various unixes, but user space isn't mapped into kernel space, and vice versa. Some variations of Unix (the Masscomp system, as I recall) made this more explicit by having user space and kernel space start at 0x00000000. So, that's the first problem: code at 0x0804890c (or where ever) writeable by the user doesn't exist in the kernel's address space.

Secondly, the malicious user would have to have the ability to change the interrupt vector. This vector conceptually could live in either kernel or user space, but probably resides in kernel space. If the interrupt vector resides in kernel space, the user doesn't have write access.  If the interrupt vector resides in user space, it's marked read-only, and the addresses in it point to code in kernel space. Which is why problem (1) above for the malicious user exists.