From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f42.google.com (mail-wr1-f42.google.com [209.85.221.42]) (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 C52C240DB53 for ; Sat, 8 Aug 2026 13:04:05 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.42 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786194249; cv=none; b=tRWACoFBQKNA7Td7++JN52g7jqN5EFrEqpFeF13w/zx0HYjDEfsLnL6Z1cVW6D/OQ4remLNWxEFp6x0vT9LljsGPOXHZ7HSAq/UTf8BctgMPPMVXAvNHmgQkQBZbWGYa7wDzT3z9XeWwW70vP/ovKwMxkdKzjQMfurQA87cTjWw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786194249; c=relaxed/simple; bh=pPO+Z6bwoX10MG1Z8ii2+Y6MoWoAJECq+PxdJgg0Y6s=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=Nm4ls669ny2uRuhQUi/FSmoxdeMB8Tj6UVc+y7+rVfv1KRrch97ORYDeP3V9A+mo2FdzM+eIYSEGTi9SsNiqdUzxG8Rh21VUkz98ks0kNsr8zCmddXVSB7hTlOgasbdE54Y7ZTrKJ+zd0qzfvQGFH+Fon0g7ULnB5xSh2KifyMU= 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=dG7HKXIG; arc=none smtp.client-ip=209.85.221.42 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="dG7HKXIG" Received: by mail-wr1-f42.google.com with SMTP id ffacd0b85a97d-47db714766aso1704428f8f.0 for ; Sat, 08 Aug 2026 06:04:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1786194243; x=1786799043; darn=vger.kernel.org; h=content-transfer-encoding:content-type:mime-version:references :in-reply-to:message-id:subject:cc:to:from:date:from:to:cc:subject :date:message-id:reply-to:content-type; bh=gk/P1QwaJrQ4JSmGI/ZGfhPo+g7crElZoj/gCPNRdKc=; b=dG7HKXIG32zAQoDGYHhcZYvgq6akIV1byyKTnIdAQr6+hmyN3yR3D6SrbiuU7IyO3E 6B3FbE3lsl0CozTun5ACIR96PNsSaoLOOLIhl4CZxnJpkslxWwzHwN+WgSqKrIcfE5ra luR9ZAI837N1tQSSab1VZhwR9ZSERTTrH5VDWP9unOzY+H3JoEcxya28/VYsLa3b9UeT x6tWMzWYAanznWiOersCdIte48bEWfK3K7qJ9J8exo6//ptnbMRk1+SWb/HiPIcTJ04h mVxgu7LXROa/lg7b94enzw/pX5w2sIuskTchEpRql77x+SkXbI65r0T1VGAxIcqslqdV poDg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786194243; x=1786799043; h=content-transfer-encoding:content-type: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 :content-type; bh=gk/P1QwaJrQ4JSmGI/ZGfhPo+g7crElZoj/gCPNRdKc=; b=mdM8eusfWvoos33i4tWCvIJquOPhcFS++9QBAaxXA35Cc4yfal2raAmh1BQxha+8sd zw5tTS/gHaKTN46qayOGLpq+FXP7TwmsF53V0L5yA8OoeQcKHrNI1RD2/EmGBcXYOrcJ qryPr/cvkHfz7d4UPiek8XVUqMUTNg41sUkZjmNUcl470oZgHvjpRX38HGVA1v76GQ6T t2CtTulawCN/3sAnLwnK7k8gJ9x33ik6nqh3/+BedHggwbX2PXAoDObeQsa7U5TXoj09 bB2LPSlRzIpKzsdhVLvv/HLq0UVXD82adhkZwki+35DS7bZn9+/pQrH/9Ki2bgLQBxsC XrSQ== X-Forwarded-Encrypted: i=1; AHgh+RpbhWlhW+/s5Lx8VdHZ5fMjfTCqSb0qjVqaoklPHq2Xl6CU+fJN17uAj5j3R+Q1K2tG4KFBPUTlk90LOPc=@vger.kernel.org X-Gm-Message-State: AOJu0YwnCKsCeGmPz1eM0sNJZnyQsU1xSsZxRs+3tv37QUg02lfljiQv gCtu3BY2SoVmILbwb6/NTFEg+ixL2E3VOHySAoedKMx3tEZryYQ6LdZs X-Gm-Gg: AR+sD10nCvOf5LPXHve6xM1ivZ+i7lM5tN2NbxVdffGID/wK3bD/2L6sldjNYCv4con 4asg37o1e/BFvDd3irzDZObjH451WBNnW3+VWXMpNRivHI1CrdSdqilqYS6TAbpu30gT7ql0qOz +VC6IqjVWIhQ88FAlE8Pi3FPt71L7DjEGkkncDBfdxThSl87rZQ4sdg+NPMBgR0jKm6qDf34tYe 9q5UTVrvybB8iN/V1i//GeW+osggpsAtioTraw33pfwMSmyqPlIvAqHy4j+ZByvJ+6KWOa9BP87 z9TNteeyHbrCvZdfQla1qA+tIKwixDBoWNPiB0MT62yDrP3mBw+bpctJWnv+Ldq86uj7jIEMiEi UtDU1rTMNAJxD8nPu8aMsUk9RzNfhTzMhRNzBxW3wWJ+WHGW6uWmMbfdFUZsn86n6y5nLuBvP5V kd6Oz5SVF65dNFHgsw+Dy6msTAqoggI255F18IjPCQqHbDCbUbzgJvj/MeK1Gqn9Mr9lmTu6AK3 cRXUi+kzkpaHr8h7ePMpycI3Q== X-Received: by 2002:a05:6000:2889:b0:47f:90f1:68c8 with SMTP id ffacd0b85a97d-48131915e4cmr7384863f8f.1.1786194243024; Sat, 08 Aug 2026 06:04:03 -0700 (PDT) Received: from pumpkin (82-69-66-36.dsl.in-addr.zen.co.uk. [82.69.66.36]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-480021501bcsm14698089f8f.9.2026.08.08.06.04.02 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 08 Aug 2026 06:04:02 -0700 (PDT) Date: Sat, 8 Aug 2026 14:04:01 +0100 From: David Laight To: Kees Cook Cc: Takashi Iwai , Mahad Ibrahim , Takashi Iwai , Jaroslav Kysela , Andy Shevchenko , linux-sound@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 0/7] ALSA: remove remaining strlcat() users under sound/ Message-ID: <20260808140401.485a84de@pumpkin> In-Reply-To: <202608071442.37E40CEFC@keescook> References: <20260807114139.1661-1-mahad.ibrahim.dev@gmail.com> <87jyq2azz4.wl-tiwai@suse.de> <878q6hc3yp.wl-tiwai@suse.de> <202608071442.37E40CEFC@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 Fri, 7 Aug 2026 14:46:44 -0700 Kees Cook wrote: > On Fri, Aug 07, 2026 at 06:03:58PM +0200, Takashi Iwai wrote: > > If strlcat() were super-dangerous, it's understandable to drop. But, > > it's not, and issues discussed in the github are minor and something > > that can be addressed in strlcat() implementation; that is, can't we > > rather re-implement strlcat() in a safer way, instead of killing it? > > > > Sure, there are code calling strlcat() that could be optimized better. > > They can be cleaned up. But it alone can't be a reason that strlcat() > > must die without mercy. > > The risk comes from the compiler having no way to know what the size of > the destination buffer is, as the "char *" argument has no length > associated with it. One thing we can do is change the argument > requirements for strlcat (like we did when designing memtostr, etc), > that requires that the argument explicitly be an array (not a string > pointer), at which point bounds checking can be done. > > Usually this requires changing the plumbing of arguments, as a lot of C > code is used to just passing around a bare "char *", etc. And if that > re-plumbing is going to happen, it might as well be seq_buf. > > But yes, just replacing it with strlen/strscpy isn't very ergonomic. > Adding the length explicitly with strscpy certainly gets us the bounds > again, but it's _separate_ from the string still, and that will lead to > mistakes too. Better to have it be part of the type (i.e. either an > array or seq_buf). And, if the destination is an array (where the compiler knows the size) there is nothing wrong with a 2 argument function. Like strscpy() you want any result to be the new length of the destination string. Embedding a fixed length char[] in a struct can be a simple better option and lets the compiler do a lot of the checks for you. David > > -Kees >