From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f52.google.com (mail-wm1-f52.google.com [209.85.128.52]) (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 DFE3E331ED7 for ; Wed, 10 Jun 2026 22:39:35 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.52 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781131177; cv=none; b=dm3esPwDg/JDyy19E0a7GgXwF9keh4RdMUJ340izD6MnRowf9TNIFxxzXRa3Q6d2MhcsaJkR4ELSB0kEwhxgwmMQ+IzAAGEn4C69SJaBkpyYwUERgv/M/k+VNCUOVEBFfenBNYXHxAkNmlftZjb1AzFFK0DBudOnz0SlzHQm1vc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781131177; c=relaxed/simple; bh=javK4O2Yrjc5y5bSMX38OZRHuKf/BPcjHnNMauM59qA=; h=Date:From:To:Subject:Message-ID:In-Reply-To:References: Content-Type:MIME-Version; b=okDCPpq8470gc4gOLvhhz9RUsLi7N6pUoYjD29ust9uQ0ghuH2gvzPwjTpUksNGfk9Kn8rQX7cdv8vgO2nvQmouSlWEwj+4qEFw97/7ddvdDFGIQk4CjMzsfAH0qFk7J+q/s8ZH5NqUb7UH7k6lEyffG2HSbhWUe5Oil553IvDI= 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=s093aeSb; arc=none smtp.client-ip=209.85.128.52 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="s093aeSb" Received: by mail-wm1-f52.google.com with SMTP id 5b1f17b1804b1-490be29c1c5so93089875e9.2 for ; Wed, 10 Jun 2026 15:39:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1781131174; x=1781735974; 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=yaSOsg7Wl3rQURa0rl92u4t+K7aMyqi/k71oO1cerCg=; b=s093aeSbkhkCot+cMX286tpSWFhi34BnrcOijfzXuKOVlLPKNC8IDCPA163tSD9qke 7/PdQQKJkiKYRZwN7MbXrY9Ypi85+9MPXLQRfk447F/zSuB69PdfulOL5baeEHvCUHi8 A6SV/1r4gbnK5YF2mPC7E6BOLbiNDht2b8KDHnkcPdWb+krBU8Cu2tIr81wppCMHyZVc py60PhT2Kcf3LgLO0NK4caBhjhiAvGp8fPt6B10mSz5ZYq9sB5ztV/Be6sMrc3SQ5gRe CUqup4ccsnmw3EAQlzK5lXGKBd0Mk7FrwZ+e1pEP4oQQgr5I22RB7B98KqPNQwXokHBH eyQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1781131174; x=1781735974; 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=yaSOsg7Wl3rQURa0rl92u4t+K7aMyqi/k71oO1cerCg=; b=pffvHJiyZAuJF8Jd0i1Ey5NCXCCAz6XImGyK/OVK7uEGoil2T3dg6pXcObXxek9Em4 ObW34XoJIM7fybqHBp+xD63sgHH84eZnuseDFWjvsHrptOEDS4ydg2AHkbh76Rcc183g Reu+qsBsgkXXA04flYWL32ysNyiPX9ZB77jkGu+L+BBK1O3cKT5uLlfEJY9widLQazT2 UeFkmf4XtRTnwTTecFN4xNrtqYjaOrt9LpgjFYqwOutZUPqcYeS97pw8MmZzsTYqpNjh io2it40ywot/5FF312//MPmY0QELwte04abDmkJp7KBEXVm5zE4i6e3NppIn22yVc7Pv u9DA== X-Forwarded-Encrypted: i=1; AFNElJ/Xr4PihEzeO9XYNk8N+ZOgwrt+LHzLsITRSUTiuobRKcoC4oJWpbA/y9zc+gEkgwaoKKNayCnPa+pP3bk=@vger.kernel.org X-Gm-Message-State: AOJu0YyEtiNkcNRpp5OnuM/FNVYDuVbwRw66tKTGqEl/a4Tt+Wv5ZJXI ul+X+XhqpVFpG1IfBXwiDOj7gWGBwEaCnGjLI68oQXcnHJzgtxVKlZrz X-Gm-Gg: Acq92OG4dw/zjT4CCI6pqSJlnmHdvdx619+rl4hN/6TuLNSthzW4IuBRagiiqhQuker /+UprR5PO3UolXrAM2BDsv3+Qn2Rni7peHgaAGnXUKYx11yJSJ+CsOnresemDEOBwB1XdFQXjoM xK/BJkWG+ZUceMdiAaRhtnWRvUrxswafgly2WTm19MAQRhbcnI8zM3xnvBLB9epkocbZ7Hyt0Iz FiaVRsx+4Tm++IkGFyv5TG1uE82ohxs0rVFT61yherfgZOwOSBnk5S7aDpum9XfoaMKONHEsdTK 8L3E50ugM4hIHkGzckl5+cEom2hyK6E4vw8DYCID6AGg0cmy3A5mPrfgwHL5S93p5478XzVGx4R sh3nRU31RUb9pqD5jqyBXjxHY6NZnMF33Lx886ENlVQ2MmocgjLuvUaJQXDqg8OMabFpGmkrmis YIBKVjjm8v//D4zN7Qo5j3Xb/yF9CpOrRYBqkjito0nrHbiw== X-Received: by 2002:a05:600c:6087:b0:490:c024:2eba with SMTP id 5b1f17b1804b1-490c25b06edmr447644135e9.22.1781131174155; Wed, 10 Jun 2026 15:39:34 -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.33 (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 2/5] lib: scatterlist: fix sg_split_phys() ->length clobber on !NEED_SG_DMA_LENGTH Message-ID: <178113124323.90620.15074575220138727748@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_split_phys() builds each output entry by copying the input entry and then scrubbing the output's DMA view: *out_sg = *in_sg; sg_dma_address(out_sg) = 0; sg_dma_len(out_sg) = 0; On configurations where CONFIG_NEED_SG_DMA_LENGTH is not selected, sg_dma_len() is defined as ((sg)->length): there is no separate dma_length member. The sg_dma_len(out_sg) = 0 line therefore zeroes the CPU ->length that the function computes for the split. The trailing out_sg[-1].length = split->length_last_sg; restores only the last entry, so for a multi-entry split every non-last entry is left with length 0 and the split silently exposes fewer bytes than requested. Where CONFIG_NEED_SG_DMA_LENGTH is selected (any config with an IOMMU, and arches such as x86, arm64, powerpc, s390 or sparc) sg_dma_len() touches the distinct dma_length field and ->length is untouched, so the bug does not manifest. Compute the length into a local and assign ->length after the DMA scrub, so the value survives on both configurations: unsigned int len = in_sg->length; *out_sg = *in_sg; sg_dma_address(out_sg) = 0; sg_dma_len(out_sg) = 0; if (!j) { out_sg->offset += split->skip_sg0; len -= split->skip_sg0; } out_sg->length = len; The sg_dma_len() = 0 scrub is kept deliberately: on NEED configurations it clears the dma_length copied by *out_sg = *in_sg, which a consumer would otherwise read as stale. Deleting it would fix the !NEED case but leak a stale DMA length on NEED; reordering is correct on both. No in-tree caller triggers this: the only caller that hands sg_split() an unmapped list and requests a multi-entry partial split (the DTHEv2 AEAD driver) builds for an arm64 platform, which selects CONFIG_NEED_SG_DMA_LENGTH and is therefore immune. It was found while correcting an in_mapped_nents argument in the KUnit suite (next patch), which is what first exercised the unmapped multi-entry path on a !NEED build. Fixes: f8bcbe62acd0 ("lib: scatterlist: add sg splitting function") Assisted-by: Claude:claude-opus-4-8 hegel-c Signed-off-by: Charles Pellegrini --- lib/sg_split.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/lib/sg_split.c b/lib/sg_split.c index 28fe7fa6c9ac..ab574dd26b03 100644 --- a/lib/sg_split.c +++ b/lib/sg_split.c @@ -84,13 +84,16 @@ static void sg_split_phys(struct sg_splitter *splitters, const int nb_splits) in_sg = split->in_sg0; out_sg = split->out_sg; for (j = 0; j < split->nents; j++, out_sg++) { + unsigned int len = in_sg->length; + *out_sg = *in_sg; + sg_dma_address(out_sg) = 0; + sg_dma_len(out_sg) = 0; if (!j) { out_sg->offset += split->skip_sg0; - out_sg->length -= split->skip_sg0; + len -= split->skip_sg0; } - sg_dma_address(out_sg) = 0; - sg_dma_len(out_sg) = 0; + out_sg->length = len; in_sg = sg_next(in_sg); } out_sg[-1].length = split->length_last_sg; -- 2.47.3