Linux panic on fragemented IPv6 traffic (icmp6_send) | Hacker News Reader

Linux panic on fragemented IPv6 traffic (icmp6_send)

seclists.org

146 pointsBuuQu9hu25 comments

It was assigned CVE-2016-9919. https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-9919

This all happened December 8th. I'm surprised this didn't make more noise, but it's unclear to me what versions are affected. It was reported on 4.8.12 and not marked as a regression, and was fixed during 4.9 development.

It's normal not to make noise about security bugs. The CVE was issued almost two weeks after the fix landed in mainline. Surely the stable kernels were patched at the same time and the distros had pushed updates already.

Corollary: people writing exploits actively follow email lists such as this one for security issues.

Naturally they do.

I'm guessing this was intentionally handled quietly (though still in the open) until most people had already updated.

curious would this affect some consumer products that are ipv6 ready but dont ever get patched?

It'd be a relatively narrow window - it didn't affect RHEL 5/6/7 or the Ubuntu releases, so it'd need to be someone running a recent enough kernel to catch it but unmaintained enough to not push out the fixes.

Presuming this landed in 4.8 (guessing based on the kernels Debian listed fixes for versus not affected [1]), which came out in October 2016, that's 2 months of time when someone could have picked a stable release and gotten bitten by this.

update: it's actually even narrower, since it looks like those lines were added in a patch from November 3rd [2], so maybe a month.

[1] - https://security-tracker.debian.org/tracker/CVE-2016-9919

[2] - https://www.spinics.net/lists/netdev/msg402791.html

Kernel 4.8 won't be in many distros before years.

Kernel 4.8 will probably never be in distros, 4.9 is probably the LTS release they will use.

As far as I can tell it appears to be a classic use of an uninitialized pointer.

Are there not static analysis tools routinely used against Linux that should have caught this?

Or runtime memory access detection, like valgrind.

I know both might be slow on a project the size the Linux kernel, but it seems worth it.

You can't run valgrind on the kernel (not because of the speed, but because the way valgrind works it's not technically feasible), but even if you could, the bad access only occurred when the particular type of packet was received. The kernel panic essentially was the kernel's run-time bad access detection triggering.

you can run the kernel in userspace so that valgrind can attach to it.

It was done for UML kernel 2.6 with patches: http://web.archive.org/web/20100126181646/http://uml.jfdi.or... .

But today, it's impossible:

http://marc.info/?l=user-mode-linux-user&m=140187124116532&w...

> > So, is it possible to run linux (>3.12) with valgrind? If yes, how to do it?

> No.

> A long time ago it was possible after applying a patch to both UML and valgrind.

But why would you want to? There's kasan, which is faster and catches more bug classes.

It was catched with syzcaller and kasan. syzcaller is a kernel fuzzing tool, kasan is "like valgrind, but for the kernel" (the kernel version of address sanitizer. in general I like to describe address sanitizer as "like valgrind, just better".)

Neat! I wonder why they're not part of kernel release tests.

Yes there are:

https://scan.coverity.com/projects/linux

100% code coverage for symbolic execution of the kernel seems a bit optimistic, no?

Already fixed in Debian, probably fixed in most other distros as well considering it was posted Dec 8th.

https://security-tracker.debian.org/tracker/CVE-2016-9919

It's going to be interesting to watch for all of the same exploits come through for IPv6 that came through for v4. This sounds like Teardrop from the Win9x era, I'm waiting to see WinNuke and whatever other variants are still to be discovered.

Oh, so that's why I've been seeing that weird IPv6 traffic on my collectors.

Record a bit if you see any more, maybe.

With its millions of lines of code, Linux is guaranteed to hide a bug or two.

I'm a bit confused. One if changes between IPv4 and IPv6 was removing fragmentation feature. How does it work then. For some reason the CVE does not load for me.

What was removed was fragmentation done by the network. Now it's hard coded to use PMTU discovery, whereas in v4 fragmentation was transparent to apps if you didn't set the "don't fragment" bit.

Reply on news.ycombinator.com