LVS
lvs-devel
Google
 
Web LinuxVirtualServer.org

Re: [PATCH] libipvs: Initialize ipvs_service_t variable

To: "Ryan O'Hara" <rohara@xxxxxxxxxx>
Subject: Re: [PATCH] libipvs: Initialize ipvs_service_t variable
Cc: lvs-devel@xxxxxxxxxxxxxxx
From: Julian Anastasov <ja@xxxxxx>
Date: Fri, 17 Jan 2014 23:03:43 +0200 (EET)
        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.

Regards

--
Julian Anastasov <ja@xxxxxx>
--
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

<Prev in Thread] Current Thread [Next in Thread>