Skip to contentSkip to conversation

Couple of classifier fixes

PATCH In review Daniel Borkmann 5 participants 12 messages Jul 17, 2015 – Jul 21, 2015

Subsystems (5)
Networking Network drivers BPF Traffic control (tc) +1 more subsystems
lore
Share & tools
lore

Daniel Borkmann

author maintainer
#0 lore raw

cover Couple of classifier fixes

This fixes a couple of panics in the form of (analogous for cls_flow{,er}):

[  912.759276] BUG: unable to handle kernel NULL pointer dereference at (null)
[  912.759373] IP: [<ffffffffa09d4d6d>] cls_bpf_change+0x23d/0x268 [cls_bpf]
[  912.759441] PGD 8783c067 PUD 5f684067 PMD 0 
[  912.759491] Oops: 0002 [#1] SMP DEBUG_PAGEALLOC 
[  912.759543] Modules linked in: cls_bpf(E) act_gact [...]
[  912.772734] CPU: 3 PID: 10489 Comm: tc Tainted: G        W   E   4.2.0-rc2+ #73
[  912.775004] Hardware name: Apple Inc. MacBookAir5,1/Mac-66F35F19FE2A0D05, BIOS MBA51.88Z.00EF.B02.1211271028 11/27/2012
[  912.777327] task: ffff88025eaa8000 ti: ffff88005f734000 task.ti: ffff88005f734000
[  912.779662] RIP: 0010:[<ffffffffa09d4d6d>]  [<ffffffffa09d4d6d>] cls_bpf_change+0x23d/0x268 [cls_bpf]
[  912.781991] RSP: 0018:ffff88005f7379c8  EFLAGS: 00010286
[  912.784183] RAX: ffff880201d64e48 RBX: 0000000000000000 RCX: ffff880201d64e40
[  912.786402] RDX: 0000000000000000 RSI: ffffffffa09d51c0 RDI: ffffffffa09d51a6
[  912.788625] RBP: ffff88005f737a68 R08: 0000000000000000 R09: 0000000000000000
[  912.790854] R10: 0000000000000001 R11: 0000000000000001 R12: ffff880078ab5a80
[  912.793082] R13: ffff880232b31570 R14: ffff88005f737ae0 R15: ffff8801e215d1d0
[  912.795181] FS:  00007f3c0c80d740(0000) GS:ffff880265400000(0000) knlGS:0000000000000000
[  912.797281] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  912.799402] CR2: 0000000000000000 CR3: 000000005460f000 CR4: 00000000001407e0
[  912.799403] Stack:
[  912.799407]  ffffffff00000000 ffff88023ea18000 000000005f737a08 0000000000000000
[  912.799415]  ffffffff81f06140 ffff880201d64e40 0000000000000000 ffff88023ea1804c
[  912.799418]  0000000000000000 ffff88023ea18044 ffff88023ea18030 ffff88023ea18038
[  912.799418] Call Trace:
[  912.799437]  [<ffffffff816d5685>] tc_ctl_tfilter+0x335/0x910
[  912.799443]  [<ffffffff813622a8>] ? security_capable+0x48/0x60
[  912.799448]  [<ffffffff816b90e5>] rtnetlink_rcv_msg+0x95/0x240
[  912.799454]  [<ffffffff810f612d>] ? trace_hardirqs_on+0xd/0x10
[  912.799456]  [<ffffffff816b902f>] ? rtnetlink_rcv+0x1f/0x40
[  912.799459]  [<ffffffff816b902f>] ? rtnetlink_rcv+0x1f/0x40
[  912.799461]  [<ffffffff816b9050>] ? rtnetlink_rcv+0x40/0x40
[  912.799464]  [<ffffffff816df38f>] netlink_rcv_skb+0xaf/0xc0
[  912.799467]  [<ffffffff816b903e>] rtnetlink_rcv+0x2e/0x40
[  912.799469]  [<ffffffff816deaef>] netlink_unicast+0xef/0x1b0
[  912.799471]  [<ffffffff816defa0>] netlink_sendmsg+0x3f0/0x620
[  912.799476]  [<ffffffff81687028>] sock_sendmsg+0x38/0x50
[  912.799479]  [<ffffffff81687938>] ___sys_sendmsg+0x288/0x290
[  912.799482]  [<ffffffff810f7852>] ? __lock_acquire+0x572/0x2050
[  912.799488]  [<ffffffff810265db>] ? native_sched_clock+0x2b/0x90
[  912.799493]  [<ffffffff8116135f>] ? __audit_syscall_entry+0xaf/0x100
[  912.799497]  [<ffffffff8116135f>] ? __audit_syscall_entry+0xaf/0x100
[  912.799501]  [<ffffffff8112aa19>] ? current_kernel_time+0x69/0xd0
[  912.799505]  [<ffffffff81266f16>] ? __fget_light+0x66/0x90
[  912.799508]  [<ffffffff81688812>] __sys_sendmsg+0x42/0x80
[  912.799510]  [<ffffffff81688862>] SyS_sendmsg+0x12/0x20
[  912.799515]  [<ffffffff817f9a6e>] entry_SYSCALL_64_fastpath+0x12/0x76
[  912.799540] Code: 4d 88 49 8b 57 08 48 89 51 08 49 8b 57 10 48 89 c8 48 83 c0 08 48
                     89 51 10 48 8b 51 10 48 c7 c6 c0 51 9d a0 48 c7 c7 a6 51 9d a0 <48>
                     89 02 48 8b 51 08 48 89 42 08 48 b8 00 02 20 00 00 00 ad de 
