-
Notifications
You must be signed in to change notification settings - Fork 148
kallsyms: Prevent invalid access when showing module buildid #10211
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: bpf-next_base
Are you sure you want to change the base?
Conversation
|
Upstream branch: 4cb4897 |
AI reviewed your patch. Please fix the bug or email reply why it's not a bug. In-Reply-To-Subject: |
|
Forwarding comment 3491665677 via email |
|
Upstream branch: 4cb4897 |
944eb87 to
0fc10f9
Compare
de0745f to
efe6edf
Compare
|
Upstream branch: b54a8e1 |
0fc10f9 to
6c46881
Compare
Add a helper function for reading the optional "build_id" member of struct module. It is going to be used also in ftrace_mod_address_lookup(). Use "#ifdef" instead of "#if IS_ENABLED()" to match the declaration of the optional field in struct module. Signed-off-by: Petr Mladek <[email protected]> Reviewed-by: Petr Pavlu <[email protected]>
Put the code for appending the optional "buildid" into a helper function, It makes __sprint_symbol() better readable. Also print a warning when the "modname" is set and the "buildid" isn't. It might catch a situation when some lookup function in kallsyms_lookup_buildid() does not handle the "buildid". Use pr_*_once() to avoid an infinite recursion when the function is called from printk(). The recursion is rather theoretical but better be on the safe side. Signed-off-by: Petr Mladek <[email protected]>
Make bpf_address_lookup() compatible with module_address_lookup() and clear the pointer to @modbuildid together with @modname. It is not strictly needed because __sprint_symbol() reads @modbuildid only when @modname is set. But better be on the safe side and make the API more safe. Fixes: 9294523 ("module: add printk formats to add module build ID to stacktraces") Signed-off-by: Petr Mladek <[email protected]>
|
Upstream branch: b54a8e1 |
__sprint_symbol() might access an invalid pointer when kallsyms_lookup_buildid() returns a symbol found by ftrace_mod_address_lookup(). The ftrace lookup function must set both @modname and @modbuildid the same way as module_address_lookup(). Fixes: 9294523 ("module: add printk formats to add module build ID to stacktraces") Signed-off-by: Petr Mladek <[email protected]> Acked-by: Steven Rostedt (Google) <[email protected]>
The function kallsyms_lookup_buildid() initializes the given @namebuf
by clearing the first and the last byte. It is not clear why.
The 1st byte makes sense because some callers ignore the return code
and expect that the buffer contains a valid string, for example:
- function_stat_show()
- kallsyms_lookup()
- kallsyms_lookup_buildid()
The initialization of the last byte does not make much sense because it
can later be overwritten. Fortunately, it seems that all called
functions behave correctly:
- kallsyms_expand_symbol() explicitly adds the trailing '\0'
at the end of the function.
- All *__address_lookup() functions either use the safe strscpy()
or they do not touch the buffer at all.
Document the reason for clearing the first byte. And remove the useless
initialization of the last byte.
Signed-off-by: Petr Mladek <[email protected]>
kallsyms_lookup_buildid() copies the symbol name into the given buffer so that it can be safely read anytime later. But it just copies pointers to mod->name and mod->build_id which might get reused after the related struct module gets removed. The lifetime of struct module is synchronized using RCU. Take the rcu read lock for the entire __sprint_symbol(). Signed-off-by: Petr Mladek <[email protected]>
6c46881 to
1caa425
Compare
Pull request for series with
subject: kallsyms: Prevent invalid access when showing module buildid
version: 1
url: https://patchwork.kernel.org/project/netdevbpf/list/?series=1019899