Created kernel tracking bugs for this issue:

Affects: fedora-all [bug 1715502]

Investigation (Paraphrased):

The declared NULL ptr dereference within this function can not happen.

Reporting below the relevant code (pretty much unchanged since Red Hat Enterprise Linux 5  at its introduction):

        new_ra = on ? kmalloc(sizeof(*new_ra), GFP_KERNEL) : NULL;
	/* ^^^^ this is where it apparently can fail */

        mutex_lock(&net->ipv4.ra_mutex);
        for (rap = &net->ipv4.ra_chain;
             (ra = rcu_dereference_protected(*rap,
                        lockdep_is_held(&net->ipv4.ra_mutex))) != NULL;
             rap = &ra->next) {
                if (ra->sk == sk) {
                        if (on) {
                                mutex_unlock(&net->ipv4.ra_mutex);
                                kfree(new_ra); /* *************** kfree() would deal with a null here */
                                return -EADDRINUSE;
                        }
                        /* dont let ip_call_ra_chain() use sk again */
                        ra->sk = NULL;
                        RCU_INIT_POINTER(*rap, ra->next);
                        mutex_unlock(&net->ipv4.ra_mutex);

                        if (ra->destructor)
                                ra->destructor(sk);
                        /*
                         * Delay sock_put(sk) and kfree(ra) after one rcu grace
                         * period. This guarantee ip_call_ra_chain() dont need
                         * to mess with socket refcounts.
                         */
                        ra->saved_sk = sk;
                        call_rcu(&ra->rcu, ip_ra_destroy_rcu);
                        return 0;
                }
        }
        if (!new_ra) { /* ******* this is the null check that was believed to be missing, it bails here if null*/
                mutex_unlock(&net->ipv4.ra_mutex);
                return -ENOBUFS;
        }
        new_ra->sk = sk; /* THis part will never be executed/run if new_ra is null */
        new_ra->destructor = destructor; /* this part will never be dereferenced if new_ra is null */


Since kfree() is designed to handle correctly even NULL ptr, the above derefences of new_ra can not happen as they are protected by the immediate check above them.

Red Hat is open to discussion on this flaw if you have an an additional vector within the code please dont hesitate to put a discussion here and set NEEDINFO on wmealing.

Thanks!

Hi Wade,

I have the same question with you. I can't find the risk from the new_ra as a C developer, if the 'new_ra = NULL', it will be checked before it is used. 
But I saw the linux-stable had merged this patch. The kernel maintainers may have a reason to do this. 
I'm not familiar about the 'NULL pointer dereference', maybe the attacker can use this?  

I really want to know the risk of this CVE. 
Anyone can help to explain?  Thanks a lot!

Best Regards,
Dongyang