KEYS: DNS: limit the length of option strings
Subsystems (3)
PATCH RESEND v2 1/1 KEYS: DNS: limit the length of option strings
From: Eric Biggers <[email protected]>
Adding a dns_resolver key whose payload contains a very long option name resulted in that string being printed in full. This hit the WARN_ONCE() in set_precision() during the printk(), because printk() only supports a precision of up to 32767 bytes:
precision 1000000 too large
WARNING: CPU: 0 PID: 752 at lib/vsprintf.c:2189 vsnprintf+0x4bc/0x5b0Fix it by limiting option strings (combined name + value) to a much more reasonable 128 bytes. The exact limit is arbitrary, but currently the only recognized option is formatted as "dnserror=%lu" which fits well within this limit.
Also ratelimit the printks.
Reproducer:
perl -e 'print "#", "A" x 1000000, "\x00"' | keyctl padd dns_resolver desc @s
This bug was found using syzkaller.
--- net/dns_resolver/dns_key.c | 12 +++++------- 1 file changed, 5 insertions(+), 7 deletions(-)
net/dns_resolver/dns_key.c +5 -7
@@ -91,9 +91,9 @@ dns_resolver_preparse(struct key_preparsed_payload *prep) next_opt =memchr (opt,'#' , end - opt) ?: end; opt_len = next_opt - opt; -if (!opt_len) { -printk (KERN_WARNING -"Empty option to dns_resolver key\n" ); +if (opt_len <=0 || opt_len >128 ) { +pr_warn_ratelimited ("Invalid option length (%d) for dns_resolver key\n" , + opt_len);return -EINVAL ; }
@@ -127,10 +127,8 @@ dns_resolver_preparse(struct key_preparsed_payload *prep) } bad_option_value: -printk (KERN_WARNING -"Option '%*.*s' to dns_resolver key:" -" bad/missing value\n" , - opt_nlen, opt_nlen, opt); +pr_warn_ratelimited ("Option '%*.*s' to dns_resolver key: bad/missing value\n" , + opt_nlen, opt_nlen, opt);return -EINVAL ; }while (opt = next_opt +1 , opt < end); }
Signature · 1 line
2.17.0.484.g0c8726318c-goog
From: Eric Biggers <[email protected]>
Date: Mon, 16 Apr 2018 14:29:22 -0700
Quoted 19 lines
From: Eric Biggers <[email protected]>
Adding a
dns_resolverkey whose payload contains a very long option name resulted in that string being printed in full. This hit theWARN_ONCE()inset_precision()during theprintk(), becauseprintk()only supports a precision of up to 32767 bytes:precision 1000000 too large WARNING: CPU: 0 PID: 752 at lib/vsprintf.c:2189 vsnprintf+0x4bc/0x5b0Fix it by limiting option strings (combined name + value) to a much more reasonable 128 bytes. The exact limit is arbitrary, but currently the only recognized option is formatted as "dnserror=%lu" which fits well within this limit.
Also ratelimit the printks.
Reproducer:
Quoted 7 lines
perl -e 'print "#", "A" x 1000000, "\x00"' | keyctl padd dns_resolver desc @sThis bug was found using syzkaller.
Reported-by Mark Rutland <[email protected]>Fixes 4a2d789267e0 ("DNS: If the DNS server returns an error, allow that to be cached [ver #2]")Signed-off-by Eric Biggers <[email protected]>
Applied, thanks.
Quoted 24 lines · David Miller
From: Eric Biggers <[email protected]>
Date: Mon, 16 Apr 2018 14:29:22 -0700Quoted 21 lines
From: Eric Biggers <[email protected]>
Adding a
dns_resolverkey whose payload contains a very long option name resulted in that string being printed in full. This hit theWARN_ONCE()inset_precision()during theprintk(), becauseprintk()only supports a precision of up to 32767 bytes:precision 1000000 too large WARNING: CPU: 0 PID: 752 at lib/vsprintf.c:2189 vsnprintf+0x4bc/0x5b0Fix it by limiting option strings (combined name + value) to a much more reasonable 128 bytes. The exact limit is arbitrary, but currently the only recognized option is formatted as "dnserror=%lu" which fits well within this limit.
Also ratelimit the printks.
Reproducer:
perl -e 'print "#", "A" x 1000000, "\x00"' | keyctl padd dns_resolver desc @s
Quoted 7 lines
Quoted 5 lines
This bug was found using syzkaller.
Reported-by Mark Rutland <[email protected]>Fixes 4a2d789267e0 ("DNS: If the DNS server returns an error, allow that to be cached [ver #2]")Signed-off-by Eric Biggers <[email protected]>Applied, thanks.
Can you queue this up for stable too? syzbot has been hitting this on older kernel versions.
Eric
David Miller
maintainerFrom: Eric Biggers <[email protected]>
Date: Tue, 17 Apr 2018 11:23:40 -0700
Quoted 2 lines
Can you queue this up for stable too? syzbot has been hitting this on older kernel versions.
If you want a patch bound for stable, it must show up in Linus's tree first which means you should target 'net' rather than 'net-next'.
Quoted 8 lines · David Miller
From: Eric Biggers <[email protected]>
Date: Tue, 17 Apr 2018 11:23:40 -0700Quoted 2 lines
Can you queue this up for stable too? syzbot has been hitting this on older kernel versions.
If you want a patch bound for stable, it must show up in Linus's tree first which means you should target 'net' rather than 'net-next'.
Okay, can you move the patch there, or do I need to resend, or is it too late already? It's a clean cherry-pick. Sorry, I'm not too familiar with the quirks of net and netdev -- most other maintainers do things differently.
Thanks,
Eric
David Miller
maintainerFrom: Eric Biggers <[email protected]>
Date: Tue, 17 Apr 2018 11:37:36 -0700
Quoted 7 lines · David Miller
Quoted 6 lines
From: Eric Biggers <[email protected]>
Date: Tue, 17 Apr 2018 11:23:40 -0700Quoted 2 lines
Can you queue this up for stable too? syzbot has been hitting this on older kernel versions.
Quoted 6 lines
Quoted 2 lines
If you want a patch bound for stable, it must show up in Linus's tree first which means you should target 'net' rather than 'net-next'.
Okay, can you move the patch there, or do I need to resend, or is it too late already? It's a clean cherry-pick. Sorry, I'm not too familiar with the quirks of net and netdev -- most other maintainers do things differently.
It's already in net-next, so submit another copy based on net.