From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f46.google.com (mail-wr1-f46.google.com [209.85.221.46]) (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 950C7233936 for ; Sun, 31 May 2026 23:42:23 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.46 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780270945; cv=none; b=AyPsVcbAw7rrjgxzcfqQB7Zl1qBO++T3DJFnaeGT9C9MpZbSmdgtyI6TPXj7mnpTnMNFQcBVq7JtwaE5vReCWb89zEUKSUDnenOrFfdesy8LbajWbcRLy3o8fm8/pFLkzMNh18FZZBbUP5guqKi9rOMc7u26rowNEITEv4YcUhc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780270945; c=relaxed/simple; bh=ZdhCfU2NCRfkFTPirJO2EahHOFjwRR2cXrXkEpHHKNQ=; h=Date:From:To:Subject:Message-ID:In-Reply-To:References: Content-Type:MIME-Version; b=Lc+QP7H0cKnHW4JCQ/BYuk8fDp0tUioz1fpK5+kd5sL9V7kyiIWA1LCdNZvy1MhsOELPCBtYXPUC+vcS+3Y+QeZWtvim16gT81Shf5c63TkpE+BKw/DAWKgp71CPiQfDzDgB77vbd5S/tijDsbPWJFykb7Uaacp44K2/x+NfYog= 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=r7/Amuv7; arc=none smtp.client-ip=209.85.221.46 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="r7/Amuv7" Received: by mail-wr1-f46.google.com with SMTP id ffacd0b85a97d-45ee1a56328so4001163f8f.3 for ; Sun, 31 May 2026 16:42:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1780270942; x=1780875742; 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=zsfWlGncHQgiiYO7yjj/ulRFmjF/DIPVayuRQPsVfhY=; b=r7/Amuv7iskUF0IM9AJaewyfaNF/rhEUxYSUwyPPD2vTHwDf4TYvzlwoDhzKqYChcl WvIJ17SnuDL4e6ITGYL7Fb4v7w5+kUJr4/lNomNVLIgJL+TQQUx/YYzp9ap5PoFucTRs rw/NB6TspQmk+QQWiNOipzf0ngfY4Sai4MGTtBIU/gHhOJY6CYKa+JAqe4+2crRA6ZFJ ysbr1Tk13bYH2rsxP9cl7g225xgTpAOXd74MjK+OVo/04T+AwMI20Z552x/AWdqCxN3p omMtNtqoMlRggg0Ck8LZ7vRc04CMgHHrKTzHOEdp9fYXXjElOk16mCAqTEtO+vWkqVOn vb3A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1780270942; x=1780875742; 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=zsfWlGncHQgiiYO7yjj/ulRFmjF/DIPVayuRQPsVfhY=; b=VQqhZVrkp9zvfwc9B+tSWW/7s2neIc+8lwXJsyB2PoXSvThc1O2VyyMb0vpSld7e0R oQW8EHXBdC/BCXJEC3Y4wOyNWmvQZOC10EUPi3EUodIqwSLS+4+A95BFZcp/H3ZtMYU2 9y6P7UB5dg1fLovHSiWXk5yujDMr/V4V6wnokLH8W6iL31IqVK8mvUqfrWvPzOEkBubT gd8pWVlJMnzN1yuKttARXS3Otlq+3Ys/iOp8N8zl/a4b4ju546Jl1Ty2jEGCK1hJ54wb /QBSzONBMLs1mMhzjnDZdxo2wXJXgNfZGAa3U2sE5GJ7FB73yqWjQtwLA7EE3dFQdzjG +/lA== X-Forwarded-Encrypted: i=1; AFNElJ8hR5u0HYYsZGQrM5m/JoFX70xvnsn5YuTnEI0FL0FqfagBtTTG9svoDKl5LCdJZ0xOvmIbmxoVsMuiJ7Y=@vger.kernel.org X-Gm-Message-State: AOJu0YzhDveWdorQ8EyiykIjGTNo8L9WK9YxUGtNENVcWNlRy5/0yc1A LrYe1BZ5kW72HhUu2zRaYUgCW0j+++fLHQ/ijhTKcGpMWVUvzAsj5eECg6uLTM5N X-Gm-Gg: Acq92OG4bVuSnL9YNGnHnLV76LGbQLcdhOyh0nMTE2cq2NkGbN2oxmwuwEWDnRbRjI5 jWTAai0IXIlFNxuUttmhwNRlCXPTRKDXqJ+H1Ye54Vvf/mBVtkqH5raZe6UYs9hAqgumB3A0Bav l+sjTWLsZCMN6MRZOjQWR40waEGxIdaJFgEZ71sRuy2NXxoKP/vCaaJ65stuq+58l8GTeHVtcNB HvZbe0P9UqS6yGvwmGPuaERKF2kDbFAOZfVwT6zsguiHsePeq11ZvuVZ+kMXX+Nx1n2WS0267Kp c/65VfEztb2nVpn/l33bxh9VnyiZ4b0yIHsRkTpP3Qytuq0shhLBoQiBgbCGNQHUWygPht+WcUH vLPnqBVX4fWvudsfUzBOZ5Blloe/Z49uEg59kf3XFTHFXOfhikj2hdyCQbCS4a/3HOHEX0rWb2P 7b/RTtFBFr4JlZj3fAgiOLXSHUPGTQZzvo5TVGroB9+RNXIQ== X-Received: by 2002:a5d:6049:0:b0:45e:ea68:5237 with SMTP id ffacd0b85a97d-45ef6b138e9mr12774487f8f.11.1780270941936; Sun, 31 May 2026 16:42:21 -0700 (PDT) Received: from [127.0.0.1] ([141.255.129.1]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-45ef354cf0dsm21196831f8f.17.2026.05.31.16.42.20 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 31 May 2026 16:42:21 -0700 (PDT) Date: Sun, 31 May 2026 16:42:21 -0700 (PDT) From: Charles Pellegrini To: akpm@linux-foundation.org, egorenar-dev@posteo.net, robert.jarzmik@free.fr, t-pratham@ti.com, linux-kernel@vger.kernel.org Subject: [PATCH 1/2] lib: scatterlist: fix sg_calculate_split() nb_splits overshoot on partial coverage Message-ID: <178027099087.72481.15914006421095162619@gmail.com> In-Reply-To: <178027099087.72481.1976843064458686851@gmail.com> References: <178027099087.72481.1976843064458686851@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. The KUnit test added in the following patch (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