From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f45.google.com (mail-wr1-f45.google.com [209.85.221.45]) (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 1D0BD286D70 for ; Wed, 10 Jun 2026 22:39:34 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.45 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781131176; cv=none; b=mOJfACFp1h31ZEFlsxZ+PM138IuTBIn0px/aGRVpQDbgjepkLdiSDDqsRLtYupao56Ym7DYV21Jn6+SChCArZzQbqSrUyUOISfVq4Cuxq6nSfl1l4Mn1TcNzqwTQUbHfc0/PyeoHZZPqWNvyzvuPtJ2t6NVbec5xFX5CqffqoAY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781131176; c=relaxed/simple; bh=uymIhH8EkIlLYX0R0I1xIbysPZ8OabISRNpJoqhW0Kg=; h=Date:From:To:Subject:Message-ID:In-Reply-To:References: Content-Type:MIME-Version; b=sqTfyP8UCU7CHGhx4H2m7lCraS6DnHpwkpQY0i6TVByG0a+N99bECbMAiXjECjjm9iZOuDc3iqakNBA2Ut5oPFiPu4IQvau392Gb+2wM3S2y6vcdpe1o8oJoD8jKaylHj4g5OhlEKzTzI4DdHTtTwIEuWIjPUGR+WTgdW2Y9Owg= 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=I4DDArSW; arc=none smtp.client-ip=209.85.221.45 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="I4DDArSW" Received: by mail-wr1-f45.google.com with SMTP id ffacd0b85a97d-45ee5cdbd28so182385f8f.1 for ; Wed, 10 Jun 2026 15:39:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1781131173; x=1781735973; darn=vger.kernel.org; h=mime-version:content-transfer-encoding:references:in-reply-to :message-id:subject:to:from:date:from:to:cc:subject:date:message-id :reply-to; bh=cLDLj29X5MZRz65xRsFV/d7tpi8z5WuB8iOUPaHcw/A=; b=I4DDArSWcHi+pdJcglodKtQrs1+w45J/emA4Bd4OR6LEmDMz1IdIWHs11YAYoMgVOM phtNhB4CgizWmWSmHouYUNx0KkrYyMhX/gz7OdbYI+dFj3ZbNpwcC2r4NJT072FMPNTd fE6NJl3dlfU2Byw2gRNBzmIx1iRNJ1tfMNTiJFjsUW8Qitl8eNjr9yqFO+u1n/WnvVHv +2r5PwBoNtw3BGNaimqUVmJ3zCh1mhlyZb89/MQsB283QBAiMpiClk94qag43VkLKbPF Gqy/UWxG+BeWShDcPVSFNOFkqO1H7xTDzXiHIKhKmpAeky+0GCw0sykEtWnuRxML4Uf/ CLbg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1781131173; x=1781735973; h=mime-version:content-transfer-encoding:references:in-reply-to :message-id:subject:to:from:date:x-gm-gg:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=cLDLj29X5MZRz65xRsFV/d7tpi8z5WuB8iOUPaHcw/A=; b=NlYhd0bnCs9xqD0rURTXIVuphyF1gl6DJmhdk4LDPzcSitQWqGEO6SRtNVArWS8VIk xBfsyAJ3fth0kwE6tiR87Vvz0G/QCBlPuC1JTU3kYdD2DfzHnFbp77IGHcNo+DDDpnNp /l5t499SNvFkHhuO7RhHaU+Er0vI25Y/9pnrFGGjSD6n/40Y8h68zBbOyt5XwDSxwUWs avW14BX2l4CK69Gj+07THJY+zG+0mrC2nPdtGSJzHw6kHOyrGGU+LSUqDvBHdnLls7/J EIW4KhOt5PM7VPrdH58+eVbvCvjfAUCrTeccnxvBpdWL1BwOj9AxaaKFVooQ+O+OI1Sr jLDw== X-Forwarded-Encrypted: i=1; AFNElJ9Dp+l+BlXUMgYo0Ud1txion/ZkJ6VF0+Ki1TmHa8VgdPtgeZUt8S+1oS1zQIZdY1RFkZKYs5wKBo0w4d4=@vger.kernel.org X-Gm-Message-State: AOJu0YwZqq7f0Fx2yA60alPElMPivTBmIvIDqbPxJLvFSENswn3V48Sr um+tDOrUR6LxfxpPCFqYoUrE1OZWHb+AuhAxoaiARId8rhz2FW4vVgXf X-Gm-Gg: Acq92OF94mL3bYZcZWe8OQkTU9/IN/4Jakd9KMmpr7oBFH14bZ1MJ13Rh2njImLbcy1 LE7CdGBqffBSg3L2Ats6stQY+VdVwLUj6QrOJhEnaSN9x8GqF1vkNOCM7n9KgSu5ZS4OTtVm5Qy QCBb993rwIdEa4tBwiDpApfCNHUwpzLe84XtzarO95B0Q0/KmO4qHBgQAkTHwFDiMmbTsPJA0IJ yRvONTBIpiTTmkbKFZciSdYFxOszpw1hSp4D8H5kygQMNMbt88RNOBRD8KazNmhm8bVdnEhPu3J TmO+oOHpwEmXs66a29xiIX8dKDH2yx9I5s75/XhV4El+va9qoQWV0HzttRw2m7NuxusqchVb5Hp kNZor0BSNkcVOBfcRXnIyjgtMWHjhk6EiXmjEo63s5BeLCD3BYDtS9Akg1ViELyIElh9UMxNme6 3i5IQfQRitFP6lB8hdu0wIuUxj5/a1F3GVEOEXBFNKde4BGQ== X-Received: by 2002:a05:6000:481e:b0:460:2d57:6923 with SMTP id ffacd0b85a97d-460664fe034mr582568f8f.10.1781131173437; Wed, 10 Jun 2026 15:39:33 -0700 (PDT) Received: from [127.0.0.1] ([141.255.129.1]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-4601f360bd6sm81616932f8f.36.2026.06.10.15.39.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 10 Jun 2026 15:39:33 -0700 (PDT) Date: Wed, 10 Jun 2026 15:39:33 -0700 (PDT) From: Charles Pellegrini To: akpm@linux-foundation.org, egorenar-dev@posteo.net, robert.jarzmik@free.fr, t-pratham@ti.com, david@davidgow.net, linux-kernel@vger.kernel.org Subject: [PATCH v2 1/5] lib: scatterlist: fix sg_calculate_split() nb_splits overshoot on partial coverage Message-ID: <178113124323.90620.17790224289870749013@gmail.com> In-Reply-To: <178113124323.90620.6403136846887207198@gmail.com> References: <178027099087.72481.1976843064458686851@gmail.com> <178113124323.90620.6403136846887207198@gmail.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 sg_calculate_split() decrements nb_splits in two places per outer-loop iteration: once in the inner while() that advances to the next output split when a split boundary falls mid-entry, and once in the trailing if (!size && --nb_splits > 0) The loop-termination check only tests for nb_splits == 0: if (!nb_splits) break; When the final requested split ends mid-entry of a non-last input entry, both decrements run with their bodies skipped: the inner while() takes nb_splits 1 -> 0, then the trailing if() takes it 0 -> -1. The termination check then sees -1, not 0, so the loop does not break and the next input entry is folded into the last split, inflating its nents and length_last_sg. The resulting split covers more bytes than requested. For in=[2, 1], skip=0, nb_splits=1, sizes=[1] the single output split reports a total length of 2 instead of 1. Widen the termination check to also catch the overshoot to -1: if (nb_splits <= 0) break; The new condition only fires when nb_splits is already negative, which is reachable solely through the double decrement above, so it cannot change behaviour for any input that splits correctly today. This was first reported by Alexander Egorenkov in 2021, with an identical root-cause analysis; that patch was never reviewed or merged. Its proposed fix moved the existing termination check above the second decrement rather than widening it. That handles the mid-entry case but regresses edge-aligned partial coverage -- a split ending exactly on an input-entry boundary with further entries trailing -- which the current code handles correctly. A KUnit test added later in this series (sg_split_t10_edge_first_two_trailing) covers that regression. No in-tree caller triggers the bug today: four request full coverage or re-split over a DMA-mapped subset, and the one caller that requests partial coverage (the DTHEv2 AEAD driver) bounds its consumer by cryptlen, masking the wrong geometry. The fix matters for callers that legitimately request partial coverage, which the API has documented as supported since the original commit ("the union of spans of all resulting scatter lists is a subrange of the span of the original scatter list"). Fixes: f8bcbe62acd0 ("lib: scatterlist: add sg splitting function") Reported-by: Alexander Egorenkov Closes: https://lore.kernel.org/all/20210418143425.22944-1-egorenar-dev@posteo.net/ Assisted-by: Claude:claude-opus-4-8 hegel-c Signed-off-by: Charles Pellegrini --- lib/sg_split.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/sg_split.c b/lib/sg_split.c index 24e8f5e48e63..28fe7fa6c9ac 100644 --- a/lib/sg_split.c +++ b/lib/sg_split.c @@ -67,7 +67,7 @@ static int sg_calculate_split(struct scatterlist *in, int nents, int nb_splits, size = *(++sizes); } - if (!nb_splits) + if (nb_splits <= 0) break; } -- 2.47.3