net-firewall/iptables 1.8.11 and 1.8.11-r1 segfault when invoked as: /usr/bin/iptables -A HOST_BLOCK_SRC_DROP -m limit --limit 1/m --limit-burst 1 -j LOG --log-level info --log-prefix FW:Blocked inbound host: Reproducible: Always Steps to Reproduce: 1.Run "/usr/bin/iptables -A HOST_BLOCK_SRC_DROP -m limit --limit 1/m --limit-burst 1 -j LOG --log-level info --log-prefix FW:Blocked inbound host:" 2. 3. Actual Results: ~ # /sbin/iptables -A HOST_BLOCK_SRC_DROP -m limit --limit 1/m --limit-burst 1 -j LOG --log-level info --log-prefix FW:Blocked inbound host: iptables v1.8.11 (legacy): Segmentation fault ~ # /sbin/ip6tables -A HOST_BLOCK_SRC_DROP -m limit --limit 1/m --limit-burst 1 -j LOG --log-level info --log-prefix FW:Blocked inbound host: ip6tables v1.8.11 (legacy): Segmentation fault The syslog shows: kernel: iptables[2914]: segfault at 10000000a ip 00007f5f13bbd6da sp 00007ffe57577908 error 4 in libc.so.6[7f5f13b36000+158000] likely on CPU 0 (core 0, socket 0) kernel: ip6tables[2919]: segfault at 10000000a ip 00007fbdf773e6da sp 00007ffc64202408 error 4 in libc.so.6[7fbdf76b7000+158000] likely on CPU 7 (core 3, socket 0) net-firewall/iptables =<1.8.10-r1 run with no such problems.
Created attachment 915994 [details] emerge.info emerge --info - attachment.
Created attachment 915995 [details] CPU FLAGS CPU FLAGS - attachment.
Created attachment 915996 [details] Backtrace Backtrace - attachment.
Created attachment 915997 [details] valgrind capture valgrind capture - attachment.
Could you rebuild with more debug info & sources (https://wiki.gentoo.org/wiki/Debugging#Per-package)? Line numbers would be helpful.
Created attachment 923608 [details] Additional backtrace I hope this backtrace has enough information.
Hi Sam, (In reply to MickKi from comment #6) > Created attachment 923608 [details] > Additional backtrace > > I hope this backtrace has enough information. I've followed the debugging wiki page, but I am not sure if I've missed anything. Please let me know what additional info may be required.
Thanks! I've attempted to report it upstream but their Bugzilla isn't working for me. I've emailed their administrators for help.
Created attachment 925000 [details] iptables-draft-bug.txt Attached my draft text for the upstream bug so I don't lose it.
The crash seems impossible looking at the code. Do you perhaps have a stale DSO in /usr/lib64/xtables/? Could you please paste the output of 'ls /usr/lib64/xtables/lib*_LOG.so'?
Thank you Phil, I seem to have three files listed: ~ # ls -la /usr/lib64/xtables/lib*_LOG.so -rwxr-xr-x 1 root root 14616 Nov 20 2022 /usr/lib64/xtables/libip6t_LOG.so -rwxr-xr-x 1 root root 14616 Nov 20 2022 /usr/lib64/xtables/libipt_LOG.so -rwxr-xr-x 1 root root 15208 Apr 6 13:58 /usr/lib64/xtables/libxt_LOG.so
(In reply to MickKi from comment #11) > Thank you Phil, I seem to have three files listed: > > ~ # ls -la /usr/lib64/xtables/lib*_LOG.so > -rwxr-xr-x 1 root root 14616 Nov 20 2022 /usr/lib64/xtables/libip6t_LOG.so > -rwxr-xr-x 1 root root 14616 Nov 20 2022 /usr/lib64/xtables/libipt_LOG.so > -rwxr-xr-x 1 root root 15208 Apr 6 13:58 /usr/lib64/xtables/libxt_LOG.so The last file belongs to iptables, but qfile did not come up with any owners for the first two. I moved these out of the way and the latest iptables version no longer segfaults. Clearly my segfault problem was caused by these two files and not by an iptables bug. Thank you for pointing me to the cause of it and sorry for the noise. Any idea what had left behind libip6t_LOG.so and libipt_LOG.so?
(In reply to MickKi from comment #12) > (In reply to MickKi from comment #11) > > Thank you Phil, I seem to have three files listed: > > > > ~ # ls -la /usr/lib64/xtables/lib*_LOG.so > > -rwxr-xr-x 1 root root 14616 Nov 20 2022 /usr/lib64/xtables/libip6t_LOG.so > > -rwxr-xr-x 1 root root 14616 Nov 20 2022 /usr/lib64/xtables/libipt_LOG.so > > -rwxr-xr-x 1 root root 15208 Apr 6 13:58 /usr/lib64/xtables/libxt_LOG.so > > The last file belongs to iptables, but qfile did not come up with any owners > for the first two. I moved these out of the way and the latest iptables > version no longer segfaults. I'm glad we found the cause. > Clearly my segfault problem was caused by these two files and not by an > iptables bug. Thank you for pointing me to the cause of it and sorry for > the noise. > > Any idea what had left behind libip6t_LOG.so and libipt_LOG.so? That's a question for the packager(s). Upstream, we merged libip6t_LOG and libipt_LOG into libxt_LOG at some point. So these should have been removed during an update.
Thank you very much both of you! I'll ask around but so far, nobody seems to have any idea if there was some historical reason that could've happened.
Thank you Sam, the only historical reason I can think of is this system was recovered from a failing drive. Following the recovery the whole @system and @world was rebuilt. Perhaps some shrapnel was left behind which caused these obsolete files to hang around? No other systems have come up with this error, which with hindsight makes me conclude this is very much an one off and filesystem specific problem. Please don't waste any more time on it - I can see you're busy enough as it is! :-)
(In reply to MickKi from comment #15) Ah, it is likely that /var/db/pkg was out-of-sync, which caused some files to be orphaned when iptables was reinstalled.
