linux-kernel - [PATCH v3] Updating a deprecated use of strcpy.

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-next>] [day] [month] [year] [list]

Message-Id: <20240703084124.11530-1-qasim.majeed20@gmail.com>
Date: Wed,  3 Jul 2024 13:41:25 +0500
From: Muhammad Qasim Abdul Majeed <qasim.majeed20@...il.com>
To: rafael@...nel.org,
	lenb@...nel.org,
	linux-acpi@...r.kernel.org,
	linux-kernel@...r.kernel.org
Cc: Muhammad Qasim Abdul Majeed <qasim.majeed20@...il.com>
Subject: [PATCH v3] Updating a deprecated use of strcpy.

Replacing strcpy with strscpy.
strcpy is a deprecated function.
It should be removed from the kernel source.

Link: https://github.com/KSPP/linux/issues/88

Signed-off-by: Muhammad Qasim Abdul Majeed <qasim.majeed20@...il.com>

> Replacing strcpy with strscpy and memory bound the copy.

> Why?  In this particular case, it is not fundamentally necessary.

> strcpy is a deprecated function. It should be removed from the kernel source.

> If the goal is to get rid of all strcpy() calls from the kernel
> because using it is generally unsafe, just say so in the changelog and
> it will be fine.
changelog has been updated.

> So is it necessary to use the size argument here and below?
Size argument is not necessary as destination is an array of 40 bytes. Patch has been updated.

> for that to work, shouldn't the size of the *destination* buffer be
> passed, instead of the length of the string we want to copy?
Yes, size of the destination should be passed.

> Not tested, but the 3rd argument of strscpy () is optional.
> (https://elixir.bootlin.com/linux/v6.10-rc6/source/include/linux/string.h#L87),
> so maybe just:

>        strscpy(acpi_device_name(device), ACPI_VIDEO_DEVICE_NAME);
Thank you for sharing the reference, this suggestion will do the work and accomodated in the patch.

---
	v2 -> v3: Changelog has been updated. size argument has been removed.

 drivers/acpi/acpi_video.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/acpi/acpi_video.c b/drivers/acpi/acpi_video.c
index 1fda30388297..8274a17872ed 100644
--- a/drivers/acpi/acpi_video.c
+++ b/drivers/acpi/acpi_video.c
@@ -1128,8 +1128,8 @@ static int acpi_video_bus_get_one_device(struct acpi_device *device, void *arg)
 		return -ENOMEM;
 	}
 
-	strcpy(acpi_device_name(device), ACPI_VIDEO_DEVICE_NAME);
-	strcpy(acpi_device_class(device), ACPI_VIDEO_CLASS);
+	strscpy(acpi_device_name(device), ACPI_VIDEO_DEVICE_NAME);
+	strscpy(acpi_device_class(device), ACPI_VIDEO_CLASS);
 
 	data->device_id = device_id;
 	data->video = video;
@@ -2010,8 +2010,8 @@ static int acpi_video_bus_add(struct acpi_device *device)
 	}
 
 	video->device = device;
-	strcpy(acpi_device_name(device), ACPI_VIDEO_BUS_NAME);
-	strcpy(acpi_device_class(device), ACPI_VIDEO_CLASS);
+	strscpy(acpi_device_name(device), ACPI_VIDEO_BUS_NAME);
+	strscpy(acpi_device_class(device), ACPI_VIDEO_CLASS);
 	device->driver_data = video;
 
 	acpi_video_bus_find_cap(video);
-- 
2.34.1