[PATCH net 0/3] Couple of classifier fixes

[PATCH net 0/3] Couple of classifier fixes

[Daniel Borkmann]

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(-)

-- 
1.9.3

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

[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

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 <daniel@iogearbox.net>
---
 net/sched/cls_bpf.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/sched/cls_bpf.c b/net/sched/cls_bpf.c
index c79ecfd..e5168f8 100644
--- a/net/sched/cls_bpf.c
+++ b/net/sched/cls_bpf.c
@@ -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 {
-- 
1.9.3

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

[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 <daniel@iogearbox.net>
---
 net/sched/cls_flower.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/sched/cls_flower.c b/net/sched/cls_flower.c
index 9d37ccd..2f3d03f 100644
--- a/net/sched/cls_flower.c
+++ b/net/sched/cls_flower.c
@@ -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 {
-- 
1.9.3

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

[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 <daniel@iogearbox.net>
---
 net/sched/cls_flow.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/net/sched/cls_flow.c b/net/sched/cls_flow.c
index 76bc3a2..bb2a0f5 100644
--- a/net/sched/cls_flow.c
+++ b/net/sched/cls_flow.c
@@ -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;
 
-- 
1.9.3

Re: [PATCH net 0/3] Couple of classifier fixes

[Daniel Borkmann]

On 07/17/2015 10:38 PM, Daniel Borkmann wrote:
> 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. ]

> [  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(-)
>

Re: [PATCH net 0/3] Couple of classifier fixes

[John Fastabend]

On 15-07-17 01:41 PM, Daniel Borkmann wrote:
> On 07/17/2015 10:38 PM, Daniel Borkmann wrote:
>> 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

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

[John Fastabend]

On 15-07-17 01:38 PM, Daniel Borkmann wrote:
> 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 <daniel@iogearbox.net>
> ---

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

FWIW,

Acked-by: John Fastabend <john.r.fastabend@intel.com>

>  net/sched/cls_bpf.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/net/sched/cls_bpf.c b/net/sched/cls_bpf.c
> index c79ecfd..e5168f8 100644
> --- a/net/sched/cls_bpf.c
> +++ b/net/sched/cls_bpf.c
> @@ -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 {
> 

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

[Daniel Borkmann]

On 07/17/2015 11:05 PM, John Fastabend wrote:
...
> 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

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

[John Fastabend]

On 15-07-17 01:38 PM, Daniel Borkmann wrote:
> 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 <daniel@iogearbox.net>
> ---
>  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 <john.r.fastabend@intel.com>

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

[Alexei Starovoitov]

On 7/17/15 2:05 PM, John Fastabend wrote:
> On 15-07-17 01:38 PM, Daniel Borkmann wrote:
>> >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<daniel@iogearbox.net>
>> >---
> Thanks Daniel. Apparently I got this right in cls_basic but botched it
> here and in cls_flow.
>
> FWIW,
>
> Acked-by: John Fastabend<john.r.fastabend@intel.com>

Thanks for the quick fix.
Acked-by: Alexei Starovoitov <ast@plumgrid.com>

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

[Jiri Pirko]

Fri, Jul 17, 2015 at 10:38:44PM CEST, daniel@iogearbox.net 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
>
>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 <daniel@iogearbox.net>


Acked-by: Jiri Pirko <jiri@resnulli.us>

Re: [PATCH net 0/3] Couple of classifier fixes

[David Miller]

From: Daniel Borkmann <daniel@iogearbox.net>
Date: Fri, 17 Jul 2015 22:38:42 +0200

> This fixes a couple of panics in the form of (analogous for
> cls_flow{,er}):
 ...
> I've split them into 3 patches, so they can be backported easier
> when needed.

Series applied and queued up for -stable, thanks.