[  912.799544] RIP  [<ffffffffa09d4d6d>] cls_bpf_change+0x23d/0x268 [cls_bpf]
[  912.799544]  RSP <ffff88005f7379c8>
[  912.799545] CR2: 0000000000000000
[  912.807380] ---[ end trace a6440067cfdc7c29 ]---

I've split them into 3 patches, so they can be backported easier when needed.

Thanks!

Daniel Borkmann (3):
sched: cls_bpf: fix panic on filter replace
sched: cls_flower: fix panic on filter replace
sched: cls_flow: fix panic on filter replace

 net/sched/cls_bpf.c    | 2 +-
 net/sched/cls_flow.c   | 5 +++--
 net/sched/cls_flower.c | 2 +-
 3 files changed, 5 insertions(+), 4 deletions(-)
Signature · 1 line
1.9.3
author maintainer
#1 lore raw

PATCH 1/3 sched: cls_bpf: fix panic on filter replace

The following test case causes a NULL pointer dereference in cls_bpf:

FOO="1,6 0 0 4294967295,"
tc filter add dev foo parent 1: bpf bytecode "$FOO" flowid 1:1 action ok tc filter replace dev foo parent 1: pref 49152 handle 0x1 \
bpf bytecode "$FOO" flowid 1:1 action drop

The problem is that commit 1f947bf151e9 ("net: sched: rcu'ify cls_bpf") accidentally swapped the arguments of list_replace_rcu(), the old element needs to be the first argument and the new element the second.

Fixes 1f947bf151e9 ("net: sched: rcu'ify cls_bpf")
Signed-off-by Daniel Borkmann <[email protected]>
---
 net/sched/cls_bpf.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
