netdev - Re: [PATCH] net/vxlan: fix potential null pointer deference

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 31 May 2019 10:50:41 +0200
From:   Paolo Abeni <pabeni@...hat.com>
To:     Young Xiao <92siuyang@...il.com>, davem@...emloft.net,
        petrm@...lanox.com, roopa@...ulusnetworks.com, idosch@...lanox.com,
        sbrivio@...hat.com, netdev@...r.kernel.org
Subject: Re: [PATCH] net/vxlan: fix potential null pointer deference

On Fri, 2019-05-31 at 16:34 +0800, Young Xiao wrote:
> There is a possible null pointer deference bug in vxlan_fdb_info(),
> which is similar to the bug which was fixed in commit 6adc5fd6a142
> ("net/neighbour: fix crash at dumping device-agnostic proxy entries").
> 
> Signed-off-by: Young Xiao <92siuyang@...il.com>
> ---
>  drivers/net/vxlan.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/net/vxlan.c b/drivers/net/vxlan.c
> index 5994d54..1ba5977 100644
> --- a/drivers/net/vxlan.c
> +++ b/drivers/net/vxlan.c
> @@ -274,7 +274,7 @@ static int vxlan_fdb_info(struct sk_buff *skb, struct vxlan_dev *vxlan,
>  	} else
>  		ndm->ndm_family	= AF_BRIDGE;
>  	ndm->ndm_state = fdb->state;
> -	ndm->ndm_ifindex = vxlan->dev->ifindex;
> +	ndm->ndm_ifindex = vxlan->dev ? vxlan->dev->ifindex : 0;
>  	ndm->ndm_flags = fdb->flags;
>  	if (rdst->offloaded)
>  		ndm->ndm_flags |= NTF_OFFLOADED;

vxlan->dev points to the struct net_device for this vxlan device. It
can't be NULL. 

I suggest to look for working reproducer for this kind of issue before
adding additional, unneeded, checks. We want to avoid as many unneeded
conditionals as possible.

Thanks,

Paolo