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]
Message-ID: <577685EE.1050704@ispras.ru>
Date:	Fri, 01 Jul 2016 19:02:06 +0400
From:	Pavel Andrianov <andrianov@...ras.ru>
To:	Hans Verkuil <hverkuil@...all.nl>
CC:	Mauro Carvalho Chehab <mchehab@...nel.org>,
	Vladis Dronov <vdronov@...hat.com>,
	Insu Yun <wuninsu@...il.com>, Oliver Neukum <oneukum@...e.com>,
	linux-media@...r.kernel.org, linux-kernel@...r.kernel.org,
	Vaishali Thakkar <vaishali.thakkar@...cle.com>,
	ldv-project@...uxtesting.org
Subject: Re: A potential race

01.07.2016 19:53, Hans Verkuil пишет:
> On 07/01/2016 04:39 PM, Pavel Andrianov wrote:
>>   Hi!
>>
>> There is a potential race condition between usbvision_v4l2_close and usbvision_disconnect. The possible scenario may be the following. usbvision_disconnect starts execution, assigns usbvision->remove_pending = 1, and is interrupted
>> (rescheduled) after mutex_unlock. After that usbvision_v4l2_close is executed, decrease usbvision->user-- , checks usbvision->remove_pending, executes usbvision_release and finishes. Then usbvision_disconnect continues its execution. It checks
>> usbversion->user (it is already 0) and also execute usbvision_release. Thus, release is executed twice. The same situation may
>> occur if usbvision_v4l2_close is interrupted by usbvision_disconnect. Moreover, the same problem is in usbvision_radio_close. In all these cases the check before call usbvision_release under mutex_lock protection does not solve the problem, because  there may occur an open() after the check and the race takes place again. The question is: why the usbvision_release
>> is called from close() (usbvision_v4l2_close and usbvision_radio_close)? Usually release functions are called from
>> disconnect.
> Please don't use html mail, mailinglists will silently reject this.
>
> The usbvision driver is old and unloved and known to be very bad code. It needs a huge amount of work to make all this work correctly.
>
> I don't see anyone picking this up...
>
> Regards,
>
> 	Hans
If you know the driver, could you, please, explain me, why 
usbvision_release is called from close functions (usbvision_v4l2_close 
and usbvision_radio_close) and not only from disconnect? Thanks!

-- 
Pavel Andrianov
Linux Verification Center, ISPRAS
web: http://linuxtesting.org
e-mail: andrianov@...ras.ru

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