From nobody Thu Sep 18 11:14:15 2025 Delivered-To: wpasupplicant.patchew@gmail.com Received: by 2002:a05:6638:38c:0:0:0:0 with SMTP id y12csp1818925jap; Thu, 6 Jan 2022 14:06:50 -0800 (PST) X-Google-Smtp-Source: ABdhPJwuwz13PWPyMgS97nQwF+brSQaqIa/dRnhqUal9IhDs+W7MxSrKTMNIeW6kmVYa66fG1Gj2 X-Received: by 2002:a05:6e02:1908:: with SMTP id w8mr26836893ilu.148.1641506810847; Thu, 06 Jan 2022 14:06:50 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1641506810; cv=none; d=google.com; s=arc-20160816; b=EnA9a32151LNLKUUtTWBMN5Hkw6dvhU0VpA3r8y7CF9WS6o04EBUPU7jO00kzjZrn/ SzQy4xlHWznQBsI1/KPnLXV0OkZK5Zes5pGcRSpw2NCMuUFEEp2w/itqxHnPPbE71+Lx 2K1/GzEHbz9HI+CbFe2z8beoC2pt4h/cicNGUspg6Q/nER7RN5y7oOCBLZFBcVawGZbH ZQefi1QBAISStABDjGfSezJZLqJxso5gK5SKMN9uL7MB9HOo/ZAXHQx3d9ZCnBhdKSiO 7SVgH/CkcoQoNtS4FQP4RoXGXFerOhse/kCzBxrAzpOuxsfGtYyZBDvQVJv0Kg1xaYWU J6XQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:references:in-reply-to:message-id :date:subject:cc:to:from:dkim-signature; bh=P/uuvgyeo/PB67PmbALKeEB2FKyBW6+kgtIHVRtf7ak=; b=qlwWRwr58tZ8Fm8vq86j5Gj6EWR79ULTdMKK3OABcuQQIESRsmlVdg/xNxei+DIgFb zo+BxQMGMavWoDqq/SSz7vTFs0PUVv+GMNxx/AomvV7ECQitiz/hn4spsD63bWxYjywW RrZwyUG6ZqOuwKTnUqPWqbzTl1vs43im5N2ik8s5Pjqoy2MGSUg7MjO/WEoX4NBfVFA6 IexdSTtH9uWDc6UhN12M6iJ06s4JcfG824XhfHFJkKe1c6syqtx4pqHE/F9TRzBtCy5+ YNsdNKbSsE11Yx3ElbZJ1hmGyP41mAsJedjTIoVMZ8pqPPRY+g08EINugQ52p3BOWMCP vuLg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=cHkP1b0v; spf=pass (google.com: domain of mptcp+bounces-2943-wpasupplicant.patchew=gmail.com@lists.linux.dev designates 147.75.197.195 as permitted sender) smtp.mailfrom="mptcp+bounces-2943-wpasupplicant.patchew=gmail.com@lists.linux.dev"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from ewr.edge.kernel.org (ewr.edge.kernel.org. [147.75.197.195]) by mx.google.com with ESMTPS id k41si1472222jav.117.2022.01.06.14.06.50 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 06 Jan 2022 14:06:50 -0800 (PST) Received-SPF: pass (google.com: domain of mptcp+bounces-2943-wpasupplicant.patchew=gmail.com@lists.linux.dev designates 147.75.197.195 as permitted sender) client-ip=147.75.197.195; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=cHkP1b0v; spf=pass (google.com: domain of mptcp+bounces-2943-wpasupplicant.patchew=gmail.com@lists.linux.dev designates 147.75.197.195 as permitted sender) smtp.mailfrom="mptcp+bounces-2943-wpasupplicant.patchew=gmail.com@lists.linux.dev"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ewr.edge.kernel.org (Postfix) with ESMTPS id 4D18A1C0E9E for ; Thu, 6 Jan 2022 22:06:50 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 723392CA6; Thu, 6 Jan 2022 22:06:49 +0000 (UTC) X-Original-To: mptcp@lists.linux.dev Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 197E72C80 for ; Thu, 6 Jan 2022 22:06:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1641506808; x=1673042808; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=gWSnuUd95xzqkKUJMcBHVpFvEnDrTIzs+mXz8xua7TA=; b=cHkP1b0vqefR+3/Zt5dcvqaotwP7eMLyF3fh9vEL0aySwQk04Y9IxbSQ NgtY1n9wn+MZg28pDRMJuNl4vtwjnPTMXFMrA7UwYWH/HcEUiQkerAaCJ wdI1q2xmFzfyOjAd33PVNBCNYh/LY4CsXxhkGVCfAZ7ZxbX3KY88fSoaa R4iGhci+ogNcvKEOpODDM0jAIPnEVyukp7ofM8d9qGBpopicCCDqCcrqj 1hydecrQak+F/n0n+6zbJEg8Wi6hVxcM6iHdySVn8UpIgTlLs4agEFrKa lwEvcN/Ng/DZXuudJ41ob5ngJO468tlnbYiGTwGJ9yI2mujPmD0lTiybz w==; X-IronPort-AV: E=McAfee;i="6200,9189,10217"; a="240303712" X-IronPort-AV: E=Sophos;i="5.88,267,1635231600"; d="scan'208";a="240303712" Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 Jan 2022 14:06:44 -0800 X-IronPort-AV: E=Sophos;i="5.88,267,1635231600"; d="scan'208";a="618479822" Received: from mjmartin-desk2.amr.corp.intel.com (HELO mjmartin-desk2.intel.com) ([10.209.94.200]) by fmsmga002-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 Jan 2022 14:06:44 -0800 From: Mat Martineau To: netdev@vger.kernel.org Cc: Mat Martineau , davem@davemloft.net, kuba@kernel.org, matthieu.baerts@tessares.net, mptcp@lists.linux.dev, pabeni@redhat.com, geliang.tang@suse.com, syzbot+bc9e2d2dbcb347dd215a@syzkaller.appspotmail.com, Andrew Morton , Michal Hocko Subject: [PATCH net 3/3] mptcp: Check reclaim amount before reducing allocation Date: Thu, 6 Jan 2022 14:06:38 -0800 Message-Id: <20220106220638.305287-4-mathew.j.martineau@linux.intel.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20220106220638.305287-1-mathew.j.martineau@linux.intel.com> References: <20220106220638.305287-1-mathew.j.martineau@linux.intel.com> Precedence: bulk X-Mailing-List: mptcp@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" syzbot found a page counter underflow that was triggered by MPTCP's reclaim code: page_counter underflow: -4294964789 nr_pages=3D4294967295 WARNING: CPU: 2 PID: 3785 at mm/page_counter.c:56 page_counter_cancel+0xcf/= 0xe0 mm/page_counter.c:56 Modules linked in: CPU: 2 PID: 3785 Comm: kworker/2:6 Not tainted 5.16.0-rc1-syzkaller #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.14.0-2 04/01/2014 Workqueue: events mptcp_worker RIP: 0010:page_counter_cancel+0xcf/0xe0 mm/page_counter.c:56 Code: c7 04 24 00 00 00 00 45 31 f6 eb 97 e8 2a 2b b5 ff 4c 89 ea 48 89 ee = 48 c7 c7 00 9e b8 89 c6 05 a0 c1 ba 0b 01 e8 95 e4 4b 07 <0f> 0b eb a8 4c 8= 9 e7 e8 25 5a fb ff eb c7 0f 1f 00 41 56 41 55 49 RSP: 0018:ffffc90002d4f918 EFLAGS: 00010082 RAX: 0000000000000000 RBX: ffff88806a494120 RCX: 0000000000000000 RDX: ffff8880688c41c0 RSI: ffffffff815e8f28 RDI: fffff520005a9f15 RBP: ffffffff000009cb R08: 0000000000000000 R09: 0000000000000000 R10: ffffffff815e2cfe R11: 0000000000000000 R12: ffff88806a494120 R13: 00000000ffffffff R14: 0000000000000000 R15: 0000000000000001 FS: 0000000000000000(0000) GS:ffff88802cc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000001b2de21000 CR3: 000000005ad59000 CR4: 0000000000150ee0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: page_counter_uncharge+0x2e/0x60 mm/page_counter.c:160 drain_stock+0xc1/0x180 mm/memcontrol.c:2219 refill_stock+0x139/0x2f0 mm/memcontrol.c:2271 __sk_mem_reduce_allocated+0x24d/0x550 net/core/sock.c:2945 __mptcp_rmem_reclaim net/mptcp/protocol.c:167 [inline] __mptcp_mem_reclaim_partial+0x124/0x410 net/mptcp/protocol.c:975 mptcp_mem_reclaim_partial net/mptcp/protocol.c:982 [inline] mptcp_alloc_tx_skb net/mptcp/protocol.c:1212 [inline] mptcp_sendmsg_frag+0x18c6/0x2190 net/mptcp/protocol.c:1279 __mptcp_push_pending+0x232/0x720 net/mptcp/protocol.c:1545 mptcp_release_cb+0xfe/0x200 net/mptcp/protocol.c:2975 release_sock+0xb4/0x1b0 net/core/sock.c:3306 mptcp_worker+0x51e/0xc10 net/mptcp/protocol.c:2443 process_one_work+0x9b2/0x1690 kernel/workqueue.c:2298 worker_thread+0x658/0x11f0 kernel/workqueue.c:2445 kthread+0x405/0x4f0 kernel/kthread.c:327 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:295 __mptcp_mem_reclaim_partial() could call __mptcp_rmem_reclaim() with a negative value, which passed that negative value to __sk_mem_reduce_allocated() and triggered the splat above. Check for a reclaim amount that is positive and large enough for __mptcp_rmem_reclaim() to actually adjust rmem_fwd_alloc (much like the sk_mem_reclaim_partial() code the function is based on). v2: Use '>' instead of '>=3D', since SK_MEM_QUANTUM - 1 would get right-shifted into nothing by __mptcp_rmem_reclaim. Fixes: 6511882cdd82 ("mptcp: allocate fwd memory separately on the rx and t= x path") Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/252 Reported-and-tested-by: syzbot+bc9e2d2dbcb347dd215a@syzkaller.appspotmail.c= om Cc: Andrew Morton Cc: Michal Hocko Acked-by: Paolo Abeni Signed-off-by: Mat Martineau --- net/mptcp/protocol.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/net/mptcp/protocol.c b/net/mptcp/protocol.c index 54613f5b7521..0cd55e4c30fa 100644 --- a/net/mptcp/protocol.c +++ b/net/mptcp/protocol.c @@ -972,7 +972,9 @@ static void __mptcp_mem_reclaim_partial(struct sock *sk) =20 lockdep_assert_held_once(&sk->sk_lock.slock); =20 - __mptcp_rmem_reclaim(sk, reclaimable - 1); + if (reclaimable > SK_MEM_QUANTUM) + __mptcp_rmem_reclaim(sk, reclaimable - 1); + sk_mem_reclaim_partial(sk); } =20 --=20 2.34.1