From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-f53.google.com (mail-wm1-f53.google.com [209.85.128.53]) by sourceware.org (Postfix) with ESMTPS id 60C7F3858C35 for ; Fri, 9 Feb 2024 15:47:03 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 60C7F3858C35 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=palves.net Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 60C7F3858C35 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=209.85.128.53 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1707493625; cv=none; b=xglsZ7V2UEsNRoONuAwvOsWPpz1AwaZiol3mu7pbO1uUQ2iXQONGBGOLnP9rvbcmdlWWgEhgFgs6A3P1VoQfLm7eeLC17ET0Df2g7cJRmOYIW6icGixH8qigqJHFUwoCfKVirnlJFbjmEBgH+BPvNoLS0hjkbARRzq47xxnXtFk= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1707493625; c=relaxed/simple; bh=T9atFCD01vMhiNyDAMfqeW4IDXlFMQyUPBRF3fwXlzQ=; h=Message-ID:Date:MIME-Version:Subject:To:From; b=WAfvaZ2jkokbZ441vvzfMIFpq9BdEmAqNV88bg3ROhtPxU21Et+8OaQKfmGJgQ93nHRLSYwjJFxuVOBKA9Yi48aLwKPcETX953CcFKYoC6RbK9ad+wU6C6OFtWzcESfDfNB1Eae1S2/D1CEcNNwlXEIOuNq27XcRN60zGtPEAII= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-wm1-f53.google.com with SMTP id 5b1f17b1804b1-4102f273c46so10125895e9.2 for ; Fri, 09 Feb 2024 07:47:03 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1707493622; x=1708098422; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=nuRP4ESVR5lqtIOAzFRElG1iGJ4CXqQ/O+HEhkRaTLw=; b=TVOtCaDdgfqy6FppMltsTZ/nLQNwILOza9X27NUqfL2JdwHM4KLkqkeFvHXPqc/U/G Xhjk7JS36MYAg4WrdL2C5Uq3CHI3voyLWpsIx20z3yWmkFcUKqOnHNMfhbGD2e4IjyaL ifZ0F9R5QFtEd0oX3jniu8CpZjeWwfjdkcAxM58o1YhdyTey5ZS/dhLWvfFM+aZ51Itm 39ZX2hLLQ6atBiejGo4fParg8RJLTNnJxjYYXZMUKQ9VGFTloktLnRSt9S91jpqpPjb3 rSVLd4sKGSRahDSHB0dhMqqeCPRq1LWpjMhWxFUk6nD7IhmqtNmFF2ydxWY9XPMzS5TZ MJPQ== X-Gm-Message-State: AOJu0YzUl4xYlTBcDUbjIrFTZPCXfNJoxulTysBA5LLmDWiTv61S2FmA w6DqLoCxzs1RyBrF0z90vh70gcncBU+2uH7YmCjnsPnR5+TjTkJz X-Google-Smtp-Source: AGHT+IE+DrOLm0wXLiIWaSJyUqg18gxeZSVfvY1GUONnxasvMIt5bZOSC6ajmb2bfJ0p0FcTefuMKQ== X-Received: by 2002:a05:600c:601c:b0:410:709e:f2f1 with SMTP id az28-20020a05600c601c00b00410709ef2f1mr1406269wmb.7.1707493621802; Fri, 09 Feb 2024 07:47:01 -0800 (PST) X-Forwarded-Encrypted: i=1; AJvYcCULMkLfvYmO9Rgogn+kGeV+JCg6jpiqk1X6csTjz4R+bXcfyIGwQH62iqOkLNZeB/nYvyu9BF7BRiAZotuDOukntP8NsGLv+qqc6Q== Received: from ?IPV6:2001:8a0:f923:4f00:b2a1:dfbd:2dca:65cf? ([2001:8a0:f923:4f00:b2a1:dfbd:2dca:65cf]) by smtp.gmail.com with ESMTPSA id jr6-20020a05600c560600b0041079d336c7sm979538wmb.39.2024.02.09.07.47.01 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 09 Feb 2024 07:47:01 -0800 (PST) Message-ID: <830ab71f-8968-4ab0-b8e7-8a2884169d4c@palves.net> Date: Fri, 9 Feb 2024 15:46:59 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] [gdb] Fix heap-use-after-free in select_event_lwp Content-Language: en-US To: Tom de Vries , gdb-patches@sourceware.org Cc: Simon Marchi References: <20240123114830.20253-1-tdevries@suse.de> From: Pedro Alves In-Reply-To: <20240123114830.20253-1-tdevries@suse.de> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3.5 required=5.0 tests=BAYES_00,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS,KAM_DMARC_STATUS,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 2024-01-23 11:48, Tom de Vries wrote: > Since heap-use-after-free is essentially an address sanitizer complaint, I > also tried building gdb with -O0 -fsanitize=address, but with this setup it > doesn't seem to trigger (0 times out of 10). > > The heap-use-after-free happens during the following scenario: > - linux_nat_wait_1 selects an LWP thread T1 with a status to report. > - it sets variable lp to point to the corresponding lwp_info. > - it calls stop_callback and stop_wait_callback for all threads > (because !target_is_non_stop_p ()). > - it calls select_event_lwp to maybe pick another thread than T1, to prevent > starvation. > > The problem seems to be the following: > - while calling stop_wait_callback for all threads, it also does this for T1. > While doing so, the corresponding lwp_info is deleted (callstack > stop_wait_callback -> wait_lwp -> exit_lwp -> delete_lwp), leaving variable > lp as a dangling pointer. > - variable lp is passed to select_event_lwp, which derefences it, which causes > the heap-use-after-free. > > Note that the comment here mentions "all other LWP's": > ... > /* Now stop all other LWP's ... */ > iterate_over_lwps (minus_one_ptid, stop_callback); > /* ... and wait until all of them have reported back that > they're no longer running. */ > iterate_over_lwps (minus_one_ptid, stop_wait_callback); > ... > which presumably means other than the one in lp, but the iterators > don't skip lp. I think I'm missing something here. The reason the comments say "all other LWP's", and don't bother filtering out LP is that lp->stopped should be true at this point, and the callbacks (both stop_callback and stop_wait_callback) check that flag, and do nothing if set. I.e., they skip already-stopped threads, so they should skip LP. It sounds like we were about to report a stop for a thread that isn't marked as stopped? Now it looks to me that _that_ would be the bug to fix. Pedro Alves