| Summary: | Kernel: memory corruption with ipv6 udp offloading (CVE-2013-4387) | ||
|---|---|---|---|
| Product: | Gentoo Security | Reporter: | Agostino Sarubbo <ago> |
| Component: | Kernel | Assignee: | Gentoo Kernel Security <security-kernel> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | kernel |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| URL: | http://www.openwall.com/lists/oss-security/2013/09/28/1 | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
CVE-2013-4387 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2013-4387): net/ipv6/ip6_output.c in the Linux kernel through 3.11.4 does not properly determine the need for UDP Fragmentation Offload (UFO) processing of small packets after the UFO queueing of a large packet, which allows remote attackers to cause a denial of service (memory corruption and system crash) or possibly have unspecified other impact via network traffic that triggers a large response packet. Fix in 3.11.7 onwards |
From ${URL} : Hi! I guess the following patch might be worth a CVE: | [PATCH] ipv6: udp packets following an UFO enqueued packet need also be handled by UFO | | In the following scenario the socket is corked: | If the first UDP packet is larger then the mtu we try to append it to the | write queue via ip6_ufo_append_data. A following packet, which is smaller | than the mtu would be appended to the already queued up gso-skb via | plain ip6_append_data. This causes random memory corruptions. | | In ip6_ufo_append_data we also have to be careful to not queue up the | same skb multiple times. So setup the gso frame only when no first skb | is available. | | This also fixes a shortcoming where we add the current packet's length to | cork->length but return early because of a packet > mtu with dontfrag set | (instead of sutracting it again). | | Found with trinity. While writing a reproducer to test this patch, I have seen silent memory corruption (which later manifests as e.g. a panic or hangs on shutdown) and oopses. It has been reported to netdev by Dmitry Vyukov <dvyukov@...gle.com> and was found with the AddressSanitizer for the kernel[1] and trinity. The patch is queued up for stable: http://patchwork.ozlabs.org/patch/276835/ and is already committed to linux-net: https://git.kernel.org/cgit/linux/kernel/git/davem/net.git/commit/?id=2811ebac2521ceac84f2bdae402455baa6a7fb47 I guess the erroneous behaviour was introduced here: | git describe --contains e89e9cf539a28df7d0eb1d0a545368e9920b34ac | v2.6.15-rc1~731^2~31 The reproducers are available on request. [1] https://code.google.com/p/address-sanitizer/wiki/AddressSanitizerForKernel