linux-kernel - Re: [PATCH] lib: vsprintf: fix invalid arg check

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]

Date:	Thu, 11 Nov 2010 12:38:01 -0800 (PST)
From:	David Rientjes <rientjes@...gle.com>
To:	Vasiliy Kulikov <segooon@...il.com>
cc:	Andrew Morton <akpm@...ux-foundation.org>,
	kernel-janitors@...r.kernel.org,
	André Goddard Rosa <andre.goddard@...il.com>,
	Joe Perches <joe@...ches.com>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Bjorn Helgaas <bjorn.helgaas@...com>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] lib: vsprintf: fix invalid arg check

On Thu, 11 Nov 2010, Vasiliy Kulikov wrote:

> > > > "size" is size_t.  If we want to check whether it was underflowed
> > > > then we should cast it to ssize_t instead of int.  When
> > > > sizeof(size_t) > sizeof(int) the code sees UINT_MAX as underflow,
> > > > but it is not.
> > > > 
> > > 
> > > Does this patch fix any actual observed problem?
> 
> I don't think so, this fix is more theoretical than practical.
> However, maybe there is some crazy driver that fills array of 2GB with
> s*printf().
> 

All sizes passed to vsprintf() greater than INT_MAX are invalid; that's 
what the original code is testing, warning, and handling correctly.

> > > >  Compile tested.
> > > > 
> > > 
> > > I guess not.
> 
> What do you mean here? 
> 
> $ make lib/vsprintf.o
>   CHK     include/linux/version.h
>   CHK     include/generated/utsrelease.h
>   CALL    scripts/checksyscalls.sh
>   CC      lib/vsprintf.o
> 
> Compiled without warnings.
> 

Andrew was commenting that this was the only additional information you 
provided instead of showing a working example.

> > > >  	/* Reject out-of-range values early.  Large positive sizes are
> > > >  	   used for unknown buffer sizes. */
> > > 
> > > Thousands of people would find that comment to be utterly mysterious. 
> > > I am one.
> > > 
> [...]
> > The changelog is wrong: if sizeof(size_t) > sizeof(int) then the return value overflows.
> 
> This comparison is intended for size_t _underflow_, e.g. in such (buggy)
> code:
> 
> len = snprintf(buf, sizeof(buf), "%s", string);
> len += snprintf(buf + len, sizeof(buf) - len, "%s", string2);
> 

That's buggy because len may be greater than sizeof(buf).  snprintf() 
returns the number of characters that would have been generated if it 
wasn't truncated so that we can test that value upon return.

> If the first snprintf() returns len that is greater than sizeof(buf),
> then sizeof(buf)-len is negative; casted to (unsigned!) size_t it
> becomes some big value. buf+len points to somewhere after the real buf.
> 

Right, that's the behavior of snprintf(), but that doesn't mean the passed 
size can be anything larger than INT_MAX.

> To detect this situation we check whether size is negative (as signed).
> But it should be checked as integer of the same size.
> 
> > vsprintf() and sprintf() pass INT_MAX for an unbounded buffer length
> 
> OK, this should be changed to LONG_MAX.
> 

No, it shouldn't, these functions return int.  INT_MAX is the largest 
value we can handle successfully and that's why it is the special case for 
sprintf() and vsprintf().

The code as it stands is correct not because of the type of the size but 
rather the type of the return value.
--
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/