From: Thadeu Lima de Souza Cascardo cascardo@canonical.com
commit 9ad36309e2719a884f946678e0296be10f0bb4c1 upstream.
When a route filter is replaced and the old filter has a 0 handle, the old one won't be removed from the hashtable, while it will still be freed.
The test was there since before commit 1109c00547fc ("net: sched: RCU cls_route"), when a new filter was not allocated when there was an old one. The old filter was reused and the reinserting would only be necessary if an old filter was replaced. That was still wrong for the same case where the old handle was 0.
Remove the old filter from the list independently from its handle value.
This fixes CVE-2022-2588, also reported as ZDI-CAN-17440.
Reported-by: Zhenpeng Lin zplin@u.northwestern.edu Signed-off-by: Thadeu Lima de Souza Cascardo cascardo@canonical.com Reviewed-by: Kamal Mostafa kamal@canonical.com Cc: stable@vger.kernel.org Acked-by: Jamal Hadi Salim jhs@mojatatu.com Link: https://lore.kernel.org/r/20220809170518.164662-1-cascardo@canonical.com Signed-off-by: Jakub Kicinski kuba@kernel.org Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org --- net/sched/cls_route.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
--- a/net/sched/cls_route.c +++ b/net/sched/cls_route.c @@ -526,7 +526,7 @@ static int route4_change(struct net *net rcu_assign_pointer(f->next, f1); rcu_assign_pointer(*fp, f);
- if (fold && fold->handle && f->handle != fold->handle) { + if (fold) { th = to_hash(fold->handle); h = from_hash(fold->handle >> 16); b = rtnl_dereference(head->table[th]);