Skip to contentSkip to conversation

NFQUEUE: Fix bug with order of fanout and bypass

PATCH In review Shivani Bhardwaj 2 participants 4 messages Apr 12, 2016 netfilter

lore
Share & tools
lore
#0 lore raw

PATCH 1/1 NFQUEUE: Fix bug with order of fanout and bypass

NFQUEUE had a bug with the ordering of fanout and bypass options which was arising due to same and odd values for flags and bypass when used together. Because of this, during bitwise ANDing of flags and NFQ_FLAG_CPU_FANOUT, the value always evaluated to false (since NFQ_FLAG_CPU_FANOUT=0x02) and led to skipping of fanout option whenever it was used before bypass because then flags would be 1.

Before this patch,

$ sudo iptables -A FORWARD -j NFQUEUE -p TCP --sport 80 --queue-balance 0:3 --queue-cpu-fanout --queue-bypass

Chain FORWARD (policy ACCEPT)

target     prot opt source               destination
NFQUEUE    tcp  --  anywhere             anywhere             tcp spt:http NFQUEUE balance 0:3 bypass

After this patch,

Chain FORWARD (policy ACCEPT)

target     prot opt source               destination
NFQUEUE    tcp  --  anywhere             anywhere             tcp spt:http NFQUEUE balance 0:3 bypass cpu-fanout

Closes bugzilla entry: http://bugzilla.netfilter.org/show_bug.cgi?id=939

---
 extensions/libxt_NFQUEUE.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
extensions/libxt_NFQUEUE.c +1 -1
index 8115457..0b5becc 100644
@@ -99,7 +99,7 @@ static void NFQUEUE_parse_v2(struct xt_option_call *cb)
 	NFQUEUE_parse_v1(cb);
 	switch (cb->entry->id) {
 	case O_QUEUE_BYPASS:
-		info->bypass = 1;
+		info->bypass |= NFQ_FLAG_BYPASS;
 		break;
 	}
 }
Signature · 1 line
1.9.1
maintainer
#1 lore raw
Quoted 15 lines · Shivani Bhardwaj

NFQUEUE had a bug with the ordering of fanout and bypass options which was arising due to same and odd values for flags and bypass when used together. Because of this, during bitwise ANDing of flags and NFQ_FLAG_CPU_FANOUT, the value always evaluated to false (since NFQ_FLAG_CPU_FANOUT=0x02) and led to skipping of fanout option whenever it was used before bypass because then flags would be 1.

Before this patch,

$ sudo iptables -A FORWARD -j NFQUEUE -p TCP --sport 80 --queue-balance 0:3 --queue-cpu-fanout --queue-bypass

Chain FORWARD (policy ACCEPT)

target     prot opt source               destination
NFQUEUE    tcp  --  anywhere             anywhere             tcp spt:http NFQUEUE balance 0:3 bypass
Quoted 7 lines

After this patch,

Chain FORWARD (policy ACCEPT)

target     prot opt source               destination
NFQUEUE    tcp  --  anywhere             anywhere             tcp spt:http NFQUEUE balance 0:3 bypass cpu-fanout

Closes bugzilla entry: http://bugzilla.netfilter.org/show_bug.cgi?id=939

Ugh, good catch!

extensions/libxt_NFQUEUE.c static void NFQUEUE_parse_v2(struct xt_option_call *cb) · line 103

