linux-kernel - Re: ebtables problems on 2.6.19.1 *and* 2.6.16.36

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-next>] [day] [month] [year] [list]

Message-ID: <200612252344_MC3-1-D65C-20B2@compuserve.com>
Date:	Mon, 25 Dec 2006 23:42:32 -0500
From:	Chuck Ebbert <76306.1226@...puserve.com>
To:	"Christopher S. Aker" <caker@...shore.net>
Cc:	Patrick McHardy <kaber@...sh.net>,
	Santiago Garcia Mantinan <manty@...ty.net>,
	linux-kernel@...r.kernel.org, ebtables-devel@...ts.sourceforge.net
Subject: Re: ebtables problems on 2.6.19.1 *and* 2.6.16.36

In-Reply-To: <458DEF02.90908@...shore.net>

On Sat, 23 Dec 2006 22:07:46 -0500, Christopher S. Aker wrote:

> We're hitting this too, on both 2.6.16.36 and 2.6.19.1.
> 
> BUG: unable to handle kernel paging request at virtual address f8cec008
>   printing eip:
> c0462272
> *pde = 00000000
> Oops: 0000 [#1]
> SMP
> Modules linked in: e1000
> CPU:    1
> EIP:    0060:[<c0462272>]    Not tainted VLI
> EFLAGS: 00010286   (2.6.19.1-1-bigmem #1)
> EIP is at translate_table+0x2b3/0xddf

> Considering I've never had these problems before, and that both stable 
> (2.6.16.36) and current (2.6.19.1) exhibit this issue, I'd venture to 
> guess that it's something that went into both of them very recently.

Bingo!

It is dying here:

 static inline int
 ebt_check_entry(struct ebt_entry *e, struct ebt_table_info *newinfo,
    const char *name, unsigned int *cnt, unsigned int valid_hooks,
    struct ebt_cl_stack *cl_s, unsigned int udc_cnt)
 {
        struct ebt_entry_target *t;
        struct ebt_target *target;
        unsigned int i, j, hook = 0, hookmask = 0;
        size_t gap = e->next_offset - e->target_offset; <================
        int ret;

        /* don't mess with the struct ebt_entries */
        if (e->bitmask == 0)
                return 0;


when trying to access e->next_offset, which may or may not exist because
'e' sometimes points to a 'struct ebt_entries', not 'struct ebt_entry'
(note the comment before the 'if'.) This code was recently added.

So this (untested) patch should fix it (I tried to move the computation to
a place where it's efficient.)  If so it's needed for 2.6.16.x, 2.6.18.x,
2.6.19.x and 2.6.20-rc.


ebtables: don't compute gap until we know we have an ebt_entry

We must check the bitmap field to make sure we have an ebt_entry and
not an ebt_entries struct before using fields from ebt_entry.

Signed-off-by: Chuck Ebbert <76306.1226@...puserve.com>

--- 2.6.19.1-32smp.orig/net/bridge/netfilter/ebtables.c
+++ 2.6.19.1-32smp/net/bridge/netfilter/ebtables.c
@@ -575,7 +575,7 @@ ebt_check_entry(struct ebt_entry *e, str
 	struct ebt_entry_target *t;
 	struct ebt_target *target;
 	unsigned int i, j, hook = 0, hookmask = 0;
-	size_t gap = e->next_offset - e->target_offset;
+	size_t gap;
 	int ret;
 
 	/* don't mess with the struct ebt_entries */
@@ -625,6 +625,7 @@ ebt_check_entry(struct ebt_entry *e, str
 	if (ret != 0)
 		goto cleanup_watchers;
 	t = (struct ebt_entry_target *)(((char *)e) + e->target_offset);
+	gap = e->next_offset - e->target_offset;
 	target = find_target_lock(t->u.name, &ret, &ebt_mutex);
 	if (!target)
 		goto cleanup_watchers;
-- 
MBTI: IXTP
-
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/