From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=172.105.4.254 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1792482927; b=bls9YMTNP51uK4wXKlvmNdDQWYHssCV02CxDG291f8S4pbUUILFPn0b2E5Jfv9ZI92Pg dnB4334vd/+GJbYMmwrTKTxeZtO2uIBXxC311Ww47e/C0vB4+Nw7683b/CqjVhZCwoagz WX3gQObm/JUL0TC84rX9dqJM5jOlyQU2FG6XF4ftS5Sj0BnP/y/rx2evnCfj5OSbVaBm4 tDdisigTgqwczsPmfvvxAZaWJcxiC0dPKP9u99eOx9lgDYqzBhAjkYX1D+U1Me6Czlxus qiBIYTBOcmicm1riAtWVAz9qxOi9RcTWvxKNt1SKNmOMKTxHIxp3t4aODRtcxJXD4wA== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1792482927; h=DMARC-Filter:Received:Received:DKIM-Signature:Date:From:To:Cc: Subject:Message-ID:References:MIME-Version:Content-Type: Content-Disposition:In-Reply-To; bh=wiYcyYLmidZvaVJOjwXyMAgj6pRDKve8NH/1uX7Y5XE=; b=jRN5SWHe+/nxOsSVkoVP0qSz1HuDkxQgofQ2Uy/Oo6NdS5ZNy+ufQFJ/LlC2REanxaKz px81GXNG7+5rIu1cULH+SQnaVob/N1/QjoDZ/aaZ/vUr6MSnGNKD8gLgTzk3Bq2e8w/+r 78oMT1OUg6g1yJaHFyD+g7VgpRDneZ7W14bBTu9m0p1MLZigWsVwhUBBpunjXr1v6XNWd OIjCj9PWQYIOyBlL5Do3sDKtXvLuCaD/tX5B9itKXFXmYEjnAqTlVQosb9gBthpECJEmh o4Aj2zuE4fju6/rJlenGR88PxY9J2lzuSv4CFEi2u888EC1k5OMOpmdn9qHDkoXIetQ== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass header.from=kernel.org; spf=pass smtp.mailfrom=kernel.org; dkim=pass header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20260515 header.b=MijKg5Pi; arc=none smtp.remote-ip=172.105.4.254 Received: from tor.source.kernel.org (tor.source.kernel.org [172.105.4.254]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 50604606A31D for ; Tue, 20 Oct 2026 07:55:27 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.2 smtp.subspace.kernel.org 50604606A31D Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=kernel.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=kernel.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key, unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20260515 header.b=MijKg5Pi Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by tor.source.kernel.org (Postfix) with ESMTP id 3D6E860DA4; Tue, 20 Oct 2026 07:55:26 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6EC1C1F000C4; Tue, 20 Oct 2026 07:55:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1792482926; bh=wiYcyYLmidZvaVJOjwXyMAgj6pRDKve8NH/1uX7Y5XE=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=MijKg5PiQSN4IeG87vq5Yt3/rVEOVOiaPlYoJcUIm++uXCodktoqH3rFHZJ3vXLg3 MbEvGyMVcu8ta0JQAZ/6/CyKJfnVs4NOL4EO+SuFnsyFAQfDFloIovKzTmVtFaywE7 5MMyInA6heob1AvwY1YlJuSGSYD2epYDU9VT0CA8ur5h1stMY9++8Pt69cam5D5j34 iMie7hxbn7ltrvpnSMwsadaWIPXrdctRpqpTxvJSgyhCjtXz0Swx33L9AsJADIY7qi ei8UsEfMAQ9C9tuXNadnmHWd63vc/UzaTHUiXU8zbmpRzPsHDUkiwnCjZDGuQVEOE7 6TBQDsjEdSP2g== Date: Tue, 20 Oct 2026 09:55:20 +0200 From: Joel Granados To: Oleg Nesterov Cc: Allison Henderson , kernel test robot , oe-lkp@lists.linux.dev, lkp@intel.com, linux-kernel@vger.kernel.org, linux-m68k@lists.linux-m68k.org, linux-s390@vger.kernel.org, linux-fsdevel@vger.kernel.org, netdev@vger.kernel.org, wireguard@lists.zx2c4.com, rds-devel@oss.oracle.com Subject: Re: [linus:master] [sysctl] 8d75c338f0: BUG:KASAN:slab-use-after-free_in_touch_wq_lockdep_map Message-ID: References: <202610190310.9737b2e3-lkp@intel.com> X-Mailing-List: linux-m68k@vger.kernel.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="a42qtuqnvg7yxrg6" Content-Disposition: inline In-Reply-To: --a42qtuqnvg7yxrg6 Content-Type: text/plain; protected-headers=v1; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Subject: Re: [linus:master] [sysctl] 8d75c338f0: BUG:KASAN:slab-use-after-free_in_touch_wq_lockdep_map MIME-Version: 1.0 On Mon, Oct 19, 2026 at 04:49:55PM +0200, Oleg Nesterov wrote: > On 10/19, Joel Granados wrote: > > > > On Mon, Oct 19, 2026 at 01:41:05PM +0200, Oleg Nesterov wrote: > > > On 10/19, kernel test robot wrote: > > > > > > > > > > > > Hello, > > > > > > > > kernel test robot noticed "BUG:KASAN:slab-use-after-free_in_touch_w= q_lockdep_map" on: > > > > > > > > commit: 8d75c338f0bcecaa6c9af67f86c176b67b6acf3e ("sysctl: remove C= ONFIG_PROC_SYSCTL, it just mirrors CONFIG_SYSCTL") https://git.kernel.org/c= git/linux/kernel/git/torvalds/linux.git master > > > > > > I don't think that commit could cause such a problem. Please re-check. > > > > > > Oleg. > > > > That commit might not be the one that introduces the UAF, but it might > > be the one that exposes it? > > > > You have CONFIG_SYSCTL=3Dn & CONFIG_RDS=3Dy & CONFIG_RDS_RDMA=3Dy. > > Therefore rds_sysctl_init() returns -ENOMEM and rds_ib_sysctl_init > > returns -ENOMEM. > > > > If rds_ib_sysctl_init is called after a failed rds_sysctl_init, then > > rds_ib_sysctl_init would call a flush_workqueue on a rds_wq that has > > already been freed by the failed rds_sysctl_init. Right? > > > > Please let me know if I missed anything. >=20 > I think you are right... >=20 > rds_init() does >=20 > rds_threads_init() > rds_wq =3D create_singlethread_workqueue("krdsd"); >=20 > rds_sysctl_init() > fails due to CONFIG_SYSCTL=3Dn >=20 > out_threads: > destroy_workqueue(rds_wq); >=20 > After that any access to rds_wq is wrong. >=20 > If rds_rdma_init() runs after that, rds_ib_init() will call > rds_ib_unregister_client() -> flush_workqueue(rds_wq). >=20 > And this will equally happen before the blamed commit 8d75c338f0bc, > just you need CONFIG_PROC_SYSCTL=3Dn instead of CONFIG_SYSCTL=3Dn. >=20 >=20 > But. rds_init() can also fail even if CONFIG_SYSCTL=3Dy, after > rds_sysctl_init(), so to me this looks like a bug in net/rds/. >=20 >=20 > In any case, I guess net/rds/ init paths should not fail if > CONFIG_SYSCTL=3Dn ? That is up to net/rds.=20 The question is: do you have to fail if a sysctl registration fails? Or another way to ask it is: Can't it (net/rds or others) run while not being tuned or queried through sysctl? If the answer to these questions is that the sysctl path is necessary, then the failure is reasonable. But if they can work without the sysctl, the failure is an overreaction (IMO). Best >=20 > Oleg. >=20 --a42qtuqnvg7yxrg6 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGzBAABCgAdFiEErkcJVyXmMSXOyyeQupfNUreWQU8FAmrXHlsACgkQupfNUreW QU912gv/eejjrtoxUgh51UagvsJXA0SMOI6Yaa+uIBcExUpCjVRcUBjhj2jT/GV9 JRJK0zb9dOeEg4yIm/bzf4j3qYwBTqiRdVf5++8HB9yuqIx4w0NlVIbks9Q8YDQh QRXDBUAUoP6FxYb3jE1U49avWB37mPqj986qpNiwwqXq9nIRDKDf/9sPY/b2Vvyn RibI+hOi7hfCSUntOsrbN7NmOtV9e1FQtHZxCjHpdz51bQqn1S84/WJ0dDgy+RUT J1sLIQsUlmxKtJ78VYmaCPUJ+owrm3mFNvzmw2ERplHoA2JqT3r6lY1jP2G5Xi8y pRSKsCTfoRUgVrXh6yByuK/2ywuqzfTEneUTJ4F97bLgJClP+4FtYcUjnbZOvsrm l/VWLpeaTxFHDiDWu/rJ+K9YFs8JcsnTtmJqJ/pLJAW/IjvQ5sQsT6P+d04LgWQJ fRYc1/dcsViZ1Bz/LUpV4NWsMtqP70EPbjuvvPYA5GG5HRM1bj6x4hHL2e9gGsQ5 vMczI+dC =OX/2 -----END PGP SIGNATURE----- --a42qtuqnvg7yxrg6--