From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f53.google.com (mail-wm1-f53.google.com [209.85.128.53]) (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 0580A271471 for ; Wed, 25 Feb 2026 14:40:24 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.53 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772030426; cv=none; b=pi/920hZkOqDqnmQl9yAFK4GTIB7oz2aJQP4PjF6lPHebVYQ3HUPiETwO9lltaTaBqy7z9MINgNrQ57c3MynZL8WB3a8BHteU+JVJpL07KtGf3Mt6RmnaliINlAd217v4zufQzoJhf1Qee+Wm5ySf7dccBDPyDTMjVWQrc60JMw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772030426; c=relaxed/simple; bh=666U2SeH2IF2l8bqfN3ChEOx/oJUibMvCH6ENY3ztPA=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=JqQDmZrEgrG+7nRiui2kyULZNCzitcJEJH2T/x0Cd5WS4QiRcNxYVh9De6LMOciZR0LLVOIfv8AkNXNwq6tb/jrIompBswZliu9UfYPciBwhnVMCbu5kniG/7PYd6k2+dI+GkgMaeXXfCyX3qbIkaiP3Y9vzXYFyn1jbvDUvDq0= 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=QOUpS3mT; arc=none smtp.client-ip=209.85.128.53 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="QOUpS3mT" Received: by mail-wm1-f53.google.com with SMTP id 5b1f17b1804b1-48371119eacso79327025e9.2 for ; Wed, 25 Feb 2026 06:40:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1772030423; x=1772635223; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=7q8RWpVROZPmxmIqcGCn3629mxXy+yPwavVRfw3rfAU=; b=QOUpS3mTecDe+Kw70tHOqPRUWapF32cfKstoDDBqnUiXfHHiL9yBtOmuMVBbANzsyl 3RzAVQha2ZCDMfoUDM9aAxD6LG9aBT6WMsGKVwPESWDWlnymdKQjxS+JN2Ou9Wg24wCr CBX7QhzwXrqolmsjdfLel7JllYRJkDtrDoL409epV/kNhzLQwrHVUfwHseFbPVsZMrh0 c3GmCCtLg2/c4KhOoNcHg6enyudKTShFWePUqW+Jt7dt6vfSxckcM2xiRoGL6wFytQgF xkv4pLWxFRERHZQp3haqoMmM/fAjdv7f6t//QlwGV0iaUdmSyzVWZxPM6hquTp03zrqf SLEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772030423; x=1772635223; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=7q8RWpVROZPmxmIqcGCn3629mxXy+yPwavVRfw3rfAU=; b=dsG+8rAg1CCe8ZpqUYQJbugRwgJVv/ORLY3yeDUH4hR3BBvStEf+yBIpVD42wSv7J8 ZasyTVMeFqcpAgDhsuHJZK06e4Ndx6Ko5Xr3np3N9F5thypUCYxBRKtHRlpXNmQ0+C+4 20TacZBvCIooByFT0ECP4o2CG0KztiQ0dBqx0s/mY3W9oA50mHL0p8xSgC9r+plN6xtI dPwOW6LojkMDNCmUCpchZHOeazC2PYWFpeaTWOHhbxWUF2F2FtUOhYKcNAqzt1ZSF0O/ OGKZymNKcZPEt48hlT+sSQ50rageVZ92nl71wzPCo6z2MOnrVTi67dxFr1Dt2jjIPfsv QD7w== X-Forwarded-Encrypted: i=1; AJvYcCWAlW+g+5zthEIiiqYKKnZb/r80PKjfwyMQwNtbjQcArG/99OQc/g5hzLoyGdXzwbHZvx9SSzgqtpHJGmM=@vger.kernel.org X-Gm-Message-State: AOJu0YzecwcpwlgZAcJAb1D+hQ5xdPlsyEThb3q8a83d7MGy1UrpI7TD Q4P6AodnKjJw3GDrN5cESxR/4goYMcCXLFDig27kaDeDBL14MRu7Y+lo X-Gm-Gg: ATEYQzzzrd0f/NSzLhur90YNPPnU/DXdzrONv+4Ncv8HNYxq/sXILIgn88GsdsgMRlQ tan6Zrh01ArGCprt7w/4m9VCfuuLRRcDmXWUZQBfEsiGDXbRKJYdQ3n7DslBVR/b+PDz2GPkJkL jT+r+GmQT8cUaXaNaBchUA+Y6D3jA4pWKyuPP6sOmkMbP+/bS0xWLnEuMdVJj+Et1zdyJA54H8t SSan8qCb0jQPbK96WWmVoWEdbgjy65eza7Hlpvjm8JF8rOAEMjI451V3a622tqH/fuSgNXtAMC0 lqJWMEHs6vOB9vs9ozaVGe///G8DLRez3e6Nof2iTShE530q4ga+mjHyWwFtR+D+nF5QUACFRKW DExB2U9CFBTG488xpHqaF7K1cycAAgCXpYwGDYpYv3pUN9ZaE7yomtJ+VHWf/R7hEX3SKAgB7M4 JDp3aHi2992IDxcUQL7QSBwOAi3u7SMJPLf2NpMBrAebVv201wbBlGmVgSLm7o9b+e X-Received: by 2002:a05:600c:1d29:b0:477:a36f:1a57 with SMTP id 5b1f17b1804b1-483a95eb537mr244540785e9.3.1772030423078; Wed, 25 Feb 2026 06:40:23 -0800 (PST) Received: from pumpkin (82-69-66-36.dsl.in-addr.zen.co.uk. [82.69.66.36]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-483bfcb4f8bsm33408465e9.4.2026.02.25.06.40.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 25 Feb 2026 06:40:22 -0800 (PST) Date: Wed, 25 Feb 2026 14:40:21 +0000 From: David Laight To: Fuad Tabba Cc: Kees Cook , Andy Shevchenko , Andrew Morton , linux-hardening@vger.kernel.org, linux-kernel@vger.kernel.org, will@kernel.org Subject: Re: [PATCH] lib/string: Fix UBSAN misaligned access in sized_strscpy Message-ID: <20260225144021.61ba508e@pumpkin> In-Reply-To: References: <20260224170427.2296592-1-tabba@google.com> <202602241302.75B565883@keescook> X-Mailer: Claws Mail 4.1.1 (GTK 3.24.38; arm-unknown-linux-gnueabihf) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Wed, 25 Feb 2026 08:08:34 +0000 Fuad Tabba wrote: ... > I also noticed that the read path already expects and handles > unaligned addresses. If you look at load_unaligned_zeropad() (called > above the write), it explicitly loads an unaligned word and handles > potential page-crossing faults. The write path lacked the equivalent > put_unaligned() wrapper, leaving it exposed to UB. Not really, the read side is doing reads that might go past the '\0' that terminates the string. If they are misaligned they can fault even though the string is correctly terminated. OTOH the write side must not write beyond the terminating '\0' so the memory must always be there. I didn't look at exactly how the 'word at a time' version terminates. For strlen() doing it at all is pretty marginal for 32bit. For strcpy() it may depend on whether the byte writes get merged it the cpu's store buffer. On 64bit you have to try quite hard to stop the compiler making 'a right pigs breakfast' of generating the constants; it is pretty bad on x64-64, mips64 is a lot worse. On LE with fast 'bit scan' you can quickly determine the number of partial bytes - so they can be written without re-reading from memory. The actual problem with that version of strlen() is that it is only faster for strings above (about and IIRC) 64 bytes long. So in the kernel it is pretty much a complete waste of time. The same is probably true for strscpy(). My guess is that the fastest code uses the 'unrolled once' loop: do { if ((dst[len] = src[len]) == 0) break; if ((dst[len + 1] = src[len + 1]) == 0) { len++; break; } } while ((len += 2) < lim); (Provided it gets compiled reasonably). Without the writes that was pretty much the best strlen() on the few cpu I tried it on. David