On Fri, 17 Jan 2014 15:15:17 -0600 "Ryan O'Hara" <rohara@xxxxxxxxxx> wrote: > On Fri, Jan 17, 2014 at 11:03:43PM +0200, Julian Anastasov wrote: > > > > Hello, > > > > On Fri, 17 Jan 2014, Ryan O'Hara wrote: > > > > > The ipvs_get_service function declares an ipvs_service_t type variable > > > and initializes some of the values, but should really start by > > > initializing the entire structure. > > > > > > Signed-off-by: Ryan O'Hara <rohara@xxxxxxxxxx> > > > --- > > > libipvs/libipvs.c | 1 + > > > 1 file changed, 1 insertion(+) > > > > > > diff --git a/libipvs/libipvs.c b/libipvs/libipvs.c > > > index d2fec49..8baafed 100644 > > > --- a/libipvs/libipvs.c > > > +++ b/libipvs/libipvs.c > > > @@ -942,6 +942,7 @@ ipvs_get_service(__u32 fwmark, __u16 af, __u16 protocol, union nf_inet_addr addr > > > if (!svc) > > > return NULL; > > > > > > + memset(&tsvc, 0, sizeof(tsvc)); > > > tsvc.fwmark = fwmark; > > > tsvc.af = af; > > > tsvc.protocol= protocol; > > > -- > > > 1.8.1.4 > > > > Yes, it is a good idea. Another variant is to > > change malloc to calloc. May be ipvs_nl_fill_service_attr() > > can not crash in all cases when reading svc->pe_name[]. > > As for the kernel part, ip_vs_genl_parse_service() uses just > > the initialized fields when full_entry=0 for IPVS_CMD_GET_SERVICE > > but it is better to avoid problems in the future. > > Right. This 'bug' was found while running the code through a static > analyzer, which finds all sorts of nit-picks. Since the variable in > question here is on the stack, a simple memset seems sufficient. Sorry > for trivial patches, just trying to get rid of the complaints from the > analyzer. Thanks Ryan, Applied the patch. More followup patches to address more areas are welcome. Git tree for ipvsadm avail at: https://git.kernel.org/cgit/utils/kernel/ipvsadm/ipvsadm.git/ -- Best regards, Jesper Dangaard Brouer MSc.CS, Sr. Network Kernel Developer at Red Hat Author of http://www.iptv-analyzer.org LinkedIn: http://www.linkedin.com/in/brouer -- To unsubscribe from this list: send the line "unsubscribe lvs-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
