ctnetlink expect dumping bug

ctnetlink expect dumping bug

[Harald Welte]

[-- Attachment #1: Type: text/plain, Size: 1442 bytes --]

Hi!

While doing some nf_conntrack development, I hit a bug that I originally
thought to be in my modifications.

However, after reverting all my patches, the bug persists.

The issue is that for dumping the expect mask, we use regular tuple
dumping functions.  Those regular dumping functions call proto_find_get
and l3proto_find_get with protocol value 0xffff, which leads to an array
overflow in those NPROTO sized arrays.

Rather than using the mask value, we'd need to pass the respective value
from the expect tuple for dumping the expect mask.

From looking at the code, it seems the bug also exists in
ip_conntrack_netlink, but I didn't really test it.

Pablo, would you please prepare a fix for this, and confirm it by having
helpers create expectations inside the kernel while running 'conntrack
-E' ?

Thanks.

p.s.: Patrick and me agreed last week to re-work the structure of an
expectation (and its handling).  Despite any of those (probably 2.6.17)
changes, we need to fix this bug in the current upstream stable releases
now.

-- 
- Harald Welte <laforge@netfilter.org>                 http://netfilter.org/
============================================================================
  "Fragmentation is like classful addressing -- an interesting early
   architectural error that shows how much experimentation was going
   on while IP was being designed."                    -- Paul Vixie

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: ctnetlink expect dumping bug

[Pablo Neira Ayuso]

Hi!

Harald Welte wrote:
> The issue is that for dumping the expect mask, we use regular tuple
> dumping functions.  Those regular dumping functions call proto_find_get
> and l3proto_find_get with protocol value 0xffff, which leads to an array
> overflow in those NPROTO sized arrays.
> 
> Rather than using the mask value, we'd need to pass the respective value
> from the expect tuple for dumping the expect mask.
> 
> From looking at the code, it seems the bug also exists in
> ip_conntrack_netlink, but I didn't really test it.

No problem, ip_conntrack doesn't have the l3num field.

> Pablo, would you please prepare a fix for this, and confirm it by having
> helpers create expectations inside the kernel while running 'conntrack
> -E' ?

I did, we're still discussing :). Anyway Patrick have workaround for
this but it still remains a bit tricky. Please have a look at:

expectation mask handling in nfctnetlink (Was Re: [PATCH] fix
nf_conntrack_netlink expectation dumping/event notification)

cheers,

-- 
Pablo

Re: ctnetlink expect dumping bug

[Harald Welte]

[-- Attachment #1: Type: text/plain, Size: 1006 bytes --]

On Wed, Feb 01, 2006 at 03:14:24AM +0100, Pablo Neira Ayuso wrote:

> > From looking at the code, it seems the bug also exists in
> > ip_conntrack_netlink, but I didn't really test it.
> 
> No problem, ip_conntrack doesn't have the l3num field.

the same problem exists with the 'proto' field.

> > Pablo, would you please prepare a fix for this, and confirm it by having
> > helpers create expectations inside the kernel while running 'conntrack
> > -E' ?
> 
> I did, we're still discussing :). Anyway Patrick have workaround for
> this but it still remains a bit tricky. Please have a look at:

ok, I'll look at it.
-- 
- Harald Welte <laforge@netfilter.org>                 http://netfilter.org/
============================================================================
  "Fragmentation is like classful addressing -- an interesting early
   architectural error that shows how much experimentation was going
   on while IP was being designed."                    -- Paul Vixie

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]