From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 1CAF81AB6EA for ; Thu, 2 Jan 2025 23:34:00 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1735860841; cv=none; b=GIgtIpEMfjBRb8/8wnEbCyEHzo6X7ZhKlsfwqm+l8ayeCkTxqG7tgeuKKnzUdrz8jfYm/Lo+cMZKm5JdPz3+ir89tztVPdzFKnCniZupAbUTVAuEarYXjOEAHfEPXAktOqeHH6j/fy2dLoExs2tIZ+F8Ob602nuyFhLKxwhcglE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1735860841; c=relaxed/simple; bh=sgaP7mRu/fXjdn7/QptTgL7s7P2ug28/SGc7CEJJwaQ=; h=Date:From:To:Cc:Subject:Message-Id:In-Reply-To:References: Mime-Version:Content-Type; b=RGe5VaPs7xmHNvOaMZMpzm4qMzYE+5qFcy4NFL6E+SSI84oTUTL0orHLKFHFEzorKO/vsJMbPQjvrsbUzwzhgdsKCRzxdLo5XZ/2EguTXO1qy3tlW2OyzmHar90ssiuKMbMvrP4NYSuqCQf0PwPTZUvmrJSRPC9/pkAxEtrqk1I= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b=m8KjPT25; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b="m8KjPT25" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 497C8C4CED0; Thu, 2 Jan 2025 23:34:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1735860840; bh=sgaP7mRu/fXjdn7/QptTgL7s7P2ug28/SGc7CEJJwaQ=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=m8KjPT25m/9nbXCpTmqEPl27+yidEvA6wHy2r06tl9nxrTcRR9pZVhRnVDUg2cweV mTVMJwGBe2DbRqbDGZXAoNunXLMTFeRl+o0np1MxVt6oFxAcWVyKYhP40/O5QaOxDj 8rvEIh+gY5svAFMHZn3Sp9XMWiSbHHr1AyYxlxn4= Date: Thu, 2 Jan 2025 15:33:59 -0800 From: Andrew Morton To: "Huang, Ying" Cc: kingdix10@qq.com, andriy.shevchenko@linux.intel.com, ilpo.jarvinen@linux.intel.com, bhelgaas@google.com, mika.westerberg@linux.intel.com, huang.ying.caritas@gmail.com, jhubbard@nvidia.com, peterz@infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] resource: use kstrdup_const to prevent wild pointer issues Message-Id: <20250102153359.0bb10b8bb0d4293a935c4a3a@linux-foundation.org> In-Reply-To: <87seq2dlhd.fsf@DESKTOP-5N7EMDA> References: <87seq2dlhd.fsf@DESKTOP-5N7EMDA> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; x86_64-pc-linux-gnu) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Thu, 02 Jan 2025 09:59:26 +0800 "Huang, Ying" wrote: > > From: King Dix > > > > When a stack string variable is passed during the request resource > > operation, it causes an oops problem when executing cat /proc/iomem. > > > > In the original code, in functions like __request_region_locked, the name > > member of the resource structure was directly assigned the stack string > > pointer without proper memory management. > > > > This fix changes the assignment of res->name to use kstrdup_const for > > string copying, ensuring the correct storage and release of the string > > and thus avoiding potential memory errors and oops issues. > > > > Signed-off-by: King Dix > > In general, I think that it's good to improve the resource requesting > API. However, it's not good to use so many GFP_ATOMIC too. Why do you > need to call resource requesting API with stack variable? If it's just > some programming bugs, we should add more checks instead of hiding the > bugs. For example, if we only allows kernel rodata and slab memory to be > used in resource requesting. We can add a VM_WARN_ON() to check that. I agree. It may not be a very good idea, but request_region() requires that the caller pass in a `name' string which is permanently available. __request_region() kerneldoc doesn't document this, and it should. Because of this present interface design, calling request_region() with an on-stack string must be considered a bug in the calling code.