linux-kernel - Re: bug in sscanf()?

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: <CA+55aFy_V8ze2CPmHY0Ga-K-DX_SATVu-Tb=_nKq_1Rb5WqaUQ@mail.gmail.com>
Date:	Tue, 14 Jan 2014 07:22:49 +0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Al Viro <viro@...iv.linux.org.uk>
Cc:	"Allan, Bruce W" <bruce.w.allan@...el.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Jan Beulich <JBeulich@...e.com>,
	Alexey Dobriyan <adobriyan@...il.com>
Subject: Re: bug in sscanf()?

On Tue, Jan 14, 2014 at 6:30 AM, Al Viro <viro@...iv.linux.org.uk> wrote:
>
> Comments?

Do we have actual users of this? Because I'd almost be inclined to say
"we just don't support field widths on sscanf() and will warn" unless
there are users.

We've done that before. The kernel has various limited functions. See
the whole snprint() issue with %n, which we decided that supporting
the full semantics was actually a big mistake and we actively
*removed* code that had been misguidedly added just because people
thought we should do everything a standard user library does..

Limiting our problem space is a *good* thing, not a bad thing.

If it's possible, of course, and we don't have nasty users.

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