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: <alpine.OSX.2.21.1907311431410.3567@exun.local>
Date:   Wed, 31 Jul 2019 14:32:46 -0700 (PDT)
From:   Mark Balantzyan <mbalant3@...il.com>
To:     Hans Verkuil <hverkuil@...all.nl>
cc:     Mark Balantzyan <mbalant3@...il.com>,
        ezequiel@...guardiasur.com.ar, linux-media@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] media input infrastructure:tw686x: Fix of possibleinconsistent
 memory deallocation and/or race condition by implementation of custom
 video_device_release function in tw686x driver

Hi Hans, all,

Sorry for the poor patching, I am a student and as you may tell still new 
to this system. At the time of the patching, I wasn't fully informed of 
all the requirements that go into such things, and am still learning.

Would it be alright if I submit a report instead? In order to, I am 
(still, sorry) trying to understand the issue at hand. How in fact may the 
release() callback be overridden (by a tw686x-specific function) to free 
the dma memory and call video_device_release()? To my understanding at the 
time, this was merely a re-implementation of video_device_release with 
said requirements and subtraction of extra features from 
tw686x_video_free()..

 	This release() callback is called by the V4L2 framework when the last user
 	of the device closes its filehandle, so that's a good point to free all
 	the memory. Doing it earlier (as the current code does) runs the risk that someone might
 	still access that memory, and you don't want that.

Yes, I definitely don't want that. :)

Thank you,
Mark

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