linux-kernel - Re: [PATCH v1 2/6] lib: scanf: handle integer overflows in vsscanf

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Sun, 10 Mar 2019 22:06:27 +0100
From:   Rasmus Villemoes <linux@...musvillemoes.dk>
To:     Konstantin Khlebnikov <khlebnikov@...dex-team.ru>,
        linux-kernel@...r.kernel.org
Cc:     Tejun Heo <tj@...nel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Alexey Dobriyan <adobriyan@...il.com>
Subject: Re: [PATCH v1 2/6] lib: scanf: handle integer overflows in vsscanf

On 10/03/2019 17.56, Konstantin Khlebnikov wrote:
> Traditional scanf implementations ignore integer overflows because
> C language standard allows here undefined behavior (§7.21.6.2 #10).
> 
> So, sane and safe behavior wouldn't harm anything.
> 
> This patch carefully checks integer overflows and stops matching if result
> does not fit into appropriate type before assigning it into argument.

IIRC, this has been attempted before, causing a userspace regression
because some sysfs/procfs file matched with %u or %x, and somebody wrote
-1 to get 0xffffffff .

I can't remember or find a reference right now, making the above a
rather weak argument. However, please start the series with your test
cases, before any refactoring. That makes it easier to see what
behaviour you're changing (i.e., what used to be allowed is now treated
as non-match, etc.).

Rasmus