linux-kernel - Re: [PATCH] firmware: Don't attempt to allocate zero bytes with vmalloc()

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: <20121009041947.GB8237@opensource.wolfsonmicro.com>
Date:	Tue, 9 Oct 2012 13:19:50 +0900
From:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
To:	Ming Lei <ming.lei@...onical.com>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] firmware: Don't attempt to allocate zero bytes with
 vmalloc()

On Tue, Oct 09, 2012 at 06:56:02AM +0800, Ming Lei wrote:

> Considered that zero-length firmware image doesn't make sense for drivers
> (callers), maybe it is a insane firmware image, so how about treating it as a
> failure?

It seems better to punt that decision to callers - for example, the case
I ran into this with was a driver that was using a zero length firmware
to say that it didn't want to load an optional image but also didn't
want to have to time out if that was the case.  That doesn't seem
unreasonable to me, and drivers already have to validate that what
they're getting makes sense.
--
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/