On Fri, 5 Aug 2022 at 10:53, Zhang Chen <chen.zh...@intel.com> wrote: > > When enable the virtio-net-pci, guest network packet will > load the vnet_hdr. In COLO status, the primary VM's network > packet maybe redirect to another VM, it need filter-redirect > enable the vnet_hdr flag at the same time, COLO-proxy will > correctly parse the original network packet. If have any > misconfiguration here, the vnet_hdr_len is wrong for parse > the packet, the data+offset will point to wrong place. > > Signed-off-by: Zhang Chen <chen.zh...@intel.com> > --- > net/colo.c | 17 +++++++++-------- > 1 file changed, 9 insertions(+), 8 deletions(-) > > diff --git a/net/colo.c b/net/colo.c > index 6b0ff562ad..524afa3d9b 100644 > --- a/net/colo.c > +++ b/net/colo.c > @@ -44,21 +44,22 @@ int parse_packet_early(Packet *pkt) > { > int network_length; > static const uint8_t vlan[] = {0x81, 0x00}; > - uint8_t *data = pkt->data + pkt->vnet_hdr_len; > + uint8_t *data = pkt->data; > uint16_t l3_proto; > ssize_t l2hdr_len; > > - if (data == NULL) { > - trace_colo_proxy_main_vnet_info("This packet is not parsed > correctly, " > + assert(data); > + > + /* Check the received vnet_hdr_len then add the offset */ > + if (pkt->size < sizeof(struct eth_header) + sizeof(struct vlan_header) > + + pkt->vnet_hdr_len) {
I think this expression needs more care to avoid overflow with a maliciously over-large vnet_hdr_len value. Casting pkt->vnet_hdr_len to int64_t would be one way to do that; there may be better approaches. thanks -- PMM