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_wq_lockdep_map" on:
> > > >
> > > > commit: 8d75c338f0bcecaa6c9af67f86c176b67b6acf3e ("sysctl: remove CONFIG_PROC_SYSCTL, it just mirrors CONFIG_SYSCTL") https://git.kernel.org/cgit/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=n & CONFIG_RDS=y & CONFIG_RDS_RDMA=y.
> > 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.
> 
> I think you are right...
> 
> rds_init() does
> 
> 	rds_threads_init()
> 		rds_wq = create_singlethread_workqueue("krdsd");
> 
> 	rds_sysctl_init()
> 		fails due to CONFIG_SYSCTL=n
> 
> 	out_threads:
> 		destroy_workqueue(rds_wq);
> 
> After that any access to rds_wq is wrong.
> 
> If rds_rdma_init() runs after that, rds_ib_init() will call
> rds_ib_unregister_client() -> flush_workqueue(rds_wq).
> 
> And this will equally happen before the blamed commit 8d75c338f0bc,
> just you need CONFIG_PROC_SYSCTL=n instead of CONFIG_SYSCTL=n.
> 
> 
> But. rds_init() can also fail even if CONFIG_SYSCTL=y, after
> rds_sysctl_init(), so to me this looks like a bug in net/rds/.
> 
> 
> In any case, I guess net/rds/ init paths should not fail if
> CONFIG_SYSCTL=n ?

That is up to net/rds. 

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


> 
> Oleg.
>