linux-kernel - Re: [PATCH] base: dd: don't remove driver_data in -EPROBE

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: <20160503131126.GA18494@ulmo.ba.sec>
Date:	Tue, 3 May 2016 15:11:26 +0200
From:	Thierry Reding <thierry.reding@...il.com>
To:	Yi Zhang <yizhang_hust@....com>
Cc:	gregkh@...uxfoundation.org, linux-kernel@...r.kernel.org,
	linux-tegra@...r.kernel.org
Subject: Re: [PATCH] base: dd: don't remove driver_data in -EPROBE_DEFER case

On Tue, Mar 08, 2016 at 11:15:22PM +0800, Yi Zhang wrote:
> the driver_data may be used for sanity check, it fails the
> probe() if driver_data is NULL after it is re-triggered.
> for example, soc_probe() in sound/soc/soc-core.c
> 
> Signed-off-by: Yi Zhang <yizhang_hust@....com>
> ---
>  drivers/base/dd.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)

Hi Greg,

This causes a boot regression on at least one board, caused by one of
the drivers looking at driver data to check whether or not the driver
has properly loaded. If the code encounters a non-NULL pointer it
tries to dereference it, but because it's already been freed there is
no memory backing it and things crash.

I don't think keeping stale pointers around is a good idea. The whole
point of setting this to NULL in the core is so that probe failures
result in the same starting conditions no matter what.

Can we please get this reverted?

Cc'ing linux-tegra for visibility since that's where the boot regression
is observed.

Thierry

Download attachment "signature.asc" of type "application/pgp-signature" (820 bytes)