Re: [PATCH v2] net/sched: fix use-after-free in taprio_dev_notifier

[Hyunwoo Kim <imv4bel@gmail.com>]

On Fri, Jun 13, 2025 at 11:52:06PM +0300, Vladimir Oltean wrote:
> On Thu, Jun 12, 2025 at 11:36:12PM -0400, Hyunwoo Kim wrote:
> > On Thu, Jun 12, 2025 at 01:23:38PM -0700, Cong Wang wrote:
> > > On Thu, Jun 12, 2025 at 07:16:55AM -0400, Hyunwoo Kim wrote:
> > > > diff --git a/net/sched/sch_taprio.c b/net/sched/sch_taprio.c
> > > > index 14021b812329..bd2b02d1dc63 100644
> > > > --- a/net/sched/sch_taprio.c
> > > > +++ b/net/sched/sch_taprio.c
> > > > @@ -1320,6 +1320,7 @@ static int taprio_dev_notifier(struct notifier_block *nb, unsigned long event,
> > > >     if (event != NETDEV_UP && event != NETDEV_CHANGE)
> > > >             return NOTIFY_DONE;
> > > >
> > > > +   rcu_read_lock();
> > > >     list_for_each_entry(q, &taprio_list, taprio_list) {
> > > >             if (dev != qdisc_dev(q->root))
> > > >                     continue;
> > > > @@ -1328,16 +1329,17 @@ static int taprio_dev_notifier(struct notifier_block *nb, unsigned long event,
> > >
> > > There is a taprio_set_picos_per_byte() call here, it calls
> > > __ethtool_get_link_ksettings() which could be blocking.
> > >
> > > For instance, gve_get_link_ksettings() calls
> > > gve_adminq_report_link_speed() which is a blocking function.
> > >
> > > So I am afraid we can't enforce an atomic context here.
> > 
> > In that case, how about moving the lock as follows so that
> > taprio_set_picos_per_byte() isn’t included within it?
> > 
> > ```
> > diff --git a/net/sched/sch_taprio.c b/net/sched/sch_taprio.c
> > index 14021b812329..2b14c81a87e5 100644
> > --- a/net/sched/sch_taprio.c
> > +++ b/net/sched/sch_taprio.c
> > @@ -1328,13 +1328,15 @@ static int taprio_dev_notifier(struct notifier_block *nb, unsigned long event,
> > 
> >                 stab = rtnl_dereference(q->root->stab);
> > 
> > -               oper = rtnl_dereference(q->oper_sched);
> > +               rcu_read_lock();
> > +               oper = rcu_dereference(q->oper_sched);
> >                 if (oper)
> >                         taprio_update_queue_max_sdu(q, oper, stab);
> > 
> > -               admin = rtnl_dereference(q->admin_sched);
> > +               admin = rcu_dereference(q->admin_sched);
> >                 if (admin)
> >                         taprio_update_queue_max_sdu(q, admin, stab);
> > +               rcu_read_unlock();
> > 
> >                 break;
> >         }
> > ```
> > 
> > This change still prevents the race condition with advance_sched().
> 
> This should work.

OK, I’ll submit the v3 patch.

> 
> And I'm sorry for the bug introduced here, and elsewhere, by assuming
> rtnl_dereference() will be fine.
> I mostly use taprio with offload, where switch_schedules() runs in
> process context with rtnl_lock() held, not the software emulation that
> changes the schedules from the advance_sched() hrtimer. Somehow the
> different locking requirements for the 2 cases eluded me.