linux-kernel - Re: [PATCH] target/core: replace 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 for Android: free password hash cracker in your pocket

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

Message-ID: <CAH4c4jJ+BjGyhapXbHqM5HBmSm1ZNzgsYWS-mNQjbc0XpMns4w@mail.gmail.com>
Date: Tue, 29 Jul 2025 14:47:27 +0530
From: Pranav Tyagi <pranav.tyagi03@...il.com>
To: "Martin K. Petersen" <martin.petersen@...cle.com>
Cc: linux-scsi@...r.kernel.org, target-devel@...r.kernel.org, 
	linux-kernel@...r.kernel.org, skhan@...uxfoundation.org, 
	linux-kernel-mentees@...ts.linux.dev
Subject: Re: [PATCH] target/core: replace strncpy with strscpy

On Tue, Jul 29, 2025 at 8:39 AM Martin K. Petersen
<martin.petersen@...cle.com> wrote:
>
>
> Hi Pranav!
>
> > As far as I looked, I could only find the following 4 instances of
> > strncpy() for the file target_core_transport.c:
> >
> > target_core_transport.c:1115:           strncpy(p_buf, buf, p_buf_len);
> > target_core_transport.c:1165:           strncpy(p_buf, buf, p_buf_len);
> > target_core_transport.c:1225:           strncpy(p_buf, buf, p_buf_len);
> > target_core_transport.c:1279:           strncpy(p_buf, buf, p_buf_len);
> >
> > And I have changed all of them in my patch. Kindly point me out to
> > other instances, if I am missing any.
>
> Sorry, I guess I didn't read far enough. I was focused on the VPD
> identifier dump function and whether it could overrun the static buffer.
>
> > Also, I intended this to be a cleanup patch for the deprecated
> > strncpy() function and wanted to replace it with strscpy() which is
> > encouraged. No functional changes were intended.
>
> In our experience cleanup patches come with a very high risk of
> introducing regressions. Regressions in the I/O stack could potentially
> lead to issues such as systems failing to boot or people losing their
> data. So we generally only merge patches if it can be demonstrated that
> they fix an actual problem.
>
> --
> Martin K. Petersen

Hi Martin,

I did not know about the risks involved with cleanup patches for the
I/O stack. I understand that this could lead to regressions and it is best
to drop this patch. Thank you for reviewing it.

Regards
Pranav Tyagi