linux-kernel - Re: [PATCH 13/24] mfd: fix dangling pointers

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:	Sat, 20 Mar 2010 21:25:01 +0100
From:	Jean Delvare <khali@...ux-fr.org>
To:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
Cc:	Wolfram Sang <w.sang@...gutronix.de>,
	kernel-janitors@...r.kernel.org, linux-i2c@...r.kernel.org,
	linux-kernel@...r.kernel.org, Samuel Ortiz <sameo@...ux.intel.com>
Subject: Re: [PATCH 13/24] mfd: fix dangling pointers

On Sat, 20 Mar 2010 17:22:41 +0000, Mark Brown wrote:
> On Sat, Mar 20, 2010 at 03:12:54PM +0100, Wolfram Sang wrote:
> > Fix I2C-drivers which missed setting clientdata to NULL before freeing the
> > structure it points to. Also fix drivers which do this _after_ the structure
> > was freed already.
> 
> Acked-by: Mark Brown <broonie@...nsource.wolfsonmicro.com>
> 
> but it really does seem like this is something that the I2C core ought
> to handle - the assignment to null is boiler plate code that's getting
> added to the overwhelming majority of I2C devices in their teardown
> path, it'd seem a lot more sensible for the core to just trash driver
> data after the driver is unbound if it's important that this happens.

This is an interesting point. Do you know of any other subsystem doing
this? The core touching private data seems wrong to me, but I have to
agree that it would avoid a lot of duplication across drivers.

Can someone find a reasonable use case for client data surviving the
driver's .remove() call?

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