Re: [PATCH] net: sched: use-after-free in tcf_action_destroy

[Jamal Hadi Salim]

On Sat, Aug 17, 2024 at 5:35 AM Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> wrote:
>
> On Sat, Aug 17, 2024 at 05:27:17PM +0800, Alex Young wrote:
> > Hi Jamal,
> >
> > Thanks your mention. I have reviewed the latest kernel code.
> > I understand why these two tc function threads can enter the kernel at the same
> > time. It's because the request_module[2] function in tcf_action_init_1. When the
> > tc_action_init_1 function to add a new action, it will load the action
> > module. It will
> > call rtnl_unlock to let the Thread2 into the kernel space.
> >
> > Thread1                                                 Thread2
> > rtnetlink_rcv_msg                                   rtnetlink_rcv_msg
> >  rtnl_lock();
> >  tcf_action_init
> >   for(i;i<TCA_ACT_MAX_PRIO;i++)
> >    act=tcf_action_init_1 //[1]
> >         if (rtnl_held)
> >            rtnl_unlock(); //[2]
> >         request_module("act_%s", act_name);
> >
> >                                                                 tcf_del_walker
> >
> > idr_for_each_entry_ul(idr,p,id)
> >
> > __tcf_idr_release(p,false,true)
> >
> >  free_tcf(p) //[3]
> > if (rtnl_held)
> > rtnl_lock();
> >
> >    if(IS_ERR(act))
> >     goto err
> >    actions[i] = act
> >
> >   err:
> >    tcf_action_destroy
> >     a=actions[i]
> >     ops = a->ops //[4]
> > I know this time window is small, but it can indeed cause the bug. And
> > in the latest
> > kernel, it have fixed the bug. But version 4.19.x is still a
> > maintenance version.
>
> 4.19.y is only going to be alive for 4 more months, and anyone still
> using it now really should have their plans to move off of it finished
> already (or almost finished.)
>
> If this is a request_module issue, and you care about 4.19.y kernels,
> just add that module to the modprobe exclude list in userspace which
> will prevent it from being loaded automatically.  Or load it at boot
> time.
>
> And what specific commit resolved this issue in the older kernels?  Have
> you attempted to just backport that change to 4.19.y?
>

And if you or anyone cares, here it is:
d349f997686887906b1183b5be96933c5452362a

cheers,
jamal