4 ms·

Linux panic on fragemented IPv6 traffic (icmp6_send)

146 points by BuuQu9hu 10y ago

deleted 10y ago
[deleted]
codehusker 10y ago
It was assigned CVE-2016-9919. https://cve.mitre.org/cgi-bin/cvename.cgi?name=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 10y ago
  I'm guessing this was intentionally handled quietly (though still in the open) until most people had already updated.
  - rmkbow 10y ago
    curious would this affect some consumer products that are ipv6 ready but dont ever get patched?
    - rincebrain 10y ago
      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 https://security-tracker.debian.org/tracker/CVE-2016-9919 [2] - https://www.spinics.net/lists/netdev/msg402791.html https://www.spinics.net/lists/netdev/msg402791.html
    - Thaxll 10y ago
      Kernel 4.8 won't be in many distros before years.
      - justincormack 10y ago
        Kernel 4.8 will probably never be in distros, 4.9 is probably the LTS release they will use.
- ajross 10y ago
  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 10y ago
    Corollary: people writing exploits actively follow email lists such as this one for security issues.
    - mfukar 10y ago
      Naturally they do.
click170 10y ago
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 https://security-tracker.debian.org/tracker/CVE-2016-9919
trelliscoded 10y ago
Oh, so that's why I've been seeing that weird IPv6 traffic on my collectors.
- i336_ 10y ago
  Record a bit if you see any more, maybe.
xja 10y ago
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 10y ago
  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 10y ago
    you can run the kernel in userspace so that valgrind can attach to it.
    - lisivka 10y ago
      It was done for UML kernel 2.6 with patches: http://web.archive.org/web/20100126181646/http://uml.jfdi.org/uml/Wiki.jsp?page=ValgrindingUML 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=2 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.
    - hannob 10y ago
      But why would you want to? There's kasan, which is faster and catches more bug classes.
- BuuQu9hu 10y ago
  Yes there are: https://scan.coverity.com/projects/linux https://scan.coverity.com/projects/linux
snvzz 10y ago
With its millions of lines of code, Linux is guaranteed to hide a bug or two.
takeda 10y ago
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 10y ago
  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 10y ago
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.

146 points by BuuQu9hu 10y ago

deleted 10y ago

[deleted]

It was assigned CVE-2016-9919. https://cve.mitre.org/cgi-bin/cvename.cgi?name=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 10y ago
I'm guessing this was intentionally handled quietly (though still in the open) until most people had already updated.
- rmkbow 10y ago
  curious would this affect some consumer products that are ipv6 ready but dont ever get patched?
  - rincebrain 10y ago
    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 https://security-tracker.debian.org/tracker/CVE-2016-9919 [2] - https://www.spinics.net/lists/netdev/msg402791.html https://www.spinics.net/lists/netdev/msg402791.html
  - Thaxll 10y ago
    Kernel 4.8 won't be in many distros before years.
    - justincormack 10y ago
      Kernel 4.8 will probably never be in distros, 4.9 is probably the LTS release they will use.
ajross 10y ago
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 10y ago
  Corollary: people writing exploits actively follow email lists such as this one for security issues.
  - mfukar 10y ago
    Naturally they do.

click170 10y ago

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 https://security-tracker.debian.org/tracker/CVE-2016-9919

trelliscoded 10y ago

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

i336_ 10y ago
Record a bit if you see any more, maybe.

xja 10y ago

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 10y ago
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 10y ago
  you can run the kernel in userspace so that valgrind can attach to it.
  - lisivka 10y ago
    It was done for UML kernel 2.6 with patches: http://web.archive.org/web/20100126181646/http://uml.jfdi.org/uml/Wiki.jsp?page=ValgrindingUML 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=2 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.
  - hannob 10y ago
    But why would you want to? There's kasan, which is faster and catches more bug classes.
BuuQu9hu 10y ago
Yes there are: https://scan.coverity.com/projects/linux https://scan.coverity.com/projects/linux

snvzz 10y ago

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

takeda 10y ago

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 10y ago
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 10y ago

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.