Hi Maintainer:
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.
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@entry=0x55b9b4177490 "SNTL_F_set_d2ebb6067e1f5247",
offset=offset@entry=0,
idx=idx@entry=0x7ffc5ed6e654, handle=handle@entry=0x55b9b37ad2b0,
type=type@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@entry=0x55b9b4177490
"SNTL_F_set_d2ebb6067e1f5247", handle=handle@entry=0x55b9b37ad2b0)
at /root/iptables-1.8.9/libiptc/libiptc.c:734
#4 0x00007f2c961c67d0 in iptc_rename_chain
(oldname=oldname@entry=0x55b9b4177460 "STMP_F_set_d2ebb6067e1f5247",
newname=newname@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@entry=0x7ffc5ed6ea58, table=table@entry=0x7ffc5ed6ea68,
handle=handle@entry=0x7ffc5ed6ea28, restore=restore@entry=true) at
iptables.c:861
#6 0x000055b9b2db3f30 in ip46tables_restore_main (cb=0x55b9b2dbca00
<ipt_restore_cb>, argc=argc@entry=4, argv=argv@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@entry=0x55b9b2daddc0 <main>, argc=argc@entry=4,
argv=argv@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
I had requested an account for bugzilla to report this bug, but for a
long time no response.
Appreciate that someone can have a check for this issue, thanks.
