If the code to test is built into vmlinux, we could use run-time checking like
--
--- a/lib/vsprintf.c
+++ b/lib/vsprintf.c
@@ -1601,6 +1601,11 @@ int vsnprintf(char *buf, size_t size, const char *fmt,
va_list args)
if (WARN_ON_ONCE((int) size < 0))
return 0;
+
If the code to test is built into vmlinux, we could use run-time checking like
--
--- a/lib/vsprintf.c
+++ b/lib/vsprintf.c
@@ -1601,6 +1601,11 @@ int vsnprintf(char *buf, size_t size, const char *fmt,
va_list args)
if (WARN_ON_ONCE((int) size 0))
return 0;
+
Kees Cook wrote:
> > -- output start --
> > const : literal
> > not const : const char *
> > not const : const char []
> > const : const char * const
>
> What version of gcc did you use? I don't get the last as const, for
> some reason. And as Dan mentions, shouldn't const char[]
> +#define printk(fmt, ...) do { \
> + compiletime_assert(__builtin_constant_p(fmt), \
> +"Non-constant format string"); \
> + printk(fmt, ##__VA_ARGS__); \
> +} while (0)
May I recommend
On Wed, Sep 18, 2013 at 6:14 AM, Tetsuo Handa
wrote:
> Kees Cook wrote:
>> > Consider, e.g. introducing __vsnprint(), with vsnprintf(s, n, fmt, ...)
>> > expanding to __vsnprintf(1, s, n, fmt, ...) if fmt is a string literal
>> > and __vsnprintf(0, s, n, fmt, ...) otherwise. Now,
>> > int
On Wed, Sep 18, 2013 at 6:14 AM, Tetsuo Handa
wrote:
> Kees Cook wrote:
>> > Consider, e.g. introducing __vsnprint(), with vsnprintf(s, n, fmt, ...)
>> > expanding to __vsnprintf(1, s, n, fmt, ...) if fmt is a string literal
>> > and __vsnprintf(0, s, n, fmt, ...) otherwise. Now,
>> > int
On Wed, Sep 18, 2013 at 05:11:04PM +0300, Dan Carpenter wrote:
> asmlinkage __printf(1, 2) __cold
> int printk(const char *fmt, ...);
> +#define printk(fmt, ...) do { \
> + compiletime_assert(__builtin_constant_p(fmt), \
> +
Sure. There are a lot of non-const strings though.
diff --git a/include/linux/printk.h b/include/linux/printk.h
index e6131a78..317587b 100644
--- a/include/linux/printk.h
+++ b/include/linux/printk.h
@@ -122,6 +122,11 @@ asmlinkage int printk_emit(int facility, int level,
asmlinkage
Kees Cook wrote:
> > Consider, e.g. introducing __vsnprint(), with vsnprintf(s, n, fmt, ...)
> > expanding to __vsnprintf(1, s, n, fmt, ...) if fmt is a string literal
> > and __vsnprintf(0, s, n, fmt, ...) otherwise. Now,
> > int __sprintf(int safe, char *buf, const char *fmt, ...)
> > {
> >
Kees Cook wrote:
Consider, e.g. introducing __vsnprint(), with vsnprintf(s, n, fmt, ...)
expanding to __vsnprintf(1, s, n, fmt, ...) if fmt is a string literal
and __vsnprintf(0, s, n, fmt, ...) otherwise. Now,
int __sprintf(int safe, char *buf, const char *fmt, ...)
{
va_list
Sure. There are a lot of non-const strings though.
diff --git a/include/linux/printk.h b/include/linux/printk.h
index e6131a78..317587b 100644
--- a/include/linux/printk.h
+++ b/include/linux/printk.h
@@ -122,6 +122,11 @@ asmlinkage int printk_emit(int facility, int level,
asmlinkage
On Wed, Sep 18, 2013 at 05:11:04PM +0300, Dan Carpenter wrote:
asmlinkage __printf(1, 2) __cold
int printk(const char *fmt, ...);
+#define printk(fmt, ...) do { \
+ compiletime_assert(__builtin_constant_p(fmt), \
+Non-constant
On Wed, Sep 18, 2013 at 6:14 AM, Tetsuo Handa
penguin-ker...@i-love.sakura.ne.jp wrote:
Kees Cook wrote:
Consider, e.g. introducing __vsnprint(), with vsnprintf(s, n, fmt, ...)
expanding to __vsnprintf(1, s, n, fmt, ...) if fmt is a string literal
and __vsnprintf(0, s, n, fmt, ...)
On Wed, Sep 18, 2013 at 6:14 AM, Tetsuo Handa
penguin-ker...@i-love.sakura.ne.jp wrote:
Kees Cook wrote:
Consider, e.g. introducing __vsnprint(), with vsnprintf(s, n, fmt, ...)
expanding to __vsnprintf(1, s, n, fmt, ...) if fmt is a string literal
and __vsnprintf(0, s, n, fmt, ...)
+#define printk(fmt, ...) do { \
+ compiletime_assert(__builtin_constant_p(fmt), \
+Non-constant format string); \
+ printk(fmt, ##__VA_ARGS__); \
+} while (0)
May I recommend
Kees Cook wrote:
-- output start --
const : literal
not const : const char *
not const : const char []
const : const char * const
What version of gcc did you use? I don't get the last as const, for
some reason. And as Dan mentions, shouldn't const char[] be detected
On Mon, Sep 16, 2013 at 8:55 AM, Al Viro wrote:
> On Mon, Sep 16, 2013 at 12:43:55AM -0700, Kees Cook wrote:
>> Whether seq_printf should return void or error, %n still needs to be removed.
>> As such, instead of changing the seq_file structure and adding instructions
>> to all callers of
> This is completely pointless. *ANY* untrusted format string kernel-side
> is pretty much it. Blocking %n is not "defense in depth", it's security
> theater. Again, if attacker can feed an arbitrary format string to
> vsnprintf(), it's over - you've lost. It's not just about information
>
On Mon, Sep 16, 2013 at 12:43:55AM -0700, Kees Cook wrote:
> Whether seq_printf should return void or error, %n still needs to be removed.
> As such, instead of changing the seq_file structure and adding instructions
> to all callers of seq_printf, just examine seq->count for the callers that
>
On 09/16/2013 05:55 PM, Al Viro wrote:
> On Mon, Sep 16, 2013 at 12:43:55AM -0700, Kees Cook wrote:
>> Whether seq_printf should return void or error, %n still needs to be removed.
>> As such, instead of changing the seq_file structure and adding instructions
>> to all callers of seq_printf, just
Whether seq_printf should return void or error, %n still needs to be removed.
As such, instead of changing the seq_file structure and adding instructions
to all callers of seq_printf, just examine seq->count for the callers that
care about how many characters were put into the buffer, as suggested
Whether seq_printf should return void or error, %n still needs to be removed.
As such, instead of changing the seq_file structure and adding instructions
to all callers of seq_printf, just examine seq-count for the callers that
care about how many characters were put into the buffer, as suggested
On 09/16/2013 05:55 PM, Al Viro wrote:
On Mon, Sep 16, 2013 at 12:43:55AM -0700, Kees Cook wrote:
Whether seq_printf should return void or error, %n still needs to be removed.
As such, instead of changing the seq_file structure and adding instructions
to all callers of seq_printf, just examine
On Mon, Sep 16, 2013 at 12:43:55AM -0700, Kees Cook wrote:
Whether seq_printf should return void or error, %n still needs to be removed.
As such, instead of changing the seq_file structure and adding instructions
to all callers of seq_printf, just examine seq-count for the callers that
care
This is completely pointless. *ANY* untrusted format string kernel-side
is pretty much it. Blocking %n is not defense in depth, it's security
theater. Again, if attacker can feed an arbitrary format string to
vsnprintf(), it's over - you've lost. It's not just about information
leaks vs.
On Mon, Sep 16, 2013 at 8:55 AM, Al Viro v...@zeniv.linux.org.uk wrote:
On Mon, Sep 16, 2013 at 12:43:55AM -0700, Kees Cook wrote:
Whether seq_printf should return void or error, %n still needs to be removed.
As such, instead of changing the seq_file structure and adding instructions
to all
26 matches
Mail list logo
