Re: iptable/netfilter mismatch

[Patrick McHardy <kaber@trash.net>]

Jesper Bengtsson wrote:
> Hi,
> 
> When running iptables on a CRIS cpu (ETRAX FS/100LX) I have a problem with adding error targets.
> I've debugged this problem and I found an iptables/netfilter mismatch.
> 
> The structure ipt_error_target is defined in two places:
> in the kernel, include/linux/netfilter_ipv4/ip_tables.h
> struct ipt_error_target
> {
>         struct ipt_entry_target target;
>         char errorname[IPT_FUNCTION_MAXNAMELEN];
> };
> 
> and in iptables, libiptc/libiptc.c
> struct ipt_error_target
> {
>         STRUCT_ENTRY_TARGET t;
>         char error[TABLE_MAXNAMELEN];
> };
> 
> Before a patch, claiming to fix things for CRIS
> (http://lists.netfilter.org/pipermail/netfilter-devel/2007-January/026659.html),
> was applied the two structs above had the same size. After the patch the two structs differ by two
> bytes in size and when iptables tries to commit an error target to netfilter, netfilter will discard
> it since the target has incorrect size. I believe that this will only occur on architectures that don't use structure alignment, e.g. CRIS.
> 
> When modifying the struct in libiptc/libiptc.c like this:
> 
> struct ipt_error_target
> {
>         STRUCT_ENTRY_TARGET t;
>         char error[FUNCTION_MAXNAMELEN];
> };
> 
> I can add error targets on my CRIS system.
> 
> I'm a iptables/netfilter newbie and I really can't say for sure if FUNCTION_MAXNAMELEN or TABLE_MAXNAMELEN is the correct length to use in the ipt_error_target structure.
> 
> Can anyone shed some light over the ipt_error_target structure?

The versions I'm looking at uses TABLE_MAXNAMELEN in userspace,
which is 32, and FUNCTION_MAXNAMELEN in the kernel, which is 30.
So yeah, this is still broken. "errorname" is not used within
the kernel at all and the limit of 30 doesn't make any sense,
so the correct fix appears to be to also use 32 within the kernel.

This shouldn't break anything since we align to u64 and the
architectures like CRIS where this causes less than 4 byte alignment
are currently broken, for all others it doesn't have any effect.

Could you send a patch against the latest -git tree please?