bugzilla-daemon at netfilter.org
2023-Apr-09 16:16 UTC
[Bug 1562] nft aborts due to assertion `desc->base == expr->payload.base' when inserting a particular rule
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>