Replace uses of snprintf() and vsnprintf() #105

alexdewar · 2020-08-24T19:54:22Z

The C99 version of snprintf() (and vsprintf()), as used in the kernel, has a surprising gotcha: it doesn't return the number of bytes written to the buffer, but, rather, the number of bytes that would have been written had there been enough space. This could lead to buffer overflows, if the return value is used wrongly. The kernel has long had safer alternatives -- scnprintf() and vscnprintf() -- which return the number of bytes actually written and these could be used instead. Here is an article on LWN (from 2004!) which describes the problem.

For sysfs attributes, the documentation specifies that snprintf() should not be used for the show() method, though there are many places in the kernel where it is. There is a semantic patch file at scripts/coccinelle/api/device_attr_show.cocci which checks for this case. Finding and fixing these cases might be a good starting point.

In general, more or less every instance of snprintf() should be replaceable with a call to scnprintf() or, where it is certain that the buffer cannot overflow, sprintf() could be used. Obviously these changes should be made carefully as we do not want to introduce bugs, but there are plenty of cases in the kernel where things like snprintf(buf, PAGE_SIZE, "%d\n", i) are done, where the use of snprintf() doesn't achieve anything beyond giving a false sense of security.

Replacing all calls to snprintf() would guarantee that its return value is not being misused anywhere.

The text was updated successfully, but these errors were encountered:

alexdewar · 2020-08-24T19:55:08Z

This is my first attempt at contributing here, so if this is a stupid idea, feel free to tell me so and close the issue 😄

kees · 2020-08-26T23:37:21Z

This is my first attempt at contributing here, so if this is a stupid idea, feel free to tell me so and close the issue

You're all good. I'd been meaning to open this bug, and you've described the issue nicely. Thank you!

evdenis · 2020-08-27T20:08:46Z

I've send an addition to the device_attr_show.cocci script to turn simple snprintf cases to sprintf.
https://lkml.org/lkml/2020/8/13/786
It was motivated primarily by Greg's response https://lkml.org/lkml/2020/6/21/64

However, as for myself, I don't like altering the original logic of bounded print with snprintf to unbounded one with sprintf.

alexdewar · 2020-09-07T11:18:20Z

Cool, that looks really handy!

I know what you mean about replacing bounded with unbounded string ops. I think the right solution is to have a helper for the special case of sysfs show methods that we just use everywhere and has the correct checks, like Joe Perches has suggested: https://lore.kernel.org/lkml/a9054fb521e65f2809671fa9c18e2453061e9d91.1598744610.git.joe@perches.com/

That nicely hides some of the implementation details and is cleaner than a naked sprintf call.

…sfs_emit() Since snprintf() has the documented, but still rather strange trait of returning the length of the data that *would have been* written to the array if space were available, rather than the arguably more useful length of data *actually* written, it is usually considered wise to use something else instead in order to avoid confusion. In the case of sysfs call-backs, new wrappers exist that do just that. This patch replaces the 2 uses of snprintf() found in the sysfs .show() call-backs with the new sysfs_emit() helpers. Whist we're at it, let's replace the sprintf()s as well. For no other reason than consistency. Link: https://lwn.net/Articles/69419/ Link: KSPP#105 Cc: Matthieu CASTET <castet.matthieu@free.fr> Cc: Stanislaw Gruszka <stf_xl@wp.pl> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Damien Bergamini <damien.bergamini@free.fr> Cc: linux-usb@vger.kernel.org Signed-off-by: Lee Jones <lee@kernel.org>

There is a general misunderstanding amongst engineers that {v}snprintf() returns the length of the data *actually* encoded into the destination array. However, as per the C99 standard {v}snprintf() really returns the length of the data that *would have been* written if there were enough space for it. This misunderstanding has led to buffer-overruns in the past. It's generally considered safer to use the {v}scnprintf() variants in their place (or even sprintf() in simple cases). So let's do that. The uses in this file all seem to assume that data *has been* written! Link: https://lwn.net/Articles/69419/ Link: KSPP#105 Cc: Pawel Laszczak <pawell@cadence.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: linux-usb@vger.kernel.org Signed-off-by: Lee Jones <lee@kernel.org>

