From: valis sec@valis.email
Commit 76e42ae831991c828cffa8c37736ebfb831ad5ec upstream.
[ Fixed small conflict as 'fnew->ifindex' assignment is not protected by CONFIG_NET_CLS_IND on upstream since a51486266c3 ]
When fw_change() is called on an existing filter, the whole tcf_result struct is always copied into the new instance of the filter.
This causes a problem when updating a filter bound to a class, as tcf_unbind_filter() is always called on the old instance in the success path, decreasing filter_cnt of the still referenced class and allowing it to be deleted, leading to a use-after-free.
Fix this by no longer copying the tcf_result struct from the old filter.
Fixes: e35a8ee5993b ("net: sched: fw use RCU") Reported-by: valis sec@valis.email Reported-by: Bing-Jhong Billy Jheng billy@starlabs.sg Signed-off-by: valis sec@valis.email Signed-off-by: Jamal Hadi Salim jhs@mojatatu.com Reviewed-by: Victor Nogueira victor@mojatatu.com Reviewed-by: Pedro Tammela pctammela@mojatatu.com Reviewed-by: M A Ramdhan ramdhan@starlabs.sg Link: https://lore.kernel.org/r/20230729123202.72406-3-jhs@mojatatu.com Signed-off-by: Jakub Kicinski kuba@kernel.org Signed-off-by: Luiz Capitulino luizcap@amazon.com --- net/sched/cls_fw.c | 1 - 1 file changed, 1 deletion(-)
Valis, Greg,
I noticed that 4.14 is missing this fix while we backported all three fixes from this series to all stable kernels:
https://lore.kernel.org/all/20230729123202.72406-1-jhs@mojatatu.com
Is there a reason to have skipped 4.14 for this fix? It seems we need it.
This is only compiled-tested though, would be good to have a confirmation from Valis that the issue is present on 4.14 before applying.
- Luiz
diff --git a/net/sched/cls_fw.c b/net/sched/cls_fw.c index e63f9c2e37e5..7b04b315b2bd 100644 --- a/net/sched/cls_fw.c +++ b/net/sched/cls_fw.c @@ -281,7 +281,6 @@ static int fw_change(struct net *net, struct sk_buff *in_skb, return -ENOBUFS;
fnew->id = f->id; - fnew->res = f->res; #ifdef CONFIG_NET_CLS_IND fnew->ifindex = f->ifindex; #endif /* CONFIG_NET_CLS_IND */
On Mon, Sep 18, 2023 at 8:09 PM Luiz Capitulino luizcap@amazon.com wrote:
Valis, Greg,
I noticed that 4.14 is missing this fix while we backported all three fixes from this series to all stable kernels:
https://lore.kernel.org/all/20230729123202.72406-1-jhs@mojatatu.com
Is there a reason to have skipped 4.14 for this fix? It seems we need it.
Hi Luiz!
I see no reason why it should be skipped for 4.14 I've just checked 4.14.325 - it is vulnerable and needs this fix.
Best regards,
valis
This is only compiled-tested though, would be good to have a confirmation from Valis that the issue is present on 4.14 before applying.
- Luiz
diff --git a/net/sched/cls_fw.c b/net/sched/cls_fw.c index e63f9c2e37e5..7b04b315b2bd 100644 --- a/net/sched/cls_fw.c +++ b/net/sched/cls_fw.c @@ -281,7 +281,6 @@ static int fw_change(struct net *net, struct sk_buff *in_skb, return -ENOBUFS;
fnew->id = f->id;
fnew->res = f->res;
#ifdef CONFIG_NET_CLS_IND fnew->ifindex = f->ifindex;
#endif /* CONFIG_NET_CLS_IND */
2.40.1
On 2023-09-18 15:17, valis wrote:
On Mon, Sep 18, 2023 at 8:09 PM Luiz Capitulino luizcap@amazon.com wrote:
Valis, Greg,
I noticed that 4.14 is missing this fix while we backported all three fixes from this series to all stable kernels:
https://lore.kernel.org/all/20230729123202.72406-1-jhs@mojatatu.com
Is there a reason to have skipped 4.14 for this fix? It seems we need it.
Hi Luiz!
I see no reason why it should be skipped for 4.14 I've just checked 4.14.325 - it is vulnerable and needs this fix.
Thank you for the quick reply!
- Luiz
Best regards,
valis
This is only compiled-tested though, would be good to have a confirmation from Valis that the issue is present on 4.14 before applying.
- Luiz
diff --git a/net/sched/cls_fw.c b/net/sched/cls_fw.c index e63f9c2e37e5..7b04b315b2bd 100644 --- a/net/sched/cls_fw.c +++ b/net/sched/cls_fw.c @@ -281,7 +281,6 @@ static int fw_change(struct net *net, struct sk_buff *in_skb, return -ENOBUFS;
fnew->id = f->id;
#ifdef CONFIG_NET_CLS_IND fnew->ifindex = f->ifindex; #endif /* CONFIG_NET_CLS_IND */fnew->res = f->res;
-- 2.40.1
Hi Luiz,
On 19/09/23 12:47 am, valis wrote:
On Mon, Sep 18, 2023 at 8:09 PM Luiz Capitulino luizcap@amazon.com wrote:
Valis, Greg,
I noticed that 4.14 is missing this fix while we backported all three fixes from this series to all stable kernels:
https://lore.kernel.org/all/20230729123202.72406-1-jhs@mojatatu.com
Is there a reason to have skipped 4.14 for this fix? It seems we need it.
I think we need to apply this to 4.19.y as well.
Your backport patch applies there as well. I compiled the kernel after applying your patch to linux-4.19.y's tip.
Thanks, Harshit
Hi Luiz!
I see no reason why it should be skipped for 4.14 I've just checked 4.14.325 - it is vulnerable and needs this fix.
Best regards,
valis
This is only compiled-tested though, would be good to have a confirmation from Valis that the issue is present on 4.14 before applying.
- Luiz
diff --git a/net/sched/cls_fw.c b/net/sched/cls_fw.c index e63f9c2e37e5..7b04b315b2bd 100644 --- a/net/sched/cls_fw.c +++ b/net/sched/cls_fw.c @@ -281,7 +281,6 @@ static int fw_change(struct net *net, struct sk_buff *in_skb, return -ENOBUFS;
fnew->id = f->id;
#ifdef CONFIG_NET_CLS_IND fnew->ifindex = f->ifindex; #endif /* CONFIG_NET_CLS_IND */fnew->res = f->res;
-- 2.40.1
On Mon, Sep 18, 2023 at 06:08:59PM +0000, Luiz Capitulino wrote:
From: valis sec@valis.email
Commit 76e42ae831991c828cffa8c37736ebfb831ad5ec upstream.
[ Fixed small conflict as 'fnew->ifindex' assignment is not protected by CONFIG_NET_CLS_IND on upstream since a51486266c3 ]
Now queued up, thanks.
greg k-h
linux-stable-mirror@lists.linaro.org