Re: Iptable loop during kernel startup

Re: Iptable loop during kernel startup

[Patrick McHardy]

Mikael Starvik wrote:
> I have a kernel with
> 
> CONFIG_IP_NF_TABLES=y
> CONFIG_IP_NF_FILTER=y
> CONFIG_IP_NF_TARGET_LOG=y
> 
> all other NF options are off.

Which iptables/kernel versions are you using?

> During kernel startup I get
> iptables: loop hook 1 pos 00000022
> 
> when filter tries to register at module_init.
> 
> Any ideas why I get this loop?

Please post your ruleset and the kernel config.

RE: Iptable loop during kernel startup

[Mikael Starvik]

>Which iptables/kernel versions are you using?

2.6.19. After further testing it seams to be a compiler/CPU issue. The exact

same kernelconfig works on ARM. So I have to dig some...

/Mikael

Re: Iptable loop during kernel startup

[Patrick McHardy]

Mikael Starvik wrote:
>>Which iptables/kernel versions are you using?
> 
> 
> 2.6.19. After further testing it seams to be a compiler/CPU issue. The exact
> 
> same kernelconfig works on ARM. So I have to dig some...

On which architecture did the error occur? It could be related
to 32 bit compat issues ..

RE: Iptable loop during kernel startup

[Mikael Starvik]

Ok, this is what happens:

iptable_filter sets up initial_table.
The part that says { IPT_ALIGN(sizeof(struct ipt_standard_target)), "" }
  initializes a xt_entry_target struct. target_size gets the value 
  0x24 and name "". 
This is copied to loc_cpu_entry in iptables.c:ipt_register_table() 
  and translate_table is called
translate_table calls IPT_ENTRY_ITERATE with the 
  check_entry_function
check_entry does t->u.kernel.target = target;

On this particular architecture u.user.name and u.kernel.target in 
struct xt_entry_target has the same address (because of the union). So 
name that was previously "" gets mangled here.

check_entry returns into translate_table which calls mark_source_chains
mark_source_chains compares t->target.u.user.name with 
IPT_STANDARD_TARGET. name has been mangled above and the comparision 
fails. On my ARM platform name has not been mangled (I guess this is 
because target and name doesn't share address by I haven't checked).

So... Is it really correct to modify the target pointer there?

/Mikael



-----Original Message-----
From: Mikael Starvik 
Sent: Wednesday, January 10, 2007 12:29 PM
To: 'Patrick McHardy'; Mikael Starvik
Cc: 'Linux Kernel Mailing List'; Edgar Iglesias; 'Netfilter Development
Mailinglist'
Subject: RE: Iptable loop during kernel startup


>Which iptables/kernel versions are you using?

2.6.19. After further testing it seams to be a compiler/CPU issue. The exact

same kernelconfig works on ARM. So I have to dig some...

/Mikael

RE: Iptable loop during kernel startup

[Mikael Starvik]

The architecture is called CRIS. Its a straightforward 32-bit only arch. The

only special about this architecture that it doesn't force any alignment of 
data (so a packed struct and an unpacked struct is always the same).

/Mikael
-----Original Message-----
From: Patrick McHardy [mailto:kaber@trash.net] 
Sent: Wednesday, January 10, 2007 1:50 PM
To: Mikael Starvik
Cc: 'Linux Kernel Mailing List'; Edgar Iglesias; 'Netfilter Development
Mailinglist'
Subject: Re: Iptable loop during kernel startup


Mikael Starvik wrote:
>>Which iptables/kernel versions are you using?
> 
> 
> 2.6.19. After further testing it seams to be a compiler/CPU issue. The
exact
> 
> same kernelconfig works on ARM. So I have to dig some...

On which architecture did the error occur? It could be related
to 32 bit compat issues ..

Re: Iptable loop during kernel startup

[Patrick McHardy]

Mikael Starvik wrote:
> Ok, this is what happens:
> 
> iptable_filter sets up initial_table.
> The part that says { IPT_ALIGN(sizeof(struct ipt_standard_target)), "" }
>   initializes a xt_entry_target struct. target_size gets the value 
>   0x24 and name "". 
> This is copied to loc_cpu_entry in iptables.c:ipt_register_table() 
>   and translate_table is called
> translate_table calls IPT_ENTRY_ITERATE with the 
>   check_entry_function
> check_entry does t->u.kernel.target = target;
> 
> On this particular architecture u.user.name and u.kernel.target in 
> struct xt_entry_target has the same address (because of the union). So 
> name that was previously "" gets mangled here.
> 
> check_entry returns into translate_table which calls mark_source_chains
> mark_source_chains compares t->target.u.user.name with 
> IPT_STANDARD_TARGET. name has been mangled above and the comparision 
> fails. On my ARM platform name has not been mangled (I guess this is 
> because target and name doesn't share address by I haven't checked).
> 
> So... Is it really correct to modify the target pointer there?


Please try the latest -stable kernel, this should be fixed already.