There is a general misunderstanding amongst engineers that {v}snprintf() returns the length of the data *actually* encoded into the destination array. However, as per the C99 standard {v}snprintf() really returns the length of the data that *would have been* written if there were enough space for it. This misunderstanding has led to buffer-overruns in the past. It's generally considered safer to use the {v}scnprintf() variants in their place (or even sprintf() in simple cases). So let's do that. The uses in this file both seem to assume that data *has been* written! Link: https://lwn.net/Articles/69419/ Link: KSPP#105 Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Yuan-Hsin Chen <yhchen@faraday-tech.com> Cc: Feng-Hsin Chiang <john453@faraday-tech.com> Cc: Po-Yu Chuang <ratbert.chuang@gmail.com> Cc: linux-usb@vger.kernel.org Signed-off-by: Lee Jones <lee@kernel.org>

… sysfs_emit() Since snprintf() has the documented, but still rather strange trait of returning the length of the data that *would have been* written to the array if space were available, rather than the arguably more useful length of data *actually* written, it is usually considered wise to use something else instead in order to avoid confusion. In the case of sysfs call-backs, new wrappers exist that do just that. This patch replaces just one use of snprintf() found in the sysfs .show() call-back with the new sysfs_emit() helper. Link: https://lwn.net/Articles/69419/ Link: KSPP#105 Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: linux-usb@vger.kernel.org Signed-off-by: Lee Jones <lee@kernel.org>

…ce with sysfs_emit() Since snprintf() has the documented, but still rather strange trait of returning the length of the data that *would have been* written to the array if space were available, rather than the arguably more useful length of data *actually* written, it is usually considered wise to use something else instead in order to avoid confusion. In the case of sysfs call-backs, new wrappers exist that do just that. This patch replaces just one use of snprintf() found in the sysfs .show() call-back with the new sysfs_emit() helper. Link: https://lwn.net/Articles/69419/ Link: KSPP#105 Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: "Martin K. Petersen" <martin.petersen@oracle.com> Cc: Dmitry Bogdanov <d.bogdanov@yadro.com> Cc: linux-usb@vger.kernel.org Signed-off-by: Lee Jones <lee@kernel.org>

…sfs_emit() Since snprintf() has the documented, but still rather strange trait of returning the length of the data that *would have been* written to the array if space were available, rather than the arguably more useful length of data *actually* written, it is usually considered wise to use something else instead in order to avoid confusion. In the case of sysfs call-backs, new wrappers exist that do just that. This patch replaces the 2 uses of snprintf() found in the sysfs .show() call-backs with the new sysfs_emit() helpers. Whist we're at it, let's replace the sprintf()s as well. For no other reason than consistency. Link: https://lwn.net/Articles/69419/ Link: KSPP#105 Cc: Matthieu CASTET <castet.matthieu@free.fr> Cc: Stanislaw Gruszka <stf_xl@wp.pl> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Damien Bergamini <damien.bergamini@free.fr> Cc: linux-usb@vger.kernel.org Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20231130105459.3208986-2-lee@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

There is a general misunderstanding amongst engineers that {v}snprintf() returns the length of the data *actually* encoded into the destination array. However, as per the C99 standard {v}snprintf() really returns the length of the data that *would have been* written if there were enough space for it. This misunderstanding has led to buffer-overruns in the past. It's generally considered safer to use the {v}scnprintf() variants in their place (or even sprintf() in simple cases). So let's do that. The uses in this file all seem to assume that data *has been* written! Link: https://lwn.net/Articles/69419/ Link: KSPP#105 Cc: Pawel Laszczak <pawell@cadence.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: linux-usb@vger.kernel.org Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20231130105459.3208986-3-lee@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

