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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1582AC433EF for ; Sun, 6 Mar 2022 21:59:10 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232122AbiCFWAB (ORCPT ); Sun, 6 Mar 2022 17:00:01 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55012 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231819AbiCFWAA (ORCPT ); Sun, 6 Mar 2022 17:00:00 -0500 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7C04B1C125 for ; Sun, 6 Mar 2022 13:59:07 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 39C16B80F88 for ; Sun, 6 Mar 2022 21:59:06 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5E328C340EC; Sun, 6 Mar 2022 21:59:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1646603944; bh=Oq194hHEw3gPL5H+0vzA5YKAIUaMaYp5sI6Uw0qXB+Y=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=l+9IbqC36wgzOgN1wew4kafYkxae5b6o/ADtLdfRY+NL+ODOvGBAgUdL4g1gYSd/d 1/4ypwMhZXlHtGlUBbxHPcCGYI88orzloOKZ0YE6cFy2zde6zn22w0H48QqDD2Tx83 yR74/h+gAUpDHCSJ6WyOjhZN039t9FFa8dvE+WcI= Date: Sun, 6 Mar 2022 22:58:59 +0100 From: Greg KH To: Sasha Levin Cc: surenb@google.com, akpm@linux-foundation.org, brauner@kernel.org, caoxiaofeng@yulong.com, ccross@google.com, chris.hyser@oracle.com, dave.hansen@intel.com, dave@stgolabs.net, david@redhat.com, ebiederm@xmission.com, gorcunov@gmail.com, hannes@cmpxchg.org, keescook@chromium.org, kirill.shutemov@linux.intel.com, legion@kernel.org, mhocko@suse.com, pcc@google.com, sumit.semwal@linaro.org, torvalds@linux-foundation.org, vbabka@suse.cz, willy@infradead.org, stable@vger.kernel.org Subject: Re: FAILED: patch "[PATCH] mm: prevent vm_area_struct::anon_name refcount saturation" failed to apply to 5.15-stable tree Message-ID: References: <1646559441105125@kroah.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org On Sun, Mar 06, 2022 at 04:50:42PM -0500, Sasha Levin wrote: > On Sun, Mar 06, 2022 at 10:37:21AM +0100, gregkh@linuxfoundation.org wrote: > > > > The patch below does not apply to the 5.15-stable tree. > > If someone wants it applied there, or to any other stable or longterm > > tree, then please email the backport, including the original git commit > > id to . > > > > thanks, > > > > greg k-h > > > > ------------------ original commit in Linus's tree ------------------ > > > > > From 96403e11283def1d1c465c8279514c9a504d8630 Mon Sep 17 00:00:00 2001 > > From: Suren Baghdasaryan > > Date: Fri, 4 Mar 2022 20:28:55 -0800 > > Subject: [PATCH] mm: prevent vm_area_struct::anon_name refcount saturation > > > > A deep process chain with many vmas could grow really high. With > > default sysctl_max_map_count (64k) and default pid_max (32k) the max > > number of vmas in the system is 2147450880 and the refcounter has > > headroom of 1073774592 before it reaches REFCOUNT_SATURATED > > (3221225472). > > > > Therefore it's unlikely that an anonymous name refcounter will overflow > > with these defaults. Currently the max for pid_max is PID_MAX_LIMIT > > (4194304) and for sysctl_max_map_count it's INT_MAX (2147483647). In > > this configuration anon_vma_name refcount overflow becomes theoretically > > possible (that still require heavy sharing of that anon_vma_name between > > processes). > > > > kref refcounting interface used in anon_vma_name structure will detect a > > counter overflow when it reaches REFCOUNT_SATURATED value but will only > > generate a warning and freeze the ref counter. This would lead to the > > refcounted object never being freed. A determined attacker could leak > > memory like that but it would be rather expensive and inefficient way to > > do so. > > > > To ensure anon_vma_name refcount does not overflow, stop anon_vma_name > > sharing when the refcount reaches REFCOUNT_MAX (2147483647), which still > > leaves INT_MAX/2 (1073741823) values before the counter reaches > > REFCOUNT_SATURATED. This should provide enough headroom for raising the > > refcounts temporarily. > > I think that this patch depends on 78db3412833d ("mm: add anonymous vma > name refcounting") which we don't have in any of the stable trees. (is > this why it wasn't tagged for stable?). Suren said he would provide a backport on Monday, so let's see what he comes up with :) thanks, greg k-h