>> > It may be more subtle than what you describe. xtables_find_match >> > can call xtables_fully_register_pending_match which calls >> > compatible_match_revision to decide whether a match revision >> > is supported and, if multiple revisions are supported, which to prefer. >> >> The case reported in bugzilla is for match 'set', which has not had a >> new revision since v4 in 2014. Building the exact versions of iptables >> and ipset reported there and disabling v4 support in the kernel correctly >> reverts to using v3. > > Maybe the case can be reproduced with the following steps, but I'm > guessing: > > - rules inserted > - iptables binary downgraded/upgraded > - rules listed It will. This is largely what the patch protects against. But perhaps it currently unnecessarily restricts binaries that support both revisions N and N + 1 from printing structs of rev N, if those are inserted from another binary that only supported up to N. Let me try that. Before this patch, a rule inserted with a binary that only supports rev N for a given match, but read with another binary that supports rev N+1 will result in the new binary incorrectly parsing a struct of rev N as one of rev N + 1. And vice versa. See also the discussion in Re: [PATCH nf-next] netfilter: xt_bpf: support ebpf https://www.spinics.net/lists/netfilter-devel/msg45357.html Casting structs in this way is unsafe. The downgrade path cannot be fixed. But the upgrade path should. The way iptables negotiates with the kernel and only loads the highest revision for any given match or target may make this hard to change. -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
