From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1162992AbdDWRmV convert rfc822-to-8bit (ORCPT ); Sun, 23 Apr 2017 13:42:21 -0400 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:53791 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1162671AbdDWRmK (ORCPT ); Sun, 23 Apr 2017 13:42:10 -0400 Date: Sun, 23 Apr 2017 17:41:11 +0000 From: "Naveen N. Rao" Subject: Re: [PATCH v4 3/7] kprobes: validate the symbol name provided during probe registration To: Masami Hiramatsu , Michael Ellerman Cc: Ananth N Mavinakayanahalli , linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, Ingo Molnar References: <6e14d22994530fb5200c74d1593e73541d3b8028.1492604782.git.naveen.n.rao@linux.vnet.ibm.com> <20170421123234.6895-1-naveen.n.rao@linux.vnet.ibm.com> <87inlxyoja.fsf@concordia.ellerman.id.au> In-Reply-To: <87inlxyoja.fsf@concordia.ellerman.id.au> 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: 17042317-1617-0000-0000-000001C3E407 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17042317-1618-0000-0000-00004803F950 Message-Id: <1492968472.gwfhge4zw5.astroid@naverao1-tp.none> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-04-23_16:,, 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-1704230322 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Excerpts from Michael Ellerman's message of April 22, 2017 11:25: > "Naveen N. Rao" 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