linux-kernel - Re: [Qemu-devel] [PATCH v5 1/4] firmware: introduce sysfs driver for QEMU's fw

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:	Tue, 24 Nov 2015 10:38:18 -0700
From:	Eric Blake <eblake@...hat.com>
To:	"Gabriel L. Somlo" <somlo@....edu>,
	kbuild test robot <lkp@...el.com>
Cc:	mark.rutland@....com, peter.maydell@...aro.org, mst@...hat.com,
	stefanha@...il.com, qemu-devel@...gnu.org, eric@...olt.net,
	kraxel@...hat.com, linux-api@...r.kernel.org, pawel.moll@....com,
	zajec5@...il.com, galak@...eaurora.org,
	rmk+kernel@....linux.org.uk, lersek@...hat.com,
	hanjun.guo@...aro.org, devicetree@...r.kernel.org, arnd@...db.de,
	ijc+devicetree@...lion.org.uk, jordan.l.justen@...el.com,
	agross@...eaurora.org, leif.lindholm@...aro.org,
	robh+dt@...nel.org, ard.biesheuvel@...aro.org,
	gregkh@...uxfoundation.org, linux-kernel@...r.kernel.org,
	luto@...capital.net, kbuild-all@...org, sudeep.holla@....com,
	pbonzini@...hat.com, revol@...e.fr
Subject: Re: [Qemu-devel] [PATCH v5 1/4] firmware: introduce sysfs driver for
 QEMU's fw_cfg device

On 11/24/2015 09:55 AM, Gabriel L. Somlo wrote:
> On Tue, Nov 24, 2015 at 04:14:50AM +0800, kbuild test robot wrote:

>>
>>    drivers/firmware/qemu_fw_cfg.c: In function 'fw_cfg_cmdline_set':
>>>> drivers/firmware/qemu_fw_cfg.c:510:7: warning: format '%lli' expects argument of type 'long long int *', but argument 3 has type 'phys_addr_t *' [-Wformat=]
>>           &ctrl_off, &data_off, &consumed);
>>           ^
> 
> Oh, I think I know why this happened:
> 

> 
> So, I could use u64 instead of phys_addr_t and resource_size_t, and
> keep "%lli" (or "%Li"), but then I'd have to check if the parsed value

%Li is not POSIX.  Don't use it (stick with %lli).

> would overflow a 32-bit address value on arches where phys_addr_t is
> u32, which would make things a bit more messy and awkward.
> 
> I'm planning on #ifdef-ing the format string instead:
> 
> #ifdef CONFIG_PHYS_ADDR_T_64BIT
> #define PH_ADDR_SCAN_FMT "@%Li%n:%Li:%Li%n"
> #else
> #define PH_ADDR_SCAN_FMT "@%li%n:%li:%li%n"
> #endif

A more typical approach is akin to <inttypes.h>; have PH_ADDR_FMT
defined to either "lli" or "li", then write sscanf(str, "@%"PH_ADDR_FMT
"%n:..., ...), using PH_ADDR_FMT multiple times.

> ...
>         processed = sscanf(str, PH_ADDR_SCAN_FMT,
>                            &base, &consumed,
>                            &ctrl_off, &data_off, &consumed);

Umm, why are you passing &consumed to more than one sscanf() %?  That's
(probably) undefined behavior.

[In general, sscanf() is a horrid interface to use for parsing integers
- it has undefined behavior if the input text would trigger integer
overflow, making it safe to use ONLY on text that you control and can
guarantee won't overflow. By the time you've figured out if untrusted
text meets the requirement for safe parsing via sscanf(), you've
practically already parsed it via safer strtol() and friends.]

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


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