On 5/2/23 17:48, David Morel via discuss wrote: > > Hello, > I'm trying to reproduce the issue from CVE-2023-1668. > > For some context, I backported the patch to an older version, therefore I > would like to be able to confirm it was properly backported and that I'm able > to reproduce the issue before the backported patch, and not after applying it. > > What I tried to do is to create a flow rule that changes the destination ip > address: > ovs-ofctl add-flow xenbr0 "table=0, priority=100, dl_type=0x0800, ip_dst=$X, > ip_src=$Y, actions=mod_nw_dst=$X" > > I then ensured that packets from $X to $Y were matching the rule and that the > n_packets= in a dump-flows was incrementing. > > Finally I crafted a packet with scapy setting the ip proto field to 0 and > sent it in a loop. I'm not sure this was supposed to be the case, but it was > actually matching the flow rule too. > > I tried to check the bucket using: > ovs-ofctl dump-groups xenbr0 -O OpenFlow13 > > But didn't see anything, I also tried to have a lot of traffic going through > the bridge to see if memory usage would evolve as from my understanding of > the CVE, once we have a packet with a 0 proto, and a rule changing a field of > the IP header, every traffic is captured in a bucket. > > I guess I'm doing something wrong, some help would be welcome!
Hi. The main issue with your test seems to be that you need to send the wrong packet before sending correct ones. And you need to look at datapath flows installed in the kernel with ovs-appctl dpctl/dump-flows. 'ovs-ofctl dump-groups' makes no sense in this context as you're not using OpenFlow groups. In general, successful execution of the unit tests supplied with the fix should be enough to confirm that fix is working. Best regards, Ilya Maximets. _______________________________________________ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
