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 DROPIt 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>
Reasonably Related 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