Jan Engelhardt wrote:
On Feb 28 2008 13:00, Patrick McHardy wrote:
+static inline int nf_inet_addr_cmp(const union nf_inet_addr *a1,
+ const union nf_inet_addr *a2)
+{
+ return a1->all[0] == a2->all[0] &&
+ a1->all[1] == a2->all[1] &&
+ a1->all[2] == a2->all[2] &&
+ a1->all[3] == a2->all[3];
+}
+
Humm... this might raise undefined/unexpected behavior for IPv4 addresses,
for which nf_inet_addr is not properly flattened (zeroed or all-ones,
or whatever static pattern you want to put in all[1],all[2],all[3]),
but the problem already existed before I guess:
static inline int __nf_ct_tuple_src_equal(const struct nf_conntrack_tuple *t1,
const struct nf_conntrack_tuple *t2)
{
- return (t1->src.u3.all[0] == t2->src.u3.all[0] &&
- t1->src.u3.all[1] == t2->src.u3.all[1] &&
- t1->src.u3.all[2] == t2->src.u3.all[2] &&
- t1->src.u3.all[3] == t2->src.u3.all[3] &&
+ return (nf_inet_addr_cmp(&t1->src.u3, &t2->src.u3) &&
Indeed, but so far I'm pretty sure all addresses are initialized
properly. I checked conntrack several times, although its already
some time ago. xtables matches and targets should also be fine
since userspace zeroes everything before initializing it.
-
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
