summaryrefslogtreecommitdiffstats
path: root/iptables/tests/shell/testcases/iptables/0005-delete-rules_0
Commit message (Collapse)AuthorAgeFilesLines
* xtables: Fix for false-positive rule matchingPhil Sutter2019-02-051-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | When comparing two rules with non-standard targets, differences in targets' payloads wasn't respected. The cause is a rather hideous one: Unlike xtables_find_match(), xtables_find_target() did not care whether the found target was already in use or not, so the same target instance was assigned to both rules and therefore payload comparison happened over the same memory location. With legacy iptables it is not possible to reuse a target: The only case where two rules (i.e., iptables_command_state instances) could exist at the same time is when comparing rules, but that's handled using libiptc. The above change clashes with ebtables-nft's reuse of target objects: While input parsing still just assigns the object from xtables_targets list, rule conversion from nftnl to iptables_command_state allocates new data. To fix this, make ebtables-nft input parsing use the common command_jump() routine instead of its own simplified copy. In turn, this also eliminates the ebtables-nft-specific variants of parse_target(), though with a slight change of behaviour: Names of user-defined chains are no longer allowed to contain up to 31 but merely 28 characters. Signed-off-by: Phil Sutter <phil@nwl.cc> Signed-off-by: Florian Westphal <fw@strlen.de>
* xtables: Fix for crash when comparing rules with standard targetPhil Sutter2019-02-011-0/+7
When parsing an nftnl_rule with a standard verdict, nft_rule_to_iptables_command_state() initialized cs->target but didn't care about cs->target->t. When later comparing that rule to another, compare_targets() crashed due to unconditional access to t's fields. Signed-off-by: Phil Sutter <phil@nwl.cc> Signed-off-by: Florian Westphal <fw@strlen.de>