linux-kernel - Re: [PATCH v2] usb: devio: Add ioctl to disallow detaching kernel USB drivers.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 25 Jan 2016 09:39:43 +0100
From:	Bjørn Mork <bjorn@...k.no>
To:	Emilio López <emilio.lopez@...labora.co.uk>
Cc:	gregkh@...uxfoundation.org, stern@...land.harvard.edu,
	kborer@...il.com, k.opasiak@...sung.com, reillyg@...omium.org,
	keescook@...omium.org, linux-api@...r.kernel.org,
	linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org,
	jorgelo@...omium.org, dan.carpenter@...cle.com
Subject: Re: [PATCH v2] usb: devio: Add ioctl to disallow detaching kernel USB drivers.

Emilio López <emilio.lopez@...labora.co.uk> writes:

>>> diff --git a/include/uapi/linux/usbdevice_fs.h b/include/uapi/linux/usbdevice_fs.h
>>> index 019ba1e..9abcb34 100644
>>> --- a/include/uapi/linux/usbdevice_fs.h
>>> +++ b/include/uapi/linux/usbdevice_fs.h
>>> @@ -154,6 +154,10 @@ struct usbdevfs_streams {
>>>   	unsigned char eps[0];
>>>   };
>>>
>>> +struct usbdevfs_drop_privs {
>>> +	unsigned long interface_allowed_mask;
>>> +};
>>> +
>>
>> "unsigned long" isn't a very good choice here, is it?
>
> I went with a type matching ifclaimed on struct usb_dev_state to keep
> the limit the same, but I guess it's not the best idea for an ioctl. I
> can switch it to __u32, keeping the runtime check above as is, or use
> __u64. Which one would you prefer?

I don't feel much like an expert here, but I can certainly make up an
opinion anyway :)

Since 64bits kernels allow usb devio with interface numbers up to 63, I
guess you need __u64 to avoid limiting the range?  Limiting will create
all sorts of followup problems, so it's definitely easiest to just go
with __u64.



Bjørn