[Bug 1702] iptables fails to parse interface wildcard "-i +" correctly

[bugzilla-daemon at netfilter.org]

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>