[Bug 1562] nft aborts due to assertion `desc->base == expr->payload.base' when inserting a particular rule

[bugzilla-daemon at netfilter.org]

https://bugzilla.netfilter.org/show_bug.cgi?id=1562

--- Comment #2 from Anonymous <bugzilla.netfilter.org at schmutzmail.com> ---
(In reply to Fernando F. Mancera from comment #1)
> Hello!
> 
> I have investigated this issue a little bit. I noticed that the ruleset that
> pyroute2 is generating corresponds to the following output:
> 
> table ip crash {
> 	chain crash {
> 		type nat hook postrouting priority srcnat; policy accept;
> 		meta nfproto ipv4 @nh,96,32 0xa000010-0xa00001f masquerade
> 	}
> }
> 
> This is incorrect because `meta nfproto` is only useful for inet family. nft
> command line already provides a good error if you try to apply this ruleset.
> 
> I noticed that pyroute2 is setting "ip" family by default when creating a
> table and do not validate the expressions, therefore it is generating a
> wrong ruleset. In addition, pyroute2 does not allow to specify a specific
> family for the table.
> 
> As a workaround, I recommend you to apply the following ruleset:
> 
> table inet crash {
> 	chain crash {
> 		type nat hook postrouting priority srcnat; policy accept;
> 		meta nfproto ipv4 @nh,96,32 0xa000010-0xa00001f masquerade
> 	}
> }
> 
> Maybe the kernel could throw an error if the meta nfproto is being used in a
> not "inet" family table.
> 
> Please, let me know if my investigation is correct and if the workaround
> works for you.
> 
> Thanks,
> Fernando.

Thanks a lot and sorry for the very late reply.

Your investigation is correct and the workaround is functioning well. I ran
into this issue because I was programmatically creating these expressions at
the netfilter "VM" level. I have a rule creation function which gets an IP
address (either IPv4 or IPv6) as a parameter. The idea is that I can create
rules through this function without having to worry whether they will be
inserted into "inet", "ip", or "ip6" tables later. So in case an IPv4 address
was supplied, I would add a "meta nfproto ipv4" expression and expect that it
would not matter whether I inserted the generated rule into an "ip" or "inet"
table.

IMO, since this is a valid rule in terms of the kernel VM, this should not
cause an nftables crash. And IMO it would not be the task of the kernel to
disallow such a rule, because there are likely a lot of similar cases where
expression redundancy could be detected and disallowed.

-- 
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/20230409/64ddb588/attachment.html>