From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.1 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 29733 invoked from network); 9 Jan 2024 23:28:03 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 9 Jan 2024 23:28:03 -0000 Received: (qmail 13769 invoked by uid 550); 9 Jan 2024 23:26:29 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 13727 invoked from network); 9 Jan 2024 23:26:29 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1704842869; x=1705447669; darn=lists.openwall.com; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=rr6OiauElivqUn/FnqZFK2mcpdyuk7ljdycKTAD2Sn8=; b=pL19l6l+vX8LYHYUUGn3T+NG7wZl5McDccjnujnqnNTpxHQ6I0VglTduEhCq3XKN7g jAKUcfUSebmxPpYosL0ZpT0fZtxLCG709m6P3EAqiwqE8aDAFBJNtDoVT1QCZpaBeMf0 MVTdlKoSumUIezcD7hIvNBVjjTyYhesrimtWLIXcfxk1ReGCZWelTd5WP7eW7g6eWAXk HJpPXg6BUB7BzAXzgA2oww86Rie7yHO/kirJk/iD5BHjaGORd+xh1FsfGx2mvVBrvmn/ 4NgPbWoASl5K8/hDYtrx8hO0s/vk7D4bTSEPusAWt0xDlG+GNNB4ESf4qaGmXQ95x9qT EChA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704842869; x=1705447669; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=rr6OiauElivqUn/FnqZFK2mcpdyuk7ljdycKTAD2Sn8=; b=FOdA2ZJ7nfj0na7HreQcfFnV7+79ZmkHTf6KEdTemWKaLXZoxSHSCa9PYicLlYosGL Y/VdXce83NBVek09kaBA0g7jhj+QSJ4kDouMvDqfPrIXGYQpSTG/5DoY/Gh00N+l6n7l uuJ+smrCHV2NSMj6vRo99L87+ZGebqEo8xK2zFhUx5unFrziGGW3pBp1nAt5aRZayy9m 5HaQfwGp+RrCl9CjuE5bjZy2Rbw6zh42vFK0sFPV0VblStwKf2TtlRlQSzQYqy14uC5T bWjKyqfwGh5Kdn1hIWJpogvWHcsWDPDIV7tm/Az+usiao0TsIPAfMf4NehYk1V1RMxw3 sjAA== X-Gm-Message-State: AOJu0YzMWQoT8OqXJY+vk/+YgyO3y8E8pEITjLMymVYy+RZqBYtVO55T pv67kH6xwDKrd4RlnKDl2EcrZf5XGCabRFM9bzlQLANNaalMUG2h+bqUJrD5QTFP X-Google-Smtp-Source: AGHT+IHSY/+fgXw7qLWgGP4yJtz73Ns/M2KAhJetRg6CfpzzP4SqqSTYJ1+PMxpJniwYLfgqwOB/sq93+vdceMEoVn8= X-Received: by 2002:a05:6214:2029:b0:67f:d236:5c0f with SMTP id 9-20020a056214202900b0067fd2365c0fmr275579qvf.90.1704842868515; Tue, 09 Jan 2024 15:27:48 -0800 (PST) MIME-Version: 1.0 References: <20240109190726.GO4163@brightrain.aerifal.cx> In-Reply-To: <20240109190726.GO4163@brightrain.aerifal.cx> From: enh Date: Tue, 9 Jan 2024 15:27:37 -0800 Message-ID: To: musl@lists.openwall.com Cc: jvoisin Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [musl] Protect pthreads' mutexes against use-after-destroy On Tue, Jan 9, 2024 at 11:07=E2=80=AFAM Rich Felker wrote= : > > On Tue, Jan 09, 2024 at 03:37:17PM +0100, jvoisin wrote: > > Ohai, > > > > as discussed on irc, Android's bionic has a check to prevent > > use-after-destroy on phtread mutexes > > (https://github.com/LineageOS/android_bionic/blob/e0aac7df6f58138dae903= b5d456c947a3f8092ea/libc/bionic/pthread_mutex.cpp#L803), > > and musl doesn't. > > > > While odds are that this is a super-duper common bug, it would still be > > nice to have this kind of protection, since it's cheap, and would > > prevent/make it easy to diagnose weird states. > > > > Is this something that should/could be implemented? > > > > o/ > > I think you meant that the odds are it's not common. it was common enough (and hard enough to debug) that we added this "best effort" error detection to bionic :-) (the other "surely no-one actually does that?" mistake i can think of in this area is that a surprising number of people seem to think that `pthread_mutex_lock(NULL)` means something. i'm still not sure _what_ they think it means!) > There's already > enough complexity in the code paths for supporting all the different > mutex types that my leaning would be, if we do any hardening for > use-after-destroy, that it should probably just take the form of > putting the object in a state that will naturally deadlock or error > rather than adding extra checks to every path where it's used. yeah, the _other_ reason we have the abort is that we've struggled over the years to make it clear to the _callers_ that -- just because you crash/hang in libc -- it's the _caller's_ bug. explicitly saying so helps. (though we still get a decent number of people who don't read/don't understand.) > If OTOH we do want it to actually trap in all cases where it's used > after destroy, the simplest way to achieve that is probably to set it > up as a non-robust non-PI recursive or errorchecking mutex with > invalid prev/next pointers and owner of 0x3fffffff. Then the only > place that would actually have to have an explicit trap is trylock in > the code path: > > if (own =3D=3D 0x3fffffff) return ENOTRECOVERABLE; > > where it could trap if type isn't robust. The unlock code path would > trap on accessing invalid prev/next pointers. > > Rich