On Mon, Apr 02, 2018 at 12:20:35PM -0700, Eric Biggers wrote:
> On Fri, Mar 23, 2018 at 01:21:22PM -0700, Eric Biggers wrote:
> > On Mon, Mar 12, 2018 at 10:57:07AM -0700, Eric Biggers wrote:
> > > On Wed, Mar 07, 2018 at 03:54:37PM +, David Howells wrote:
> > > > Eric Biggers wrote:
> > > >
On Fri, Mar 23, 2018 at 01:21:22PM -0700, Eric Biggers wrote:
> On Mon, Mar 12, 2018 at 10:57:07AM -0700, Eric Biggers wrote:
> > On Wed, Mar 07, 2018 at 03:54:37PM +, David Howells wrote:
> > > Eric Biggers wrote:
> > >
> > > > Fix it by limiting option strings (combined name + value) to a m
On Mon, Mar 12, 2018 at 10:57:07AM -0700, Eric Biggers wrote:
> On Wed, Mar 07, 2018 at 03:54:37PM +, David Howells wrote:
> > Eric Biggers wrote:
> >
> > > Fix it by limiting option strings (combined name + value) to a much more
> > > reasonable 128 bytes. The exact limit is arbitrary, but
On Wed, Mar 07, 2018 at 03:54:37PM +, David Howells wrote:
> Eric Biggers wrote:
>
> > Fix 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"
Eric Biggers wrote:
> Fix 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.
There will be more options coming (
From: Eric Biggers
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 100 too
