1. Patchew
  2. linux
  3. View series

[PATCH v2] kallsyms: Fix wrong "big" kernel symbol type read from procfs

Zheng Yejian posted 1 patch 1 month, 2 weeks ago 
kernel/kallsyms.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
[PATCH v2] kallsyms: Fix wrong "big" kernel symbol type read from procfs
Posted by Zheng Yejian 1 month, 2 weeks ago 
Currently when the length of a symbol is longer than 0x7f characters,
its type shown in /proc/kallsyms can be incorrect.

I found this issue when reading the code, but it can be reproduced by
following steps:

  1. Define a function which symbol length is 130 characters:

    #define X13(x) x##x##x##x##x##x##x##x##x##x##x##x##x
    static noinline void X13(x123456789)(void)
    {
        printk("hello world\n");
    }

  2. The type in vmlinux is 't':

    $ nm vmlinux | grep x123456
    ffffffff816290f0 t x123456789x123456789x123456789x12[...]

  3. Then boot the kernel, the type shown in /proc/kallsyms becomes 'g'
     instead of the expected 't':

    # cat /proc/kallsyms | grep x123456
    ffffffff816290f0 g x123456789x123456789x123456789x12[...]

The root cause is that, after commit 73bbb94466fd ("kallsyms: support
"big" kernel symbols"), ULEB128 was used to encode symbol name length.
That is, for "big" kernel symbols of which name length is longer than
0x7f characters, the length info is encoded into 2 bytes.

kallsyms_get_symbol_type() expects to read the first char of the
symbol name which indicates the symbol type. However, due to the
"big" symbol case not being handled, the symbol type read from
/proc/kallsyms may be wrong, so handle it properly.

Cc: stable@vger.kernel.org
Fixes: 73bbb94466fd ("kallsyms: support "big" kernel symbols")
Signed-off-by: Zheng Yejian <zhengyejian@huaweicloud.com>
---

v1 -> v2:
- Add reproduction info into commit message to make it clearer;
- Add cc: stable line;

v1: https://lore.kernel.org/all/20240830062935.1187613-1-zhengyejian@huaweicloud.com/

 kernel/kallsyms.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/kernel/kallsyms.c b/kernel/kallsyms.c
index a9a0ca605d4a..9e4bf061bb83 100644
--- a/kernel/kallsyms.c
+++ b/kernel/kallsyms.c
@@ -103,8 +103,11 @@ static char kallsyms_get_symbol_type(unsigned int off)
 {
 	/*
 	 * Get just the first code, look it up in the token table,
-	 * and return the first char from this token.
+	 * and return the first char from this token. If MSB of length
+	 * is 1, it is a "big" symbol, so needs an additional byte.
 	 */
+	if (kallsyms_names[off] & 0x80)
+		off++;
 	return kallsyms_token_table[kallsyms_token_index[kallsyms_names[off + 1]]];
 }
 
-- 
2.25.1
Re: [PATCH v2] kallsyms: Fix wrong "big" kernel symbol type read from procfs
Posted by Matthew Wilcox 1 month, 2 weeks ago 
On Fri, Oct 11, 2024 at 10:38:53PM +0800, Zheng Yejian wrote:
> The root cause is that, after commit 73bbb94466fd ("kallsyms: support
> "big" kernel symbols"), ULEB128 was used to encode symbol name length.
> That is, for "big" kernel symbols of which name length is longer than
> 0x7f characters, the length info is encoded into 2 bytes.

Technically, at least two.  If we ever have a symbol larger than
16kB, we'll use three bytes.

> +++ b/kernel/kallsyms.c
> @@ -103,8 +103,11 @@ static char kallsyms_get_symbol_type(unsigned int off)
>  {
>  	/*
>  	 * Get just the first code, look it up in the token table,
> -	 * and return the first char from this token.
> +	 * and return the first char from this token. If MSB of length
> +	 * is 1, it is a "big" symbol, so needs an additional byte.
>  	 */
> +	if (kallsyms_names[off] & 0x80)
> +		off++;

So this "if" should be a "while" for maximum future proofing against the
day that we have a 16kB function ...
Re: [PATCH v2] kallsyms: Fix wrong "big" kernel symbol type read from procfs
Posted by Gary Guo 1 month, 2 weeks ago 
On Fri, 11 Oct 2024 23:01:12 +0100
Matthew Wilcox <willy@infradead.org> wrote:

> On Fri, Oct 11, 2024 at 10:38:53PM +0800, Zheng Yejian wrote:
> > The root cause is that, after commit 73bbb94466fd ("kallsyms: support
> > "big" kernel symbols"), ULEB128 was used to encode symbol name length.
> > That is, for "big" kernel symbols of which name length is longer than
> > 0x7f characters, the length info is encoded into 2 bytes.  
> 
> Technically, at least two.  If we ever have a symbol larger than
> 16kB, we'll use three bytes.

Let's not worry about things that would not happen.

scripts/kallsyms.c have a check to ensure that symbol names don't get
longer than 0x3FFF.

Best,
Gary

> 
> > +++ b/kernel/kallsyms.c
> > @@ -103,8 +103,11 @@ static char kallsyms_get_symbol_type(unsigned int off)
> >  {
> >  	/*
> >  	 * Get just the first code, look it up in the token table,
> > -	 * and return the first char from this token.
> > +	 * and return the first char from this token. If MSB of length
> > +	 * is 1, it is a "big" symbol, so needs an additional byte.
> >  	 */
> > +	if (kallsyms_names[off] & 0x80)
> > +		off++;  
> 
> So this "if" should be a "while" for maximum future proofing against the
> day that we have a 16kB function ...
>
Re: [PATCH v2] kallsyms: Fix wrong "big" kernel symbol type read from procfs
Posted by Zheng Yejian 1 month, 2 weeks ago 
On 2024/10/12 09:47, Gary Guo wrote:
> On Fri, 11 Oct 2024 23:01:12 +0100
> Matthew Wilcox <willy@infradead.org> wrote:
> 
>> On Fri, Oct 11, 2024 at 10:38:53PM +0800, Zheng Yejian wrote:
>>> The root cause is that, after commit 73bbb94466fd ("kallsyms: support
>>> "big" kernel symbols"), ULEB128 was used to encode symbol name length.
>>> That is, for "big" kernel symbols of which name length is longer than
>>> 0x7f characters, the length info is encoded into 2 bytes.
>>
>> Technically, at least two.  If we ever have a symbol larger than
>> 16kB, we'll use three bytes.
> 
> Let's not worry about things that would not happen.
> 
> scripts/kallsyms.c have a check to ensure that symbol names don't get
> longer than 0x3FFF.

Yes, so currently in kallsyms_expand_symbol() and get_symbol_offset(), the
symbol length are also assumed to be encoded into one byte or two bytes.
If considering the "longer than 0x3FFF" case, those two functions may should
also be changed.

> 
> Best,
> Gary
> 
>>
>>> +++ b/kernel/kallsyms.c
>>> @@ -103,8 +103,11 @@ static char kallsyms_get_symbol_type(unsigned int off)
>>>   {
>>>   	/*
>>>   	 * Get just the first code, look it up in the token table,
>>> -	 * and return the first char from this token.
>>> +	 * and return the first char from this token. If MSB of length
>>> +	 * is 1, it is a "big" symbol, so needs an additional byte.
>>>   	 */
>>> +	if (kallsyms_names[off] & 0x80)
>>> +		off++;
>>
>> So this "if" should be a "while" for maximum future proofing against the
>> day that we have a 16kB function ...
>>

-- 
Thanks,
Zheng Yejian
Re: [PATCH v2] kallsyms: Fix wrong "big" kernel symbol type read from procfs
Posted by Zheng Yejian 1 month, 2 weeks ago 
On 2024/10/12 06:01, Matthew Wilcox wrote:
> On Fri, Oct 11, 2024 at 10:38:53PM +0800, Zheng Yejian wrote:
>> The root cause is that, after commit 73bbb94466fd ("kallsyms: support
>> "big" kernel symbols"), ULEB128 was used to encode symbol name length.
>> That is, for "big" kernel symbols of which name length is longer than
>> 0x7f characters, the length info is encoded into 2 bytes.
> 
> Technically, at least two.  If we ever have a symbol larger than
> 16kB, we'll use three bytes.
> 

Well, yes!

>> +++ b/kernel/kallsyms.c
>> @@ -103,8 +103,11 @@ static char kallsyms_get_symbol_type(unsigned int off)
>>   {
>>   	/*
>>   	 * Get just the first code, look it up in the token table,
>> -	 * and return the first char from this token.
>> +	 * and return the first char from this token. If MSB of length
>> +	 * is 1, it is a "big" symbol, so needs an additional byte.
>>   	 */
>> +	if (kallsyms_names[off] & 0x80)
>> +		off++;
> 
> So this "if" should be a "while" for maximum future proofing against the
> day that we have a 16kB function ...

I'll test it and send a v3.

-- 
Thanks,
Zheng Yejian
Re: [PATCH v2] kallsyms: Fix wrong "big" kernel symbol type read from procfs
Posted by Gary Guo 1 month, 2 weeks ago 
On Fri, 11 Oct 2024 22:38:53 +0800
Zheng Yejian <zhengyejian@huaweicloud.com> wrote:

> Currently when the length of a symbol is longer than 0x7f characters,
> its type shown in /proc/kallsyms can be incorrect.
> 
> I found this issue when reading the code, but it can be reproduced by
> following steps:
> 
>   1. Define a function which symbol length is 130 characters:
> 
>     #define X13(x) x##x##x##x##x##x##x##x##x##x##x##x##x
>     static noinline void X13(x123456789)(void)
>     {
>         printk("hello world\n");
>     }
> 
>   2. The type in vmlinux is 't':
> 
>     $ nm vmlinux | grep x123456
>     ffffffff816290f0 t x123456789x123456789x123456789x12[...]
> 
>   3. Then boot the kernel, the type shown in /proc/kallsyms becomes 'g'
>      instead of the expected 't':
> 
>     # cat /proc/kallsyms | grep x123456
>     ffffffff816290f0 g x123456789x123456789x123456789x12[...]
> 
> The root cause is that, after commit 73bbb94466fd ("kallsyms: support
> "big" kernel symbols"), ULEB128 was used to encode symbol name length.
> That is, for "big" kernel symbols of which name length is longer than
> 0x7f characters, the length info is encoded into 2 bytes.
> 
> kallsyms_get_symbol_type() expects to read the first char of the
> symbol name which indicates the symbol type. However, due to the
> "big" symbol case not being handled, the symbol type read from
> /proc/kallsyms may be wrong, so handle it properly.
> 
> Cc: stable@vger.kernel.org
> Fixes: 73bbb94466fd ("kallsyms: support "big" kernel symbols")
> Signed-off-by: Zheng Yejian <zhengyejian@huaweicloud.com>

Acked-by: Gary Guo <gary@garyguo.net>

> ---
> 
> v1 -> v2:
> - Add reproduction info into commit message to make it clearer;
> - Add cc: stable line;
> 
> v1: https://lore.kernel.org/all/20240830062935.1187613-1-zhengyejian@huaweicloud.com/
> 
>  kernel/kallsyms.c | 5 ++++-
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/kernel/kallsyms.c b/kernel/kallsyms.c
> index a9a0ca605d4a..9e4bf061bb83 100644
> --- a/kernel/kallsyms.c
> +++ b/kernel/kallsyms.c
> @@ -103,8 +103,11 @@ static char kallsyms_get_symbol_type(unsigned int off)
>  {
>  	/*
>  	 * Get just the first code, look it up in the token table,
> -	 * and return the first char from this token.
> +	 * and return the first char from this token. If MSB of length
> +	 * is 1, it is a "big" symbol, so needs an additional byte.
>  	 */
> +	if (kallsyms_names[off] & 0x80)
> +		off++;
>  	return kallsyms_token_table[kallsyms_token_index[kallsyms_names[off + 1]]];
>  }
>

Patchew 2.1-devel-b67e4c2

© 2016 - 2024 Red Hat, Inc.