Messages in this thread | | | Date | Tue, 28 Aug 2018 16:59:38 +0100 | From | Al Viro <> | Subject | Re: [PATCH] net: sched: Fix memory exposure from short TCA_U32_SEL |
| |
On Tue, Aug 28, 2018 at 01:03:10AM +0100, Al Viro wrote: > if (tcf_exts_get_net(&n->exts)) > tcf_queue_work(&n->rwork, u32_delete_key_freepf_work); > else > u32_destroy_key(n->tp, n, true); > ... and we hit u32_destroy_key(<tp>, <knode>, true), which does
Speaking of which, we'd better never hit that branch for other reasons - there's no RCU delay between removal of knode from the hash chain and its kfree(). tcf_queue_work() does guarantee such delay (by use of queue_rcu_work()), direct call doesn't...
Anyway, whichever branch is taken, the memory corruption problem remains - the comments below are accurate, AFAICS.
> Incidentally, if we hit > tcf_queue_work(&n->rwork, u32_delete_key_freepf_work); > instead of u32_destroy_key(), the things don't seem to be any better - we > won't do anything to <knode> until rtnl is dropped, so u32_destroy() won't > break on the second pass through the loop - it'll free <ht0> there and > return. Setting us up for trouble, since when u32_delete_key_freepf_work() > finally gets to u32_destroy_key() we'll have <knode>->ht_down pointing > to freed memory and decrementing its contents...
| |