[PATCH] ipv6_sockglue: Fix a missing-check bug in ip6_ra_control()

[PATCH] ipv6_sockglue: Fix a missing-check bug in ip6_ra_control()

[Gen Zhang]

In function ip6_ra_control(), the pointer new_ra is allocated a memory 
space via kmalloc(). And it is used in the following codes. However, 
when there is a memory allocation error, kmalloc() fails. Thus null 
pointer dereference may happen. And it will cause the kernel to crash. 
Therefore, we should check the return value and handle the error.

Signed-off-by: Gen Zhang <blackgod016574@gmail.com>

---
diff --git a/net/ipv6/ipv6_sockglue.c b/net/ipv6/ipv6_sockglue.c
index 40f21fe..0a3d035 100644
--- a/net/ipv6/ipv6_sockglue.c
+++ b/net/ipv6/ipv6_sockglue.c
@@ -68,6 +68,8 @@ int ip6_ra_control(struct sock *sk, int sel)
 		return -ENOPROTOOPT;
 
 	new_ra = (sel >= 0) ? kmalloc(sizeof(*new_ra), GFP_KERNEL) : NULL;
+	if (sel >= 0 && !new_ra)
+		return -ENOMEM;
 
 	write_lock_bh(&ip6_ra_lock);
 	for (rap = &ip6_ra_chain; (ra = *rap) != NULL; rap = &ra->next) {

Re: [PATCH] ipv6_sockglue: Fix a missing-check bug in ip6_ra_control()

[David Miller]

From: Gen Zhang <blackgod016574@gmail.com>
Date: Fri, 24 May 2019 11:19:46 +0800

> In function ip6_ra_control(), the pointer new_ra is allocated a memory 
> space via kmalloc(). And it is used in the following codes. However, 
> when there is a memory allocation error, kmalloc() fails. Thus null 
> pointer dereference may happen. And it will cause the kernel to crash. 
> Therefore, we should check the return value and handle the error.
> 
> Signed-off-by: Gen Zhang <blackgod016574@gmail.com>

Applied.

Re: [PATCH] ipv6_sockglue: Fix a missing-check bug in ip6_ra_control()

[Jiri Slaby]

On 24. 05. 19, 5:19, Gen Zhang wrote:
> In function ip6_ra_control(), the pointer new_ra is allocated a memory 
> space via kmalloc(). And it is used in the following codes. However, 
> when there is a memory allocation error, kmalloc() fails. Thus null 
> pointer dereference may happen. And it will cause the kernel to crash. 
> Therefore, we should check the return value and handle the error.
> 
> Signed-off-by: Gen Zhang <blackgod016574@gmail.com>
> 
> ---
> diff --git a/net/ipv6/ipv6_sockglue.c b/net/ipv6/ipv6_sockglue.c
> index 40f21fe..0a3d035 100644
> --- a/net/ipv6/ipv6_sockglue.c
> +++ b/net/ipv6/ipv6_sockglue.c
> @@ -68,6 +68,8 @@ int ip6_ra_control(struct sock *sk, int sel)
>  		return -ENOPROTOOPT;
>  
>  	new_ra = (sel >= 0) ? kmalloc(sizeof(*new_ra), GFP_KERNEL) : NULL;
> +	if (sel >= 0 && !new_ra)
> +		return -ENOMEM;
>  
>  	write_lock_bh(&ip6_ra_lock);
>  	for (rap = &ip6_ra_chain; (ra = *rap) != NULL; rap = &ra->next) {
> 

Was this really an omission? There is (!new_ra) handling below the for loop:
        if (!new_ra) {
                write_unlock_bh(&ip6_ra_lock);
                return -ENOBUFS;
        }

It used to handle both (sel >= 0) and (sel == 0) cases and it used to
return ENOBUFS in case of failure. For (sel >= 0) it also could at least
return EADDRINUSE when a collision was found -- even if memory was
exhausted.

In anyway, how could this lead to a pointer dereference? And why/how did
this get a CVE number?

thanks,
-- 
js
suse labs

Re: [PATCH] ipv6_sockglue: Fix a missing-check bug in ip6_ra_control()

[Gen Zhang]

On Mon, Jul 01, 2019 at 10:57:36AM +0200, Jiri Slaby wrote:
> On 24. 05. 19, 5:19, Gen Zhang wrote:
> > In function ip6_ra_control(), the pointer new_ra is allocated a memory 
> > space via kmalloc(). And it is used in the following codes. However, 
> > when there is a memory allocation error, kmalloc() fails. Thus null 
> > pointer dereference may happen. And it will cause the kernel to crash. 
> > Therefore, we should check the return value and handle the error.
> > 
> > Signed-off-by: Gen Zhang <blackgod016574@gmail.com>
> > 
> > ---
> > diff --git a/net/ipv6/ipv6_sockglue.c b/net/ipv6/ipv6_sockglue.c
> > index 40f21fe..0a3d035 100644
> > --- a/net/ipv6/ipv6_sockglue.c
> > +++ b/net/ipv6/ipv6_sockglue.c
> > @@ -68,6 +68,8 @@ int ip6_ra_control(struct sock *sk, int sel)
> >  		return -ENOPROTOOPT;
> >  
> >  	new_ra = (sel >= 0) ? kmalloc(sizeof(*new_ra), GFP_KERNEL) : NULL;
> > +	if (sel >= 0 && !new_ra)
> > +		return -ENOMEM;
> >  
> >  	write_lock_bh(&ip6_ra_lock);
> >  	for (rap = &ip6_ra_chain; (ra = *rap) != NULL; rap = &ra->next) {
> > 
> 
> Was this really an omission? There is (!new_ra) handling below the for loop:
>         if (!new_ra) {
>                 write_unlock_bh(&ip6_ra_lock);
>                 return -ENOBUFS;
>         }
> 
> It used to handle both (sel >= 0) and (sel == 0) cases and it used to
> return ENOBUFS in case of failure. For (sel >= 0) it also could at least
> return EADDRINUSE when a collision was found -- even if memory was
> exhausted.
> 
> In anyway, how could this lead to a pointer dereference? And why/how did
> this get a CVE number?
> 
> thanks,
> -- 
> js
> suse labs
This CVE is already disputed by other maintainers and marked *DISPUTED*
on the website.

Thanks
Gen