From patchwork Thu Nov 24 17:26:58 2011 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Stefan Bader X-Patchwork-Id: 127582 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from chlorine.canonical.com (chlorine.canonical.com [91.189.94.204]) by ozlabs.org (Postfix) with ESMTP id AA2121007DA for ; Fri, 25 Nov 2011 04:27:13 +1100 (EST) Received: from localhost ([127.0.0.1] helo=chlorine.canonical.com) by chlorine.canonical.com with esmtp (Exim 4.71) (envelope-from ) id 1RTd4g-0002GU-Ma; Thu, 24 Nov 2011 17:27:02 +0000 Received: from youngberry.canonical.com ([91.189.89.112]) by chlorine.canonical.com with esmtp (Exim 4.71) (envelope-from ) id 1RTd4e-0002FF-8X for kernel-team@lists.ubuntu.com; Thu, 24 Nov 2011 17:27:00 +0000 Received: from p5b2e5ba7.dip.t-dialin.net ([91.46.91.167] helo=canonical.com) by youngberry.canonical.com with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1RTd4e-0002XW-0y for kernel-team@lists.ubuntu.com; Thu, 24 Nov 2011 17:27:00 +0000 From: Stefan Bader To: kernel-team@lists.ubuntu.com Subject: [Lucid, Maverick, M/ti-omap4, N/ti-omap4] CVE-2011-4326 Date: Thu, 24 Nov 2011 18:26:58 +0100 Message-Id: <1322155618-11591-1-git-send-email-stefan.bader@canonical.com> X-Mailer: git-send-email 1.7.5.4 X-BeenThere: kernel-team@lists.ubuntu.com X-Mailman-Version: 2.1.13 Precedence: list List-Id: Kernel team discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Sender: kernel-team-bounces@lists.ubuntu.com Errors-To: kernel-team-bounces@lists.ubuntu.com A bug was found in the way headroom check was performed in udp6_ufo_fragment() function. A remote attacker could use this flaw to crash the system. Natty to Precise got the fix pending at least. Anything before 2.6.32 is not affected. For the rest it is a clean cherry-pick all the way to Lucid. Somehow I am not sure anymore which topic branches are rebased and which are not. Hopefully the magic status will tell as soon as the master branches are updated and pushed... -Stefan From a9cf73ea7ff78f52662c8658d93c226effbbedde Mon Sep 17 00:00:00 2001 From: Shan Wei Date: Tue, 19 Apr 2011 22:52:49 +0000 Subject: [PATCH] ipv6: udp: fix the wrong headroom check At this point, skb->data points to skb_transport_header. So, headroom check is wrong. For some case:bridge(UFO is on) + eth device(UFO is off), there is no enough headroom for IPv6 frag head. But headroom check is always false. This will bring about data be moved to there prior to skb->head, when adding IPv6 frag header to skb. Signed-off-by: Shan Wei Acked-by: Herbert Xu Signed-off-by: David S. Miller BugLink: http://bugs.launchpad.net/bugs/894373 CVE-2011-4326 (cherry-picked from commit a9cf73ea7ff78f52662c8658d93c226effbbedde upstream) Signed-off-by: Stefan Bader Acked-by: Andy Whitcroft --- net/ipv6/udp.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/net/ipv6/udp.c b/net/ipv6/udp.c index 15c3774..9e305d74 100644 --- a/net/ipv6/udp.c +++ b/net/ipv6/udp.c @@ -1335,7 +1335,7 @@ static struct sk_buff *udp6_ufo_fragment(struct sk_buff *skb, u32 features) skb->ip_summed = CHECKSUM_NONE; /* Check if there is enough headroom to insert fragment header. */ - if ((skb_headroom(skb) < frag_hdr_sz) && + if ((skb_mac_header(skb) < skb->head + frag_hdr_sz) && pskb_expand_head(skb, frag_hdr_sz, 0, GFP_ATOMIC)) goto out;