linux-kernel - Re: [PATCH] hid: usbhid: hid-core: fix recursive deadlock

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:	Thu, 19 Nov 2015 22:34:18 +0100 (CET)
From:	Jiri Kosina <jikos@...nel.org>
To:	Ioan-Adrian Ratiu <adi@...rat.com>
cc:	Josh Cartwright <joshc@...com>, pinglinux@...il.com,
	linux-usb@...r.kernel.org, linux-input@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] hid: usbhid: hid-core: fix recursive deadlock

On Thu, 19 Nov 2015, Ioan-Adrian Ratiu wrote:

> But please understand further my reasoning for submitting this patch. 
> Consider if this is a bug in the wacom driver or in the usbhid core? IMO 
> this is a usbhid bug: the critical region in hid_ctrl() is too big, 
> there is no reason for the call to hid_input_report() to be protected by 
> usbhid->lock.

Hmm, it's actually true that we might not need usbhid->lock during 
hid_input_report() at the end of the day, as we shouldn't be doing any 
URB-related operations there, neither iofl are being manipulated.

If you have already done the full analysis that shows that usbhid->lock is 
indeed not needed, this absolutely needs to go into changelog as proper 
justification.

Could you please reformulate the changelog in this respect and resubmit?

Thanks,

-- 
Jiri Kosina
SUSE Labs

--
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/