Bug 545600 - [abrt] crash detected in iptables-1.4.5-1.fc12
[abrt] crash detected in iptables-1.4.5-1.fc12
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: iptables (Show other bugs)
12
x86_64 Linux
low Severity medium
: ---
: ---
Assigned To: Thomas Woerner
Fedora Extras Quality Assurance
abrt_hash:755dd51860a649993bec6b65b1e...
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-12-08 17:16 EST by Thom Carlin
Modified: 2013-01-13 08:40 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-12-03 20:57:14 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Thom Carlin 2009-12-08 17:16:30 EST
abrt 1.0.0 detected a crash.

cmdline: iptables-restore /etc/sysconfig/iptables
component: iptables
executable: /sbin/iptables-multi
kernel: 2.6.31.5-127.fc12.x86_64
package: iptables-1.4.5-1.fc12
rating: 4
reason: Process was terminated by signal 6
Comment 1 Jeff Raber 2010-02-11 19:48:23 EST
Thom,  If you can, please provide a copy of /etc/sysconfig/iptables as it was when the bug occurred.

Did you modify your iptables rules to resolve the crash?  Or did it only crash once?  Were there any recent changes to the machine before the crash occurred?
Comment 2 Thom Carlin 2010-02-22 13:23:12 EST
Hi Jeff, it's been a bit since the crashes.  I believe after fc11 -> f12, iptables would crash repeatedly.  After testing, I rewrote the rules to avoid the crash.  I believe the crash had to do with The length of the chain name (> 28 characters).  It hadn't reoccurred since.

With the newer version of abrt, I am able to attach the backtrace (with minor editing -- the string length of the chain names is unchanged) below...

Core was generated by `iptables-restore /etc/sysconfig/iptables'.
Program terminated with signal 6, Aborted.
#0  0x00000031c30326b5 in raise (sig=<value optimized out>)
    at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
64	  return INLINE_SYSCALL (tgkill, 3, pid, selftid, sig);

Thread 1 (Thread 5118):
#0  0x00000031c30326b5 in raise (sig=<value optimized out>)
    at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
        resultvar = 0
        pid = <value optimized out>
        selftid = <value optimized out>
#1  0x00000031c3033e95 in abort () at abort.c:92
        save_stage = 2
        act = {__sigaction_handler = {sa_handler = 0x7fff9bb9d2c0, 
            sa_sigaction = 0x7fff9bb9d2c0}, sa_mask = {__val = {
              140735806034672, 140735806049996, 16, 213726250931, 3, 
              140735806034682, 6, 213726250935, 2, 140735806034670, 2, 
              213726244324, 1, 213726250931, 3, 140735806034678}}, 
          sa_flags = 10, sa_restorer = 0x31c313c7b7}
        sigs = {__val = {32, 0 <repeats 15 times>}}
#2  0x00000031c306ebe3 in __libc_message (do_abort=<value optimized out>, 
    fmt=<value optimized out>) at ../sysdeps/unix/sysv/linux/libc_fatal.c:186
        ap = {{gp_offset = 32, fp_offset = 48, 
            overflow_arg_area = 0x7fff9bb9dbf0, 
            reg_save_area = 0x7fff9bb9db00}}
        ap_copy = {{gp_offset = 16, fp_offset = 48, 
            overflow_arg_area = 0x7fff9bb9dbf0, 
            reg_save_area = 0x7fff9bb9db00}}
        fd = <value optimized out>
        on_2 = <value optimized out>
        list = <value optimized out>
        nlist = <value optimized out>
        cp = <value optimized out>
        written = <value optimized out>
#3  0x00000031c30f6ea7 in __fortify_fail (
    msg=0x31c313c7ba "buffer overflow detected") at fortify_fail.c:32
No locals.
#4  0x00000031c30f4ec0 in __chk_fail () at chk_fail.c:29
No locals.
#5  0x000000000040817a in strcpy (__src=<value optimized out>, 
    __dest=<value optimized out>) at /usr/include/bits/string3.h:106
No locals.
#6  do_command (__src=<value optimized out>, __dest=<value optimized out>)
    at iptables.c:1936
        size = 40
        fw = {ip = {src = {s_addr = 0}, dst = {s_addr = 0}, smsk = {
              s_addr = 0}, dmsk = {s_addr = 0}, 
            iniface = '\000' <repeats 15 times>, 
            outiface = '\000' <repeats 15 times>, 
            iniface_mask = '\000' <repeats 15 times>, 
            outiface_mask = '\000' <repeats 15 times>, proto = 0, 
            flags = 0 '\000', invflags = 0 '\000'}, nfcache = 0, 
          target_offset = 0, next_offset = 0, comefrom = 0, counters = {
            pcnt = 0, bcnt = 0}, 
          elems = 0x7fff9bb9ddd0 "\200\006\272\233\377\177"}
        e = 0x0
        invert = 0
        nsaddrs = 1
        ndaddrs = 1
        saddrs = 0xf98d20
        smasks = 0xf98d40
        daddrs = 0xf98d60
        dmasks = 0xf98d80
        c = <value optimized out>
        verbose = <value optimized out>
        chain = 0xf98630 "SnipSnipSnipSnipForward"
        shostnetworkmask = <value optimized out>
        dhostnetworkmask = <value optimized out>
        policy = <value optimized out>
        newname = <value optimized out>
        rulenum = <value optimized out>
        options = 16
        command = 16
        pcnt = <value optimized out>
        bcnt = <value optimized out>
        ret = 1
        m = <value optimized out>
        matches = 0x0
        matchp = <value optimized out>
        target = <value optimized out>
        t = <value optimized out>
        jumpto = <value optimized out>
        protocol = 0x0
        proto_used = <value optimized out>
        cnt = 0
#7  0x00000000004030ef in iptables_restore_main (argc=<value optimized out>, 
    argv=<value optimized out>) at iptables-restore.c:442
        a = 0
        escaped = <value optimized out>
        param_len = <value optimized out>
        pcnt = <value optimized out>
        bcnt = <value optimized out>
        parsestart = 0x7fff9bba0bc8 "\314\016\272\233\377\177"
        curchar = 0x7fff9bb9debe ""
        quote_open = <value optimized out>
        ret = 0
        handle = 0xf97250
        buffer = "-A SnipSnipSnipSnipForward -j SnipSnipSnipSnipForward-Error\n\000D -j ACCEPT\n\000--\n\000\"filter NULL portscan:  --log-tcp-sequence --log-tcp-options --log-ip-options --log-uid\n\000\n\000id\n\000 --log-uid", ' ' <repeats 152 times>, "\n", '\000' <repeats 7430 times>"\214"...
        c = <value optimized out>
        curtable = "filter", '\000' <repeats 26 times>
        in = <value optimized out>
        in_table = 1
        testing = <value optimized out>
        tablename = 0x0
#8  0x00000031c301eb1d in __libc_start_main (main=<value optimized out>, 
    argc=<value optimized out>, ubp_av=<value optimized out>, 
    init=<value optimized out>, fini=<value optimized out>, 
    rtld_fini=<value optimized out>, stack_end=<value optimized out>)
    at libc-start.c:220
        result = <value optimized out>
        unwind_buf = {cancel_jmp_buf = {{jmp_buf = {0, 4512226263753203436, 
                4203904, 140735806049216, 0, 0, -4512164181510545684, 
                4538823455587606252}, mask_was_saved = 0}}, priv = {pad = {
              0x0, 0x0, 0x31c280e22f, 0x0}, data = {prev = 0x0, 
              cleanup = 0x0, canceltype = -1031740881}}}
        not_first_call = <value optimized out>
#9  0x00000000004025a9 in _start ()
No symbol table info available.
Comment 3 Benny Amorsen 2010-03-16 09:35:27 EDT
I have the exact same problem. Shortening the chain name solves the problem.

It was a bit of fun to have a firewall start without any rules loaded after the upgrade from Fedora 11 to Fedora 12. This is a security issue.

Luckily we caught it in testing, but others may not be so lucky.
Comment 4 Benny Amorsen 2010-03-16 09:43:44 EDT
Problem persists in iptables-1.4.6-2.fc13.x86_64 and even iptables-1.4.7-1.fc14.x86_64.
Comment 5 Benny Amorsen 2010-03-16 11:04:16 EDT
Now reported upstream as http://bugzilla.netfilter.org/show_bug.cgi?id=641
Comment 6 Thomas Woerner 2010-03-16 11:35:19 EDT
The size of a chain name is not consistent:

1) Adding a new chain name is checking for max length 30:

iptabels.c:1881 ( do_command):
        if (chain && strlen(chain) > IPT_FUNCTION_MAXNAMELEN)
                xtables_error(PARAMETER_PROBLEM,
                           "chain name `%s' too long (must be under %i chars)",
                           chain, IPT_FUNCTION_MAXNAMELEN);

