kdb does a strncpy(a, b, strlen(b)+1), which makes no sense. Might as
well do a strcpy at this point.
Fixes this warning:
In function 'strncpy', inlined from 'kallsyms_symbol_next' at kernel/debug/kdb/kdb_support.c:239:4:
./include/linux/string.h:253:9: warning: '__builtin_strncpy' specified bound depends on the length of the source argument [-Wstringop-overflow=]
Signed-off-by: Olof Johansson <[email protected]>
---
kernel/debug/kdb/kdb_support.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/debug/kdb/kdb_support.c b/kernel/debug/kdb/kdb_support.c
index 990b3cc526c8..d5af8b38b84d 100644
--- a/kernel/debug/kdb/kdb_support.c
+++ b/kernel/debug/kdb/kdb_support.c
@@ -236,7 +236,7 @@ int kallsyms_symbol_next(char *prefix_name, int flag)
while ((name = kdb_walk_kallsyms(&pos))) {
if (strncmp(name, prefix_name, prefix_len) == 0) {
- strncpy(prefix_name, name, strlen(name)+1);
+ strcpy(prefix_name, name);
return 1;
}
}
--
2.11.0
On Fri, Nov 02, 2018 at 02:24:05PM -0700, Olof Johansson wrote:
> kdb does a strncpy(a, b, strlen(b)+1), which makes no sense. Might as
> well do a strcpy at this point.
>
> Fixes this warning:
>
> In function 'strncpy', inlined from 'kallsyms_symbol_next' at kernel/debug/kdb/kdb_support.c:239:4:
> ./include/linux/string.h:253:9: warning: '__builtin_strncpy' specified bound depends on the length of the source argument [-Wstringop-overflow=]
I think we already have a pending patch for this:
https://lore.kernel.org/patchwork/patch/989013/
When we looked into this there actually is an unchecked overflow here so
Prarit's fix adds infrastructure to keep track of the remaining length.
Daniel.
>
> Signed-off-by: Olof Johansson <[email protected]>
> ---
> kernel/debug/kdb/kdb_support.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/kernel/debug/kdb/kdb_support.c b/kernel/debug/kdb/kdb_support.c
> index 990b3cc526c8..d5af8b38b84d 100644
> --- a/kernel/debug/kdb/kdb_support.c
> +++ b/kernel/debug/kdb/kdb_support.c
> @@ -236,7 +236,7 @@ int kallsyms_symbol_next(char *prefix_name, int flag)
>
> while ((name = kdb_walk_kallsyms(&pos))) {
> if (strncmp(name, prefix_name, prefix_len) == 0) {
> - strncpy(prefix_name, name, strlen(name)+1);
> + strcpy(prefix_name, name);
> return 1;
> }
> }
> --
> 2.11.0
>
On Sat, Nov 3, 2018 at 8:39 AM Daniel Thompson
<[email protected]> wrote:
>
> On Fri, Nov 02, 2018 at 02:24:05PM -0700, Olof Johansson wrote:
> > kdb does a strncpy(a, b, strlen(b)+1), which makes no sense. Might as
> > well do a strcpy at this point.
> >
> > Fixes this warning:
> >
> > In function 'strncpy', inlined from 'kallsyms_symbol_next' at kernel/debug/kdb/kdb_support.c:239:4:
> > ./include/linux/string.h:253:9: warning: '__builtin_strncpy' specified bound depends on the length of the source argument [-Wstringop-overflow=]
>
> I think we already have a pending patch for this:
> https://lore.kernel.org/patchwork/patch/989013/
>
> When we looked into this there actually is an unchecked overflow here so
> Prarit's fix adds infrastructure to keep track of the remaining length.
I'm not surprised that there are more bugs.
The above patch was posted a month and a half ago though, why is it
not yet merged? Can we get it in by -rc2, please?
-Olof
On 11/03/2018 12:54 PM, Olof Johansson wrote:
> On Sat, Nov 3, 2018 at 8:39 AM Daniel Thompson
> <[email protected]> wrote:
>>
>> On Fri, Nov 02, 2018 at 02:24:05PM -0700, Olof Johansson wrote:
>>> kdb does a strncpy(a, b, strlen(b)+1), which makes no sense. Might as
>>> well do a strcpy at this point.
>>>
>>> Fixes this warning:
>>>
>>> In function 'strncpy', inlined from 'kallsyms_symbol_next' at kernel/debug/kdb/kdb_support.c:239:4:
>>> ./include/linux/string.h:253:9: warning: '__builtin_strncpy' specified bound depends on the length of the source argument [-Wstringop-overflow=]
>>
>> I think we already have a pending patch for this:
>> https://lore.kernel.org/patchwork/patch/989013/
>>
>> When we looked into this there actually is an unchecked overflow here so
>> Prarit's fix adds infrastructure to keep track of the remaining length.
>
> I'm not surprised that there are more bugs.
>
> The above patch was posted a month and a half ago though, why is it
> not yet merged? Can we get it in by -rc2, please?
>
>
Jason? ping? Just making sure the above patch is in your queue.
P.
> -Olof
>