HN Explorer

26 comments

[ 3.1 ms ] story [ 59.5 ms ] thread
[deleted]
(comment deleted)
codehusker
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.

derefr
I'm guessing this was intentionally handled quietly (though still in the open) until most people had already updated.
rmkbow
curious would this affect some consumer products that are ipv6 ready but dont ever get patched?
rincebrain
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

Thaxll
Kernel 4.8 won't be in many distros before years.
justincormack
Kernel 4.8 will probably never be in distros, 4.9 is probably the LTS release they will use.
ajross
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.
alpb
Corollary: people writing exploits actively follow email lists such as this one for security issues.
trelliscoded
Oh, so that's why I've been seeing that weird IPv6 traffic on my collectors.
i336_
Record a bit if you see any more, maybe.
xja
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.

caf
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.
m00dy
you can run the kernel in userspace so that valgrind can attach to it.
hannob
But why would you want to? There's kasan, which is faster and catches more bug classes.
hannob
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".)
xja
Neat! I wonder why they're not part of kernel release tests.
snvzz
With its millions of lines of code, Linux is guaranteed to hide a bug or two.
takeda
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.
fulafel
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.
web007
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.