From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ej1-f46.google.com (mail-ej1-f46.google.com [209.85.218.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4289335E1CE for ; Tue, 25 Aug 2026 07:03:30 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.218.46 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787641411; cv=none; b=LiwCob1p2/XSUG/nzd58oJQ/m9pyifF/h6cPfJn98AcCnQaeMKfHK+0kD/Nr5UVK6R772zimyo7RzX8kreZytSzGLTHuUVfSkGcHFkFQLhEPrjzqvXJ5MKcq3FAuN692kiVnFzWF+9TyJKuQOHLxMTL8bHxAaWlQoFMCv+jzxzk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787641411; c=relaxed/simple; bh=LOf+RtJBXhs6s/eIJdx9ZRDZnUklk3vYSZNk0xKtRkE=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=lk4JouoFUoaYAQ6GCSBhH+b5xmejzLfH25nSKCtfxMpV0zNQ61J5evpZKjIEYYNedUCWt3/rfFLovmNuazjuqKLOfxYwYiP/GVy/wSjeVqpIihoWhiCgoS8vqkIyltQhjs65GPEJ/Pw079tS58JvubG20MvpGejYHYs50D4akzw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=H9Zm96d2; arc=none smtp.client-ip=209.85.218.46 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="H9Zm96d2" Received: by mail-ej1-f46.google.com with SMTP id a640c23a62f3a-c1677c91969so533844666b.1 for ; Tue, 25 Aug 2026 00:03:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1787641408; x=1788246208; darn=vger.kernel.org; h=in-reply-to:content-disposition:content-type:mime-version :references:message-id:subject:cc:to:from:date:from:to:cc:subject :date:message-id:reply-to:content-type; bh=CMzGm+i1YzxWvRFmcCkLX0OTQ3u6nTrGUJ+DECAkF1s=; b=H9Zm96d2hwd/yfziz3J+EdS0l0/RLQka3SMvYiWETiVWsPeDMuC+/WCjsDZA0sHkhU ObWfFjjUxCLfH/uWjQtdHOQ3/bdJrubzF/ER3bAAoLOsK9XX/Y+39wzEtea7v4KpLf7q SQ0XrP2MIdj+JUGeZJxGcGrGidSHozTrNIailidrsHrEvZsVGPnkAM6dvt7o26se24Fc pnbCOKwvmh26BlUBTcVjjKP78/cxwJAZOLzNlBnaPYNRfFs7EjyHWIVZbJ/tHV1j8Qs5 zQOzB/rzWULYsiTGtEM2iN1lfCSUukHgeJuEiNjkThmtI+K73vrsHV20XWkRM3HFnmPa +gVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1787641408; x=1788246208; h=in-reply-to:content-disposition:content-type:mime-version :references:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=CMzGm+i1YzxWvRFmcCkLX0OTQ3u6nTrGUJ+DECAkF1s=; b=fHqdTSXVV+hpuHvQt5GcQSUgzXatpcCFNET5SWa86KeQURFXLpSJ3my37+5yZrL8eT Q9Gtu5i1gRL+9VCRnzjetkxhyQBYlpHVE6bSH7m2ocWqgiBBPykb6Fb9pjOT4LRhU7i0 43QgTZaSrwjjMJgBaVMNH44KXHzAMlw387wVL7vGUbPGBnjPlb4Nslevp21m76t45QLN FnSIdsWfCxSQvEVXuIUQiIkRSaCJOvZLekOfheMA7Q1GP692MNnBPFsi0WBzS3NG2j6w c34lUltfaHxHtGrrHV4KSf3C1P/+G0PpCTIaEpGnuqDTGBYMMDNR9cnNdYz5vx5z05zr sO6A== X-Forwarded-Encrypted: i=1; AHgh+RohkC8b3CXPrZTy7oYrD1ArLwXivlfq+xNyIw+PJNOJwFvzjsGC+31fBwpEOu4hzSu1fTKKZYzqXKGWW1k=@vger.kernel.org X-Gm-Message-State: AFuF++nl03gZaCR8GWSVNWKH0b2kunfNIFaN73WLkh6Sg/M3Azu5+aWz ZzxQCfmHWgAUtC1qZEIsFAejvHUNyLR5IlHYVDsMUBQma5JoAFSBeSBO X-Gm-Gg: AR+sD101ZJD0fAjLsXv47hiqcpoqpXCbtRCom3ycJKiPLD85HFkrmlXSp5SDOLsDb7Q TZWfETwfjo0kEWGhmJJTePjSSe0ud9tDrshpofUwEi0rHlqx1UqkxMQuYxPglzp/Jy6Ak2NHty+ fLoktzAELPVAaFPGvqOHrMeAGlmlUO+fbWUE+hYRhXPWwtXxH/jJVdoDtZMxl+jNXWQvWCFdund SaWZslhQ/+fxr0y2yZdVcc/U6fbg+b6LmIKMEBcoXBZDpfrcJ3MgJLTRCW53My2A8E0eTtM2D7c GtTMJeWeh7amGZiuK5b3/ATCJtjlp+Hqtc5UtyrqvlpyfOBFH5oWCo/sGmSU2lmWRPIjDLBd4uX 5I7VOe5tpJo3wYVv6NNEhfSBUzBMCOivNR3dqsuqKwmnqfYkr0acYA1JxY5IyM1LALxHZfA/LrK OIBGsMd//Hu9JkQv3dfsSRAl0YmR3udTQAdlO3nwp4NIlA4hAxwXgDJLSChCnLNpYSLD/ic6rDv fUhl8kLikHt+yOyNwNB3l++4vnGDqDE5+f8aBxaoOXj6Q49/1C8w5YJBBFook5nmKL8UXKvKq90 wm5kEaQ5uJXIXsZ44AIKissOPdQPF4jgqfLcjXRr36KgRX/p9OE36xVXva6p/zA8YMDoczPrTiO J X-Received: by 2002:a17:907:948a:b0:c1f:922d:34c3 with SMTP id a640c23a62f3a-c24926a1c3dmr2295180566b.14.1787641408067; Tue, 25 Aug 2026 00:03:28 -0700 (PDT) Received: from unknown748F3CBA5068 (dynamic-2a02-3100-af54-b201-7419-a557-62e9-4d13.310.pool.telefonica.de. [2a02:3100:af54:b201:7419:a557:62e9:4d13]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-c24966f64e0sm1897627466b.32.2026.08.25.00.03.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 25 Aug 2026 00:03:27 -0700 (PDT) Date: Tue, 25 Aug 2026 09:03:25 +0200 From: Karl Mehltretter To: Greg Kroah-Hartman Cc: Andrew Morton , Matthew Wilcox , "Rafael J. Wysocki" , Danilo Krummrich , driver-core@lists.linux.dev, linux-kernel@vger.kernel.org, syzbot+9cb1ac7fce4944ba9165@syzkaller.appspotmail.com, stable@vger.kernel.org Subject: Re: [PATCH] klist: avoid accesses after waking klist_remove() Message-ID: References: <20260825040408.59225-1-kmehltretter@gmail.com> <2026082559-cyclist-annoying-7a55@gregkh> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2026082559-cyclist-annoying-7a55@gregkh> On Tue, Aug 25, 2026 at 07:25:48AM +0100, Greg Kroah-Hartman wrote: > > to go out of scope and its caller to free or reuse the node. > > But does that ever actually happen? klist_remove() waits until the node is removed so the containing object can be freed. bus_remove_driver() can later free drv->p, while device_move() immediately adds the same node to another list. > > The task reference keeps the waiter task alive if it returns and exits > > before wake_up_process(). wake_up_process() provides the full barrier > > required by the sleep/wakeup protocol, so remove the explicit mb(). > > I'm confused, what actual bug is here? I found this during a targeted klist.c review. Only later I cam across the syzbot report. That report became too prominent in the commit message. klist_release() sets waiter->woken, then reads waiter->process and later writes n->n_klist. After seeing woken, the waiter can return on another CPU. My initial KASAN reproducer was klist-only. One thread held an iterator while another removed and freed the object. A delay after the wakeup made the race easy, hit KASAN on n_klist in qemu arm64. > > Closes: https://syzkaller.appspot.com/bug?extid=9cb1ac7fce4944ba9165 > > Tested-by: syzbot+9cb1ac7fce4944ba9165@syzkaller.appspotmail.com > > Are you sure? the whole bind/unbind mess that syzbot is throwing at us > right now is really causing people to go down odd paths in thinking it's > even a valid thing to consider at all. I did not verify the dummy_udc bind/unbind sequence. The klist issue does not depend on this USB path. I can reword a v2 around the generic reproducer. anything else I should investigate before sending it ? Thanks, Karl