linux-kernel - Re: [PATCH 1/1] firmware_loading_store: fix firmware loading use-after-free oops

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>] [day] [month] [year] [list]

Message-ID: <20111213173135.GC17096@kroah.com>
Date:	Tue, 13 Dec 2011 09:31:35 -0800
From:	Greg KH <greg@...ah.com>
To:	DONG-DONG YANG <gdb746@...orola.com>
Cc:	linux-kernel <linux-kernel@...r.kernel.org>,
	Kroah-Hartman <gregkh@...e.de>,
	Yi-wei Zhao <gbjc64@...orola.com>, TAO HU <taohu@...orola.com>,
	David Ding <dding@...orola.com>,
	Jeffrey Carlyle <jeff.carlyle@...orola.com>,
	zhiming YUAN <a14194@...orola.com>
Subject: Re: [PATCH 1/1] firmware_loading_store: fix firmware loading
 use-after-free oops

A: No.
Q: Should I include quotations after my reply?

http://daringfireball.net/2007/07/on_top

On Tue, Dec 13, 2011 at 01:31:32PM +0800, DONG-DONG YANG wrote:
> If we do the check for fw in the fw_load_abort call, I concern whether it would
> limit FW_STATUS_ABORT scope, which would presume any fw_abort occur after fw
> instance generation.

Are you sure this really fixes anything?  What happens if the fw pointer
becomes null after the check happens but before the call?  What is
protecting that from happening here?

> The issue was introduced when the webtop components are integrated into the
> Linux Android platform.
> The webtop firmware loading performs udev configuration files (under /lib/udev/
> *) by default, however,
> ueventd is in charge of such loading task on android framework. The conflict
> causes the weird things happen.
>
> 50-firmware.rules, one of udev default rules, forks a sub-process, named
> "firmware", which sends "-1" to "loading" fw ctrl file on receiving "add"
> event. Such firmware loading failure should bring on APP processes exit or
> error report, but it causes use-after-free oops due to we have no check for fw
> in firmware_loading_store.

Sounds like this is a major userspace configuration error.  Not that
this means we shouldn't be applying the kernel patch, just that you need
to fix up your system first :)

Hm, so, you have two different processes trying to write to the firmware
file at the same time?  And when one finishes, the other one tries to
abort things?

Ok, I can understand that, it's a very messed up userspace, but I
understand.

But, your patch needs to properly hold the lock when this is being
checked, otherwise it will still race and could still oops.

And, your check needs to be done in a different place, again, what's to
keep that pointer from going away later, in the middle of that call you
just made?

Care to fix this up properly?

> The patch and log analysis are attached.

Please don't attach patches, it's not easy to apply them when they are
in base64 mode.

Also, your patch can't be applied as you made it against a very wierd
patch "rbase"?

thanks,

greg k-h
--
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/