From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f51.google.com (mail-wm1-f51.google.com [209.85.128.51]) (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 26CDE48CD48 for ; Wed, 29 Jul 2026 13:31:07 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.51 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785331872; cv=none; b=LdB+xMOZuJvXIS3eXpzJKuV31lKGoUusPDAGD4cyxVgSdf6w/b1EMM7iM+3/gfFZWuBk5QoQldEkvYN++LwkC2VwWq0JKry/7rfTWA6KUtC3GQWQpFTu3igizS8dhYdIAmE216RI+OPKUseiiWGtRF0GhUNbtFV4QC3kWuXTBs4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785331872; c=relaxed/simple; bh=hjUmjXkB9UqZjdhvchzSAh4aT18yRtPZMsMt/C8cemE=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=kYpsDAFA8eUgJfeUSqow3z0a6OVnVqO19Vsx7XblLT+2ME/H9q8W3d8iUqqotGYIfzfzDg/mTxkRBp4Bu9ZEL7tY7Q2ue+H0xLReLZodwgzIt0vsi11X4tXsi6gc9CIaCPgnTFuYSzGPOpRGv8+PYI4anX/CMgRWEw/PWKJ+6bE= 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=gO7jED87; arc=none smtp.client-ip=209.85.128.51 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="gO7jED87" Received: by mail-wm1-f51.google.com with SMTP id 5b1f17b1804b1-49553515a8bso12281825e9.1 for ; Wed, 29 Jul 2026 06:31:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1785331864; x=1785936664; darn=vger.kernel.org; h=content-transfer-encoding:content-type:mime-version:references :in-reply-to:message-id:subject:cc:to:from:date:from:to:cc:subject :date:message-id:reply-to:content-type; bh=sBNzF2/kv4bsWB3aoi5mu0BFf7zwh2SbrwxerdvN25Q=; b=gO7jED87Cpj403ZnFO6SXX21uleRBQww2NBl8iNW7AFxMm8duzTrXPVSqmAmhDLtp4 4K735AmYlQ8nejAzjfaRx3OcdysaBAdR95ZMUCRIO972D9GLsE89712eppvfe+H5eqUU HkKDAJLlhyO+UQkOlDJmyeH1YZK7zov+RjU5d2ntKDydwNh0RxbWqlSKLDtOhu2D0qqx bLs9kw4A0w657XViuKuefVo1M2QuFSw+0b9oYafEeWfQWOEQQrAvIlJ7soVMSZqsVESz tBSZ7x2PJsr9HggdyRA0aKKCJg4g5f5A9hfmEF0Yyj328Hihei9X/RrjJwz1Ng8jfrtZ CNRQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1785331864; x=1785936664; h=content-transfer-encoding:content-type:mime-version:references :in-reply-to: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=sBNzF2/kv4bsWB3aoi5mu0BFf7zwh2SbrwxerdvN25Q=; b=Imwwc9jTpYqLGGiCSYzk9VxvznsH4Qc9dp5WWfaN8k8dZDoFOti9pR77ZiHgSwMhon 3ihGyItnqbX6CXFuwF4X6DA72LtxSr14dRRJ0cEKBkG+3zPpNxttQDjuvjCwBEIeVY5q OVRNKRIUCCDamHnX5Kedd5vERFmCOh1exhpS9HrPm8Ckk2um8K41YqOZ5oN0rFBcdZ4z fbABj4cWoBsMu+UjyDf6eJHsp/EF0YwrB4hTG1cYaKuL8GOUHvt0UhVHRFEB02gb7UYX PrIfnv5pQwjBqN1Qv6OwS1sUBH4zvYfgSVZmlMnmQNPBaJ8HFBCsdz7ybmYc1xMFC9KS tiCQ== X-Forwarded-Encrypted: i=1; AHgh+RrXFIzni5sdr/Wq0TjVLP5wNp1pbUCcK1JUOHzSDGAv72pIJM7vusZGU65YhqFBwAQPJNI9Zka6Nc4rccc=@vger.kernel.org X-Gm-Message-State: AOJu0YyAxK5XbLZ61qIPDsjCHas9BfQA/HENmzyDAfOHM0ghF0RmDtTV uIBhLkExfkQh66R6pnANCPd1mDsQguaQBppoBUj2oAjg6h8eHYjbOdEbZnSOFzwDvNA= X-Gm-Gg: AR+sD10Jsq2ZYtCYH8k6jDNXR/E6LMEbiwOqkN+sYANHJIv4cBsX8aDRU4BMcBxVYjW WIewyM3ERfG+PyRG6cM4Gnan7K6XmBLt+8+v9/DI7dJ8FaPToa2a0vGrzL51i25kYhkEPZL0yrJ 5JFa7fLHZdBYNBASPsmvt0cGfLDqIBKumol52mpm9lYQl7hf9TgT7oDlk4apyg6by7+vUCBCQwj tIrWcrmo+Fwifu1RY7n7jHlfip/F1OD81A4P4vwaM9adMID1mbK9tyrrg6/iVyx01y3k6+pOn9e 9iuY872Pyy8eaDOKC8aDSSS5FLR6ePRbSBl1hi0qlg32C9AbOcHClqJ+j9V2IvzD51LZ08yUos6 RMPggZt7tGsFZyAflM059DrFATXGP9jFYVawtXLS2E0AdrbmU5v47KmoPboIxuMYjka24ELC3SN hjP/tnNXWk6j79N9z6fULNn4xoIXBlJYHgeCao+HAXMKAReifZ8AYpl7hMdmtKsmInszcIjsHe1 k2B/jiktrKMGAVYWdq7++iFqdxPiZiZOMd0SPTQjBr/E53y8V/tQmMYETp2kxu4uWDluUEgx8mO iz3hhxygkB+R7MINNRAKLdcT5DFpSq24NVY4cwRLIwlVj95+hqq+vOY4E6jRvq9OH5R4bmMEZg5 CGfeni0pQoe/t5HubrSBAeawRXJ/TDHccFODrvorYScpols0SLb0T8vVWX0F37Msm+MLwupG6T/ QEFvrgPQ== X-Received: by 2002:a05:600c:3541:b0:495:7a04:b006 with SMTP id 5b1f17b1804b1-496c64261f2mr79062695e9.8.1785331864237; Wed, 29 Jul 2026 06:31:04 -0700 (PDT) Received: from localhost (90-182-112-124.rcp.o2.cz. [90.182.112.124]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4976bd52f3fsm34215665e9.0.2026.07.29.06.31.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 29 Jul 2026 06:31:03 -0700 (PDT) Date: Wed, 29 Jul 2026 15:31:02 +0200 From: Joshua Crofts To: Breno Leitao Cc: Andreas Hindborg , linux-kernel@vger.kernel.org, syzbot+35790eb7861f8fc57382@syzkaller.appspotmail.com Subject: Re: [PATCH] configfs: fix refcount warning in configfs_get_config_item() Message-ID: <20260729153102.00003658@gmail.com> In-Reply-To: References: <20260729085505.1316-1-joshua.crofts1@gmail.com> X-Mailer: Claws Mail 4.4.0 (GTK 3.24.51; x86_64-w64-mingw32) 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-Transfer-Encoding: 7bit On Wed, 29 Jul 2026 03:06:09 -0700 Breno Leitao wrote: > On Wed, Jul 29, 2026 at 08:55:05AM +0000, Joshua Crofts wrote: > > syzbot reported a "refcount_t: addition on 0; use-after-free" warning > > in configfs_get_config_item(). > > > > This occurs when configfs_get_config_item() races with a concurrent > > teardown (e.g. rmdir). When the target config_item's refcount drops to > > 0, configfs_get_config_item() calls config_item_get(), which > > unconditionally increments the refcount via kref_get(), triggering the > > refcount warning. > > Shouldn't be this the fix we are interested in fixing? > > > Fix this by using config_item_get_unless_zero(), which safely returns > > NULL if the refcount is already 0. > > This looks like more a workaround than a proper fix, no? > > I got the impression that we have a UAF behind this refcount issue, and > this is not being solved by this patch. Okay, so my interpretation was that this is a concurrency issue that's causing the UAF by incrementing a 0 refcount. Isn't this exactly the reason that config_item_get_unless_zero() was implemented? If the refcount is 0 then it just returns -ENOENT. -- Kind regards, Joshua Crofts