From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18172 invoked by alias); 22 Mar 2017 17:17:00 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 18154 invoked by uid 89); 22 Mar 2017 17:16:59 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_LOW autolearn=no version=3.3.2 spammy= X-HELO: mx0a-001b2d01.pphosted.com Received: from mx0b-001b2d01.pphosted.com (HELO mx0a-001b2d01.pphosted.com) (148.163.158.5) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 22 Mar 2017 17:16:58 +0000 Received: from pps.filterd (m0098413.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.16.0.20/8.16.0.20) with SMTP id v2MHE4Y2062420 for ; Wed, 22 Mar 2017 13:16:57 -0400 Received: from e06smtp15.uk.ibm.com (e06smtp15.uk.ibm.com [195.75.94.111]) by mx0b-001b2d01.pphosted.com with ESMTP id 29b9vngxdt-1 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT) for ; Wed, 22 Mar 2017 13:16:57 -0400 Received: from localhost by e06smtp15.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 22 Mar 2017 17:16:56 -0000 Received: from b06cxnps4076.portsmouth.uk.ibm.com (9.149.109.198) by e06smtp15.uk.ibm.com (192.168.101.145) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Wed, 22 Mar 2017 17:16:54 -0000 Received: from d06av21.portsmouth.uk.ibm.com (d06av21.portsmouth.uk.ibm.com [9.149.105.232]) by b06cxnps4076.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id v2MHGshH35848362; Wed, 22 Mar 2017 17:16:54 GMT Received: from d06av21.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 3DC1B52041; Wed, 22 Mar 2017 16:15:17 +0000 (GMT) Received: from ThinkPad (unknown [9.152.212.148]) by d06av21.portsmouth.uk.ibm.com (Postfix) with ESMTP id 1E0F15203F; Wed, 22 Mar 2017 16:15:17 +0000 (GMT) Date: Wed, 22 Mar 2017 17:17:00 -0000 From: Philipp Rudo To: Pedro Alves Cc: gdb-patches@sourceware.org Subject: Re: [PATCH] Fix read after xfree in linux_nat_detach In-Reply-To: <1ba8e9a2-2155-cab4-a530-ef7344a40c33@redhat.com> References: <20170322131132.98976-1-prudo@linux.vnet.ibm.com> <20170322131132.98976-2-prudo@linux.vnet.ibm.com> <1ba8e9a2-2155-cab4-a530-ef7344a40c33@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 x-cbid: 17032217-0020-0000-0000-0000032B430A X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17032217-0021-0000-0000-000040E9907E Message-Id: <20170322181652.6d145e7f@ThinkPad> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-03-22_15:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=2 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1702020001 definitions=main-1703220150 X-IsSubscribed: yes X-SW-Source: 2017-03/txt/msg00403.txt.bz2 On Wed, 22 Mar 2017 15:07:22 +0000 Pedro Alves wrote: > On 03/22/2017 01:11 PM, Philipp Rudo wrote: > > At the end of linux_nat_detach there is a check whether the > > inferior has a fork. If no fork exists the main_lwp is detached > > (detach_one_lwp) and later, outside the check, deleted > > (delete_lwp). This is problematic as detach_one_lwp also calls > > delete_lwp freeing main_lwp. Thus the second call to delete_lwp > > reads from already freed memory. Fix this by removing delete_lwp > > at the end of detach_one_lwp. > > Why not just move that unconditional call to delete_lwp call at > the end of linux_nat_detach to the forks_exist_p/true branch? That was the first idea I had. But I decided that it would be better for both detach functions (linux_fork_detach and detach_one_lwp) to have the same behavior and not free the lwp but do that in a separate step ... > Actually, that call looks unnecessary for the fork case too, > since we have: > > linux_fork_detach > -> fork_load_infrun_state > -> linux_nat_switch_fork > -> purge_lwp_list > -> lwp_lwpid_htab_remove_pid > -> lwp_free ... I obviously missed that. > > So... couldn't we just remove that delete_lwp line and be done with > it? Looks like we can get simply rid of it. I'll see that I get a test case running which forks to verify it, tomorrow. Thanks Philipp > Thanks, > Pedro Alves >