There is a general misunderstanding amongst engineers that {v}snprintf() returns the length of the data *actually* encoded into the destination array. However, as per the C99 standard {v}snprintf() really returns the length of the data that *would have been* written if there were enough space for it. This misunderstanding has led to buffer-overruns in the past. It's generally considered safer to use the {v}scnprintf() variants in their place (or even sprintf() in simple cases). So let's do that. The uses in this file both seem to assume that data *has been* written! Link: https://lwn.net/Articles/69419/ Link: KSPP#105 Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Yuan-Hsin Chen <yhchen@faraday-tech.com> Cc: Feng-Hsin Chiang <john453@faraday-tech.com> Cc: Po-Yu Chuang <ratbert.chuang@gmail.com> Cc: linux-usb@vger.kernel.org Signed-off-by: Lee Jones <lee@kernel.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20231130105459.3208986-4-lee@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

… sysfs_emit() Since snprintf() has the documented, but still rather strange trait of returning the length of the data that *would have been* written to the array if space were available, rather than the arguably more useful length of data *actually* written, it is usually considered wise to use something else instead in order to avoid confusion. In the case of sysfs call-backs, new wrappers exist that do just that. This patch replaces just one use of snprintf() found in the sysfs .show() call-back with the new sysfs_emit() helper. Link: https://lwn.net/Articles/69419/ Link: KSPP#105 Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: linux-usb@vger.kernel.org Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20231130105459.3208986-5-lee@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

…ce with sysfs_emit() Since snprintf() has the documented, but still rather strange trait of returning the length of the data that *would have been* written to the array if space were available, rather than the arguably more useful length of data *actually* written, it is usually considered wise to use something else instead in order to avoid confusion. In the case of sysfs call-backs, new wrappers exist that do just that. This patch replaces just one use of snprintf() found in the sysfs .show() call-back with the new sysfs_emit() helper. Link: https://lwn.net/Articles/69419/ Link: KSPP#105 Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: "Martin K. Petersen" <martin.petersen@oracle.com> Cc: Dmitry Bogdanov <d.bogdanov@yadro.com> Cc: linux-usb@vger.kernel.org Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20231130105459.3208986-6-lee@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

…variant There is a general misunderstanding amongst engineers that {v}snprintf() returns the length of the data *actually* encoded into the destination array. However, as per the C99 standard {v}snprintf() really returns the length of the data that *would have been* written if there were enough space for it. This misunderstanding has led to buffer-overruns in the past. It's generally considered safer to use the {v}scnprintf() variants in their place (or even sprintf() in simple cases). So let's do that. Link: https://lwn.net/Articles/69419/ Link: KSPP#105 Signed-off-by: Lee Jones <lee@kernel.org>

…riant There is a general misunderstanding amongst engineers that {v}snprintf() returns the length of the data *actually* encoded into the destination array. However, as per the C99 standard {v}snprintf() really returns the length of the data that *would have been* written if there were enough space for it. This misunderstanding has led to buffer-overruns in the past. It's generally considered safer to use the {v}scnprintf() variants in their place (or even sprintf() in simple cases). So let's do that. Link: https://lwn.net/Articles/69419/ Link: KSPP#105 Cc: Ruslan Bilovol <ruslan.bilovol@gmail.com> Cc: Julian Scheel <julian@jusst.de> Cc: Bryan Wu <cooloney@kernel.org> Signed-off-by: Lee Jones <lee@kernel.org>

…riant There is a general misunderstanding amongst engineers that {v}snprintf() returns the length of the data *actually* encoded into the destination array. However, as per the C99 standard {v}snprintf() really returns the length of the data that *would have been* written if there were enough space for it. This misunderstanding has led to buffer-overruns in the past. It's generally considered safer to use the {v}scnprintf() variants in their place (or even sprintf() in simple cases). So let's do that. Link: https://lwn.net/Articles/69419/ Link: KSPP#105 Cc: James Gruber <jimmyjgruber@gmail.com> Cc: Yadwinder Singh <yadi.brar01@gmail.com> Cc: Jaswinder Singh <jaswinder.singh@linaro.org> Cc: Ruslan Bilovol <ruslan.bilovol@gmail.com> Signed-off-by: Lee Jones <lee@kernel.org>

