| Message ID | 20221007132931.123755-2-acherniakov@astralinux.ru (mailing list archive) |
|---|---|
| State | Not Applicable |
| Headers | show |
| Series | rpmsg: qcom: glink: replace strncpy() with strscpy_pad() | expand |
On Fri, Oct 07, 2022 at 04:29:31PM +0300, Andrew Chernyakov wrote: > From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> > > commit 766279a8f85df32345dbda03b102ca1ee3d5ddea upstream. > > The use of strncpy() is considered deprecated for NUL-terminated > strings[1]. Replace strncpy() with strscpy_pad(), to keep existing > pad-behavior of strncpy, similarly to commit 08de420a8014 ("rpmsg: > glink: Replace strncpy() with strscpy_pad()"). This fixes W=1 warning: > > In function ‘qcom_glink_rx_close’, > inlined from ‘qcom_glink_work’ at ../drivers/rpmsg/qcom_glink_native.c:1638:4: > drivers/rpmsg/qcom_glink_native.c:1549:17: warning: ‘strncpy’ specified bound 32 equals destination size [-Wstringop-truncation] > 1549 | strncpy(chinfo.name, channel->name, sizeof(chinfo.name)); > > [1] https://www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings > > Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> > Reviewed-by: Stephen Boyd <sboyd@kernel.org> > Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> > Link: https://lore.kernel.org/r/20220519073330.7187-1-krzysztof.kozlowski@linaro.org > Signed-off-by: Andrew Chernyakov <acherniakov@astralinux.ru> > --- > drivers/rpmsg/qcom_glink_native.c | 2 +- > drivers/rpmsg/qcom_smd.c | 4 ++-- > 2 files changed, 3 insertions(+), 3 deletions(-) Why just this specific kernel branch? We can't add patches to an older tree and have someone upgrade to a newer one and hit the same issue. So please provide backports for all active versions. In this case that would be 5.15.y and 5.19.y. thanks, greg k-h
From: Greg Kroah-Hartman > Sent: 07 October 2022 17:40 > > On Fri, Oct 07, 2022 at 04:29:31PM +0300, Andrew Chernyakov wrote: > > From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> > > > > commit 766279a8f85df32345dbda03b102ca1ee3d5ddea upstream. > > > > The use of strncpy() is considered deprecated for NUL-terminated > > strings[1]. Replace strncpy() with strscpy_pad(), to keep existing > > pad-behavior of strncpy, similarly to commit 08de420a8014 ("rpmsg: > > glink: Replace strncpy() with strscpy_pad()"). This fixes W=1 warning: > > > > In function ‘qcom_glink_rx_close’, > > inlined from ‘qcom_glink_work’ at ../drivers/rpmsg/qcom_glink_native.c:1638:4: > > drivers/rpmsg/qcom_glink_native.c:1549:17: warning: ‘strncpy’ specified bound 32 equals > destination size [-Wstringop-truncation] > > 1549 | strncpy(chinfo.name, channel->name, sizeof(chinfo.name)); > > > > [1] https://www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings > > > > Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> > > Reviewed-by: Stephen Boyd <sboyd@kernel.org> > > Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> > > Link: https://lore.kernel.org/r/20220519073330.7187-1-krzysztof.kozlowski@linaro.org > > Signed-off-by: Andrew Chernyakov <acherniakov@astralinux.ru> > > --- > > drivers/rpmsg/qcom_glink_native.c | 2 +- > > drivers/rpmsg/qcom_smd.c | 4 ++-- > > 2 files changed, 3 insertions(+), 3 deletions(-) > > Why just this specific kernel branch? We can't add patches to an older > tree and have someone upgrade to a newer one and hit the same issue. > > So please provide backports for all active versions. In this case that > would be 5.15.y and 5.19.y. If it is only fixing a compile warning is it even stable material? The generic commit message doesn't say whether the old code was actually right or wrong. At least one of these 'replace strncpy()' changes was definitely broken (the copy needed to be equivalent to memcpy()). So applying ANY of them to stable unless they actually fix a real bug seems dubious. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)
On 08/10/2022 23:11, David Laight wrote: >>> --- >>> drivers/rpmsg/qcom_glink_native.c | 2 +- >>> drivers/rpmsg/qcom_smd.c | 4 ++-- >>> 2 files changed, 3 insertions(+), 3 deletions(-) >> >> Why just this specific kernel branch? We can't add patches to an older >> tree and have someone upgrade to a newer one and hit the same issue. >> >> So please provide backports for all active versions. In this case that >> would be 5.15.y and 5.19.y. > > If it is only fixing a compile warning is it even stable material? > The generic commit message doesn't say whether the old code was > actually right or wrong. > > At least one of these 'replace strncpy()' changes was definitely > broken (the copy needed to be equivalent to memcpy()). > > So applying ANY of them to stable unless they actually fix > a real bug seems dubious. Except the warning from GCC, there was no bug to fix. The warning is about discouraged and risky practice, but no actual real risk was identified, so for me it matches stable rules poorly. It's basically backporting to silence automated code checkers... Best regards, Krzysztof
On Sun, Oct 09, 2022 at 05:23:06PM +0200, Krzysztof Kozlowski wrote: > On 08/10/2022 23:11, David Laight wrote: > >>> --- > >>> drivers/rpmsg/qcom_glink_native.c | 2 +- > >>> drivers/rpmsg/qcom_smd.c | 4 ++-- > >>> 2 files changed, 3 insertions(+), 3 deletions(-) > >> > >> Why just this specific kernel branch? We can't add patches to an older > >> tree and have someone upgrade to a newer one and hit the same issue. > >> > >> So please provide backports for all active versions. In this case that > >> would be 5.15.y and 5.19.y. > > > > If it is only fixing a compile warning is it even stable material? > > The generic commit message doesn't say whether the old code was > > actually right or wrong. > > > > At least one of these 'replace strncpy()' changes was definitely > > broken (the copy needed to be equivalent to memcpy()). > > > > So applying ANY of them to stable unless they actually fix > > a real bug seems dubious. > > Except the warning from GCC, there was no bug to fix. The warning is > about discouraged and risky practice, but no actual real risk was > identified, so for me it matches stable rules poorly. > > It's basically backporting to silence automated code checkers... Are you sure? Look at the code path here, there might be a way to overflow the string, from the virtio interface, but I might be wrong... Anyway, I need all the backports before I can take this one, sorry. greg k-h
diff --git a/drivers/rpmsg/qcom_glink_native.c b/drivers/rpmsg/qcom_glink_native.c index 4840886532ff..7cbed0310c09 100644 --- a/drivers/rpmsg/qcom_glink_native.c +++ b/drivers/rpmsg/qcom_glink_native.c @@ -1472,7 +1472,7 @@ static void qcom_glink_rx_close(struct qcom_glink *glink, unsigned int rcid) cancel_work_sync(&channel->intent_work); if (channel->rpdev) { - strncpy(chinfo.name, channel->name, sizeof(chinfo.name)); + strscpy_pad(chinfo.name, channel->name, sizeof(chinfo.name)); chinfo.src = RPMSG_ADDR_ANY; chinfo.dst = RPMSG_ADDR_ANY; diff --git a/drivers/rpmsg/qcom_smd.c b/drivers/rpmsg/qcom_smd.c index 0b1e853d8c91..b5167ef93abf 100644 --- a/drivers/rpmsg/qcom_smd.c +++ b/drivers/rpmsg/qcom_smd.c @@ -1073,7 +1073,7 @@ static int qcom_smd_create_device(struct qcom_smd_channel *channel) /* Assign public information to the rpmsg_device */ rpdev = &qsdev->rpdev; - strncpy(rpdev->id.name, channel->name, RPMSG_NAME_SIZE); + strscpy_pad(rpdev->id.name, channel->name, RPMSG_NAME_SIZE); rpdev->src = RPMSG_ADDR_ANY; rpdev->dst = RPMSG_ADDR_ANY; @@ -1304,7 +1304,7 @@ static void qcom_channel_state_worker(struct work_struct *work) spin_unlock_irqrestore(&edge->channels_lock, flags); - strncpy(chinfo.name, channel->name, sizeof(chinfo.name)); + strscpy_pad(chinfo.name, channel->name, sizeof(chinfo.name)); chinfo.src = RPMSG_ADDR_ANY; chinfo.dst = RPMSG_ADDR_ANY; rpmsg_unregister_device(&edge->dev, &chinfo);