Harshad,
On 6/5/20 10:40 AM, harshad shirwadkar wrote:
> I see. But my worry is that if we don't check for bounds in the kernel
> in this case, a non-root user who has access to any block device (even
> a simple loop device) can make the kernel go out of memory.
> ---
> ...
> int main(int argc, char *argv[])
> {
> struct blk_user_trace_setup buts;
> int fd;
> int ret;
>
> fd = open(argv[1], O_RDONLY|O_NONBLOCK);
>
> memset(&buts, 0, sizeof(buts));
> buts.buf_size = ~0;
> buts.buf_nr = 1;
> buts.act_mask = 65535;
> return ioctl(fd, BLKTRACESETUP, &buts);
> }
> ---
>
> I understand that introducing artificial hard-coded limits is probably
> not the best approach. However, not having a reasonable sanity
> checking on the IOCTL arguments, especially when the IOCTL itself
> doesn't require any special capability checks and the kernel uses
> those arguments almost as-is for allocating memory seems like a
> vulnerability that attackers can exploit.
Yes this is a problem and needs to be fixed with keeping the backward
compatibility as per pointed out by Bart.
I'm not aware of the applications (apart from blktrace-blkparse
userspace tools) which implement block trace userspace interface,
can you please point me to the application ?
If so those needs to be fixed also than imposing hard limits in kernel.
