From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-9.1 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_PASS,URIBL_BLOCKED,USER_AGENT_GIT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 94B14C07E85 for ; Tue, 11 Dec 2018 16:17:42 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 5945120851 for ; Tue, 11 Dec 2018 16:17:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1544545062; bh=6LtsVLtWMEeIyOG/cJ/YmeGf4eXJNMiNKfRxpDX2Sqw=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=V7J7ejMNRBXuHZPUPY4uEQlTqBW2aJOBpon8mmLRO2FIX1O5cKBXjweRKKwMLo4P/ Lq97rhUH8hRsZr0ZYXS8Nb4E8DOwWG0Nv+Cn4hf95PKWxVVlb2WhVusNwkxgfg0php aRkVIi7GrIvOIgRTdr4CA/wk4U2eW95zQLnjLWJw= DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 5945120851 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linuxfoundation.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729012AbeLKQRl (ORCPT ); Tue, 11 Dec 2018 11:17:41 -0500 Received: from mail.kernel.org ([198.145.29.99]:35450 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728452AbeLKPrD (ORCPT ); Tue, 11 Dec 2018 10:47:03 -0500 Received: from localhost (5356596B.cm-6-7b.dynamic.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id A9D9121104; Tue, 11 Dec 2018 15:47:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1544543222; bh=6LtsVLtWMEeIyOG/cJ/YmeGf4eXJNMiNKfRxpDX2Sqw=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=v6F1KUz8DF3Jw2Kdn0DW/XdKZPGjFr7/2P5bSH7sijSOXbYH1i5NvUOoo81mqc6be OoqrvlGCnYh7lW22FhZ4H0rgLIF+RtUYYyJoInJmJMI1PF2Tswk9EPenb6sxRgzPHY cqOckI7wtLJGcqnj9mwI1xPbv5lvy/ctTgvIFBfA= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Martin Weinelt , Sven Eckelmann , Simon Wunderlich , Sasha Levin , =?UTF-8?q?Linus=20L=C3=BCssing?= Subject: [PATCH 4.4 60/91] batman-adv: Expand merged fragment buffer for full packet Date: Tue, 11 Dec 2018 16:41:19 +0100 Message-Id: <20181211151610.948845988@linuxfoundation.org> X-Mailer: git-send-email 2.20.0 In-Reply-To: <20181211151606.026852373@linuxfoundation.org> References: <20181211151606.026852373@linuxfoundation.org> User-Agent: quilt/0.65 X-stable: review X-Patchwork-Hint: ignore MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 4.4-stable review patch. If anyone has any objections, please let me know. ------------------ [ Upstream commit d7d8bbb40a5b1f682ee6589e212934f4c6b8ad60 ] The complete size ("total_size") of the fragmented packet is stored in the fragment header and in the size of the fragment chain. When the fragments are ready for merge, the skbuff's tail of the first fragment is expanded to have enough room after the data pointer for at least total_size. This means that it gets expanded by total_size - first_skb->len. But this is ignoring the fact that after expanding the buffer, the fragment header is pulled by from this buffer. Assuming that the tailroom of the buffer was already 0, the buffer after the data pointer of the skbuff is now only total_size - len(fragment_header) large. When the merge function is then processing the remaining fragments, the code to copy the data over to the merged skbuff will cause an skb_over_panic when it tries to actually put enough data to fill the total_size bytes of the packet. The size of the skb_pull must therefore also be taken into account when the buffer's tailroom is expanded. Fixes: 610bfc6bc99b ("batman-adv: Receive fragmented packets and merge") Reported-by: Martin Weinelt Co-authored-by: Linus Lüssing Signed-off-by: Sven Eckelmann Signed-off-by: Simon Wunderlich Signed-off-by: Sasha Levin --- net/batman-adv/fragmentation.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/batman-adv/fragmentation.c b/net/batman-adv/fragmentation.c index 5d2f9d4879b2..d50c3b003dc9 100644 --- a/net/batman-adv/fragmentation.c +++ b/net/batman-adv/fragmentation.c @@ -266,7 +266,7 @@ batadv_frag_merge_packets(struct hlist_head *chain) kfree(entry); packet = (struct batadv_frag_packet *)skb_out->data; - size = ntohs(packet->total_size); + size = ntohs(packet->total_size) + hdr_size; /* Make room for the rest of the fragments. */ if (pskb_expand_head(skb_out, 0, size - skb_out->len, GFP_ATOMIC) < 0) { -- 2.19.1