Quoted 11 lines
extensions/libxt_NFQUEUE.c +1 -1
index 8115457..0b5becc 100644
@@ -99,7 +99,7 @@ static void NFQUEUE_parse_v2(struct xt_option_call *cb)
 	NFQUEUE_parse_v1(cb);
 	switch (cb->entry->id) {
 	case O_QUEUE_BYPASS:
-		info->bypass = 1;
+		info->bypass |= NFQ_FLAG_BYPASS;
 		break;

I don't like this mix of v2 and v3 layout.

Could you try to create an alternate patch that changes NFQUEUE_parse_v3 to call NFQUEUE_parse_v1 and then add

	case O_QUEUE_BYPASS:
		info->bypass |= NFQ_FLAG_BYPASS;

to NFQUEUE_parse_v3?

I think that this would make it a bit clearer and
it also avoids the v3/v2/v1 stacking.

Thanks!

#2 lore raw
Quoted 42 lines · Florian Westphal
Quoted 15 lines · Shivani Bhardwaj

NFQUEUE had a bug with the ordering of fanout and bypass options which was arising due to same and odd values for flags and bypass when used together. Because of this, during bitwise ANDing of flags and NFQ_FLAG_CPU_FANOUT, the value always evaluated to false (since NFQ_FLAG_CPU_FANOUT=0x02) and led to skipping of fanout option whenever it was used before bypass because then flags would be 1.

Before this patch,

$ sudo iptables -A FORWARD -j NFQUEUE -p TCP --sport 80 --queue-balance 0:3 --queue-cpu-fanout --queue-bypass

Chain FORWARD (policy ACCEPT)

target     prot opt source               destination
NFQUEUE    tcp  --  anywhere             anywhere             tcp spt:http NFQUEUE balance 0:3 bypass
Quoted 7 lines

After this patch,

Chain FORWARD (policy ACCEPT)

target     prot opt source               destination
NFQUEUE    tcp  --  anywhere             anywhere             tcp spt:http NFQUEUE balance 0:3 bypass cpu-fanout

Closes bugzilla entry: http://bugzilla.netfilter.org/show_bug.cgi?id=939

Ugh, good catch!

extensions/libxt_NFQUEUE.c static void NFQUEUE_parse_v2(struct xt_option_call *cb) · line 103

Quoted 11 lines
extensions/libxt_NFQUEUE.c +1 -1
index 8115457..0b5becc 100644
@@ -99,7 +99,7 @@ static void NFQUEUE_parse_v2(struct xt_option_call *cb)
      NFQUEUE_parse_v1(cb);
      switch (cb->entry->id) {
      case O_QUEUE_BYPASS:
-             info->bypass = 1;
+             info->bypass |= NFQ_FLAG_BYPASS;
              break;

I don't like this mix of v2 and v3 layout.

Could you try to create an alternate patch that changes NFQUEUE_parse_v3 to call NFQUEUE_parse_v1 and then add

Quoted 8 lines
        case O_QUEUE_BYPASS:
                info->bypass |= NFQ_FLAG_BYPASS;

to NFQUEUE_parse_v3?

I think that this would make it a bit clearer and
it also avoids the v3/v2/v1 stacking.

Sure.
Just to make sure I get this right, should I be using two objects of structures xt_NFQ_info_v3 and xt_NFQ_info_v2 (since v3 does not have bypass) and make switch cases accordingly in v3?
Should I be doing this for all the functions (save, xlate, print) since the same stacking is there too?

Thanks!

Quoted 1 line

Thanks!

maintainer
#3 lore raw
Quoted 7 lines · Shivani Bhardwaj
Quoted 3 lines

I think that this would make it a bit clearer and
it also avoids the v3/v2/v1 stacking.

Sure.
Just to make sure I get this right, should I be using two objects of structures xt_NFQ_info_v3 and xt_NFQ_info_v2 (since v3 does not have bypass) and make switch cases accordingly in v3?

I meant something like this (untested):

extensions/libxt_NFQUEUE.c +4 -1
index 8115457..9750ce0 100644
@@ -108,11 +108,14 @@ static void NFQUEUE_parse_v3(struct xt_option_call *cb)
 {
 	struct xt_NFQ_info_v3 *info = cb->data;
 
-	NFQUEUE_parse_v2(cb);
+	NFQUEUE_parse_v1(cb);
 	switch (cb->entry->id) {
 	case O_QUEUE_CPU_FANOUT:
 		info->flags |= NFQ_FLAG_CPU_FANOUT;
 		break;
+	case O_QUEUE_BYPASS:
+		info->flags |= NFQ_FLAG_BYPASS;
+		break;
 	}
 }
 
Quoted 2 lines

Should I be doing this for all the functions (save, xlate, print) since the same stacking is there too?

Hmm, I think it would make sense to disentangle this as well (as a 2nd cleanup patch).

The ->bypass/->flag overloading works but its not really obvious...

I don't have a strong opinion however, if you think your v1 patch is ok I'm fine with it as well.