3 ms·
> MegaCli is still the ultimate cause strongly disagree! no kernel component should introduce memory corruption, and especially not in response to an ioctl fro
by munin 15y ago
> MegaCli is still the ultimate cause
strongly disagree! no kernel component should introduce memory corruption, and especially not in response to an ioctl from any user mode code. they say:
> Specifically, various offsets provided from userspace are used by the driver without any checks. If these offsets are maliciously chosen, the driver can be induced to write to arbitrary kernel memory
sure hope they patched that too!
- pmjordan 15y agosure hope they patched that too! The patch appears to discard the DMA flags coming from user space, and instead applies the ones that are correct given the kernel's knowledge of the buffer. But yes, this is ultimately a kernel bug - specifically one of the driver's userspace API.
- rwmj 15y agoBugs happen though. And these sort are old. I wrote a super [root] exploit for OS-9 which worked by tricking the GETSTAT call [equivalent of ioctl] for some driver to write its result to a random, unchecked place in memory. That was in 1992 / OS-9 2.4.
- munin 15y agobugs DO happen. the root cause is in the kernel component that deals with memory inappropriately though. user space should be free to blast whatever into kernel space via system calls and ioctl and rely on the operating system to not crash, and also for the kernel to continue enforcing the rules of the operating system. this is like saying "the root cause is Dan, who typed in a `drop tables. our solution is to take away Dans keyboard"