From patchwork Wed Jan 16 15:32:25 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Matthias Klose X-Patchwork-Id: 212561 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) by ozlabs.org (Postfix) with SMTP id 342DB2C0085 for ; Thu, 17 Jan 2013 02:32:52 +1100 (EST) Comment: DKIM? See http://www.dkim.org DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=gcc.gnu.org; s=default; x=1358955173; h=Comment: DomainKey-Signature:Received:Received:Received:Received: Message-ID:Date:From:User-Agent:MIME-Version:To:Subject: Content-Type:Mailing-List:Precedence:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:Sender:Delivered-To; bh=OhjCBBM yAQObH49XDrpgLOukwMA=; b=TWD1aaxTNBdXTT8U8BCB2k7Bdue/9KApKxO17BM PfTzgkwohMcmk73zXuCbqMJfkAFHTpvAEJ7/kbHYnXMqK/FyO5BSyXVKGzz+DhF5 nIK/ZHnCKDbr2c3krjnUDp9QZxnh8zCxiSSPrg1j0zFhqMwTRQlxJTmhNQWaSYJu 7aUE= Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gcc.gnu.org; h=Received:Received:X-SWARE-Spam-Status:X-Spam-Check-By:Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type:Mailing-List:Precedence:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:Sender:Delivered-To; b=JYLGn1bgIGE0dyaO3zA7Jwg1xyDaFHDGS7s/Tnt/Sr+RGexrHhQFoGINz96ptD ZMW9PN32wyFbTsR13pmjeLGiMy05ZIssLcGUezN2GUrvL7CfnnF2VUDvVgrq+Z7x XzWG4E4ACFg59naN3MdccxqctC8eHfC6ZJu4dKO3iD3PM=; Received: (qmail 11973 invoked by alias); 16 Jan 2013 15:32:41 -0000 Received: (qmail 11964 invoked by uid 22791); 16 Jan 2013 15:32:39 -0000 X-SWARE-Spam-Status: No, hits=-2.2 required=5.0 tests=AWL, BAYES_00, KHOP_RCVD_UNTRUST, RCVD_IN_DNSWL_LOW X-Spam-Check-By: sourceware.org Received: from youngberry.canonical.com (HELO youngberry.canonical.com) (91.189.89.112) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 16 Jan 2013 15:32:35 +0000 Received: from dslb-088-073-118-239.pools.arcor-ip.net ([88.73.118.239] helo=[192.168.42.216]) by youngberry.canonical.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1TvUyg-0005YC-L0 for gcc-patches@gcc.gnu.org; Wed, 16 Jan 2013 15:32:34 +0000 Message-ID: <50F6C809.3070601@ubuntu.com> Date: Wed, 16 Jan 2013 16:32:25 +0100 From: Matthias Klose User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: GCC Patches Subject: [patch] libmudflap: check for NULL path in dlopen wrapper Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org From the bug report: If mudflap is used to instrument a program using dlopen, and the program (assuming it is compiled with -rdynamic) loads itself by passing NULL for the path to dlopen, the program will crash unconditionally; that is, regardless of the options passed to mudflap, so long as instrumentation is enabled. This is because (at least with GNU/Linux) it is valid to pass a NULL pointer as the path argument to dlopen, and the instrumentation code unconditionally uses strlen on that pointer, without checking first if it is NULL. Ok for the trunk? Matthias PR mudflap/24619 * mf-hooks2.c (dlopen wrapper): Check for NULL path. Index: b/src/libmudflap/mf-hooks2.c =================================================================== --- a/libmudflap/mf-hooks2.c +++ b/libmudflap/mf-hooks2.c @@ -1677,8 +1677,10 @@ size_t n; TRACE ("%s\n", __PRETTY_FUNCTION__); n = strlen (path); - MF_VALIDATE_EXTENT (path, CLAMPADD(n, 1), __MF_CHECK_READ, "dlopen path"); - p = dlopen (path, flags); + if (NULL != path) { + MF_VALIDATE_EXTENT (path, CLAMPADD(n, 1), __MF_CHECK_READ, "dlopen path"); + p = dlopen (path, flags); + } if (NULL != p) { #ifdef MF_REGISTER_dlopen __mf_register (p, 0, MF_REGISTER_dlopen, "dlopen result");