bugzilla-daemon at netfilter.org
2023-Sep-03 17:05 UTC
[Bug 1702] New: iptables fails to parse interface wildcard "-i +" correctly
https://bugzilla.netfilter.org/show_bug.cgi?id=1702
Bug ID: 1702
Summary: iptables fails to parse interface wildcard "-i +"
correctly
Product: iptables
Version: 1.8.x
Hardware: x86_64
OS: Ubuntu
Status: NEW
Severity: major
Priority: P5
Component: iptables
Assignee: netfilter-buglog at lists.netfilter.org
Reporter: thomas.strangert at emblasoft.com
If I enter a simple iptables rule that uses the "-i +" input interface
wildcard
thing in it, but note that I don't give any interface namestring
"prefix"
before the "+" - for example:
iptables -A INPUT -i + -d 192.168.1.10 -j DROP
iptables -A INPUT -i + -d 192.168.1.11 -j DROP
iptables -A INPUT -i + -d 192.168.1.12 -j DROP
Then printouts of both iptables-save and iptables -L -n -v will show weird
non-ascii/non-printable characters where the interfaces are supposed to be
printed!
The result for my rule example above shows as:
-A INPUT -d 192.168.80.10/32 -i ??P
+ -j DROP
-A INPUT -d 192.168.80.11/32 -i ??P?+ -j DROP
-A INPUT -d 192.168.80.12/32 -i ??P + -j DROP
(The garbage chars in hex were for me \c0\a8\50\0a, \c0\a8\50\0b, \c0\a8\50\0c
respectively. Note the \0a newline char breaking up the printout into two lines
for the first rule.)
The garbage characters makes
"iptables-save > /etc/iptables/rules.v4"
followed up with
"iptables-restore < /etc/iptables/rules.v4"
to fail!
I discovered that if the rule also includes some "protocol"
constraints like
"-p tcp -m tcp --dport 123" then iptables parses/prints the rule
seemingly ok,
but for "simpler" rules iptables gets confused.
However, adding a state constraint like "-m conntrack --ctstate NEW"
will still
make the bug happen.
Notes about (possibly) related bug reports:
https://bugzilla.netfilter.org/show_bug.cgi?id=1085
https://bugs.launchpad.net/ubuntu/+source/iptables/+bug/2033663
--
You are receiving this mail because:
You are watching all bug changes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.netfilter.org/pipermail/netfilter-buglog/attachments/20230903/5ebebbed/attachment.html>
bugzilla-daemon at netfilter.org
2023-Sep-04 12:10 UTC
[Bug 1702] iptables fails to parse interface wildcard "-i +" correctly
https://bugzilla.netfilter.org/show_bug.cgi?id=1702 --- Comment #1 from thomas.strangert at emblasoft.com --- For clarity: I made a copy-paste/edit error with the IP addresses when writing the bug report, happened to first give IPs in the 192.168.1.x subnet then as 192.168.80.x. This is a textual error here. In the actual server where I found the bug, both subnets are the same. -- You are receiving this mail because: You are watching all bug changes. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.netfilter.org/pipermail/netfilter-buglog/attachments/20230904/28600f23/attachment.html>
bugzilla-daemon at netfilter.org
2023-Sep-05 12:00 UTC
[Bug 1702] iptables fails to parse interface wildcard "-i +" correctly
https://bugzilla.netfilter.org/show_bug.cgi?id=1702
Phil Sutter <phil at nwl.cc> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |ASSIGNED
CC| |phil at nwl.cc
Assignee|netfilter-buglog at lists.netf |phil at nwl.cc
|ilter.org |
--- Comment #2 from Phil Sutter <phil at nwl.cc> ---
I can neither reproduce this with current HEAD nor v1.8.7 tag. Is this a
downstream issue? I see you're facing the problem with
iptables-1.8.7-1ubuntu5.1, can you try to reproduce with a vanilla build?
Also, you could try calling:
valgrind --leak-check=full iptables -A INPUT -i + -d 192.168.1.10 -j DROP
It should report garbage data read and give some
details as to where/why it happens.
--
You are receiving this mail because:
You are watching all bug changes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.netfilter.org/pipermail/netfilter-buglog/attachments/20230905/cc32d228/attachment.html>
bugzilla-daemon at netfilter.org
2023-Sep-05 12:52 UTC
[Bug 1702] iptables fails to parse interface wildcard "-i +" correctly
https://bugzilla.netfilter.org/show_bug.cgi?id=1702 --- Comment #3 from thomas.strangert at emblasoft.com --- # valgrind --leak-check=full iptables -A INPUT -i + -d 192.168.8.13 -j DROP ==3046844== Memcheck, a memory error detector ==3046844== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==3046844== Using Valgrind-3.18.1 and LibVEX; rerun with -h for copyright info ==3046844== Command: iptables -A INPUT -i + -d 192.168.8.13 -j DROP ==3046844===3046844== Syscall param socketcall.sendto(msg) points to uninitialised byte(s) ==3046844== at 0x49DABBA: sendto (sendto.c:27) ==3046844== by 0x11666D: ??? (in /usr/sbin/xtables-nft-multi) ==3046844== by 0x123A5D: ??? (in /usr/sbin/xtables-nft-multi) ==3046844== by 0x12705B: ??? (in /usr/sbin/xtables-nft-multi) ==3046844== by 0x11CF12: ??? (in /usr/sbin/xtables-nft-multi) ==3046844== by 0x11D73C: ??? (in /usr/sbin/xtables-nft-multi) ==3046844== by 0x11D9E0: ??? (in /usr/sbin/xtables-nft-multi) ==3046844== by 0x11DA2F: ??? (in /usr/sbin/xtables-nft-multi) ==3046844== by 0x48DCD8F: (below main) (libc_start_call_main.h:58) ==3046844== Address 0x1ffeffc30f is on thread 1's stack ==3046844===3046844== Syscall param sendmsg(msg.msg_iov[0]) points to uninitialised byte(s) ==3046844== at 0x49DAB17: sendmsg (sendmsg.c:28) ==3046844== by 0x11A4DC: ??? (in /usr/sbin/xtables-nft-multi) ==3046844== by 0x11D9E0: ??? (in /usr/sbin/xtables-nft-multi) ==3046844== by 0x11DA2F: ??? (in /usr/sbin/xtables-nft-multi) ==3046844== by 0x48DCD8F: (below main) (libc_start_call_main.h:58) ==3046844== Address 0x4aebccb is 59 bytes inside a block of size 200,703 alloc'd ==3046844== at 0x4848899: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so) ==3046844== by 0x4877A45: ??? (in /usr/lib/x86_64-linux-gnu/libnftnl.so.11.6.0) ==3046844== by 0x48791AC: nftnl_batch_alloc (in /usr/lib/x86_64-linux-gnu/libnftnl.so.11.6.0) ==3046844== by 0x11A1A7: ??? (in /usr/sbin/xtables-nft-multi) ==3046844== by 0x11D9E0: ??? (in /usr/sbin/xtables-nft-multi) ==3046844== by 0x11DA2F: ??? (in /usr/sbin/xtables-nft-multi) ==3046844== by 0x48DCD8F: (below main) (libc_start_call_main.h:58) ==3046844===3046844===3046844== HEAP SUMMARY: ==3046844== in use at exit: 0 bytes in 0 blocks ==3046844== total heap usage: 77 allocs, 77 frees, 247,730 bytes allocated ==3046844===3046844== All heap blocks were freed -- no leaks are possible ==3046844===3046844== Use --track-origins=yes to see where uninitialised values come from ==3046844== For lists of detected and suppressed errors, rerun with: -s ==3046844== ERROR SUMMARY: 4 errors from 2 contexts (suppressed: 0 from 0) -- You are receiving this mail because: You are watching all bug changes. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.netfilter.org/pipermail/netfilter-buglog/attachments/20230905/a5e0e188/attachment.html>
bugzilla-daemon at netfilter.org
2023-Sep-05 12:57 UTC
[Bug 1702] iptables fails to parse interface wildcard "-i +" correctly
https://bugzilla.netfilter.org/show_bug.cgi?id=1702
Pablo Neira Ayuso <pablo at netfilter.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |pablo at netfilter.org
--- Comment #4 from Pablo Neira Ayuso <pablo at netfilter.org> ---
(In reply to thomas.strangert from comment #3)> # valgrind --leak-check=full iptables -A INPUT -i + -d 192.168.8.13 -j DROP
> ==3046844== Memcheck, a memory error detector
> ==3046844== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et
al.
> ==3046844== Using Valgrind-3.18.1 and LibVEX; rerun with -h for copyright
> info
> ==3046844== Command: iptables -A INPUT -i + -d 192.168.8.13 -j DROP
It is the listing that shows the garbage, correct? Then, run valgring on
iptables-save.
--
You are receiving this mail because:
You are watching all bug changes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.netfilter.org/pipermail/netfilter-buglog/attachments/20230905/89e9f8fd/attachment.html>
bugzilla-daemon at netfilter.org
2023-Sep-05 13:16 UTC
[Bug 1702] iptables fails to parse interface wildcard "-i +" correctly
https://bugzilla.netfilter.org/show_bug.cgi?id=1702
--- Comment #5 from thomas.strangert at emblasoft.com ---
Now the garbage seems to end with a CR char, making the printout partly
overwrite itself - the line now starts with the +.
# iptables -L -n -v
Chain INPUT (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
27M 252G ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0
ctstate RELATED,ESTABLISHED
... ...
0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0
+ * 0.0.0.0/0 192.168.8.13
# iptables-save
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
... ...
-A INPUT -j DROP
+ -j DROP-d 192.168.8.13/32 -i ?
--
You are receiving this mail because:
You are watching all bug changes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.netfilter.org/pipermail/netfilter-buglog/attachments/20230905/552298f7/attachment.html>
bugzilla-daemon at netfilter.org
2023-Sep-05 13:20 UTC
[Bug 1702] iptables fails to parse interface wildcard "-i +" correctly
https://bugzilla.netfilter.org/show_bug.cgi?id=1702 --- Comment #6 from thomas.strangert at emblasoft.com --- # valgrind --leak-check=full iptables-save ==3054371== Memcheck, a memory error detector ==3054371== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==3054371== Using Valgrind-3.18.1 and LibVEX; rerun with -h for copyright info ==3054371== Command: iptables-save ==3054371===3054371== Syscall param socketcall.sendto(msg) points to uninitialised byte(s) ==3054371== at 0x49DABBA: sendto (sendto.c:27) ==3054371== by 0x11666D: ??? (in /usr/sbin/xtables-nft-multi) ==3054371== by 0x123D61: ??? (in /usr/sbin/xtables-nft-multi) ==3054371== by 0x11C3D7: ??? (in /usr/sbin/xtables-nft-multi) ==3054371== by 0x1270B7: ??? (in /usr/sbin/xtables-nft-multi) ==3054371== by 0x11C7DE: ??? (in /usr/sbin/xtables-nft-multi) ==3054371== by 0x48DCD8F: (below main) (libc_start_call_main.h:58) ==3054371== Address 0x1ffeffc3af is on thread 1's stack ==3054371===3054371== Syscall param socketcall.sendto(msg) points to uninitialised byte(s) ==3054371== at 0x49DABBA: sendto (sendto.c:27) ==3054371== by 0x11666D: ??? (in /usr/sbin/xtables-nft-multi) ==3054371== by 0x123D61: ??? (in /usr/sbin/xtables-nft-multi) ==3054371== by 0x11C423: ??? (in /usr/sbin/xtables-nft-multi) ==3054371== by 0x1270B7: ??? (in /usr/sbin/xtables-nft-multi) ==3054371== by 0x11C7DE: ??? (in /usr/sbin/xtables-nft-multi) ==3054371== by 0x48DCD8F: (below main) (libc_start_call_main.h:58) ==3054371== Address 0x1ffeffc3af is on thread 1's stack ==3054371=# Generated by iptables-save v1.8.7 on Tue Sep 5 15:18:09 2023 *mangle ... ... :mangle_WAN_DDoS - [0:0] -A PREROUTING -i wan -j mangle_WAN_DDoS ==3054371== Syscall param socketcall.sendto(msg) points to uninitialised byte(s) ==3054371== at 0x49DABBA: sendto (sendto.c:27) ==3054371== by 0x1139E0: ??? (in /usr/sbin/xtables-nft-multi) ==3054371== by 0x48A62C6: xtables_find_match (in /usr/lib/x86_64-linux-gnu/libxtables.so.12.4.0) ==3054371== by 0x48A601A: ??? (in /usr/lib/x86_64-linux-gnu/libxtables.so.12.4.0) ==3054371== by 0x48A63C6: xtables_find_match (in /usr/lib/x86_64-linux-gnu/libxtables.so.12.4.0) ==3054371== by 0x114944: ??? (in /usr/sbin/xtables-nft-multi) ==3054371== by 0x11C02B: ??? (in /usr/sbin/xtables-nft-multi) ==3054371== by 0x11C124: ??? (in /usr/sbin/xtables-nft-multi) ==3054371== by 0x11C423: ??? (in /usr/sbin/xtables-nft-multi) ==3054371== by 0x11C527: ??? (in /usr/sbin/xtables-nft-multi) ==3054371== by 0x11C95B: ??? (in /usr/sbin/xtables-nft-multi) ==3054371== by 0x48DCD8F: (below main) (libc_start_call_main.h:58) ==3054371== Address 0x1ffeffbe02 is on thread 1's stack ==3054371=... ... :Cid82520X12088.0 - [0:0] ==3054371== Syscall param socketcall.sendto(msg) points to uninitialised byte(s) ==3054371== at 0x49DABBA: sendto (sendto.c:27) ==3054371== by 0x1139E0: ??? (in /usr/sbin/xtables-nft-multi) ==3054371== by 0x48A5C95: xtables_find_target (in /usr/lib/x86_64-linux-gnu/libxtables.so.12.4.0) ==3054371== by 0x48A5FF1: ??? (in /usr/lib/x86_64-linux-gnu/libxtables.so.12.4.0) ==3054371== by 0x48A5D20: xtables_find_target (in /usr/lib/x86_64-linux-gnu/libxtables.so.12.4.0) ==3054371== by 0x114A1D: ??? (in /usr/sbin/xtables-nft-multi) ==3054371== by 0x11C02B: ??? (in /usr/sbin/xtables-nft-multi) ==3054371== by 0x11C124: ??? (in /usr/sbin/xtables-nft-multi) ==3054371== by 0x11C3D7: ??? (in /usr/sbin/xtables-nft-multi) ==3054371== by 0x11C527: ??? (in /usr/sbin/xtables-nft-multi) ==3054371== by 0x11C95B: ??? (in /usr/sbin/xtables-nft-multi) ==3054371== by 0x48DCD8F: (below main) (libc_start_call_main.h:58) ==3054371== Address 0x1ffeffbdfd is on thread 1's stack ==3054371=... ... # Completed on Tue Sep 5 15:18:09 2023 ==3054371===3054371== HEAP SUMMARY: ==3054371== in use at exit: 0 bytes in 0 blocks ==3054371== total heap usage: 10,741 allocs, 10,741 frees, 1,328,016 bytes allocated ==3054371===3054371== All heap blocks were freed -- no leaks are possible ==3054371===3054371== Use --track-origins=yes to see where uninitialised values come from ==3054371== For lists of detected and suppressed errors, rerun with: -s ==3054371== ERROR SUMMARY: 60 errors from 4 contexts (suppressed: 0 from 0) -- You are receiving this mail because: You are watching all bug changes. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.netfilter.org/pipermail/netfilter-buglog/attachments/20230905/fa1d8ea3/attachment-0001.html>
bugzilla-daemon at netfilter.org
2023-Sep-05 13:31 UTC
[Bug 1702] iptables fails to parse interface wildcard "-i +" correctly
https://bugzilla.netfilter.org/show_bug.cgi?id=1702 --- Comment #7 from thomas.strangert at emblasoft.com --- (In reply to Phil Sutter from comment #2)> I can neither reproduce this with current HEAD nor v1.8.7 tag. Is this a > downstream issue? I see you're facing the problem with > iptables-1.8.7-1ubuntu5.1, can you try to reproduce with a vanilla build? > > Also, you could try calling: > > valgrind --leak-check=full iptables -A INPUT -i + -d 192.168.1.10 -j DROP > > It should report garbage data read and give some > details as to where/why it happens.I noticed it when I moved to a Ubuntu 22.04 LTS from 20.04 LTS, all using native/standard distro/downstream builds I suppose. I have reported the bug to Ubuntu as well, so I hope that they can do the "flavored" tests. I don't have the servers/setup/bandwidth to go much deeper that I'm already in at. Ubuntu bug report: https://bugs.launchpad.net/ubuntu/+source/iptables/+bug/2033663 -- You are receiving this mail because: You are watching all bug changes. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.netfilter.org/pipermail/netfilter-buglog/attachments/20230905/6c8a5a97/attachment.html>
bugzilla-daemon at netfilter.org
2023-Sep-05 16:09 UTC
[Bug 1702] iptables fails to parse interface wildcard "-i +" correctly
https://bugzilla.netfilter.org/show_bug.cgi?id=1702
--- Comment #8 from Phil Sutter <phil at nwl.cc> ---
Reproduced in Ubuntu 22.04 LTS live ISO.
Looking at v1.8.7 code, I think I found the culprit:
Suppose the rule is '-A FORWARD -i + -d 1.2.3.4 -j ACCEPT'.
When adding the rule, add_iniface() unconditionally adds the meta expression
and skips adding the cmp one if interface name is "+" (actually: Ends
with "+"
and is not longer than 1).
Afterwards, payload match is created as expected. The rule in kernel then looks
like this:
[ meta load iifname => reg 1 ]
[ payload load 4b @ network header + 16 => reg 1 ]
[ cmp eq reg 1 0x04030201 ]
[ counter pkts 0 bytes 0 ]
[ immediate reg 0 accept ]
When parsing the rule, first nft_parse_meta() is called which sets ctx->reg
and
sets NFT_XT_CTX_META bit in ctx->flags. Next nft_parse_payload() is called
which overwrites ctx->reg, initializes ctx->payload and sets
NFT_XT_CTX_PAYLOAD
bit in ctx->flags. Next, nft_parse_cmp() is called which acts upon *both*
bits
in ctx->flags and thus calls h->ops->parse_meta (i.e.,
nft_ipv4_parse_meta)
with a cmp expression holding the IP address value.
With v1.8.9 all this changed via commit f315af1cf8871 ("nft: track each
register individually") which eliminated the ctx->flags use and
instroduced
reg->type instead.
We still have the odd add_iniface() (and add_outiface(), too) code in HEAD
which unconditionally emits a meta expression without following cmp one.
Therefore it should be possible to write a patch which applies to upstream and
(after dealing with context conflicts) fixes v1.8.7.
--
You are receiving this mail because:
You are watching all bug changes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.netfilter.org/pipermail/netfilter-buglog/attachments/20230905/d1fc1d9f/attachment.html>
bugzilla-daemon at netfilter.org
2023-Sep-08 14:01 UTC
[Bug 1702] iptables fails to parse interface wildcard "-i +" correctly
https://bugzilla.netfilter.org/show_bug.cgi?id=1702
Fabio <pedretti.fabio at gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |pedretti.fabio at gmail.com
--
You are receiving this mail because:
You are watching all bug changes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.netfilter.org/pipermail/netfilter-buglog/attachments/20230908/44a342b3/attachment.html>
bugzilla-daemon at netfilter.org
2023-Sep-14 10:35 UTC
[Bug 1702] iptables fails to parse interface wildcard "-i +" correctly
https://bugzilla.netfilter.org/show_bug.cgi?id=1702
Phil Sutter <phil at nwl.cc> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |RESOLVED
Resolution|--- |FIXED
--- Comment #9 from Phil Sutter <phil at nwl.cc> ---
Fix pushed upstream in commit 52ed0ac516db9 ("nft: Fix for useless meta
expressions in rule").
--
You are receiving this mail because:
You are watching all bug changes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.netfilter.org/pipermail/netfilter-buglog/attachments/20230914/299467cc/attachment.html>
Seemingly Similar Threads
- Re: [Qemu-devel] Hvmloader: Modify ACPI to only supply _EJ0 methods for PCIslots that support hotplug by runtime patching
- Iptables blocks out going connetion some times
- nwfilter : iptables rules not working
- [Bug 1423] New: iptables-translate silently discards --ctstate DNAT
- [Bug 712] New: iptables-save does not save correcly rateest bps parameter