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.4 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no 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 38987C43461 for ; Mon, 14 Sep 2020 11:21:41 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id CE56521D7E for ; Mon, 14 Sep 2020 11:21:40 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=chrisdown.name header.i=@chrisdown.name header.b="NrVooSir" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726024AbgINLVf (ORCPT ); Mon, 14 Sep 2020 07:21:35 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36660 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725980AbgINLUm (ORCPT ); Mon, 14 Sep 2020 07:20:42 -0400 Received: from mail-wr1-x443.google.com (mail-wr1-x443.google.com [IPv6:2a00:1450:4864:20::443]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 85798C061788 for ; Mon, 14 Sep 2020 04:20:41 -0700 (PDT) Received: by mail-wr1-x443.google.com with SMTP id t10so18306575wrv.1 for ; Mon, 14 Sep 2020 04:20:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chrisdown.name; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=kLfSmpZKw0IcWAbxwnk8PLqM8595LR3Odif7KTgUXZk=; b=NrVooSirCkC89uwDGsSlSp0zG/q+C1jxdMRgf5vGubOWhuYbiNfYYdydkZ3JndP3vc 6j1Zt4R+v3/omPJt4fTsTB0b5IQG7u4qoZ9UkGKoveS0XQF9k1VBJIsF5vwqHnYw5nbh MlxJi+tdMfm8TSZbWKWyyv0HVCHtRKJeEg0u8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=kLfSmpZKw0IcWAbxwnk8PLqM8595LR3Odif7KTgUXZk=; b=nHfvs+FQchrjbnBu6a7uuDOc2EtZIyM07p0/EAovWleCZxreLv8nm6zodBRm/KEoP/ UL8z/DKsVwREjcjZw0eocUoI2Pl0wBlyNzUcsiijSHRP6O4G/OQho8XdqyXwKjFS117G rNQv5YAiynbhC+bCDDA3YrZ7o0wBnQTc9mYsapL7ssrH0gvrRN0q1fL08EpducXrMHrn ut0ukhEz97BBXf0Dbyf1wCV4vkHidPi2flTJ7EH8WS/8vh+0/V+7Ii6IwnASITYQROvl TBjIyHH26y/Dby7O+zd0+vzv71PGrRU0uXIyAxp0jMjiPNLyq2R6BUGT38XzINCY0gEx JWXg== X-Gm-Message-State: AOAM5319pOIPoM6ZRdvWuHjqUML+AydKpkgy5PbhDsQtnOJH32NaH4jm nP0kShJ/a+ewi4Tkh0c/snG1rg== X-Google-Smtp-Source: ABdhPJwBJtsZXWlo/8DZ9/96K7Ym7PgHSobyj/KV5SR5J+lZjhcTVzvshIGxo/oQce5aFlYqWEXtuA== X-Received: by 2002:a5d:674c:: with SMTP id l12mr15342266wrw.325.1600082438340; Mon, 14 Sep 2020 04:20:38 -0700 (PDT) Received: from localhost ([2a01:4b00:8432:8a00:63de:dd93:20be:f460]) by smtp.gmail.com with ESMTPSA id m185sm19699575wmf.5.2020.09.14.04.20.37 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 14 Sep 2020 04:20:37 -0700 (PDT) Date: Mon, 14 Sep 2020 12:20:37 +0100 From: Chris Down To: Michal Hocko Cc: Muchun Song , Andrew Morton , Johannes Weiner , Vladimir Davydov , Cgroups , Linux Memory Management List , LKML Subject: Re: [External] Re: [PATCH] mm: memcontrol: Fix out-of-bounds on the buf returned by memory_stat_format Message-ID: <20200914112037.GA2417148@chrisdown.name> References: <20200912155100.25578-1-songmuchun@bytedance.com> <20200912174241.eeaa771755915f27babf9322@linux-foundation.org> <20200914091844.GE16999@dhcp22.suse.cz> <20200914103205.GI16999@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <20200914103205.GI16999@dhcp22.suse.cz> User-Agent: Mutt/1.14.6 (2020-07-11) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Michal Hocko writes: >> > > Yeah, I think we should cc:stable. >> > >> > Is this a real problem? The buffer should contain 36 lines which makes >> > it more than 100B per line. I strongly suspect we are not able to use >> > that storage up. >> >> Before memory_stat_format() return, we should call seq_buf_putc(&s, '\0'). >> Otherwise, the return buf string has no trailing null('\0'). But users treat buf >> as a string(and read the string oob). It is wrong. Thanks. > >I am not sure I follow you. vsnprintf which is used by seq_printf will >add \0 if there is a room for that. And I argue there is a lot of room >in the buffer so a corner case where the buffer gets full doesn't happen >with the current code. I don't feel very strongly either way, but in general I agree with Michal. As it is this feels quite perfunctory. If you can demonstrate reading the string out of bounds in a userspace-exploitable way -- that is, you can demonstrate one can coerce memory.stat to a format where you would read out of bounds -- then we should obviously cc stable and keep the Fixes tag, but you have not come close to demonstrating this yet. Otherwise, if you cannot provide any way to read the string out of bounds, because the buffer is simply way too big for this to ever happen, this is just a code cleanup, and neither Fixes nor stable are appropriate. So, the question is, which is it? :-)