Bugzilla – Bug 547131
VUL-0: CVE-2009-3613: kernel: ping of death II: return of the POD
Last modified: 2016-09-22 08:14:13 UTC
Your friendly security team received the following report via oss-security. Please respond ASAP. Date: Thu, 15 Oct 2009 14:20:00 +0800 From: Eugene Teo <eugeneteo@kernel.sg> To: oss-security@lists.openwall.com Subject: [oss-security] CVE request kernel: flood ping cause out-of-iommu error and panic when mtu larger than 1500 CC: "Steven M. Christey" <coley@linus.mitre.org> Executing ping -f -s 3000 IP in a certain network setup could trigger an out-of-IOMMU error, leading to a denial of service. Steps to reproduce the issue: https://bugzilla.redhat.com/show_bug.cgi?id=529137#c0 Triggering the issue would result in: PCI-DMA: Out of IOMMU space for 7222 bytes at device 0000:03:00.0 PCI-DMA: Out of IOMMU space for 7222 bytes at device 0000:03:00.0 <Repeated Many Many Times> PCI-DMA: Out of IOMMU space for 7222 bytes at device 0000:03:00.0 PCI-DMA: Out of IOMMU space for 7222 bytes at device 0000:03:00.0 HARDWARE ERROR CPU 0: Machine Check Exception: 7 Bank 4: bc0000000005001b RIP 10:<ffffffff8006b2b0> {default_idle+0x29/0x50} TSC 10116da2355 ADDR 4000000 MISC c008000001000000 This is not a software problem! Run through mcelog --ascii to decode and contact your hardware vendor Kernel panic - not syncing: Uncorrected machine check <7>APIC error on CPU2: 00(08) Upstream commits: http://git.kernel.org/linus/a866bbf6aacf95f849810079442a20be118ce905 http://git.kernel.org/linus/97d477a914b146e7e6722ded21afa79886ae8ccd References: http://bugzilla.kernel.org/show_bug.cgi?id=9468 https://bugzilla.redhat.com/show_bug.cgi?id=529137 Thanks, Eugene
SLE11 is not vulnerable, this was fixed in 2.6.27 and 2.6.27.22. Kernels older than this will have this problem, but it is only with one specific piece of hardware.
CVE-2009-3613
jiri? jeff? could you merge this to the older kernels too please?
Checked in to SLES10_SP3_BRANCH, SLES10_SP2_BRANCH, and SL110_BRANCH
A SLES 10 SP3 kernel update was just released that mentions / fixes this bug. The kernel version in the update is 2.6.16.60-0.58.1.
A SLES 10 SP2 kernel update was just released that mentions / fixes this bug. The kernel version in the update is 2.6.16.60-0.42.8.
Update released for: kernel-debug, kernel-debug-debuginfo, kernel-default, kernel-default-debuginfo, kernel-kdump, kernel-kdump-debuginfo, kernel-smp, kernel-smp-debuginfo, kernel-source, kernel-source-debuginfo, kernel-syms, kernel-xen, kernel-xen-debuginfo Products: SLE-DEBUGINFO 10-SP2 (x86_64) SLE-DESKTOP 10-SP2 (x86_64) SLE-SAP-AIO 10-SP2 (x86_64) SLE-SDK 10-SP2 (x86_64) SLE-SERVER 10-SP2 (x86_64)
Update released for: ib-bonding-kmp-rt, ib-bonding-kmp-rt_bigsmp, ib-bonding-kmp-rt_debug, ib-bonding-kmp-rt_timing, kernel-rt, kernel-rt_bigsmp, kernel-rt_debug, kernel-rt_timing, kernel-source, kernel-syms, ofed, ofed-cxgb3-NIC-kmp-rt, ofed-cxgb3-NIC-kmp-rt_bigsmp, ofed-cxgb3-NIC-kmp-rt_debug, ofed-cxgb3-NIC-kmp-rt_timing, ofed-doc, ofed-kmp-rt, ofed-kmp-rt_bigsmp, ofed-kmp-rt_debug, ofed-kmp-rt_timing Products: SLE-RT 10-SP2 (i386, x86_64)
AFACIS this issue is fixed by 2 patches: patches.drivers/r8169-balance-pci_map-pci_unmap-pair.patch patches.drivers/r8169-use-hardware-auto-padding.patch The code in sles10sp1 looks little bit differently so I think that the only 2nd patch is necessary. The code looks as follows: static int rtl8169_rx_interrupt(struct net_device *dev, struct rtl8169_private *tp, void __iomem *ioaddr) { [...] struct sk_buff *skb = tp->Rx_skbuff[entry]; int pkt_size = (status & 0x00001FFF) - 4; void (*pci_action)(struct pci_dev *, dma_addr_t, size_t, int) = pci_dma_sync_single_for_device; /* * The driver does not support incoming fragmented * frames. They are seen as a symptom of over-mtu * sized frames. */ if (unlikely(rtl8169_fragmented_frame(status))) { tp->stats.rx_dropped++; tp->stats.rx_length_errors++; rtl8169_mark_to_asic(desc, tp->rx_buf_sz); continue; } rtl8169_rx_csum(skb, desc); pci_dma_sync_single_for_cpu(tp->pci_dev, le64_to_cpu(desc->addr), tp->rx_buf_sz, PCI_DMA_FROMDEVICE); if (rtl8169_try_rx_copy(&skb, pkt_size, desc, tp->rx_buf_sz, tp->align)) { pci_action = pci_unmap_single; // <<<<<<<< tp->Rx_skbuff[entry] = NULL; } pci_action(tp->pci_dev, le64_to_cpu(desc->addr), tp->rx_buf_sz, PCI_DMA_FROMDEVICE); So we always use tp->rx_buf_sz rather than pkt_size. Is this interpretation correct?
Note that my sles10sp1 tree already contains backported patches.fixes/r8169-fix-crash-when-large-packets-are-received.patch (bug 511243).
bug be gone
Update released for: acerhk-kmp-debug, acx-kmp-debug, appleir-kmp-debug, at76_usb-kmp-debug, atl2-kmp-debug, aufs-kmp-debug, dazuko-kmp-debug, drbd-kmp-debug, gspcav-kmp-debug, iscsitarget-kmp-debug, ivtv-kmp-debug, kernel-debug, kernel-default, kernel-docs, kernel-kdump, kernel-pae, kernel-ppc64, kernel-ps3, kernel-source, kernel-syms, kernel-vanilla, kernel-xen, kqemu-kmp-debug, nouveau-kmp-debug, omnibook-kmp-debug, pcc-acpi-kmp-debug, pcfclock-kmp-debug, tpctl-kmp-debug, uvcvideo-kmp-debug, virtualbox-ose-kmp-debug, vmware-kmp-debug, wlan-ng-kmp-debug Products: openSUSE 11.0 (debug, i386, ppc, x86_64)