linux-kernel - [PATCH v2 0/5] firmware: few fixes for name uses

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

Message-Id: <1431455457-25322-1-git-send-email-mcgrof@do-not-panic.com>
Date:	Tue, 12 May 2015 11:30:52 -0700
From:	"Luis R. Rodriguez" <mcgrof@...not-panic.com>
To:	ming.lei@...onical.com, rusty@...tcorp.com.au
Cc:	dhowells@...hat.com, seth.forshee@...onical.com,
	torvalds@...ux-foundation.org, linux-kernel@...r.kernel.org,
	pebolle@...cali.nl, linux-wireless@...r.kernel.org,
	"Luis R. Rodriguez" <mcgrof@...e.com>
Subject: [PATCH v2 0/5] firmware: few fixes for name uses

From: "Luis R. Rodriguez" <mcgrof@...e.com>

This is a follow up to my original series that added kernel firmware
signature check support. That series was split into 3 parts, one which
had fixes, a second set which added firmware signature support, and
a last set which provided system data firmware support as a spring
cleaning effort on the firmware_class driver API. During review I've
spotted even more fixes required on firmware_class, because of this
and in order to help make the review easier I'm splitting the series
out completely. This series only addresses fixes and enhancements for
firmware_class. When reviewing these please keep in mind that one of
the end goals here is to eventually add address firmware signature support,
this means we want to be pretty pedantic and careful about how we handle
names and files.

I've removed Cc: stable notations because although they are fixes they
don't really fix any reported issues even though I can trigger at least
one panic on demand, I'll let Greg and others decide what patches should
be merged in and trickled down to stable. Its not an easy judgement call,
and because of this I've tried to split out fixes out as atomically as
possible. If its of any help I think the Patch 1-2, 4, should all go
in to stable while Patch 3, 5 can be considered optimizations which are
not really stable fixes.

Luis R. Rodriguez (5):
  firmware: fix __getname() missing failure check
  firmware: check for file truncation on direct firmware loading
  firmware: check for possible file truncation early
  firmware: fix possible use after free on name on asynchronous request
  firmware: use const for remaining firmware names

 drivers/base/firmware_class.c | 110 ++++++++++++++++++++++++++++++++++--------
 1 file changed, 91 insertions(+), 19 deletions(-)

-- 
2.3.2.209.gd67f9d5.dirty

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