Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Bug#929527: /usr/sbin/xtables-nft-multi: restoring IP Tables with an self-defined chain segfaults in libnftnl.so
90 views
Skip to first unread message
Thomas Lamprecht
May 25, 2019, 1:00:02 PM5/25/19
to
Package: iptables
Version: 1.8.2-4
Severity: grave
File: /usr/sbin/xtables-nft-multi
Justification: renders package unusable by segfaulting on usage
Dear Maintainer,
First, it may be that this should be actually filed against nftables,
so I'd like to say sorry in advance if made noise to the wrong people.
Anyway, on a Debian Stretch system installed from latest weekly ISO
restoring a relative simple IP Table with a single "intermediate" chain
causes a segfaul and no restoration of said table.
Reproducer:
# cat simple-segv-table
*filter
:NEW-OUTPUT - [0:0]
-A OUTPUT -j NEW-OUTPUT
-F NEW-OUTPUT
-A NEW-OUTPUT -j ACCEPT
COMMIT
# iptables ./simple-segv-table
Segmentation fault
# dmesg | tail -1
[12860.813350] traps: iptables-restor[19173] general protection ip:7f4894682793 sp:7ffcedc177d0 error:0 in libnftnl.so.11.0.0[7f4894677000+17000]
# addr2line -e /usr/lib/x86_64-linux-gnu/libnftnl.so.11.0.0 -fCi $(printf "%x" $[0x7f2cb9882793 - 0x7f2cb9877000])
nftnl_batch_is_supported
??:?
(hope that my addr2line foo isn't to much off)
Above example works just fine on a Debian Stretch 9.9 based machine.
As intially I produced this on a, let's say, far from minimal and a bit
Frankenstein'ed Buster, I installed the netinst weekly ISO again in a
QEMU/KVM backed VM, same outcome.
As said, this may well be an issue in the linked libnftnl shared
library, but could also be an issue from how iptables uses it, as I
produced the error by calling into a iptables provided binary I choose
to report it here (not sure if one can report against multiple
packages).
-- System Information:
Debian Release: 10.0
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 4.19.0-5-amd64 (SMP w/16 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages iptables depends on:
ii libc6 2.28-10
ii libip4tc0 1.8.2-4
ii libip6tc0 1.8.2-4
ii libiptc0 1.8.2-4
ii libmnl0 1.0.4-2
ii libnetfilter-conntrack3 1.0.7-1
ii libnfnetlink0 1.0.1-3+b1
ii libnftnl11 1.1.2-2
ii libxtables12 1.8.2-4
Versions of packages iptables recommends:
ii nftables 0.9.0-2
Versions of packages iptables suggests:
ii kmod 26-1
-- no debconf information
Version: 1.8.2-4
Severity: grave
File: /usr/sbin/xtables-nft-multi
Justification: renders package unusable by segfaulting on usage
Dear Maintainer,
First, it may be that this should be actually filed against nftables,
so I'd like to say sorry in advance if made noise to the wrong people.
Anyway, on a Debian Stretch system installed from latest weekly ISO
restoring a relative simple IP Table with a single "intermediate" chain
causes a segfaul and no restoration of said table.
Reproducer:
# cat simple-segv-table
*filter
:NEW-OUTPUT - [0:0]
-A OUTPUT -j NEW-OUTPUT
-F NEW-OUTPUT
-A NEW-OUTPUT -j ACCEPT
COMMIT
# iptables ./simple-segv-table
Segmentation fault
# dmesg | tail -1
[12860.813350] traps: iptables-restor[19173] general protection ip:7f4894682793 sp:7ffcedc177d0 error:0 in libnftnl.so.11.0.0[7f4894677000+17000]
# addr2line -e /usr/lib/x86_64-linux-gnu/libnftnl.so.11.0.0 -fCi $(printf "%x" $[0x7f2cb9882793 - 0x7f2cb9877000])
nftnl_batch_is_supported
??:?
(hope that my addr2line foo isn't to much off)
Above example works just fine on a Debian Stretch 9.9 based machine.
As intially I produced this on a, let's say, far from minimal and a bit
Frankenstein'ed Buster, I installed the netinst weekly ISO again in a
QEMU/KVM backed VM, same outcome.
As said, this may well be an issue in the linked libnftnl shared
library, but could also be an issue from how iptables uses it, as I
produced the error by calling into a iptables provided binary I choose
to report it here (not sure if one can report against multiple
packages).
-- System Information:
Debian Release: 10.0
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 4.19.0-5-amd64 (SMP w/16 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages iptables depends on:
ii libc6 2.28-10
ii libip4tc0 1.8.2-4
ii libip6tc0 1.8.2-4
ii libiptc0 1.8.2-4
ii libmnl0 1.0.4-2
ii libnetfilter-conntrack3 1.0.7-1
ii libnfnetlink0 1.0.1-3+b1
ii libnftnl11 1.1.2-2
ii libxtables12 1.8.2-4
Versions of packages iptables recommends:
ii nftables 0.9.0-2
Versions of packages iptables suggests:
ii kmod 26-1
-- no debconf information
Stoiko Ivanov
May 27, 2019, 6:30:03 AM5/27/19
to
Changing the iptables alternative to use the legacy binaries causes the
segfault not to occur.
segfault not to occur.
Thomas Lamprecht
Jun 25, 2019, 4:30:02 AM6/25/19
to
Don't want to nag to much but is there any news regarding this?
Buster is planned to release pretty soon (<2 weeks) and iptables
is quite a important package, IMO. Maybe it went under my radar
but I saw no unblock request on d.o release list.
For now I just used update-alternative to use the legacy variants,
which work fine here, but if my understanding is correct then this
package (version?) could be thrown out of Buster if it still has RC
bug so close to the planned release, I mean iptables may be an
exception as it's quite relevant and still used by a lot but still.
Buster is planned to release pretty soon (<2 weeks) and iptables
is quite a important package, IMO. Maybe it went under my radar
but I saw no unblock request on d.o release list.
For now I just used update-alternative to use the legacy variants,
which work fine here, but if my understanding is correct then this
package (version?) could be thrown out of Buster if it still has RC
bug so close to the planned release, I mean iptables may be an
exception as it's quite relevant and still used by a lot but still.
Thomas Lamprecht
Jun 26, 2019, 10:30:03 AM6/26/19
to
On 6/26/19 2:59 PM, Arturo Borrero Gonzalez wrote:
> On 6/26/19 2:28 PM, Thomas Lamprecht wrote:
>> Hmm, but that's a grave issue which may just render the firewall void
>> for _any_ intermediate chain and produces segmentation faults errors.
>>
> The issue you found is not a general-case issue.
> The segfault is only produced apparently if you:
>
> * define a custom chain
> * flush all rules of that custom chain (not required, because the chain was just
> created)
> * add a rule to that custom chain
>
> all in the same batch.
>
> I may understand that this is important for some scripts or robots making use of
> the iptables interface in that particular way, but is not the general case of
> how people define and add rules to custom chain/ruleset.
> Because of this, I think we should lower the severity of this bug.
I see this exactly the other way, this is the normal use case for
iptables-restore, i.e.:
* iptables-save before shutdown
* iptables-restore after boot
And in such an use all your points always happen in one batch. Also, all my
servers do it that way and I do not think that manual, rule-by-rule,
iptables editing is the norm or general case, like you're trying to suggest.
I only add new stuff this way, and that only quite seldom.
If I had not tried this before quite a few of my servers would have been
without any FW rule, no protection, no NAT masquerading for LANs, this
would have real and bad implications...
Because of this, I think the bug importance downgrade now should not be done,
this is IMO still grave.
I mean I and we as downstream distro with a few 100k users now know it and can
work around it, but I guess that this may hit quite some Debian users which update
to Buster without knowing that they would even need working around this.
> On 6/26/19 2:28 PM, Thomas Lamprecht wrote:
>> Hmm, but that's a grave issue which may just render the firewall void
>> for _any_ intermediate chain and produces segmentation faults errors.
>>
> The issue you found is not a general-case issue.
> The segfault is only produced apparently if you:
>
> * define a custom chain
> * flush all rules of that custom chain (not required, because the chain was just
> created)
> * add a rule to that custom chain
>
> all in the same batch.
>
> I may understand that this is important for some scripts or robots making use of
> the iptables interface in that particular way, but is not the general case of
> how people define and add rules to custom chain/ruleset.
> Because of this, I think we should lower the severity of this bug.
I see this exactly the other way, this is the normal use case for
iptables-restore, i.e.:
* iptables-save before shutdown
* iptables-restore after boot
And in such an use all your points always happen in one batch. Also, all my
servers do it that way and I do not think that manual, rule-by-rule,
iptables editing is the norm or general case, like you're trying to suggest.
I only add new stuff this way, and that only quite seldom.
If I had not tried this before quite a few of my servers would have been
without any FW rule, no protection, no NAT masquerading for LANs, this
would have real and bad implications...
Because of this, I think the bug importance downgrade now should not be done,
this is IMO still grave.
I mean I and we as downstream distro with a few 100k users now know it and can
work around it, but I guess that this may hit quite some Debian users which update
to Buster without knowing that they would even need working around this.
Rhonda D'Vine
Jun 28, 2019, 6:10:03 AM6/28/19
to
Hi,
* Arturo Borrero Gonzalez <art...@debian.org> [2019-06-26 14:14:50 CEST]:
> The last upstream release of iptables won't make it into Debian Buster at this
> point.
>
> Once buster is released I will:
>
> * provide uptodate package backports of newer upstream releases in
> buster-backports (for both iptables and nftables)
Please don't abuse backports for bugfixes that belong in stable. This
won't solve the issues for users of stable. Backports is for newer
features in software, not for offering bugfixes for stable.
> * for important bugs, I would try backporting concrete patches to the version in
> buster-stable.
The regression pointed out here through the switch of the default from
iptables-legacy to iptables-nft is kinda important, in my opinion.
Custom chains aren't really something exotic like you try to imply.
Most tools that offer a bit more of a complex possibility to maintain
your firewall settings are using them. And if a simple iptables-restore
can trigger this segfault for a setup that is far from exotic then it's
a regression that appears through the change of the tool that should
rather ring alarm clocks instead of trying to downplay the issue, in my
opinion. :/
I know that the release is happening next week, and I understand that
it is considered too late to do anything right now - but please think
about the impact of this for the first point release.
Thanks,
Rhonda
--
Fühlst du dich mutlos, fass endlich Mut, los |
Fühlst du dich hilflos, geh raus und hilf, los | Wir sind Helden
Fühlst du dich machtlos, geh raus und mach, los | 23.55: Alles auf Anfang
Fühlst du dich haltlos, such Halt und lass los |
* Arturo Borrero Gonzalez <art...@debian.org> [2019-06-26 14:14:50 CEST]:
> point.
>
> Once buster is released I will:
>
> * provide uptodate package backports of newer upstream releases in
> buster-backports (for both iptables and nftables)
Please don't abuse backports for bugfixes that belong in stable. This
won't solve the issues for users of stable. Backports is for newer
features in software, not for offering bugfixes for stable.
> * for important bugs, I would try backporting concrete patches to the version in
> buster-stable.
The regression pointed out here through the switch of the default from
iptables-legacy to iptables-nft is kinda important, in my opinion.
Custom chains aren't really something exotic like you try to imply.
Most tools that offer a bit more of a complex possibility to maintain
your firewall settings are using them. And if a simple iptables-restore
can trigger this segfault for a setup that is far from exotic then it's
a regression that appears through the change of the tool that should
rather ring alarm clocks instead of trying to downplay the issue, in my
opinion. :/
I know that the release is happening next week, and I understand that
it is considered too late to do anything right now - but please think
about the impact of this for the first point release.
Thanks,
Rhonda
--
Fühlst du dich mutlos, fass endlich Mut, los |
Fühlst du dich hilflos, geh raus und hilf, los | Wir sind Helden
Fühlst du dich machtlos, geh raus und mach, los | 23.55: Alles auf Anfang
Fühlst du dich haltlos, such Halt und lass los |
0 new messages