On Tue, Jan 22, 2019 at 6:30 AM Darrell Ball <[email protected]> wrote:
> The call to inet_ntop() in repl_ftp_v6_addr() is 1 short to handle > the maximum possible V6 address size for v4 mapping case. > > Found by inspection. > > Signed-off-by: Darrell Ball <[email protected]> > --- > lib/conntrack.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/lib/conntrack.c b/lib/conntrack.c > index 6b66750..922a58c 100644 > --- a/lib/conntrack.c > +++ b/lib/conntrack.c > @@ -3161,7 +3161,7 @@ repl_ftp_v6_addr(struct dp_packet *pkt, struct > ct_addr v6_addr_rep, > > char v6_addr_str[IPV6_SCAN_LEN] = {0}; > ovs_assert(inet_ntop(AF_INET6, &v6_addr_rep.ipv6_aligned, v6_addr_str, > - IPV6_SCAN_LEN - 1)); > + sizeof v6_addr_str)); > modify_packet(pkt, ftp_data_start + addr_offset_from_ftp_data_start, > addr_size, v6_addr_str, strlen(v6_addr_str), > orig_used_size); > Afaics in the rest of the code, IPV6_SCAN_LEN is only used in conjonction with ovs_scan*(). It makes more sense to me to use the libc buffer size when calling inet_ntop. Hence, should not v6_addr_str be declared as INET6_ADDRSTRLEN bytes long ? -- David Marchand _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