There is a general misunderstanding amongst engineers that {v}snprintf() returns the length of the data *actually* encoded into the destination array. However, as per the C99 standard {v}snprintf() really returns the length of the data that *would have been* written if there were enough space for it. This misunderstanding has led to buffer-overruns in the past. It's generally considered safer to use the {v}scnprintf() variants in their place (or even sprintf() in simple cases). So let's do that. Link: https://lwn.net/Articles/69419/ Link: KSPP#105 Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Daniel Scally <dan.scally@ideasonboard.com> Cc: Andrzej Pietrasiewicz <andrzejtp2010@gmail.com> Signed-off-by: Lee Jones <lee@kernel.org>

…) variant There is a general misunderstanding amongst engineers that {v}snprintf() returns the length of the data *actually* encoded into the destination array. However, as per the C99 standard {v}snprintf() really returns the length of the data that *would have been* written if there were enough space for it. This misunderstanding has led to buffer-overruns in the past. It's generally considered safer to use the {v}scnprintf() variants in their place (or even sprintf() in simple cases). So let's do that. Link: https://lwn.net/Articles/69419/ Link: KSPP#105 Cc: Cristian Birsan <cristian.birsan@microchip.com> Cc: Nicolas Ferre <nicolas.ferre@microchip.com> Cc: Alexandre Belloni <alexandre.belloni@bootlin.com> Cc: Claudiu Beznea <claudiu.beznea@tuxon.dev> Cc: linux-arm-kernel@lists.infradead.org Signed-off-by: Lee Jones <lee@kernel.org>

There is a general misunderstanding amongst engineers that {v}snprintf() returns the length of the data *actually* encoded into the destination array. However, as per the C99 standard {v}snprintf() really returns the length of the data that *would have been* written if there were enough space for it. This misunderstanding has led to buffer-overruns in the past. It's generally considered safer to use the {v}scnprintf() variants in their place (or even sprintf() in simple cases). So let's do that. Link: https://lwn.net/Articles/69419/ Link: KSPP#105 Cc: Pawel Laszczak <pawell@cadence.com> Signed-off-by: Lee Jones <lee@kernel.org>

… variant There is a general misunderstanding amongst engineers that {v}snprintf() returns the length of the data *actually* encoded into the destination array. However, as per the C99 standard {v}snprintf() really returns the length of the data that *would have been* written if there were enough space for it. This misunderstanding has led to buffer-overruns in the past. It's generally considered safer to use the {v}scnprintf() variants in their place (or even sprintf() in simple cases). So let's do that. Link: https://lwn.net/Articles/69419/ Link: KSPP#105 Cc: Cristian Birsan <cristian.birsan@microchip.com> Cc: Nicolas Ferre <nicolas.ferre@microchip.com> Cc: Alexandre Belloni <alexandre.belloni@bootlin.com> Cc: Claudiu Beznea <claudiu.beznea@tuxon.dev> Cc: linux-arm-kernel@lists.infradead.org Signed-off-by: Lee Jones <lee@kernel.org>

There is a general misunderstanding amongst engineers that {v}snprintf() returns the length of the data *actually* encoded into the destination array. However, as per the C99 standard {v}snprintf() really returns the length of the data that *would have been* written if there were enough space for it. This misunderstanding has led to buffer-overruns in the past. It's generally considered safer to use the {v}scnprintf() variants in their place (or even sprintf() in simple cases). So let's do that. Whilst we're at it, let's define some magic numbers to increase readability and ease of maintenance. Link: https://lwn.net/Articles/69419/ Link: KSPP#105 Cc: Tomoki Sekiyama <tomoki.sekiyama@gmail.com> Signed-off-by: Lee Jones <lee@kernel.org>

