Created kernel tracking bugs for this issue:

Affects: fedora-all [bug 1715460]

This flaw is rated as moderate as the exploit conditions required to force a system into 'low memory' externally would often results in local applications being terminated by the system out-of-memory handler (oomkiller) making this a very infeffective denial of service.

As these packets are also usually not-routed (link-local only) the attacker would need to be on the local network making them somewhat easy to trace.

This looks as though suse was the reporter or at least where we got it from, Awaiting an answer from them before you should continue...

Ive been involved in an email chain regarding this flaw.  The reporter was running a static code analysis software that had reported this flaw and the CVE was assigned.  He doesn't have an interest in either confirming or denying where this flaw takes place.

An email to mitre regarding retracting this CVE has been sent and no response has been made yet.

At this time Red Hat will not be consider this flaw to be valid and will not be fixing this issue.

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 ):

        new_ra = (sel >= 0) ? kmalloc(sizeof(*new_ra), GFP_KERNEL) : NULL;
        // the "fix" adds here: 'if (sel >= 0 && !new_ra) return -ENOMEM;'

        write_lock_bh(&ip6_ra_lock);
        for (rap = &ip6_ra_chain; (ra = *rap) != NULL; rap = &ra->next) {
                if (ra->sk == sk) {
                        if (sel >= 0) {
                                write_unlock_bh(&ip6_ra_lock);
                                kfree(new_ra);
                                return -EADDRINUSE;
                        }

                        *rap = ra->next;
                        write_unlock_bh(&ip6_ra_lock);

                        sock_put(sk);
                        kfree(ra);
                        return 0;
                }
        }
        if (!new_ra) {
                write_unlock_bh(&ip6_ra_lock);
                return -ENOBUFS;
        }
        new_ra->sk = sk;
        new_ra->sel = sel;
        new_ra->next = ra;
        *rap = new_ra;
        sock_hold(sk);
        write_unlock_bh(&ip6_ra_lock);
        return 0;

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!