From nobody Mon May 25 02:57:57 2026 Received: from mail-wm1-f50.google.com (mail-wm1-f50.google.com [209.85.128.50]) (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 BB99F348C62 for ; Tue, 19 May 2026 13:30:38 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.50 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779197440; cv=none; b=KINZtDWFU5rcjx4ZA6dAInfIwCZCEH7W9fuZjpDYPaEDuldpICbggkpVyYIII4wea9rFN/iSZ68GOzqafAJi52xB7ha0deTHoLoHxZTDrhMrpO/Lit4sDft8K+tbiyTBtoCLyCJX9+vlso+uTkPkNccIcdiJN5I4uLr5aOMnoDc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779197440; c=relaxed/simple; bh=T7hmCnyhQzzscqgFF2ZS1aF6SwPsdArS5/C7Z+iJcVg=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=NHR1x5Jyi5LlEOoVJKQjXsA5nNppY91phFBTN8c13VViiDvIZKmoezAZXDMQEj09bVVAZiChcvy3JN/hxr7zsDQnNKEWwtFKuGOjnTo4FxHW4MC09cFppja4GWo2bKtVfUZJeiTU7hGNnuRW71rWqrhhpgzXQZuEDaNBs7EW4pk= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=jM17acKl; arc=none smtp.client-ip=209.85.128.50 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="jM17acKl" Received: by mail-wm1-f50.google.com with SMTP id 5b1f17b1804b1-4890d945eb4so24634545e9.0 for ; Tue, 19 May 2026 06:30:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1779197437; x=1779802237; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=EKiZp6w902hBrKMv0fRjCuQOc40X5kR259+Yoc8tiYk=; b=jM17acKlcoLbkVA/VLY6b8YYxhnvT87fG9oGIh04hDKEmNDa7AzsGWsLXqH7szLrjF F7uwuteTOBFRdsygRakPiQ1SCJGSD8TsEjzYC78S52k6BgRWokP8lCim4ikvVoSukXF2 0tjEn+PzK+phoHsS+7MOTLzhtz5rBc2oDmFeW0nByhtOwxhuE2Xmz0C0V0EB3gDdA/Hd Jp4FoWSufMwrfgFQoeyf/zsibPXvxDnAKYsW2+wuf0M1S4+m7DyYy79I9kBu2ChB/tIo FRZ/KIQDAlOp9HVRqc7qqlQFMWxvPaSltGgnTJOC55c4L25e5Cs4JJsCk4JptZcANVxJ ULKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779197437; x=1779802237; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=EKiZp6w902hBrKMv0fRjCuQOc40X5kR259+Yoc8tiYk=; b=jdAP61GyftTOtn1NbARpFNw76vKn3s/nC2oWywc7XYSKxAdHN2UnNWLK0uGTPZ7WOI um/EZTbqeg+pWhJrF329+twCBZE1ZlJs7n/BeFqtvc+F6Y+6fUiSxbIj3DzaR1RhSclY 0ndIezRjFFayJgJMAuigmQoDf3WETcGF5CSq3AHkHxH6ZtMlIj+qs8EDQSNAuLQkm78r VeBreaV4XEA1LwEEVsov7+ORzIOtDCxoX8r4A9qwoPjsDs53h9IzEJAHoESyZ7goPMNC 2M8OGDiDjDlm5hbNwnbn8tc6p1LdMRVZHiijNmc4+NRO3YslcNMdOfHOaSP6mjbkJpUS BgNQ== X-Forwarded-Encrypted: i=1; AFNElJ/7CK7xqT8gZjwmkaIamjIGbHw0LuN4/5+rAAzuhgRLch9GcRL/MpPzwumqbBHc7AsowuHgnwC4cc+XPqs=@vger.kernel.org X-Gm-Message-State: AOJu0YxcB21AgRhXejbYVeom73g3keRIJ04WrWRQUaHVAVt8DRw6mXSU cQ4SsE7+037hHXN9V1WMmkxIzPZQ6pcxFuMrWFzNU4QqL2LbMVTJFvSY X-Gm-Gg: Acq92OEP0yX94rBmkpEQgi6WM8ifONB/MBIL6/wZsCcg9O8jmoqUPmPYgGKtrpbt6Q1 9Ti/mTd5zK7nDNVZppSPdkPbZ8Noe5OV+H5Zoo6ejORuD0GvpQqGRumV8scwnWPPJfGdok4HJZD u3IUJmKjJsi2ExX4vxADU25Mlvt5Tv/Xh6s51zDchMq+Wuywd8mWWq6IdO6K3MFqsuPk34TYV7O sjmA/KOVVjk5YRE6ohYNh+hRcPB6iPDyAzGnfjqiTBAV2O3at1DnYOY9vwiOHoogFPCXjbZbf94 JVaY5L3nlXd59Q1u4vXfCb2m/rtTqXTapxut4KPNvjYGLgjJqHESe7Vqn8sN9G9foON7Ow11mKz HSZEJsMgk/QgRaPlvvdRX5O9aaJA8Da9wI6LhlOvU4a5ofsEks5qifcyn6Yf6XwylcMDgImDlQY n1fsNAO4y6Hjf/LNdC5Bc5lEbWQNPYTm2OPRe83dAnKkX/y+DDDUfg4N+ARczgebU4SHy5a1KwD v/Dk4COe2JgL2+esJu5RcG5AgZUpvw66EvSrg== X-Received: by 2002:a05:600c:a406:b0:489:32b:ac0b with SMTP id 5b1f17b1804b1-48fe4fa1902mr235741575e9.6.1779197437094; Tue, 19 May 2026 06:30:37 -0700 (PDT) Received: from iku.Home ([2a06:5906:61b:2d00:3f5e:825d:a98f:fd29]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-48feaa2a878sm168177835e9.1.2026.05.19.06.30.36 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 19 May 2026 06:30:36 -0700 (PDT) From: Prabhakar X-Google-Original-From: Prabhakar To: Ulf Hansson , Kees Cook , "Gustavo A. R. Silva" , Wolfram Sang , Geert Uytterhoeven Cc: linux-mmc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-hardening@vger.kernel.org, linux-renesas-soc@vger.kernel.org, Prabhakar , Biju Das , Fabrizio Castro , Lad Prabhakar Subject: [PATCH v2] mmc: mmc_test: Fix counter tracking in mmc_test_alloc_mem() Date: Tue, 19 May 2026 14:30:25 +0100 Message-ID: <20260519133025.618255-1-prabhakar.mahadev-lad.rj@bp.renesas.com> X-Mailer: git-send-email 2.54.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Lad Prabhakar Fix an counter tracking in mmc_test_alloc_mem() that causes a kernel panic during error unwinding. The `struct mmc_test_mem` uses the `__counted_by(cnt)` annotation on its flexible array member `arr`. While kzalloc_flex() initially sets the counter field (`cnt`) to `max_segs`, the allocation loop needs to track how many elements have actually been populated. Previously, leaving `mem->cnt` at `max_segs` meant that if the loop failed midway (e.g., "Failed to map sg list"), the error unwinding path in mmc_test_free_mem() would attempt to clean up uninitialized trailing array slots. This resulted in passing NULL pointers to __free_pages(), triggering a kernel panic: [ 66.172845] mmc0: Failed to map sg list [ 66.176722] Unable to handle kernel NULL pointer dereference at virtua= l address 0000000000000000 ... [ 66.432747] Call trace: [ 66.435191] ___free_pages+0x1c/0xc4 (P) [ 66.439119] __free_pages+0x14/0x20 [ 66.442608] mmc_test_area_cleanup+0x58/0x84 [mmc_test] Fix this by explicitly resetting `mem->cnt` to 0 immediately after allocation. Then, move the existing `mem->cnt` increment so that it occurs prior to populating each array slot, using `mem->cnt - 1` for the actual assignment index. This guarantees that the counter accurately tracks initialized entries for safe error cleanup, while dynamically expanding the `__counted_by` validation boundary ahead of each flexible array write. Additionally, rewrite the cleanup loop in mmc_test_free_mem() to use a standard forward for-loop. This addresses the unsafe post-decrement logic in the original `while (mem->cnt--)` loop which evaluated and decremented the counter field before indexing the array, and avoids a potential integer underflow/wrap-around of the counter field if the cleanup path is invoked when `mem->cnt` is 0. Fixes: c3126dccfd7b ("mmc: mmc_test: use kzalloc_flex") Signed-off-by: Lad Prabhakar --- v1->v2: - Started with cnt =3D 0 and incremented before assignment to ensure accurate tracking of initialized entries in mmc_test_alloc_mem(). - In mmc_test_free_mem(), replaced the while loop with a forward for-loop to safely iterate over initialized entries without risking underflow. - Updated commit message to clarify the issue and the fix. v1: https://lore.kernel.org/all/20260513201315.3186621-1-prabhakar.mahadev-= lad.rj@bp.renesas.com/ --- drivers/mmc/core/mmc_test.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/drivers/mmc/core/mmc_test.c b/drivers/mmc/core/mmc_test.c index ab38e4c45a8d..3c7e8a0704bb 100644 --- a/drivers/mmc/core/mmc_test.c +++ b/drivers/mmc/core/mmc_test.c @@ -318,9 +318,8 @@ static void mmc_test_free_mem(struct mmc_test_mem *mem) { if (!mem) return; - while (mem->cnt--) - __free_pages(mem->arr[mem->cnt].page, - mem->arr[mem->cnt].order); + for (unsigned int i =3D 0; i < mem->cnt; i++) + __free_pages(mem->arr[i].page, mem->arr[i].order); kfree(mem); } =20 @@ -356,6 +355,7 @@ static struct mmc_test_mem *mmc_test_alloc_mem(unsigned= long min_sz, mem =3D kzalloc_flex(*mem, arr, max_segs); if (!mem) return NULL; + mem->cnt =3D 0; =20 while (max_page_cnt) { struct page *page; @@ -375,9 +375,9 @@ static struct mmc_test_mem *mmc_test_alloc_mem(unsigned= long min_sz, goto out_free; break; } - mem->arr[mem->cnt].page =3D page; - mem->arr[mem->cnt].order =3D order; mem->cnt +=3D 1; + mem->arr[mem->cnt - 1].page =3D page; + mem->arr[mem->cnt - 1].order =3D order; if (max_page_cnt <=3D (1UL << order)) break; max_page_cnt -=3D 1UL << order; --=20 2.54.0