linux-kernel - Re: [PATCH] net: sched: use-after-free in tcf_action

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAFC++j0y7LZuZaZrVa01o3d1OSbo1VOccEw=zhJ+nc=-6bZOQg@mail.gmail.com>
Date: Mon, 19 Aug 2024 09:10:45 +0800
From: Alex Young <alex000young@...il.com>
To: Greg KH <gregkh@...uxfoundation.org>
Cc: Jamal Hadi Salim <jhs@...atatu.com>, netdev@...r.kernel.org, linux-kernel@...r.kernel.org, 
	xiyou.wangcong@...il.com, jiri@...nulli.us, davem@...emloft.net, 
	security@...nel.org, xkaneiki@...il.com, hackerzheng666@...il.com
Subject: Re: [PATCH] net: sched: use-after-free in tcf_action_destroy

Hi greg.
Thanks for your suggestion. I will try to use the new kernel.
By the way, the 5.4.y you mentioned does not fix this bug either.

Best regards,
Alex

Greg KH <gregkh@...uxfoundation.org> 于2024年8月18日周日 18:40写道：
>
> On Sat, Aug 17, 2024 at 08:11:50AM -0400, Jamal Hadi Salim wrote:
> > On Sat, Aug 17, 2024 at 5:35 AM Greg KH <gregkh@...uxfoundation.org> 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
>
> Thanks for that.  Looks like it might be good to backport that to 5.4.y
> if someone cares about this issue there as well.
>
> thanks,
>
> greg k-h