| Message ID | 20230808-net-netfilter-v1-2-efbbe4ec60af@google.com (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | netfilter: refactor deprecated strncpy | expand |
Justin Stitt <justinstitt@google.com> wrote:
> Prefer `strscpy` over `strncpy`.
Just like all other nft_*.c changes, this relies on zeroing
the remaining buffer, so please use strscpy_pad if this is
really needed for some reason.
On Tue, Aug 8, 2023 at 4:40 PM Florian Westphal <fw@strlen.de> wrote: > > Justin Stitt <justinstitt@google.com> wrote: > > Prefer `strscpy` over `strncpy`. > > Just like all other nft_*.c changes, this relies on zeroing > the remaining buffer, so please use strscpy_pad if this is > really needed for some reason. I'm soon sending a v2 series that prefers `strscpy_pad` to `strscpy` as per Florian and Kees' feedback. It should be noted that there was a similar refactor that took place in this tree as well [1]. Wolfram Sang opted for `strscpy` as a replacement to `strlcpy`. I assume the zero-padding is not needed in such instances, right? [1]: https://lore.kernel.org/all/20220818210224.8563-1-wsa+renesas@sang-engineering.com/ Thanks.
diff --git a/net/netfilter/nft_ct.c b/net/netfilter/nft_ct.c index 38958e067aa8..10126559038b 100644 --- a/net/netfilter/nft_ct.c +++ b/net/netfilter/nft_ct.c @@ -108,7 +108,7 @@ static void nft_ct_get_eval(const struct nft_expr *expr, helper = rcu_dereference(help->helper); if (helper == NULL) goto err; - strncpy((char *)dest, helper->name, NF_CT_HELPER_NAME_LEN); + strscpy((char *)dest, helper->name, NF_CT_HELPER_NAME_LEN); return; #ifdef CONFIG_NF_CONNTRACK_LABELS case NFT_CT_LABELS: {
Prefer `strscpy` over `strncpy`. Signed-off-by: Justin Stitt <justinstitt@google.com> --- Note: It is hard to tell if there was a bug here in the first place but it's better to use a more robust and less ambiguous interface anyways. `helper->name` has a size of 16 and the 3rd argument to `strncpy` (NF_CT_HELPER_LEN) is also 16. This means that depending on where `dest`'s offset is relative to `regs->data` which has a length of 20, there may be a chance the dest buffer ends up non NUL-terminated. This is probably fine though as the destination buffer in this case may be fine being non NUL-terminated. If this is the case, we should probably opt for `strtomem` instead of `strscpy`. --- net/netfilter/nft_ct.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)