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] [day] [month] [year] [list]
Date:	Wed, 06 May 2015 09:49:35 +0200
From:	Rasmus Villemoes <linux@...musvillemoes.dk>
To:	Alexey Dobriyan <adobriyan@...il.com>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Linux Kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 04/10] sscanf: fix overflow

On Tue, May 05 2015, Alexey Dobriyan <adobriyan@...il.com> wrote:

> On Tue, May 5, 2015 at 12:51 PM, Rasmus Villemoes
> <linux@...musvillemoes.dk> wrote:
>> On Sat, May 02 2015, Alexey Dobriyan <adobriyan@...il.com> wrote:
>>
>>> Fun fact:
>>>
>>>       uint8_t val;
>>>       sscanf("256", "%hhu", &val);
>>>
>>> will return 1 (as it should), and make val=0 (as it should not).
>>>
>>
>> What do you base these "should" and "should not" on? Both C99 and POSIX
>> say that the behaviour is undefined - the kernel can obviously define
>> its own semantics for scanf, but what do you think they should be?
>
> POSIX can say whatever it wants,

That was sort of the point, POSIX doesn't say anything, which is why I
asked what you think the semantics should be.

> it's about common sense.
>
> sscanf(), both kernel and libc, in this situation returns 0 when "0"
> character is nowhere to be found in the string!  It should either
> return 25

Really? Do you consider it common sense that sscanf("256 123", "%hhu%d", &x,
&y) can end up returning 2, putting 25 in x and 6 in y?

> or do not return anything

I agree that _that_ would be the sane thing to do, but again, I'm
confused why you then said the first example should return 1.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