Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1162096AbdDWPpl convert rfc822-to-8bit (ORCPT ); Sun, 23 Apr 2017 11:45:41 -0400 Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:40707 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1045781AbdDWPpb (ORCPT ); Sun, 23 Apr 2017 11:45:31 -0400 Date: Sun, 23 Apr 2017 15:44:32 +0000 From: "Naveen N. Rao" Subject: Re: [PATCH v3 3/7] kprobes: validate the symbol name length To: Masami Hiramatsu Cc: Ananth N Mavinakayanahalli , linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, Ingo Molnar , Michael Ellerman References: <6e14d22994530fb5200c74d1593e73541d3b8028.1492604782.git.naveen.n.rao@linux.vnet.ibm.com> <20170419233750.8552f5de8ce1ed1398807284@kernel.org> <1492619420.q0fv2gslsy.astroid@naverao1-tp.none> <20170421224236.d1c53002f0b3c4750fd6f664@kernel.org> In-Reply-To: <20170421224236.d1c53002f0b3c4750fd6f664@kernel.org> User-Agent: astroid/0.8 (https://github.com/astroidmail/astroid) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT X-TM-AS-MML: disable x-cbid: 17042315-0048-0000-0000-00000221645C X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17042315-0049-0000-0000-000047CEF751 Message-Id: <1492962128.c0nhtlqdo4.astroid@naverao1-tp.none> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-04-23_15:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1704230286 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2927 Lines: 85 Excerpts from Masami Hiramatsu's message of April 21, 2017 19:12: > On Wed, 19 Apr 2017 16:38:22 +0000 > "Naveen N. Rao" wrote: > >> Excerpts from Masami Hiramatsu's message of April 19, 2017 20:07: >> > On Wed, 19 Apr 2017 18:21:02 +0530 >> > "Naveen N. Rao" wrote: >> > >> >> 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. >> > >> > Would we really need this? Of course it may filter out longer >> > strings... anyway such name should be rejected by kallsyms. >> >> I felt this would be good to have generically, as kallsyms does many >> string operations on the symbol name, including an unbounded >> strchr(). > > OK, so this is actually for performance reason. > >> >> > >> > [...] >> >> diff --git a/kernel/kprobes.c b/kernel/kprobes.c >> >> index 6a128f3a7ed1..bb86681c8a10 100644 >> >> --- a/kernel/kprobes.c >> >> +++ b/kernel/kprobes.c >> >> @@ -1382,6 +1382,28 @@ bool within_kprobe_blacklist(unsigned long addr) >> >> return false; >> >> } >> >> >> >> +bool is_valid_kprobe_symbol_name(const char *name) >> > >> > This just check the length of symbol_name buffer, and can contain >> > some invalid chars. >> >> Yes, I kept the function name generic incase we would like to do more >> validation in future, plus it's shorter than >> is_valid_kprobe_symbol_name_len() ;-) > > OK, if this is enough general, we'd better define this in > kernel/kallsyms.c or in kallsyms.h. Of course the function > should be called is_valid_symbol_name(). :-) I actually think this should be done in kprobes itself. The primary intent is to perform such validation right when we first obtain the input from the user. In this case, however, kallsyms_lookup_name() is also an exported symbol, so I do think some validation there would be good to have as well. > >> >> +{ >> >> + size_t sym_len; >> >> + char *s; >> >> + >> >> + s = strchr(name, ':'); >> >> Hmm.. this should be strnchr(). I re-factored the code that moved the >> strnlen() above this below. I'll fix this. >> >> >> + if (s) { >> >> + sym_len = strnlen(s+1, KSYM_NAME_LEN); >> > >> > If you use strnlen() here, you just need to ensure sym_len < KSYM_NAME_LEN. >> >> Hmm.. not sure I follow. Are you saying the check for sym_len <= 0 is >> not needed? > > You can check sym_len != 0, but anyway, here we concern about > "longer" string (for performance reason), we can focus on > such case. > (BTW, could you also check the name != NULL at first?) > > So, what I think it can be; > > if (strnlen(s+1, KSYM_NAME_LEN) == KSYM_NAME_LEN || > (size_t)(s - name) >= MODULE_NAME_LEN) > return false; Sure, thanks. I clearly need to refactor this code better! - Naveen