A large number of bugs in the iptables Module

Maual BUG section of iptables:
BUGS
Bugs? What's this? ;-) Well, you might want to have a look at http://bugzilla.netfilter.org/
OK, I am going to the netfilter bug site... Alas, these guys!
I believe that many people have encountered the problem that iptables rules cannot be deleted. For example, I used the condition module in xtables-addons. After successfully setting a rule:
Iptables-t mangle-a prerouting-m condition -- condition xtt-j ACCEPT
Then try to use the D command of the above rule to delete it:
Iptables-t mangle-d prerouting-m condition -- condition xtt-j ACCEPT
I got an error:

However, if I use rulenum, it will be deleted successfully! That is, you can first find the rulenum of the above rule, and then delete the rule marked by this num. However, there is an additional step, I cannot just add or delete A rule through simple A or D, so I have to find out what is wrong.
Where can I save iptables rules? The answer is to save the rule in the kernel and keep it in a continuous address space. The layout is roughly as follows:
Metadata | match2 |... | target
Note that the user State does not store rules. Whenever you want to delete a rule, you must provide sufficient details about the rule to be deleted, then compare with the rule group in the kernel. The rule is deleted directly from the kernel only after the exact match is successful, that is, no ambiguity matching is successful, the specific communication mechanism (Netlink, ioctl, etc.) is not important. It is important that iptables has multiple ways to delete rules.
Delete iptables Rules 1. deleting the kernel according to rulenum will perform a numbered index for each iptables rule stored in the kernel. This index is unique on a specific HOOK point/TABLE, therefore, using rulenum for deletion does not have any ambiguity.
2. exact match Delete exact match Delete is complicated. You must give every detail of the rule. Just like when you added the rule, the only difference between the rule and the Add action is that, you need to change-A to-D. The successful deletion of this exact match depends on all the match fields provided by the user. The target field must be exactly the same as the one saved in the kernel and accurate to the byte level. If one byte does not match, the deletion fails.
3. Delete the entire table chain when you callIptables-t $ table-FAll the rules in the table will no longer exist. Because the rules belong to the table, they will not have any ambiguity. The meaning of the whole chain deletion is similar, mainly because, no matter the table or the chain, it is the upper-level organization of the specific rules. What is the saying is that the chain is not saved, and it will be omitted!
Problem
Taking the problem I encountered as an example, the info structure of xt_condition is as follows:

enum {        CONDITION_NAME_LEN = 31,};struct xt_condition_mtinfo {        char name[CONDITION_NAME_LEN];        __u8 invert;        /* Used internally by the kernel */        void *condvar __attribute__((aligned(8)));};

Note that annotation! The condvar field is used only in the kernel. If you have used the condition module, you will know that it does not carry any parameters except a name parameter. That is to say, the iptables command alone does not set condvar. The default value may be NULL, however, the entire struct, including condvar, will be injected into the kernel and saved by the kernel when adding rules. The assignment of condvar is carried out in the kernel, it represents the address of a kernel struct.
What if we use the exact match rule to delete a condition rule? In the kernel, The condvar field of the xt_condition_mtinfo struct in this rule has been assigned the address of a kernel-state address space. It will be used for byte-level comparison with the user-state same struct, the name of the first field is clearly accurate, and the second field is normal. condition_parse will handle well, but the third condvar field does not match, in the rule given by the user, this field is 0, and in the kernel state, this field is an address! Therefore, deletion will fail!
The issue validation section is irrelevant. The Hackers of netfilter have fixed the issue for a long time, but it is only at the programming level, and I need to elaborate on the problem at the business level, each match and each target of iptables are provided in the form of modules except for the few built-in items, and the problems that cannot be deleted are not only one of the condition modules, many modules have this problem, so I personally think this is not a bug in iptables, but a bug in each module.
In the xt_condition.c Kernel File, I detected the condvar value in xt_condition_mtinfo after the rule arrives at the kernel. Here I will return 0xffffff88000a2d0bc0. In the process of deletion, according to the definition of the above struct, there must be a 33rd-byte mismatch. After debugging, it is confirmed that the 33rd bytes of the kernel struct are 0xC0, the corresponding bytes calculated by iptables according to the command typed by the user are 0x0. Okay, I hardcoded It In The condition_parse parsing callback function:

static int condition_parse(int c, char **argv, int invert, unsigned int *flags,                           const void *entry, struct xt_entry_match **match){        struct xt_condition_mtinfo *info = (void *)(*match)->data;        if (c == 'X') {                if (*flags)                        xtables_error(PARAMETER_PROBLEM,                                   "Can't specify multiple conditions");                if (strlen(optarg) < sizeof(info->name))                        strcpy(info->name, optarg);                else                        xtables_error(PARAMETER_PROBLEM,                                   "File name too long");                info->invert = invert;#ifdef _DEBUG                memset((char *)info+32, 0xC0, 1);                memset((char *)info+33, 0x0B, 1);                memset((char *)info+34, 0x2D, 1);                memset((char *)info+35, 0x0A, 1);                memset((char *)info+36, 0x00, 1);                memset((char *)info+37, 0x88, 1);                memset((char *)info+38, 0xFF, 1);                memset((char *)info+39, 0xFF, 1);#endif                *flags = 1;                return true;        }        return false;}

In this way, after make install, you can successfully delete it!
The problem has been solved. We can see that we only need to tell iptables not to compare the condvar field of the struct. What should we do? Iptables provides an interface, that is, the userspacesize field of the xtables_match struct. The original condition module defines the following:

.userspacesize  = XT_ALIGN(sizeof(struct xt_condition_mtinfo)),

Obviously this is not correct, but in fact it should be:

. Userspacesize = XT_ALIGN (sizeof (struct xt_condition_mtinfo)-sizeof (...)-alignment...

There is a better way:

.userspacesize  = offsetof(struct xt_condition_mtinfo, condvar ),

In this way, iptables ignores the comparison of the condvar field.
However, this means that you cannot randomly deploy the fields in the structure of the match/target module. You must put all the "kernel-specific" fields at the end of the struct, then offsetof is used to take the offset of the first such field and assign it to userspacesize, which undoubtedly puts a burden on programmers. I think this is a bug. Debugging is difficult if developers do not understand this rule. The more intelligent way is to let the programmer specify the purpose of the field when constructing the struct, or simply divide it into user-state and kernel-State structures, the iptables framework is responsible for merging and integrating it.
Unlike other bugs, this bug exists in large quantities and cannot be solved at one time. If you search for related bugs on the http://bugzilla.netfilter.org, there will be a lot of results, involving multiple modules, one module corrected does not mean the other module will be corrected, although the authors of both modules make the same mistake. For example, for the condition module, I first encountered it in the xtables-addons-1.46, found its bug, and then downloaded the xtables-addons-2.2 version, the bug is still healthy!