linux-kernel - Re: [PATCH 0/1] Bluetooth: hidp: Add support for hidraw HIDIOCGFEATURE and HIDIOCSFEATURE

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] [day] [month] [year] [list]

Message-ID: <4C16163C.4080606@signal11.us>
Date:	Mon, 14 Jun 2010 07:45:00 -0400
From:	Alan Ott <alan@...nal11.us>
To:	Marcel Holtmann <marcel@...tmann.org>,
	"David S. Miller" <davem@...emloft.net>,
	Jiri Kosina <jkosina@...e.cz>,
	Michael Poole <mdpoole@...ilus.org>,
	Bastien Nocera <hadess@...ess.net>,
	Eric Dumazet <eric.dumazet@...il.com>,
	linux-bluetooth@...r.kernel.org, linux-kernel@...r.kernel.org,
	netdev@...r.kernel.org
Subject: Re: [PATCH 0/1] Bluetooth: hidp: Add support for hidraw HIDIOCGFEATURE  and HIDIOCSFEATURE

On 06/13/2010 06:18 PM, Alan Ott wrote:
> 3. A blocking, synchronous GET_REPORT transfer was easy when I 
> implemented this for USB because data is both sent and received as 
> part of a single control transfer. Because of the nature of Bluetooth 
> however, where it is viewed more as an asynchronous network device, 
> and with hidraw allowing multiple handles to a single device to exist, 
> there could be a race when two handles call the hidp_get_raw_report() 
> function concurrently, requesting the same report. I've convinced 
> myself that this is not a problem, because since both callers 
> requested the same report, the worst that could happen is that one 
> could get a report which is slightly out of date.
>
> Consider the following case:
>     1. Client 1 requests report (Userspace call to HIDIOCGFEATURE)
>     2. Client 2 requests report (Userspace call to HIDIOCGFEATURE)
>     3. Client 1's report is returned, and delivered to BOTH clients
>     4. Client 2's report is returned (and discarded)
>
> Note here that Client 1's report and Client 2's report are the same 
> report, ie: they reflect the state of the same data on the device, 
> just at different times. In this case, they are indeed exactly the 
> same data, but consider this case:
>     1. Client 1 requests report (Userspace call to HIDIOCGFEATURE)
>     2. Client 2 SETS report (Userspace call to HIDIOCSFEATURE)
>     2. Client 2 requests report (Userspace call to HIDIOCGFEATURE)
>     3. Client 1's report is returned, and delivered to Clients 1 and 2
>     4. Client 2's report is returned
>
> In this case, client 2 receives OLD data (since it set new data, and 
> the call to write the reports is currently not synchronous). To make 
> writes synchronous, we'd run into the same problem, of two writes 
> happening concurrently, and the 2nd one receiving the ACK from the 
> first one.
>
> Alan.
>

I just remembered to look at the hidraw.c source, to see that the call 
to the hid_get_raw_report() function pointer (which points to 
hidp_get_raw_report()) is called with a global mutex held. I believe 
this will prevent the race mentioned in #3 above in the case that all 
clients are communicating with the device using hidraw. Of course, the 
situation above could still occur if one of the clients represents an 
actual driver (which isn't subject to the hidraw mutex).


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/