Ilya Maximets <[email protected]> writes: > In a case where skb with an unconfirmed ct entry gets cloned, we may > end up processing both again but with different sets of extensions. > > The series of events: > > 1. The first clone wants to commit and runs the helpers wiring up > the extension pointer into the expectation list. > 2. Then it looses the confirmation keeping the entry unconfirmed. > 3. Second clone now wants to commit labels or run NAT and adds the > new extension for that breaking the pointer in the expectation > list causing UAF on the destruction path later. > > While this is possible to trigger, there should be no practical > network pipeline where we need to process both clones without > modifications in the same zone. So, let's just reset the entry in > case for some reason we got an skb with a shared one. This doesn't > affect any known use cases, but avoids any potential problems with > sharing and modification of the unconfirmed ct entry. > > Unlike openvswitch module, act_ct allows for NAT without commit. > Changing that would be a uAPI break. So, act_ct needs to reset on NAT > regardless of the commit flag to avoid reallocation of the extension > space. This, however, doesn't really change the picture for sensible > networking cases as there should be no need to run the same packet > twice (before and after the clone) through conntrack without packet > header or zone changes and without commit. > > The fixes tag points to the introduction of helpers, since that's the > main UAF trigger for the sharing. > > Fixes: a21b06e73191 ("net: sched: add helper support in act_ct") > Cc: [email protected] > Reported-by: Axel Mierczuk <[email protected]> > Signed-off-by: Ilya Maximets <[email protected]> > ---
Reviewed-by: Aaron Conole <[email protected]> _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
