netfilter buglog - Sep 2023 - [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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>