There is a general misunderstanding amongst engineers that {v}snprintf() returns the length of the data *actually* encoded into the destination array. However, as per the C99 standard {v}snprintf() really returns the length of the data that *would have been* written if there were enough space for it. This misunderstanding has led to buffer-overruns in the past. It's generally considered safer to use the {v}scnprintf() variants in their place (or even sprintf() in simple cases). So let's do that. Link: https://lwn.net/Articles/69419/ Link: KSPP#105 Signed-off-by: Lee Jones <lee@kernel.org>

…e with sysfs_emit() Since snprintf() has the documented, but still rather strange trait of returning the length of the data that *would have been* written to the array if space were available, rather than the arguably more useful length of data *actually* written, it is usually considered wise to use something else instead in order to avoid confusion. In the case of sysfs call-backs, new wrappers exist that do just that. Link: https://lwn.net/Articles/69419/ Link: KSPP#105 Cc: Hema HK <hemahk@ti.com> Signed-off-by: Lee Jones <lee@kernel.org>

…h sysfs_emit() Since snprintf() has the documented, but still rather strange trait of returning the length of the data that *would have been* written to the array if space were available, rather than the arguably more useful length of data *actually* written, it is usually considered wise to use something else instead in order to avoid confusion. In the case of sysfs call-backs, new wrappers exist that do just that. Link: https://lwn.net/Articles/69419/ Link: KSPP#105 Cc: Alan Stern <stern@rowland.harvard.edu> Cc: usb-storage@lists.one-eyed-alien.net Signed-off-by: Lee Jones <lee@kernel.org>

…variant There is a general misunderstanding amongst engineers that {v}snprintf() returns the length of the data *actually* encoded into the destination array. However, as per the C99 standard {v}snprintf() really returns the length of the data that *would have been* written if there were enough space for it. This misunderstanding has led to buffer-overruns in the past. It's generally considered safer to use the {v}scnprintf() variants in their place (or even sprintf() in simple cases). So let's do that. Link: https://lwn.net/Articles/69419/ Link: KSPP#105 Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20231213164246.1021885-2-lee@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

…riant There is a general misunderstanding amongst engineers that {v}snprintf() returns the length of the data *actually* encoded into the destination array. However, as per the C99 standard {v}snprintf() really returns the length of the data that *would have been* written if there were enough space for it. This misunderstanding has led to buffer-overruns in the past. It's generally considered safer to use the {v}scnprintf() variants in their place (or even sprintf() in simple cases). So let's do that. Link: https://lwn.net/Articles/69419/ Link: KSPP#105 Cc: Ruslan Bilovol <ruslan.bilovol@gmail.com> Cc: Julian Scheel <julian@jusst.de> Cc: Bryan Wu <cooloney@kernel.org> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20231213164246.1021885-3-lee@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

[ Upstream commit 86b20af11e84c26ae3fde4dcc4f490948e3f8035 ] There is a general misunderstanding amongst engineers that {v}snprintf() returns the length of the data *actually* encoded into the destination array. However, as per the C99 standard {v}snprintf() really returns the length of the data that *would have been* written if there were enough space for it. This misunderstanding has led to buffer-overruns in the past. It's generally considered safer to use the {v}scnprintf() variants in their place (or even sprintf() in simple cases). So let's do that. Whilst we're at it, let's define some magic numbers to increase readability and ease of maintenance. Link: https://lwn.net/Articles/69419/ Link: KSPP/linux#105 Cc: Tomoki Sekiyama <tomoki.sekiyama@gmail.com> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20231213164246.1021885-9-lee@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Stable-dep-of: 93907620b308 ("USB: misc: yurex: fix race between read and write") Signed-off-by: Sasha Levin <sashal@kernel.org>

