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]
Date:	Fri, 17 Jun 2016 15:04:03 +0200
From:	Max Kellermann <max@...mpel.org>
To:	Sakari Ailus <sakari.ailus@....fi>
Cc:	linux-media@...r.kernel.org, shuahkh@....samsung.com,
	mchehab@....samsung.com, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/3] drivers/media/media-entity: clear media_gobj.mdev in
 _destroy()

On 2016/06/17 14:53, Sakari Ailus <sakari.ailus@....fi> wrote:
> On Wed, Jun 15, 2016 at 10:15:07PM +0200, Max Kellermann wrote:
> > media_gobj_destroy() may be called twice on one instance - once by
> > media_device_unregister() and again by dvb_media_device_free().  The
> 
> Is that something that should really happen, and why? The same object should
> not be unregistered more than once --- in many call paths gobj
> unregistration is followed by kfree() on the gobj.

True, it should not happen, and I think the code is currently
misdesigned (or I just don't grasp it correctly; I may be wrong).

The "gobj" is inserted into a linked list, the list's owner
(media_device) feels responsible to free items in that list.  Plus,
the dvb_device instances holds a pointer and also tries to free it.

Usually, dvbdev.c destruction gets called first, which removes the
"gobj" from the linked list, and media_device never sees it during its
own destruction.  But that ordering is all but guaranteed.  It just
happens to be that way under "normal" circumstances.

None of this makes any sense to me.  There appears to be lots of bogus
and unsafe code.  I'm still waiting for somebody with more clue to
enlighten me.

Max

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