From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f41.google.com (mail-wm1-f41.google.com [209.85.128.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id BEFD5221FBD for ; Tue, 26 May 2026 00:51:33 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.41 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779756695; cv=none; b=Af5h6N831C4BbuFARH7uywO2Y/uRP+QmRY7MeIbC01HUyv9qt3Qr4nf/aUxrK2fmoMSdMLPZC6dAosdoCxSMIPGHg76wKdypAZ4qw7MvYUkhdTNoN4/dsg9k2dZ95YrFfZQ+Ut3PT+Q6FofA8ApAkpKTOfrKMv6KfAD10Wi5JGM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779756695; c=relaxed/simple; bh=YHxUoWZ3KTF2di8VYjrcHbb0me7uToNfc0hyJGb1qZs=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=ou1xe+/xPGVbI9GS3E1iO+vrALXgyrEBAkFpAlN43qm6KzYvZ+dIATy5YTfNWySvkLJGU/Z+NURuBmiD2pyp0UPhvKSxV3npw41MTMcVRE6iKY2TCofNEMyASWcPo7Zyb0qsPdwR2YJWkP+IYCURUIBACfwiupvhHkohN98FEj4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com; spf=pass smtp.mailfrom=suse.com; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b=Loz8r3hh; arc=none smtp.client-ip=209.85.128.41 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=suse.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b="Loz8r3hh" Received: by mail-wm1-f41.google.com with SMTP id 5b1f17b1804b1-49041fb8c23so28602025e9.0 for ; Mon, 25 May 2026 17:51:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1779756692; x=1780361492; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=h3bICaotEcFBSHr6aI2IzMVwvas+ixkBgDm+KS5EZIw=; b=Loz8r3hhIK0I9KUTA2kq4c+EdTdlohWvHA0PL1WkXAh9xKinbP0YIKxOBl1nUjfaDR dpTmFnXg7LDIeCc8IR+2vUUT2PcuatClXwrJ+SLj/GvkWjXKrJ0iFbgZIytqgdx2I3TP LwoWI5Y3h85K1vD8zmTKJ0XQOk1zAgl+mvsGcxvg3Q2/e3P02oYxhubRb3N01uKP9iQW Z/cY3XwlOvLfm58edzen5Rfs7eVwP3qW10HcwmXG2U8lqKvc3P/ZayxiqRXfi5Stya9W ajx4AujiDF/w5cWzpB/+U4jmV7eFm6XzYWppG+NlordiiScbGRqvQKvYnqVqHIWIyQt4 lwmQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779756692; x=1780361492; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=h3bICaotEcFBSHr6aI2IzMVwvas+ixkBgDm+KS5EZIw=; b=NYPWvsdALBGkXkYHJ77koKwi6D5cmlVfBkb1mXB3ovef2JsNi33+jNzFbpzp+LJUz1 LbwQUvFXgrJmQs7fTYS3OaWdyswU7RCVuBlc+AzH/k/hsnuqoVfAKsfS9MMIBCTNedm3 XmrKJAi66yk4uc4B7NjY9RqtDyNH2pmWlbzpoqBhhxLMknDWqB2z5eOPJ3Y8AQKvsFIo JQitSqDDZeYvB3bYonbftIn75cZZZ/5AJthqLsqdlVXcnDFneU3g4WY1t6QLxiVoXiMp eWPfFEKaJZivl5SQHaWPka/wa9bFQ9rWlDaIs97bkkp6kKxKyyx80HC5dkQwjRUbQKY4 8bag== X-Forwarded-Encrypted: i=1; AFNElJ/yRkvI8nu+81hVfqaNx8OumbjaoF1WeiLiHZg3sqz3rhPhn9RNFTv2g6u6GMP7UoAABx/gFD5FMDl2JcU=@vger.kernel.org X-Gm-Message-State: AOJu0YxrGWB4hCulbYFTzGIxrI9205QRJ+kSVprcmlaOR3wbDVYCueL7 5H+ry2JxTkhbVTGO8vkfI0R6FAH0gkaYPvcAwpyjvgOAeh251ekSMZ+QYVbnDyACUcQ= X-Gm-Gg: Acq92OEJ2AQIvAsIXht493LysdJaHkbtd4MqNYU3O2FLjDlnlRlwRx3u39kuNfb9AU6 QdhcdvGbuLxzSYpwNhqOh/1hji/atoSZNQIQHe5EwRsh8T2PduvkHYpvgjxHp+D6Q7pOzSEfjf0 mT/CGl365pYwrRanNsyF02RRfp1gIq3CCgOwUWUyRbSxjkbupIgXflTrcpqTcdJlr4D5+EYWvvD Q5kiT9qgH2J25C7kiOGWGK2pKmAhLaes7ak2sNaGkZzxhr2aLy24UqwqSxoYaFb6D/2mMHH4uOR /tHLdpTyKVOZCd3LpMmu7AnufYh489fPOjlweozfiKkqgD3rD5V0EL5oP9C3SB7C7NlLXMkgOHE RJad0Q7JS7gVWzrbNdCI5E1cbnCFNNmr6LAMC7+tJGl4p2XJUmllL3xlBVX8vlpmNMvzl27GE3y KyK3agw0MWJjNFOXGhT1KOeEVh4PSDl9yM+2H3MkLcDvZQ1L9cpWTzcdHqNlGxO1Ym/b4Mwiace WzgrRjO/00U4w7aXXyhaw== X-Received: by 2002:a05:600c:4743:b0:490:53d3:4767 with SMTP id 5b1f17b1804b1-49053d34a6dmr185533335e9.7.1779756691883; Mon, 25 May 2026 17:51:31 -0700 (PDT) Received: from [10.202.80.174] ([202.127.77.110]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-84164b1b3d2sm11824920b3a.26.2026.05.25.17.51.27 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 25 May 2026 17:51:30 -0700 (PDT) Message-ID: <983654c3-98a5-46bc-8e8c-e0e780c7dc61@suse.com> Date: Tue, 26 May 2026 08:51:25 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: MIPS: mm: Fix out-of-bounds write in maar_res_walk() To: "Liam R. Howlett" Cc: tsbogend@alpha.franken.de, akpm@linux-foundation.org, rppt@kernel.org, catalin.marinas@arm.com, jiaxun.yang@flygoat.com, paulburton@kernel.org, linux-mips@vger.kernel.org, linux-kernel@vger.kernel.org References: Content-Language: en-US From: Yadan Fan In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Hi Liam, On 5/25/26 22:15, Liam R. Howlett wrote: > On 26/05/25 07:06PM, Yadan Fan wrote: >> maar_res_walk() uses wi->num_cfg as the index into the fixed-size >> wi->cfg array, but checks whether the array is full only after it has >> filled the selected entry. If walk_system_ram_range() reports more than >> 16 memory ranges, the overflow call writes one struct maar_config past >> the end of the array before WARN_ON() prevents num_cfg from advancing. >> >> Move the full-array check before taking the array slot. Keep the >> existing behavior of warning and returning 0 when the scratch array has >> no room left. >> >> Fixes: a5718fe8f70f ("MIPS: mm: Drop boot_mem_map") >> Signed-off-by: Yadan Fan >> --- >> arch/mips/mm/init.c | 12 ++++++++---- >> 1 file changed, 8 insertions(+), 4 deletions(-) >> >> diff --git a/arch/mips/mm/init.c b/arch/mips/mm/init.c >> index 55b25e85122a..0ba958b7ffa5 100644 >> --- a/arch/mips/mm/init.c >> +++ b/arch/mips/mm/init.c >> @@ -272,9 +272,15 @@ static int maar_res_walk(unsigned long start_pfn, unsigned long nr_pages, >> void *data) >> { >> struct maar_walk_info *wi = data; >> - struct maar_config *cfg = &wi->cfg[wi->num_cfg]; >> + struct maar_config *cfg; >> unsigned int maar_align; >> >> + /* Ensure we don't overflow the cfg array */ >> + if (WARN_ON(wi->num_cfg >= ARRAY_SIZE(wi->cfg))) >> + return 0; > > We should probably change this to WARN_ON_ONCE() if we're moving it? Yes, it should be WARN_ON_ONCE() to avoid repeated warnings later once wi->num_cfg reached ARRAY_SIZE(wi->cfg), I will change it in patch V2. > >> + >> + cfg = &wi->cfg[wi->num_cfg]; >> + >> /* MAAR registers hold physical addresses right shifted by 4 bits */ >> maar_align = BIT(MIPS_MAAR_ADDR_SHIFT + 4); >> >> @@ -283,9 +289,7 @@ static int maar_res_walk(unsigned long start_pfn, unsigned long nr_pages, >> cfg->upper = ALIGN_DOWN(PFN_PHYS(start_pfn + nr_pages), maar_align) - 1; >> cfg->attrs = MIPS_MAAR_S; >> >> - /* Ensure we don't overflow the cfg array */ >> - if (!WARN_ON(wi->num_cfg >= ARRAY_SIZE(wi->cfg))) >> - wi->num_cfg++; >> + wi->num_cfg++; > > AFAICT, this is the only place num_cfg is incremented. Since we are > trying to avoid overflow, I think the initial logic is flawed in that we > do trigger too late - we can write one beyond the array index max (to > the array size). > > But what you have done changes the functionality in a subtle way - we > won't keep overwriting the last entry (as, I think was the initial > intent here?) Yes. > > I don't think what you did is wrong, but I think this is changing the > intended functionality and you should say so in the commit log. Right > now you are saying it doesn't change it, but I think it does - although > before we were overwriting beyond the array max so I doubt it makes a > difference and this is obviously better. Yes, it's a behavior change indeed, I will say so for this in commit log in patch V2. Thanks, Yadan