[ Upstream commit 86b20af11e84c26ae3fde4dcc4f490948e3f8035 ] There is a general misunderstanding amongst engineers that {v}snprintf() returns the length of the data *actually* encoded into the destination array. However, as per the C99 standard {v}snprintf() really returns the length of the data that *would have been* written if there were enough space for it. This misunderstanding has led to buffer-overruns in the past. It's generally considered safer to use the {v}scnprintf() variants in their place (or even sprintf() in simple cases). So let's do that. Whilst we're at it, let's define some magic numbers to increase readability and ease of maintenance. Link: https://lwn.net/Articles/69419/ Link: KSPP/linux#105 Cc: Tomoki Sekiyama <tomoki.sekiyama@gmail.com> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20231213164246.1021885-9-lee@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Stable-dep-of: 93907620b308 ("USB: misc: yurex: fix race between read and write") Signed-off-by: Sasha Levin <sashal@kernel.org> (cherry picked from commit a2ac6cb8aaa2eb23209ffa641962dd62958522a1) Signed-off-by: Siva Balasubramanian <sivakumar.bs@gmail.com>

[ Upstream commit 86b20af11e84c26ae3fde4dcc4f490948e3f8035 ] There is a general misunderstanding amongst engineers that {v}snprintf() returns the length of the data *actually* encoded into the destination array. However, as per the C99 standard {v}snprintf() really returns the length of the data that *would have been* written if there were enough space for it. This misunderstanding has led to buffer-overruns in the past. It's generally considered safer to use the {v}scnprintf() variants in their place (or even sprintf() in simple cases). So let's do that. Whilst we're at it, let's define some magic numbers to increase readability and ease of maintenance. Link: https://lwn.net/Articles/69419/ Link: KSPP/linux#105 Cc: Tomoki Sekiyama <tomoki.sekiyama@gmail.com> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20231213164246.1021885-9-lee@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Stable-dep-of: 93907620b308 ("USB: misc: yurex: fix race between read and write") Signed-off-by: Sasha Levin <sashal@kernel.org>

[ Upstream commit 86b20af11e84c26ae3fde4dcc4f490948e3f8035 ] There is a general misunderstanding amongst engineers that {v}snprintf() returns the length of the data *actually* encoded into the destination array. However, as per the C99 standard {v}snprintf() really returns the length of the data that *would have been* written if there were enough space for it. This misunderstanding has led to buffer-overruns in the past. It's generally considered safer to use the {v}scnprintf() variants in their place (or even sprintf() in simple cases). So let's do that. Whilst we're at it, let's define some magic numbers to increase readability and ease of maintenance. Link: https://lwn.net/Articles/69419/ Link: KSPP/linux#105 Cc: Tomoki Sekiyama <tomoki.sekiyama@gmail.com> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20231213164246.1021885-9-lee@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Stable-dep-of: 93907620b308 ("USB: misc: yurex: fix race between read and write") Signed-off-by: Sasha Levin <sashal@kernel.org> (cherry picked from commit a2ac6cb8aaa2eb23209ffa641962dd62958522a1) Signed-off-by: Siva Balasubramanian <sivakumar.bs@gmail.com>

[ Upstream commit 86b20af11e84c26ae3fde4dcc4f490948e3f8035 ] There is a general misunderstanding amongst engineers that {v}snprintf() returns the length of the data *actually* encoded into the destination array. However, as per the C99 standard {v}snprintf() really returns the length of the data that *would have been* written if there were enough space for it. This misunderstanding has led to buffer-overruns in the past. It's generally considered safer to use the {v}scnprintf() variants in their place (or even sprintf() in simple cases). So let's do that. Whilst we're at it, let's define some magic numbers to increase readability and ease of maintenance. Link: https://lwn.net/Articles/69419/ Link: KSPP/linux#105 Cc: Tomoki Sekiyama <tomoki.sekiyama@gmail.com> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20231213164246.1021885-9-lee@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Stable-dep-of: 93907620b308 ("USB: misc: yurex: fix race between read and write") Signed-off-by: Sasha Levin <sashal@kernel.org>

