netdev - 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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <2024081722-reflex-reverend-4916@gregkh>
Date: Sat, 17 Aug 2024 11:35:30 +0200
From: Greg KH <gregkh@...uxfoundation.org>
To: Alex Young <alex000young@...il.com>
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

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?

thanks,

greg k-h