[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20140125.110745.939440249416819926.davem@davemloft.net>
Date: Sat, 25 Jan 2014 11:07:45 -0800 (PST)
From: David Miller <davem@...emloft.net>
To: horia.geanta@...escale.com
Cc: steffen.klassert@...unet.com, netdev@...r.kernel.org
Subject: Re: [PATCH] xfrm: fix potential incorrect pointer dereference in
xfrm_bundle_create
From: Horia Geanta <horia.geanta@...escale.com>
Date: Sat, 25 Jan 2014 20:47:53 +0200
> Return value of xfrm_alloc_dst might be an error code.
> Need to check this before using the pointer safely.
>
> Signed-off-by: Horia Geanta <horia.geanta@...escale.com>
> ---
> net/xfrm/xfrm_policy.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/net/xfrm/xfrm_policy.c b/net/xfrm/xfrm_policy.c
> index 9a91f74..f230f2a 100644
> --- a/net/xfrm/xfrm_policy.c
> +++ b/net/xfrm/xfrm_policy.c
> @@ -1541,7 +1541,7 @@ static struct dst_entry *xfrm_bundle_create(struct xfrm_policy *policy,
>
> for (; i < nx; i++) {
> struct xfrm_dst *xdst = xfrm_alloc_dst(net, family);
> - struct dst_entry *dst1 = &xdst->u.dst;
> + struct dst_entry *dst1;
There is no harm in taking the address of a bad pointer. The only
trouble is if we actually dereference it, which we are not doing here.
I'm not applying this patch, sorry.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists