netdev - 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-next>] [day] [month] [year] [list]

Message-ID: <20180227164313.g7dt7bd73shyedr2@lakrids.cambridge.arm.com>
Date:   Tue, 27 Feb 2018 16:43:13 +0000
From:   Mark Rutland <mark.rutland@....com>
To:     netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Cc:     "David S. Miller" <davem@...emloft.net>,
        David Howells <dhowells@...hat.com>,
        Eric Biggers <ebiggers@...gle.com>
Subject: dns_resolver_preparse tries to print arbitrarily-large user-provided
 strings

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;
}