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
