Use `strscpy_pad` instead of `strncpy`.
Link: https://github.com/KSPP/linux/issues/90
Cc: [email protected]
Signed-off-by: Justin Stitt <[email protected]>
---
net/netfilter/ipset/ip_set_core.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/net/netfilter/ipset/ip_set_core.c b/net/netfilter/ipset/ip_set_core.c
index 0b68e2e2824e..e564b5174261 100644
--- a/net/netfilter/ipset/ip_set_core.c
+++ b/net/netfilter/ipset/ip_set_core.c
@@ -872,7 +872,7 @@ ip_set_name_byindex(struct net *net, ip_set_id_t index, char *name)
BUG_ON(!set);
read_lock_bh(&ip_set_ref_lock);
- strncpy(name, set->name, IPSET_MAXNAMELEN);
+ strscpy_pad(name, set->name, IPSET_MAXNAMELEN);
read_unlock_bh(&ip_set_ref_lock);
}
EXPORT_SYMBOL_GPL(ip_set_name_byindex);
@@ -1326,7 +1326,7 @@ static int ip_set_rename(struct sk_buff *skb, const struct nfnl_info *info,
goto out;
}
}
- strncpy(set->name, name2, IPSET_MAXNAMELEN);
+ strscpy_pad(set->name, name2, IPSET_MAXNAMELEN);
out:
write_unlock_bh(&ip_set_ref_lock);
@@ -1380,9 +1380,9 @@ static int ip_set_swap(struct sk_buff *skb, const struct nfnl_info *info,
return -EBUSY;
}
- strncpy(from_name, from->name, IPSET_MAXNAMELEN);
- strncpy(from->name, to->name, IPSET_MAXNAMELEN);
- strncpy(to->name, from_name, IPSET_MAXNAMELEN);
+ strscpy_pad(from_name, from->name, IPSET_MAXNAMELEN);
+ strscpy_pad(from->name, to->name, IPSET_MAXNAMELEN);
+ strscpy_pad(to->name, from_name, IPSET_MAXNAMELEN);
swap(from->ref, to->ref);
ip_set(inst, from_id) = to;
--
2.41.0.640.ga95def55d0-goog
Justin Stitt <[email protected]> wrote:
> Use `strscpy_pad` instead of `strncpy`.
I don't think that any of these need zero-padding.
Justin Stitt <[email protected]> wrote:
> On Wed, Aug 9, 2023 at 1:19 PM Florian Westphal <[email protected]> wrote:
> >
> > Justin Stitt <[email protected]> wrote:
> > > Use `strscpy_pad` instead of `strncpy`.
> >
> > I don't think that any of these need zero-padding.
> It's a more consistent change with the rest of the series and I don't
> believe it has much different behavior to `strncpy` (other than
> NUL-termination) as that will continue to pad to `n` as well.
>
> Do you think the `_pad` for 1/7, 6/7 and 7/7 should be changed back to
> `strscpy` in a v3? I really am shooting in the dark as it is quite
> hard to tell whether or not a buffer is expected to be NUL-padded or
> not.
No, you can keep it as-is. Which tree are you targetting with this?
On Wednesday 2023-08-09 23:40, Justin Stitt wrote:
>On Wed, Aug 9, 2023 at 1:19 PM Florian Westphal <[email protected]> wrote:
>>
>> Justin Stitt <[email protected]> wrote:
>> > Use `strscpy_pad` instead of `strncpy`.
>>
>> I don't think that any of these need zero-padding.
>It's a more consistent change with the rest of the series and I don't
>believe it has much different behavior to `strncpy` (other than
>NUL-termination) as that will continue to pad to `n` as well.
>
>Do you think the `_pad` for 1/7, 6/7 and 7/7 should be changed back to
>`strscpy` in a v3? I really am shooting in the dark as it is quite
>hard to tell whether or not a buffer is expected to be NUL-padded or
>not.
I don't recall either NF userspace or kernelspace code doing memcmp
with name-like fields, so padding should not be strictly needed.
On Wed, Aug 9, 2023 at 1:19 PM Florian Westphal <[email protected]> wrote:
>
> Justin Stitt <[email protected]> wrote:
> > Use `strscpy_pad` instead of `strncpy`.
>
> I don't think that any of these need zero-padding.
It's a more consistent change with the rest of the series and I don't
believe it has much different behavior to `strncpy` (other than
NUL-termination) as that will continue to pad to `n` as well.
Do you think the `_pad` for 1/7, 6/7 and 7/7 should be changed back to
`strscpy` in a v3? I really am shooting in the dark as it is quite
hard to tell whether or not a buffer is expected to be NUL-padded or
not.
On Wed, Aug 9, 2023 at 2:58 PM Florian Westphal <[email protected]> wrote:
>
> Justin Stitt <[email protected]> wrote:
> > On Wed, Aug 9, 2023 at 1:19 PM Florian Westphal <[email protected]> wrote:
> > >
> > > Justin Stitt <[email protected]> wrote:
> > > > Use `strscpy_pad` instead of `strncpy`.
> > >
> > > I don't think that any of these need zero-padding.
> > It's a more consistent change with the rest of the series and I don't
> > believe it has much different behavior to `strncpy` (other than
> > NUL-termination) as that will continue to pad to `n` as well.
> >
> > Do you think the `_pad` for 1/7, 6/7 and 7/7 should be changed back to
> > `strscpy` in a v3? I really am shooting in the dark as it is quite
> > hard to tell whether or not a buffer is expected to be NUL-padded or
> > not.
>
> No, you can keep it as-is. Which tree are you targetting with this?
Not sure, I let ./getmaintainer auto-add the mailing lists. Perhaps
netdev or netfilter next trees?
On Wed, Aug 09, 2023 at 11:54:48PM +0200, Jan Engelhardt wrote:
>
> On Wednesday 2023-08-09 23:40, Justin Stitt wrote:
> >On Wed, Aug 9, 2023 at 1:19 PM Florian Westphal <[email protected]> wrote:
> >>
> >> Justin Stitt <[email protected]> wrote:
> >> > Use `strscpy_pad` instead of `strncpy`.
> >>
> >> I don't think that any of these need zero-padding.
> >It's a more consistent change with the rest of the series and I don't
> >believe it has much different behavior to `strncpy` (other than
> >NUL-termination) as that will continue to pad to `n` as well.
> >
> >Do you think the `_pad` for 1/7, 6/7 and 7/7 should be changed back to
> >`strscpy` in a v3? I really am shooting in the dark as it is quite
> >hard to tell whether or not a buffer is expected to be NUL-padded or
> >not.
>
> I don't recall either NF userspace or kernelspace code doing memcmp
> with name-like fields, so padding should not be strictly needed.
My only concern with padding is just to make sure any buffers copied to
userspace have been zeroed. I would need to take a close look at how
buffers are passed around here to know for sure...
--
Kees Cook