[ Upstream commit 86b20af11e84c26ae3fde4dcc4f490948e3f8035 ] There is a general misunderstanding amongst engineers that {v}snprintf() returns the length of the data *actually* encoded into the destination array. However, as per the C99 standard {v}snprintf() really returns the length of the data that *would have been* written if there were enough space for it. This misunderstanding has led to buffer-overruns in the past. It's generally considered safer to use the {v}scnprintf() variants in their place (or even sprintf() in simple cases). So let's do that. Whilst we're at it, let's define some magic numbers to increase readability and ease of maintenance. Link: https://lwn.net/Articles/69419/ Link: KSPP/linux#105 Cc: Tomoki Sekiyama <tomoki.sekiyama@gmail.com> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20231213164246.1021885-9-lee@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Stable-dep-of: 93907620b308 ("USB: misc: yurex: fix race between read and write") Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Edwiin Kusuma Jaya <kutemeikito0905@gmail.com>

[ Upstream commit 86b20af11e84c26ae3fde4dcc4f490948e3f8035 ] There is a general misunderstanding amongst engineers that {v}snprintf() returns the length of the data *actually* encoded into the destination array. However, as per the C99 standard {v}snprintf() really returns the length of the data that *would have been* written if there were enough space for it. This misunderstanding has led to buffer-overruns in the past. It's generally considered safer to use the {v}scnprintf() variants in their place (or even sprintf() in simple cases). So let's do that. Whilst we're at it, let's define some magic numbers to increase readability and ease of maintenance. Link: https://lwn.net/Articles/69419/ Link: KSPP/linux#105 Cc: Tomoki Sekiyama <tomoki.sekiyama@gmail.com> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20231213164246.1021885-9-lee@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Stable-dep-of: 93907620b308 ("USB: misc: yurex: fix race between read and write") Signed-off-by: Sasha Levin <sashal@kernel.org>

[ Upstream commit 86b20af11e84c26ae3fde4dcc4f490948e3f8035 ] There is a general misunderstanding amongst engineers that {v}snprintf() returns the length of the data *actually* encoded into the destination array. However, as per the C99 standard {v}snprintf() really returns the length of the data that *would have been* written if there were enough space for it. This misunderstanding has led to buffer-overruns in the past. It's generally considered safer to use the {v}scnprintf() variants in their place (or even sprintf() in simple cases). So let's do that. Whilst we're at it, let's define some magic numbers to increase readability and ease of maintenance. Link: https://lwn.net/Articles/69419/ Link: KSPP/linux#105 Cc: Tomoki Sekiyama <tomoki.sekiyama@gmail.com> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20231213164246.1021885-9-lee@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Stable-dep-of: 93907620b308 ("USB: misc: yurex: fix race between read and write") Signed-off-by: Sasha Levin <sashal@kernel.org> (cherry picked from commit a2ac6cb8aaa2eb23209ffa641962dd62958522a1) Signed-off-by: Vegard Nossum <vegard.nossum@oracle.com> Signed-off-by: Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com>

[ Upstream commit 86b20af11e84c26ae3fde4dcc4f490948e3f8035 ] There is a general misunderstanding amongst engineers that {v}snprintf() returns the length of the data *actually* encoded into the destination array. However, as per the C99 standard {v}snprintf() really returns the length of the data that *would have been* written if there were enough space for it. This misunderstanding has led to buffer-overruns in the past. It's generally considered safer to use the {v}scnprintf() variants in their place (or even sprintf() in simple cases). So let's do that. Whilst we're at it, let's define some magic numbers to increase readability and ease of maintenance. Link: https://lwn.net/Articles/69419/ Link: KSPP/linux#105 Cc: Tomoki Sekiyama <tomoki.sekiyama@gmail.com> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20231213164246.1021885-9-lee@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Stable-dep-of: 93907620b308 ("USB: misc: yurex: fix race between read and write") Signed-off-by: Sasha Levin <sashal@kernel.org>

