netdev - Re: dns_resolver_preparse tries to print arbitrarily-large user-provided strings

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:   Tue, 27 Feb 2018 17:31:33 -0800
From:   Eric Biggers <ebiggers3@...il.com>
To:     Mark Rutland <mark.rutland@....com>
Cc:     netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
        "David S. Miller" <davem@...emloft.net>,
        David Howells <dhowells@...hat.com>,
        Eric Biggers <ebiggers@...gle.com>
Subject: Re: dns_resolver_preparse tries to print arbitrarily-large
 user-provided strings

Hi Mark,

On Tue, Feb 27, 2018 at 04:43:13PM +0000, Mark Rutland wrote:
> Hi,
> 
> As a heads-up, while fuzzing v4.16-rc3 on arm64 with Syzkaller, I hit a
> system hang which I was able to minize to the reproducer below. It looks
> like the system hang is an artifact of Syzkaller using panic_on_warn, as
> dns_resolver_preparse can trigger a WARN_ONCE() in the bowels of
> printk(), and we recurse on a lock that's already held.
> 
> The underlying issue is that dns_resolver_preparse() may try to dump an
> arbitrarily large chunk of user-provided data, even from an unprivileged
> user, while printk() has some internal limit on string precision.
> 
> On bare metal (without panic_on_warn), this means I get the following in
> my dmesg:
> 
> $ ./repro
> [   56.870339] Option '                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                            
> [   56.870350] ------------[ cut here ]------------
> [   56.870355] precision 1044478 too large
> [   56.870362] WARNING: CPU: 2 PID: 2450 at lib/vsprintf.c:2179 vsnprintf+0xdf0/0x1268
> [   56.870366] Modules linked in:
> [   56.870376] CPU: 2 PID: 2450 Comm: repro Not tainted 4.16.0-rc3-00002-g544c20187688-dirty #4
> [   56.870382] Hardware name: ARM Juno development board (r1) (DT)
> [   56.870386] pstate: 80000085 (Nzcv daIf -PAN -UAO)
> [   56.870390] pc : vsnprintf+0xdf0/0x1268
> [   56.870394] lr : vsnprintf+0xdf0/0x1268
> [   56.870398] sp : ffff80092b41f6f0
> [   56.870401] x29: ffff80092b41f6f0 x28: ffff20000b093f36
> [   56.870411] x27: 00000000000003e0 x26: 0000000000000002
> [   56.870421] x25: 00000000000feffe x24: 1ffff00125683eee
> [   56.870431] x23: ffff20000a433200 x22: ffff20000bc5f3c0
> [   56.870440] x21: dfff200000000000 x20: ffff20000bc5efea
> [   56.870450] x19: ffff20000a4329ce x18: 0000ffffc51e5860
> [   56.870459] x17: 0000000000411018 x16: ffff200008957d28
> [   56.870469] x15: 00000000f2000000 x14: ffff20000aa0a6c0
> [   56.870479] x13: 0000000000000000 x12: ffff20000aa0a000
> [   56.870488] x11: 1ffff00126eda462 x10: ffff100126eda462
> [   56.870498] x9 : dfff200000000000 x8 : 0000000000000000
> [   56.870507] x7 : ffff8009376d2311 x6 : ffff8009376d2312
> [   56.870517] x5 : ffff100126eda463 x4 : ffff100126eda463
> [   56.870526] x3 : 0000000000000000 x2 : 0000000000000001
> [   56.870536] x1 : fdb9418241605c00 x0 : 0000000000000000
> [   56.870545] Call trace:
> [   56.870549]  vsnprintf+0xdf0/0x1268
> [   56.870553]  vscnprintf+0x48/0x88
> [   56.870556]  vprintk_emit+0xac/0x5f0
> [   56.870560]  vprintk_default+0x44/0x50
> [   56.870564]  vprintk_func+0x3dc/0x630
> [   56.870568]  printk+0xbc/0xec
> [   56.870572]  dns_resolver_preparse+0x5bc/0x6e8
> [   56.870576]  key_create_or_update+0x298/0x828
> [   56.870580]  SyS_add_key+0x110/0x3c8
> [   56.870584]  el0_svc_naked+0x30/0x34
> [   56.870589] ---[ end trace 2b46801cfa43d927 ]---
> 
> Any ideas on how to avoid this?
> 
> Thanks,
> Mark.
> 
> ---->8----
> #include <sys/syscall.h>
> #include <unistd.h>
> 
> #define BUF_SIZE 0xff000
> 
> static char buf[BUF_SIZE] = {
> 	[0] = '#',
> 	[1 ... BUF_SIZE - 2] = 'a'
> };
> 
> int main()
> {
> 	syscall(__NR_add_key, "dns_resolver", "a", buf, BUF_SIZE, -1);
> 	return 0;
> }
> 

Thanks for the bug report.  At the very least I think dns_resolver_preparse()
should limit the option string lengths.  After all, the only accepted option
currently is "dnserror".  I'll send a patch.

Eric