Excerpts from Michael Ellerman's message of April 22, 2017 11:25:
"Naveen N. Rao" <naveen.n....@linux.vnet.ibm.com> writes:
When a kprobe is being registered, we use the symbol_name field to
lookup the address where the probe should be placed. Since this is a
user-provided field, let's ensure that the length of the string is
within expected limits.
What are we actually trying to protect against here?
If you ignore powerpc for a moment, kprobe_lookup_name() is just
kallsyms_lookup_name().
All kallsyms_lookup_name() does with name is strcmp() it against a
legitimate symbol name which is at most KSYM_NAME_LEN.
So I don't think any of this validation helps in that case?
It does:
https://patchwork.kernel.org/patch/9695139/
It is far too easy to cause a OOPS due to the above, though this is
root-only (for modules).
As I stated earlier, I think it is always a good practice to validate
inputs right on entry, rather than later. Code gets refactored,
different arch support gets added, and so on.
Doing this validation here ensures we don't have to worry about how we
process this later, or if another arch has to over-ride
kprobe_lookup_name().
In the powerpc version of kprobe_lookup_name() we do need to do some
string juggling, for which it helps to know the input is sane. But I
think we should just make that code more robust by checking the input
before we do anything with it.
Ok, I will fold those tests in with the powerpc implementation for now
and consider a patch against kallsyms_lookup_name(), like Masami
recommends.
- Naveen