net/sched/cls_bpf.c +1 -1
index c79ecfd..e5168f8 100644
@@ -378,7 +378,7 @@ static int cls_bpf_change(struct net *net, struct sk_buff *in_skb,
 		goto errout;
 
 	if (oldprog) {
-		list_replace_rcu(&prog->link, &oldprog->link);
+		list_replace_rcu(&oldprog->link, &prog->link);
 		tcf_unbind_filter(tp, &oldprog->res);
 		call_rcu(&oldprog->rcu, __cls_bpf_delete_prog);
 	} else {
Signature · 1 line
1.9.3
reviewer Acked-by on v1 1/3
#2 lore raw

Re: [PATCH net 1/3] sched: cls_bpf: fix panic on filter replace

Quoted 7 lines · Daniel Borkmann

The following test case causes a NULL pointer dereference in cls_bpf:

FOO="1,6 0 0 4294967295,"
tc filter add dev foo parent 1: bpf bytecode "$FOO" flowid 1:1 action ok tc filter replace dev foo parent 1: pref 49152 handle 0x1 \
bpf bytecode "$FOO" flowid 1:1 action drop

Quoted 7 lines

The problem is that commit 1f947bf151e9 ("net: sched: rcu'ify cls_bpf") accidentally swapped the arguments of list_replace_rcu(), the old element needs to be the first argument and the new element the second.

Fixes 1f947bf151e9 ("net: sched: rcu'ify cls_bpf")
Signed-off-by Daniel Borkmann <[email protected]>

---

Thanks Daniel. Apparently I got this right in cls_basic but botched it here and in cls_flow.

FWIW,

Acked-by John Fastabend <[email protected]>
Quoted 17 lines
 net/sched/cls_bpf.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
net/sched/cls_bpf.c +1 -1
index c79ecfd..e5168f8 100644
@@ -378,7 +378,7 @@ static int cls_bpf_change(struct net *net, struct sk_buff *in_skb,
 		goto errout;
 
 	if (oldprog) {
-		list_replace_rcu(&prog->link, &oldprog->link);
+		list_replace_rcu(&oldprog->link, &prog->link);
 		tcf_unbind_filter(tp, &oldprog->res);
 		call_rcu(&oldprog->rcu, __cls_bpf_delete_prog);
 	} else {
author maintainer
#3 lore raw

Re: [PATCH net 1/3] sched: cls_bpf: fix panic on filter replace

On 07/17/2015 11:05 PM, John Fastabend wrote:
...

Quoted 2 lines

Thanks Daniel. Apparently I got this right in cls_basic but botched it here and in cls_flow.

Yep, it's correct there. :)

Thanks,
Daniel

Acked-by
#4 lore raw

Re: [PATCH net 1/3] sched: cls_bpf: fix panic on filter replace

In reply to John Fastabend
Quoted 15 lines · John Fastabend
Quoted 7 lines · Daniel Borkmann
Quoted 7 lines

The following test case causes a NULL pointer dereference in cls_bpf:

FOO="1,6 0 0 4294967295,"
tc filter add dev foo parent 1: bpf bytecode "$FOO" flowid 1:1 action ok tc filter replace dev foo parent 1: pref 49152 handle 0x1 \
bpf bytecode "$FOO" flowid 1:1 action drop

Quoted 7 lines
Quoted 7 lines

The problem is that commit 1f947bf151e9 ("net: sched: rcu'ify cls_bpf") accidentally swapped the arguments of list_replace_rcu(), the old element needs to be the first argument and the new element the second.

Fixes 1f947bf151e9 ("net: sched: rcu'ify cls_bpf")
Signed-off-by Daniel Borkmann<[email protected]>

---

Quoted 6 lines

Thanks Daniel. Apparently I got this right in cls_basic but botched it here and in cls_flow.

FWIW,

Acked-by John Fastabend<[email protected]>

Thanks for the quick fix.

Acked-by Alexei Starovoitov <[email protected]>
author maintainer
#5 lore raw

PATCH 2/3 sched: cls_flower: fix panic on filter replace

In reply to Daniel Borkmann

The following test case causes a NULL pointer dereference in cls_flower:

tc filter add dev foo parent 1: flower eth_type ipv4 action ok flowid 1:1 tc filter replace dev foo parent 1: pref 49152 handle 0x1 \
flower eth_type ipv6 action ok flowid 1:1

The problem is that commit 77b9900ef53a ("tc: introduce Flower classifier") accidentally swapped the arguments of list_replace_rcu(), the old element needs to be the first argument and the new element the second.

Fixes 77b9900ef53a ("tc: introduce Flower classifier")
Signed-off-by Daniel Borkmann <[email protected]>
---
 net/sched/cls_flower.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
net/sched/cls_flower.c +1 -1
index 9d37ccd..2f3d03f 100644
@@ -499,7 +499,7 @@ static int fl_change(struct net *net, struct sk_buff *in_skb,
 	*arg = (unsigned long) fnew;
 
 	if (fold) {
-		list_replace_rcu(&fnew->list, &fold->list);
+		list_replace_rcu(&fold->list, &fnew->list);
 		tcf_unbind_filter(tp, &fold->res);
 		call_rcu(&fold->rcu, fl_destroy_filter);
 	} else {
Signature · 1 line
1.9.3
maintainer Acked-by on v1 2/3
#6 lore raw

Re: [PATCH net 2/3] sched: cls_flower: fix panic on filter replace

Quoted 6 lines · Fri, Jul 17, 2015 at 10:38:44PM CEST, [email protected] wrote:

The following test case causes a NULL pointer dereference in cls_flower:

tc filter add dev foo parent 1: flower eth_type ipv4 action ok flowid 1:1 tc filter replace dev foo parent 1: pref 49152 handle 0x1 \
flower eth_type ipv6 action ok flowid 1:1

Quoted 6 lines

The problem is that commit 77b9900ef53a ("tc: introduce Flower classifier") accidentally swapped the arguments of list_replace_rcu(), the old element needs to be the first argument and the new element the second.

Fixes 77b9900ef53a ("tc: introduce Flower classifier")
Signed-off-by Daniel Borkmann <[email protected]>
Acked-by Jiri Pirko <[email protected]>
author maintainer
#7 lore raw

PATCH 3/3 sched: cls_flow: fix panic on filter replace

In reply to Daniel Borkmann

The following test case causes a NULL pointer dereference in cls_flow:

tc filter add dev foo parent 1: handle 0x1 flow hash keys dst action ok tc filter replace dev foo parent 1: pref 49152 handle 0x1 \
flow hash keys mark action drop

To be more precise, actually two different panics are fixed, the first occurs because tcf_exts_init() is not called on the newly allocated filter when we do a replace. And the second panic uncovered after that happens since the arguments of list_replace_rcu() are swapped, the old element needs to be the first argument and the new element the second.

Fixes 70da9f0bf999 ("net: sched: cls_flow use RCU")
Signed-off-by Daniel Borkmann <[email protected]>
---
 net/sched/cls_flow.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)
net/sched/cls_flow.c +3 -2
index 76bc3a2..bb2a0f5 100644
@@ -425,6 +425,8 @@ static int flow_change(struct net *net, struct sk_buff *in_skb,
 	if (!fnew)
 		goto err2;
 
+	tcf_exts_init(&fnew->exts, TCA_FLOW_ACT, TCA_FLOW_POLICE);
+
 	fold = (struct flow_filter *)*arg;
 	if (fold) {
 		err = -EINVAL;

@@ -486,7 +488,6 @@ static int flow_change(struct net *net, struct sk_buff *in_skb,
 		fnew->mask  = ~0U;
 		fnew->tp = tp;
 		get_random_bytes(&fnew->hashrnd, 4);
-		tcf_exts_init(&fnew->exts, TCA_FLOW_ACT, TCA_FLOW_POLICE);
 	}
 
 	fnew->perturb_timer.function = flow_perturbation;

@@ -526,7 +527,7 @@ static int flow_change(struct net *net, struct sk_buff *in_skb,
 	if (*arg == 0)
 		list_add_tail_rcu(&fnew->list, &head->filters);
 	else
-		list_replace_rcu(&fnew->list, &fold->list);
+		list_replace_rcu(&fold->list, &fnew->list);
 
 	*arg = (unsigned long)fnew;
Signature · 1 line
1.9.3
reviewer Acked-by on v1 3/3
#8 lore raw

Re: [PATCH net 3/3] sched: cls_flow: fix panic on filter replace

Quoted 12 lines · Daniel Borkmann

The following test case causes a NULL pointer dereference in cls_flow:

tc filter add dev foo parent 1: handle 0x1 flow hash keys dst action ok tc filter replace dev foo parent 1: pref 49152 handle 0x1 \
flow hash keys mark action drop

To be more precise, actually two different panics are fixed, the first occurs because tcf_exts_init() is not called on the newly allocated filter when we do a replace. And the second panic uncovered after that happens since the arguments of list_replace_rcu() are swapped, the old element needs to be the first argument and the new element the second.

Quoted 6 lines
Fixes 70da9f0bf999 ("net: sched: cls_flow use RCU")
Signed-off-by Daniel Borkmann <[email protected]>
---
 net/sched/cls_flow.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

Thanks again, I must have missed running replace tests in these cases.

Acked-by John Fastabend <[email protected]>
author maintainer
#9 lore raw
In reply to Daniel Borkmann
Quoted 2 lines · Daniel Borkmann

This fixes a couple of panics in the form of (analogous for cls_flow{,er}):

[ Also putting John into Cc for these fixes as it has to do with all
the RCU conversion, sorry just realized that after git send-email. ]

Quoted 68 lines
[  912.759276] BUG: unable to handle kernel NULL pointer dereference at (null)
[  912.759373] IP: [<ffffffffa09d4d6d>] cls_bpf_change+0x23d/0x268 [cls_bpf]
[  912.759441] PGD 8783c067 PUD 5f684067 PMD 0
[  912.759491] Oops: 0002 [#1] SMP DEBUG_PAGEALLOC
[  912.759543] Modules linked in: cls_bpf(E) act_gact [...]
[  912.772734] CPU: 3 PID: 10489 Comm: tc Tainted: G        W   E   4.2.0-rc2+ #73
[  912.775004] Hardware name: Apple Inc. MacBookAir5,1/Mac-66F35F19FE2A0D05, BIOS MBA51.88Z.00EF.B02.1211271028 11/27/2012
[  912.777327] task: ffff88025eaa8000 ti: ffff88005f734000 task.ti: ffff88005f734000
[  912.779662] RIP: 0010:[<ffffffffa09d4d6d>]  [<ffffffffa09d4d6d>] cls_bpf_change+0x23d/0x268 [cls_bpf]
[  912.781991] RSP: 0018:ffff88005f7379c8  EFLAGS: 00010286
[  912.784183] RAX: ffff880201d64e48 RBX: 0000000000000000 RCX: ffff880201d64e40
[  912.786402] RDX: 0000000000000000 RSI: ffffffffa09d51c0 RDI: ffffffffa09d51a6
[  912.788625] RBP: ffff88005f737a68 R08: 0000000000000000 R09: 0000000000000000
[  912.790854] R10: 0000000000000001 R11: 0000000000000001 R12: ffff880078ab5a80
[  912.793082] R13: ffff880232b31570 R14: ffff88005f737ae0 R15: ffff8801e215d1d0
[  912.795181] FS:  00007f3c0c80d740(0000) GS:ffff880265400000(0000) knlGS:0000000000000000
[  912.797281] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  912.799402] CR2: 0000000000000000 CR3: 000000005460f000 CR4: 00000000001407e0
[  912.799403] Stack:
[  912.799407]  ffffffff00000000 ffff88023ea18000 000000005f737a08 0000000000000000
[  912.799415]  ffffffff81f06140 ffff880201d64e40 0000000000000000 ffff88023ea1804c
[  912.799418]  0000000000000000 ffff88023ea18044 ffff88023ea18030 ffff88023ea18038
[  912.799418] Call Trace:
[  912.799437]  [<ffffffff816d5685>] tc_ctl_tfilter+0x335/0x910
[  912.799443]  [<ffffffff813622a8>] ? security_capable+0x48/0x60
[  912.799448]  [<ffffffff816b90e5>] rtnetlink_rcv_msg+0x95/0x240
[  912.799454]  [<ffffffff810f612d>] ? trace_hardirqs_on+0xd/0x10
[  912.799456]  [<ffffffff816b902f>] ? rtnetlink_rcv+0x1f/0x40
[  912.799459]  [<ffffffff816b902f>] ? rtnetlink_rcv+0x1f/0x40
[  912.799461]  [<ffffffff816b9050>] ? rtnetlink_rcv+0x40/0x40
[  912.799464]  [<ffffffff816df38f>] netlink_rcv_skb+0xaf/0xc0
[  912.799467]  [<ffffffff816b903e>] rtnetlink_rcv+0x2e/0x40
[  912.799469]  [<ffffffff816deaef>] netlink_unicast+0xef/0x1b0
[  912.799471]  [<ffffffff816defa0>] netlink_sendmsg+0x3f0/0x620
[  912.799476]  [<ffffffff81687028>] sock_sendmsg+0x38/0x50
[  912.799479]  [<ffffffff81687938>] ___sys_sendmsg+0x288/0x290
[  912.799482]  [<ffffffff810f7852>] ? __lock_acquire+0x572/0x2050
[  912.799488]  [<ffffffff810265db>] ? native_sched_clock+0x2b/0x90
[  912.799493]  [<ffffffff8116135f>] ? __audit_syscall_entry+0xaf/0x100
[  912.799497]  [<ffffffff8116135f>] ? __audit_syscall_entry+0xaf/0x100
[  912.799501]  [<ffffffff8112aa19>] ? current_kernel_time+0x69/0xd0
[  912.799505]  [<ffffffff81266f16>] ? __fget_light+0x66/0x90
[  912.799508]  [<ffffffff81688812>] __sys_sendmsg+0x42/0x80
[  912.799510]  [<ffffffff81688862>] SyS_sendmsg+0x12/0x20
[  912.799515]  [<ffffffff817f9a6e>] entry_SYSCALL_64_fastpath+0x12/0x76
[  912.799540] Code: 4d 88 49 8b 57 08 48 89 51 08 49 8b 57 10 48 89 c8 48 83 c0 08 48
                      89 51 10 48 8b 51 10 48 c7 c6 c0 51 9d a0 48 c7 c7 a6 51 9d a0 <48>
                      89 02 48 8b 51 08 48 89 42 08 48 b8 00 02 20 00 00 00 ad de
[  912.799544] RIP  [<ffffffffa09d4d6d>] cls_bpf_change+0x23d/0x268 [cls_bpf]
[  912.799544]  RSP <ffff88005f7379c8>
[  912.799545] CR2: 0000000000000000
[  912.807380] ---[ end trace a6440067cfdc7c29 ]---

I've split them into 3 patches, so they can be backported easier when needed.

Thanks!

Daniel Borkmann (3):
sched: cls_bpf: fix panic on filter replace
sched: cls_flower: fix panic on filter replace
sched: cls_flow: fix panic on filter replace

  net/sched/cls_bpf.c    | 2 +-
  net/sched/cls_flow.c   | 5 +++--
  net/sched/cls_flower.c | 2 +-
  3 files changed, 5 insertions(+), 4 deletions(-)
reviewer
#10 lore raw
Quoted 7 lines · Daniel Borkmann
Quoted 2 lines · Daniel Borkmann

This fixes a couple of panics in the form of (analogous for cls_flow{,er}):

[ Also putting John into Cc for these fixes as it has to do with all
the RCU conversion, sorry just realized that after git send-email. ]

No problem. Thanks a lot for cleaning it up for me.

.John

maintainer
#11 lore raw
In reply to Daniel Borkmann

From: Daniel Borkmann <[email protected]>
Date: Fri, 17 Jul 2015 22:38:42 +0200

Quoted 2 lines

This fixes a couple of panics in the form of (analogous for cls_flow{,er}):

...

Quoted 2 lines

I've split them into 3 patches, so they can be backported easier when needed.

Series applied and queued up for -stable, thanks.