[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <AANLkTi==h70Cgj-SzRShVU1eJ1CGkL93-5XV55Ry6-eD@mail.gmail.com>
Date: Fri, 23 Jul 2010 12:21:35 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Joe Perches <joe@...ches.com>
Cc: Dan Carpenter <error27@...il.com>, Bruno Randolf <br1@...fach.org>,
"Luis R. Rodriguez" <lrodriguez@...eros.com>,
Nick Kossifidis <mickflemm@...il.com>,
Jiri Slaby <jirislaby@...il.com>,
Bob Copeland <me@...copeland.com>,
"John W. Linville" <linville@...driver.com>,
linux-wireless@...r.kernel.org, ath5k-devel@...ema.h4ckr.net,
kernel-janitors <kernel-janitors@...r.kernel.org>,
LKML <linux-kernel@...r.kernel.org>
Subject: Re: [patch -next] ath5k: snprintf() returns largish values
On Fri, Jul 23, 2010 at 10:48 AM, Joe Perches <joe@...ches.com> wrote:
>
> There are also many repeated uses of snprintf in kernel sources
> that could similarly be a problem.
>
> bar += snprintf(foo + bar, ...)
> bar += snprintf(foo + bar, ...)
> or
> foo += snprintf(foo, ...)
> foo += snprintf(foo, ...)
As long as the number of bytes is updated correctly, this won't be a
security problem, although it can cause a (single) warning. The kernel
vsnprintf does
if (WARN_ON_ONCE((int) size < 0))
return 0;
so if somebody overflows a buffer with multiple snprintf calls, it
will all be ok as long as the buffer size thing is updated the natural
way (possibly using pointer arithmetic, eg "end - bar").
Linus
--
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/
Powered by blists - more mailing lists