Slashdot Mirror

← Back to Stories (view on slashdot.org)

Linux Virtual Ethernet Bug Delivers Corrupt TCP/IP Data (vijayp.ca)

Posted by timothy on from the absolute-power dept.

jones_supa writes: Vijay Pandurangan from Twitter warns about a Linux kernel bug that causes containers using Virtual Ethernet devices for network routing to not check TCP checksums. Examples of software stacks that use Virtual Ethernet devices are Docker on IPv6, Kubernetes, Google Container Engine and Mesos. The kernel flaw results in applications incorrectly receiving corrupt data in a number of situations, such as with bad networking hardware. The bug dates back at least 3 years or more – it is present in kernels as far back as the Twitter engineering team has tested. Their patch has been reviewed and accepted into the kernel, and is currently being backported to -stable releases back to 3.14 in various distributions. If you use containers in your setup, Pandurangan recommends that you deploy a kernel with this patch.

4 of 40 comments (clear)

  1. Better late than never by Anonymous Coward · · Score: 4, Funny

    After ten years and billions of dollars, Twitter has finally contributed something useful to society.

  2. There's a term for that by halivar · · Score: 3, Insightful

    "Cutting off your nose to spite your face."

  3. I could have sworn this was intentional by Verdatum · · Score: 4, Interesting

    I was under the impression that virtual ethernet devices intentionally don't bother verifying checksums, because they were intended to be used in situations where there is very little probability of the data being corrupted.

    1. Re:I could have sworn this was intentional by Anonymous Coward · · Score: 5, Informative

      Most NICs don't drop packets with bad L3/L4 checksums. Instead they flag them as bad and pass them to software, and the packet doesn't get checked until it hits the TCP/IP stack. The problem is that in this configuration, the packet arrives and the physical NIC and is flagged as bad, but when it is passed through the veth device that flag is intentionally cleared, and only after passing through the veth device does it hit the TCP/IP stack. Because the checksum was marked as good the stack trusts it and passes the data up to the socket.