lkml.org 
[lkml]   [2005]   [Oct]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Subject[CHECKER] buffer overflows in net/core/filter.c?
Date
Hi,

it appears that bad filters in net/core/filter.c can read/write arbitrary
kernel memory.

Given a filter created via:

struct sock_filter s[2];
memset(s, 0, sizeof s);


s[0].code = BPF_LD|BPF_B|BPF_ABS;
s[0].k = 0x7fffffffUL;
s[1].code = BPF_RET;
s[1].k = 0xfffffff0UL;

or:

s[0].code = BPF_LD|BPF_B|BPF_IND;
s[0].k = 0x7fffffffUL;
s[1].code = BPF_RET;
s[1].k = 0xfffffff0UL;

or

s[0].code = BPF_LD|BPF_H|BPF_IND;
s[0].k = 0x7ffffffeUL;
s[1].code = BPF_B|BPF_RET;
s[1].k = 0xfffffff0UL;

or

s[0].code = BPF_LD|BPF_H|BPF_IND;
s[0].k = 0x7ffffffeUL;
s[1].code = BPF_B|BPF_RET;
s[1].k = 0xfffffff0UL;


These pass check filter calls:

sk_chk_filter(s, 2)

But then blow up severely after calling:

static inline void *skb_header_pointer(const struct sk_buff *skb, int offset,
int len, void *buffer)
{
int hlen = skb_headlen(skb);


which increments the data pointer:

if (offset + len <= hlen)
return skb->data + offset;

but does not check if (offset+len) could overflow.

Something gross along the lines of:

if((offset + len) < offset) {
printf("ERROR: hit overflow!\n");
return NULL;
}

seems to fix the problem, but most likely filter.c should do it.

If anyone could confirm or refute these I'd appreciate it. [We've been
developing a tool to automatically generate test cases by running code
partially symbolically and these were some of first errors it flagged.]

Dawson
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-10-16 11:43    [W:0.143 / U:0.272 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site