From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f54.google.com (mail-wm1-f54.google.com [209.85.128.54]) (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 9F48037F015 for ; Tue, 26 May 2026 08:50:11 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.54 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779785414; cv=none; b=X6VSSW9hJruWyFSuVkwXXY5BDKRfnpvhRTgcJtrXXV6c6VXLO/xduLLbH2G7zjwNiaQWbpOX0iOJq6lI+ucE0cCZuqIx4uDiHouSbP8VnNU7dXeVq3HeUTsjL3r1CFP+pZ+QWXc98NoVBcaKmQBzk7I91mL+1Dy6nRnlUFs7OZ8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779785414; c=relaxed/simple; bh=qmOiOS/8u8gLUHjlJbsVBgeo2YCGwMApwnR6otduJNw=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=YbhcxELYEzbK/LpHmctSxXVvKRtVdgv99PZfJflsxWLeUA5J+mSmNAlP2OTGMecwnztvffp65j2C8bEdCCBcMbwfs5Omgiu4p8K3xT64rBUewinAvGyab8F0L2Y8Oxh2XiV5jbsGDWiOgTUeWGtvPF5RpvZ56QU7DUNtl2oMNi8= 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=Rg0V6uBU; arc=none smtp.client-ip=209.85.128.54 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="Rg0V6uBU" Received: by mail-wm1-f54.google.com with SMTP id 5b1f17b1804b1-48a3e9862f0so54452585e9.1 for ; Tue, 26 May 2026 01:50:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1779785410; x=1780390210; 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=fs0o4f88e2YzBUp5ZB+5ZHTjPRkuo/KbEFrLF09ncXU=; b=Rg0V6uBU3aQlyjOEskEzdkTUjn+dTH0L3k2l7hIQLipcxvb13TV5TEZlMlcup8ib0v q3NACcjYjDv/DNxi+ei1x1sUQe6Wl/kJHuMfHeNAyTJg1WkX4fACvMmkBloPgQAegjI4 g3t31Qerv4nZcICOMhAhy/gtPM6gBX14CqkUJ/cIPAFWObM6olgDWZgzYNK2pNeJHnx/ ITUZAX2q4d9uEoSXEqsubHGcbCq+C5nw1FZVtPdIg2r0SuQKUIBCalavesFCcxuOcepT vkDU0cyX9dBxMV5bCq6gtCrAdbp1PTvBXfyad/nTN7jaoV5zgS6RyjiOqhNPUnC6bhd4 9xag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779785410; x=1780390210; 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=fs0o4f88e2YzBUp5ZB+5ZHTjPRkuo/KbEFrLF09ncXU=; b=IF5EDzAH2fKh62BGzjyoFwGDR4TIx9xO9XSxjpBjSmr7N4+0EjxEkC4WDLiYx07WNj rVd5pBUgi85vEraf1IvhWpXhoJia0D2QosBB/S5fEmUfABaxv/0WWR6QuZ1d8f4RsgGr G0mRlty45tsyfyh4/k6oJGKiQMYW61D7k24kojvCIM1mkE4AAG0I3AISpEyvmJDFh7za i7ks7NI4Kqmp1lBRkuuvI+qErgm/vT1A1o25MhoDQJ6fuSMVbThyxePm+Q/eHarR2hTk vNv52KGMnPQ4reBhCh9//2lGDgWGvRGgxkDJyeFEMjgq39WWuLVgcpQ2qtrEj3Gu99+p z4EA== X-Forwarded-Encrypted: i=1; AFNElJ8rCmCe8OYBOp49kqjTxtpirlkQdNaUmsb7j82OoyR4qh/crpeyaTy3mRWLk+zmdx+XFcoJZ/CS8l9uTp4=@vger.kernel.org X-Gm-Message-State: AOJu0YzS2dumVX6maZ+HSxYvulnEqzSCZsknKmx59o6KePro1MqA2t9Y Sdi9HWmKN4zcEjxQZvu26QTXgViEwUkLF9UnNo3kYRlYiV1LqDRTmiOq31/wGBWlbMM= X-Gm-Gg: Acq92OGxBe2gshZo5Cz5qsScH88pmGRvy4DKdDSXm6Uhk1xoZsuZnV3Awj1CA7bil7R tdh8WCTrI0T3VGdJGceGbJn9E7TdZVmvTT+QbKMrRA9NZ47Boy46qZOIqHySptJpcQjJGdVa38t a3VK8adohLMuOf9CzKRx+ect/7BjcirVPDuYVtoDp8o67ay5EQrv+I4qO6p2gEfibLh4vCKzdCa AvxkA5AVUfyMI0Stz1gicxFof/ug7OYH7aeVHY7TyW+Rmtqwh7wEouEHPpH2aFOtxFjtL+NQMvi PPtUE6eOWLRL8OPSYxFlf790b0QOkfMn8NjMARwvy+qJoj8X/BLEwdBaTg45vC+eWHr+ZB7TyOl I8CzPg2tncPnSZTRC2ZvsyLdMWhTShqH4C2SRQD+2wUnJXoovz65J/w5OHPPmJ3Qv6L0rHvCH9K hQBd4jdlP7lkrivNOlJK2B3KuTPj2fvlfkEJxfh/XXC8Wy2dVyF322aon6dCcYHqes0pJve4+iv vSmlwkEeF9Zjlt6dSA5ew== X-Received: by 2002:a05:600d:108:10b0:490:53b0:9e5a with SMTP id 5b1f17b1804b1-49053b09ff3mr132814555e9.5.1779785409766; Tue, 26 May 2026 01:50:09 -0700 (PDT) Received: from [10.202.80.174] ([202.127.77.110]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-36a676e195asm6215388a91.1.2026.05.26.01.50.05 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 26 May 2026 01:50:08 -0700 (PDT) Message-ID: <4c776dd6-528e-46a6-bcf0-795b84c7ac19@suse.com> Date: Tue, 26 May 2026 16:50:03 +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: Thomas Bogendoerfer Cc: "Liam R. Howlett" , 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: <983654c3-98a5-46bc-8e8c-e0e780c7dc61@suse.com> Content-Language: en-US From: Yadan Fan In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Hi Thomas, On 5/26/26 14:57, Thomas Bogendoerfer wrote: > On Tue, May 26, 2026 at 08:51:25AM +0800, Yadan Fan wrote: >> 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. > > no need for that, just return -1 in the error case, this will terminate > the walk Right, I will change this in v3. > >>> >>>> + >>>> + 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. > > no it wasn't. Before the switch to maas_res_walk the to be filled array > was exactly the needed size. Now we don't know how many entries there > are, but the limiting point is the numer of configured maar entries, > which might be even less than the 16 entries of the array. So we have > to deal with this problem anyway. > > Thomas. > Thanks, Yadan