[Bug 1702] New: iptables fails to parse interface wildcard "-i +" correctly
bugzilla-daemon at netfilter.org
bugzilla-daemon at netfilter.org
Sun Sep 3 19:05:07 CEST 2023
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>
More information about the netfilter-buglog
mailing list