<html>
<head>
<base href="https://bugzilla.netfilter.org/" />
</head>
<body><table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>Bug ID</th>
<td><a class="bz_bug_link
bz_status_NEW "
title="NEW - iptables-restore cmd crash"
href="https://bugzilla.netfilter.org/show_bug.cgi?id=1713">1713</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>iptables-restore cmd crash
</td>
</tr>
<tr>
<th>Product</th>
<td>iptables
</td>
</tr>
<tr>
<th>Version</th>
<td>unspecified
</td>
</tr>
<tr>
<th>Hardware</th>
<td>All
</td>
</tr>
<tr>
<th>OS</th>
<td>All
</td>
</tr>
<tr>
<th>Status</th>
<td>NEW
</td>
</tr>
<tr>
<th>Severity</th>
<td>critical
</td>
</tr>
<tr>
<th>Priority</th>
<td>P5
</td>
</tr>
<tr>
<th>Component</th>
<td>iptables-restore
</td>
</tr>
<tr>
<th>Assignee</th>
<td>netfilter-buglog@lists.netfilter.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>xwlpt@126.com
</td>
</tr></table>
<p>
<div>
<pre>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@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:
<a href="https://git.netfilter.org/iptables/tree/libiptc/libiptc.c#n402">https://git.netfilter.org/iptables/tree/libiptc/libiptc.c#n402</a>
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:
<a href="https://git.netfilter.org/iptables/tree/libiptc/libiptc.c#n341">https://git.netfilter.org/iptables/tree/libiptc/libiptc.c#n341</a>
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
(<a href="https://git.netfilter.org/iptables/tree/libiptc/libiptc.c#n605">https://git.netfilter.org/iptables/tree/libiptc/libiptc.c#n605</a>), 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.
<a href="https://git.netfilter.org/iptables/tree/libiptc/libiptc.c#n544">https://git.netfilter.org/iptables/tree/libiptc/libiptc.c#n544</a></pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are watching all bug changes.</li>
</ul>
</body>
</html>