[Bug 1713] New: iptables-restore cmd crash

[bugzilla-daemon at netfilter.org]

https://bugzilla.netfilter.org/show_bug.cgi?id=1713

            Bug ID: 1713
           Summary: iptables-restore cmd crash
           Product: iptables
           Version: unspecified
          Hardware: All
                OS: All
            Status: NEW
          Severity: critical
          Priority: P5
         Component: iptables-restore
          Assignee: netfilter-buglog at lists.netfilter.org
          Reporter: xwlpt at 126.com

Recently I met an issue on the iptables-restore command, when I run the
command:

iptables-restore -T filter --noflush < replace

It shows the Segmentation fault error.

Then I did further check. Here are my findings.

The backtrace:

Reading symbols from /home/centos/bin/iptbales/sbin/iptables-restore...

[New LWP 3272596]

[Thread debugging using libthread_db enabled]

Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Core was generated by `/home/centos/bin/iptbales/sbin/iptables-restore -T
filter --noflush'.

Program terminated with signal SIGSEGV, Segmentation fault.

#0  __strcmp_evex () at ../sysdeps/x86_64/multiarch/strcmp-evex.S:139

139 ../sysdeps/x86_64/multiarch/strcmp-evex.S: No such file or directory.

(gdb) bt

#0  __strcmp_evex () at ../sysdeps/x86_64/multiarch/strcmp-evex.S:139

#1  0x00007f2c961c4810 in __iptcc_bsearch_chain_index
(name=name at entry=0x55b9b4177490 "SNTL_F_set_d2ebb6067e1f5247",
offset=offset at entry=0,

    idx=idx at entry=0x7ffc5ed6e654, handle=handle at entry=0x55b9b37ad2b0,
type=type at entry=BSEARCH_NAME) at /root/iptables-1.8.9/libiptc/libiptc.c:402

#2  0x00007f2c961c4c2c in iptcc_bsearch_chain_index (handle=0x55b9b37ad2b0,
idx=0x7ffc5ed6e654, name=0x55b9b4177490 "SNTL_F_set_d2ebb6067e1f5247")

    at /root/iptables-1.8.9/libiptc/libiptc.c:425

#3  iptcc_find_label (name=name at entry=0x55b9b4177490
"SNTL_F_set_d2ebb6067e1f5247", handle=handle at entry=0x55b9b37ad2b0)

    at /root/iptables-1.8.9/libiptc/libiptc.c:734

#4  0x00007f2c961c67d0 in iptc_rename_chain
(oldname=oldname at entry=0x55b9b4177460 "STMP_F_set_d2ebb6067e1f5247",

    newname=newname at entry=0x55b9b4177490 "SNTL_F_set_d2ebb6067e1f5247",
handle=0x55b9b37ad2b0) at /root/iptables-1.8.9/libiptc/libiptc.c:2373

#5  0x000055b9b2db67a5 in do_command4 (argc=<optimized out>,
argv=argv at entry=0x7ffc5ed6ea58, table=table at entry=0x7ffc5ed6ea68,

    handle=handle at entry=0x7ffc5ed6ea28, restore=restore at entry=true) at
iptables.c:861

#6  0x000055b9b2db3f30 in ip46tables_restore_main (cb=0x55b9b2dbca00
<ipt_restore_cb>, argc=argc at entry=4, argv=argv at entry=0x7ffc5ed71ff8,

    cb=0x55b9b2dbca00 <ipt_restore_cb>) at iptables-restore.c:338

#7  0x000055b9b2db4744 in iptables_restore_main (argc=4, argv=0x7ffc5ed71ff8)
at iptables-restore.c:388

#8  0x00007f2c95fbbd90 in __libc_start_call_main
(main=main at entry=0x55b9b2daddc0 <main>, argc=argc at entry=4,
argv=argv at entry=0x7ffc5ed71ff8)

    at ../sysdeps/nptl/libc_start_call_main.h:58

#9  0x00007f2c95fbbe40 in __libc_start_main_impl (main=0x55b9b2daddc0 <main>,
argc=4, argv=0x7ffc5ed71ff8, init=<optimized out>, fini=<optimized out>,

    rtld_fini=<optimized out>, stack_end=0x7ffc5ed71fe8) at
../csu/libc-start.c:392

#10 0x000055b9b2daddf5 in _start ()




This is the line that code crashed:

https://git.netfilter.org/iptables/tree/libiptc/libiptc.c#n402

Looks like the pos+1 out of the bound of array handle->chain_index


After I enabled the debug logs of iptables, then we can see the context:

https://git.netfilter.org/iptables/tree/libiptc/libiptc.c#n341


bsearch Find chain:SNTL_F_set_cf70fcb2da2c9d75 (pos:2 end:5) (offset:0)

bsearch Index[2] name:SNTL_F_set_847f79f7c669e9bb res:43 jump forward to pos:3
(end:5)

bsearch Index[3] name:SNTL_F_set_c8da4e747a025ea3 res:46


We can see that when pos=3, then pos+1 will out the boundary of array
handle->chain_index, but the array size supposed to be handle->chain_index_sz =
5.


So there should be code bugs in the iptables-restore command.


After check for more, I'd think it triggered by following code path:

TC_RENAME_CHAIN->iptcc_chain_index_delete_chain->iptcc_chain_index_rebuild

In this function, there are chain deleted
(https://git.netfilter.org/iptables/tree/libiptc/libiptc.c#n605), which makes
the num_chain to be decreased from 161 to 160 (In the test, we are restore for
161 chains), then it will generate the array handle->chain_index with  only 4
elements (160/40), but keep handle->chain_index_sz = 5.
https://git.netfilter.org/iptables/tree/libiptc/libiptc.c#n544

-- 
You are receiving this mail because:
You are watching all bug changes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.netfilter.org/pipermail/netfilter-buglog/attachments/20231008/59b6894a/attachment.html>