include/linux/netfilter_ipv4/ip_tables.h
#define IPT_FUNCTION_MAXNAMELEN XT_FUNCTION_MAXNAMELEN

include/linux/netfilter/x_tables.h:
#define XT_FUNCTION_MAXNAMELEN 30


2) Using a jump target results in a check for max length 31:

iptables.c:1564 (do_command):
                        jumpto = parse_target(optarg);


iptables.c:464 (parse_target):
        if (strlen(targetname)+1 > sizeof(ipt_chainlabel))
                xtables_error(PARAMETER_PROBLEM,
                           "Invalid target name `%s' (%u chars max)",
                           targetname, (unsigned int)sizeof(ipt_chainlabel)-1);

include/libiptc/libiptc.h:
        typedef char ipt_chainlabel[32];


3) But setting the target copies the name in an array of size 29:

iptables.c:1576 (do_command):
                                strcpy(target->t->u.user.name, jumpto);


include/linux/netfilter/x_tables.h:
struct xt_entry_match {
        union {
                struct {
                        __u16 match_size;

                        /* Used by userspace */
                        char name[XT_FUNCTION_MAXNAMELEN-1];

                        __u8 revision;
                } user;
                struct {
                        __u16 match_size;

                        /* Used inside the kernel */
                        struct xt_match *match;
                } kernel;

                /* Total length */
                __u16 match_size;
        } u;

        unsigned char data[0];
};

I have sent this also to the netfilter-devel list.
Comment 7 Bug Zapper 2010-11-03 23:53:02 EDT
This message is a reminder that Fedora 12 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 12.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '12'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 12's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 12 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 8 Bug Zapper 2010-12-03 20:57:14 EST
Fedora 12 changed to end-of-life (EOL) status on 2010-12-02. Fedora 12 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

Note You need to log in before you can comment on or make changes to this bug.