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 <[email protected]>
---
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) {
From: Gen Zhang <[email protected]>
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 <[email protected]>
Applied.
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 <[email protected]>
>
> ---
> 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
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 <[email protected]>
> >
> > ---
> > 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