linux-kernel - Re: [PATCH] scsi: hpsa: Replace deprecated strncpy() with strscpy()

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <51c6b704-7dd0-4d2c-acae-8ba427d57070@acm.org>
Date: Thu, 13 Feb 2025 09:34:38 -0800
From: Bart Van Assche <bvanassche@....org>
To: Thorsten Blum <thorsten.blum@...ux.dev>,
 Don Brace <don.brace@...rochip.com>,
 "James E.J. Bottomley" <James.Bottomley@...senPartnership.com>,
 "Martin K. Petersen" <martin.petersen@...cle.com>
Cc: linux-hardening@...r.kernel.org, storagedev@...rochip.com,
 linux-scsi@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] scsi: hpsa: Replace deprecated strncpy() with strscpy()

On 2/13/25 3:24 AM, Thorsten Blum wrote:
> This subtle difference between strncpy() and strscpy() regarding the
> number of bytes copied isn't really documented anywhere, is it? The
> documentation I came across so far seems to focus mostly on the
> different return values of the two functions.

 From the description of commit 9022ed0e7e65 ("strscpy: write destination
buffer only once"):

     So strscpy not only guarantees NUL-termination (unlike strncpy), it 
also
     doesn't do unnecessary padding at the destination.  But at the same 
time
     also avoids byte-at-a-time reads and writes by _allowing_ some 
extra NUL
     writes - within the size, of course - so that the whole copy can be 
done
     with word operations.

     It is also stable in the face of a mutable source string: it explicitly
     does not read the source buffer multiple times (so an implementation
     using "strnlen()+memcpy()" would be wrong), and does not read the 
source
     buffer past the size (like the mis-design that is strlcpy does).

     Finally, the return value is designed to be simple and unambiguous: if
     the string cannot be copied fully, it returns an actual negative error,
     making error handling clearer and simpler (and the caller already knows
     the size of the buffer).  Otherwise it returns the string length of the
     result.

More information is available in the description of commit 30c44659f4a3
("Merge branch 'strscpy' of 
git://git.kernel.org/pub/scm/linux/kernel/git/cmetcalf/linux-tile").

Thanks,

Bart.