[ Upstream commit 86b20af11e84c26ae3fde4dcc4f490948e3f8035 ] There is a general misunderstanding amongst engineers that {v}snprintf() returns the length of the data *actually* encoded into the destination array. However, as per the C99 standard {v}snprintf() really returns the length of the data that *would have been* written if there were enough space for it. This misunderstanding has led to buffer-overruns in the past. It's generally considered safer to use the {v}scnprintf() variants in their place (or even sprintf() in simple cases). So let's do that. Whilst we're at it, let's define some magic numbers to increase readability and ease of maintenance. Link: https://lwn.net/Articles/69419/ Link: KSPP/linux#105 Cc: Tomoki Sekiyama <tomoki.sekiyama@gmail.com> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20231213164246.1021885-9-lee@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Stable-dep-of: 93907620b308 ("USB: misc: yurex: fix race between read and write") Signed-off-by: Sasha Levin <sashal@kernel.org> (cherry picked from commit a2ac6cb8aaa2eb23209ffa641962dd62958522a1) Signed-off-by: Vegard Nossum <vegard.nossum@oracle.com> Signed-off-by: Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com>

strncpy() is deprecated for NUL-terminated destination buffers; use strscpy() instead. The destination buffer db_root is only used with "%s" format strings and must therefore be NUL-terminated, but not NUL-padded. Use scnprintf() because snprintf() could return a value >= DB_ROOT_LEN and lead to an out-of-bounds access. This doesn't happen because count is explicitly checked against DB_ROOT_LEN before. However, scnprintf() always returns the number of characters actually written to the string buffer, which is always within the bounds of db_root_stage, and should be preferred over snprintf(). The size parameter of strscpy() is optional and since DB_ROOT_LEN is the size of the destination buffer, it can be removed. Remove it to simplify the code. Compile-tested only. Link: KSPP#90 Link: KSPP#105 Cc: linux-hardening@vger.kernel.org Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>

strncpy() is deprecated for NUL-terminated destination buffers; use strscpy() instead. The destination buffer db_root is only used with "%s" format strings and must therefore be NUL-terminated, but not NUL-padded. Use scnprintf() because snprintf() could return a value >= DB_ROOT_LEN and lead to an out-of-bounds access. This doesn't happen because count is explicitly checked against DB_ROOT_LEN before. However, scnprintf() always returns the number of characters actually written to the string buffer, which is always within the bounds of db_root_stage, and should be preferred over snprintf(). The size parameter of strscpy() is optional and since DB_ROOT_LEN is the size of the destination buffer, it can be removed. Remove it to simplify the code. Compile-tested only. Link: KSPP#90 Link: KSPP#105 Cc: linux-hardening@vger.kernel.org Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev> Link: https://lore.kernel.org/r/20250302225641.245127-2-thorsten.blum@linux.dev Reviewed-by: Kees Cook <kees@kernel.org> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>

kees added [Refactor] sprintf Refactor sprintf uses good first issue Good for newcomers labels Apr 7, 2022

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Replace uses of snprintf() and vsnprintf() #105

Replace uses of snprintf() and vsnprintf() #105

alexdewar commented Aug 24, 2020 •

edited by GustavoARSilva

Loading

alexdewar commented Aug 24, 2020

kees commented Aug 26, 2020

evdenis commented Aug 27, 2020

alexdewar commented Sep 7, 2020

Replace uses of snprintf() and vsnprintf() #105

Replace uses of snprintf() and vsnprintf() #105

Comments

alexdewar commented Aug 24, 2020 • edited by GustavoARSilva Loading

alexdewar commented Aug 24, 2020

kees commented Aug 26, 2020

evdenis commented Aug 27, 2020

alexdewar commented Sep 7, 2020

alexdewar commented Aug 24, 2020 •

edited by GustavoARSilva

Loading