Control: severity -1 serious Control: tag -1 pending Hi Gabor,
(I'm cc-ing the iptables maintainers so that they can correct me if I'm wrong in my findings below; iproute2's maintainer Alexander; and Julian who proposed an update to a new upstream release. Spoiler alert: I'm proposing to fix the most obvious issues in a targetted way.) Gabor Zsoldos <z...@zalaszam.hu> (2017-07-11): > Package: iproute2 > Version: 4.9.0-1 > Severity: normal I'm bumping severity, since a tc segfault is pretty bad… > This is a known and corrected bug in the mainstream. > See: > https://git.kernel.org/pub/scm/linux/kernel/git/shemminger/iproute2.git/commit/?h=v4.10.0&id=97a02cabefb2e2dcfe27f89943709afa84be5525 So, I've checked what happened with iptables 1.6, and tracked this down to this splendidly huge commit in iptables.git: | commit 384958620abab397062b67fb2763e813b63f74f0 | Author: Pablo Neira Ayuso <pa...@netfilter.org> | Date: Thu Sep 27 19:12:53 2012 +0200 | | use nf_tables and nf_tables compatibility interface | […] | 23 files changed, 5723 insertions(+), 5 deletions(-) Basically, it introduces a new field (compat_rev) in the xtables_globals structure, and that one needs to be initialized by library users. I've only quickly checked codesearch but it seems the 6 following packages contains hits for this structure: + connman: src/iptables.c has: .compat_rev = xtables_compatible_revision + iproute2: this bug report. + iptables: not relevant. :) + kamailio: modules/iptrtpproxy/iptrtpproxy.c only defines a NULL pointer, which is unused anyway. + nftables: src/xt.c has .compat_rev = nft_xt_compatible_revision + python-iptables: python-iptables-0.11.0/iptc/xtables.py has an xtables_version > 10 test and sets _xt_globals.compat_rev = _xt_compat_rev So it seems to me that the iproute2 package is the only one needing an update (both in unstable and in stable). That's good news! Unfortunately, cherry-picking the upstream patch above does only solve the segfault, but tc isn't fully functional anyway. Trying to set up some rules, one can get such output: tc-ipt v0.2: Extension does not know id 1504083504 A few reports online mention that deleting include/xtables.h solved the problem. I've verified this hypothesis practically (tc seems to do its job properly), but also double checked why this happens. This upstream commit adds a function pointer right in the middle of two structures (xtables_match and xtables_target): | commit 7a0992da44cfb6cab0ccd1beadcf326df8773552 | Author: Pablo Neira Ayuso <pa...@netfilter.org> | Date: Sun Jul 24 12:45:53 2016 +0200 | | src: introduce struct xt_xlate_{mt,tg}_params | […] | 56 files changed, 279 insertions(+), 261 deletions(-) So iproute2 being compiled against an outdated version of iptables's include/xtables.h header, the resulting m_xt.so plugin gets the wrong offset for a bunch of structure members (checked by comparing objdump's output directly, or with diffoscope), which leads to the issue mentioned above. Syncing the header with stretch's iptables makes it work again, so I think I'll add a patch to update it this way. (There were no further changes regarding this header between stretch and unstable yet.) There are probably reasons for including a copy of the header instead of using the system one (probably because such things are common when it comes to kernel-related headers), but deleting the header entirely would work as well. I'll upload an NMU to unstable shortly and push appropriate patches to the collab-maint repository. If everything looks fine enough, I'll move to proposing an update to stretch through stretch-proposed-updates. Cheers, -- Cyril Brulebois -- Debian Consultant @ DEBAMAX -- https://debamax.com/
signature.asc
Description: PGP signature
