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=-5.5 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE, SPF_PASS,T_DKIMWL_WL_HIGH,URIBL_BLOCKED,USER_AGENT_MUTT autolearn=unavailable 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 3583AC28CC2 for ; Wed, 29 May 2019 10:37:35 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 0F6C620B7C for ; Wed, 29 May 2019 10:37:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1559126255; bh=SxU7w6Gjg8QT0ZippUNKx1AOfJOqaCKBDZniPh5LqSs=; h=Date:From:To:Cc:Subject:References:In-Reply-To:List-ID:From; b=p+tqSb8IYQWJ42HCHCKRT6aF/RSKTUxEbOdY6RDxqbMp1l5kyJz7C6blqPVsqPJYQ 581R8lkKsWtO8gXteBrOyk5VhZuogfXCKpg+6wygH9y3fK/+WEPd3hCxLif0HaeAwP LCo5cUVWAcoRXrHe+jWprsdVacQ19L0ZaI61vrvs= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726674AbfE2Khe (ORCPT ); Wed, 29 May 2019 06:37:34 -0400 Received: from mail.kernel.org ([198.145.29.99]:43166 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725990AbfE2Khc (ORCPT ); Wed, 29 May 2019 06:37:32 -0400 Received: from localhost (ip67-88-213-2.z213-88-67.customer.algx.net [67.88.213.2]) (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 A2E4720B1F; Wed, 29 May 2019 10:37:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1559126251; bh=SxU7w6Gjg8QT0ZippUNKx1AOfJOqaCKBDZniPh5LqSs=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=X1tF7/xEJxp+DEjeBZ5UhSnuwKkSs9o3uXZQH+65q0K3WUtTevT1EF7YefAVLfCnu yzGvfQnyUvhDGeffyB0bypSWSfh7zNmqY5BGM3vtQYV0fDRBeQCc/gi/FGvGUnC8cq xQ/sOh3NdsXQeBJ0p2ljLh31pK2HmbOXPi+KIPTA= Date: Wed, 29 May 2019 03:37:31 -0700 From: Greg KH To: Stefan Bader Cc: stable , netdev@vger.kernel.org, linux-kernel@vger.kernel.org, Eric Dumazet , Sasha Levin , Peter Oskolkov , Ben Hutchings , Andy Whitcroft Subject: Re: [PATCH 1/4] ipv4: ipv6: netfilter: Adjust the frag mem limit when truesize changes Message-ID: <20190529103731.GB7383@kroah.com> References: <20190529102542.17742-1-stefan.bader@canonical.com> <20190529102542.17742-2-stefan.bader@canonical.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190529102542.17742-2-stefan.bader@canonical.com> User-Agent: Mutt/1.12.0 (2019-05-25) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, May 29, 2019 at 12:25:39PM +0200, Stefan Bader wrote: > From: Jiri Wiesner > > The *_frag_reasm() functions are susceptible to miscalculating the byte > count of packet fragments in case the truesize of a head buffer changes. > The truesize member may be changed by the call to skb_unclone(), leaving > the fragment memory limit counter unbalanced even if all fragments are > processed. This miscalculation goes unnoticed as long as the network > namespace which holds the counter is not destroyed. > > Should an attempt be made to destroy a network namespace that holds an > unbalanced fragment memory limit counter the cleanup of the namespace > never finishes. The thread handling the cleanup gets stuck in > inet_frags_exit_net() waiting for the percpu counter to reach zero. The > thread is usually in running state with a stacktrace similar to: > > PID: 1073 TASK: ffff880626711440 CPU: 1 COMMAND: "kworker/u48:4" > #5 [ffff880621563d48] _raw_spin_lock at ffffffff815f5480 > #6 [ffff880621563d48] inet_evict_bucket at ffffffff8158020b > #7 [ffff880621563d80] inet_frags_exit_net at ffffffff8158051c > #8 [ffff880621563db0] ops_exit_list at ffffffff814f5856 > #9 [ffff880621563dd8] cleanup_net at ffffffff814f67c0 > #10 [ffff880621563e38] process_one_work at ffffffff81096f14 > > It is not possible to create new network namespaces, and processes > that call unshare() end up being stuck in uninterruptible sleep state > waiting to acquire the net_mutex. > > The bug was observed in the IPv6 netfilter code by Per Sundstrom. > I thank him for his analysis of the problem. The parts of this patch > that apply to IPv4 and IPv6 fragment reassembly are preemptive measures. > > Signed-off-by: Jiri Wiesner > Reported-by: Per Sundstrom > Acked-by: Peter Oskolkov > Signed-off-by: David S. Miller > > (backported from commit ebaf39e6032faf77218220707fc3fa22487784e0) > [smb: context adjustments in net/ipv6/netfilter/nf_conntrack_reasm.c] > Signed-off-by: Stefan Bader I can't take a patch for 4.4.y that is not in 4.9.y as anyone upgrading kernel versions would have a regression :( Can you also provide a backport of the needed patches for 4.9.y for this issue so I can take these? thanks, greg k-h