Merge branch 'net_sched-hfsc-address-reentrant-enqueue-adding-class-to-eltree-twice'
authorPaolo Abeni <pabeni@redhat.com>
Wed, 28 May 2025 06:55:37 +0000 (08:55 +0200)
committerPaolo Abeni <pabeni@redhat.com>
Wed, 28 May 2025 06:55:37 +0000 (08:55 +0200)
commitfc6895345fe682e68bc594a186cbf90d35b3bf7c
tree2fe30b4d54a65895576f9c93aa8c01678131fceb
parent67af4ec948e8ce3ea53a9cf614d01fddf172e56d
parent2945ff733dee951ed64d0f13cba22348bfc1f438
Merge branch 'net_sched-hfsc-address-reentrant-enqueue-adding-class-to-eltree-twice'

Pedro Tammela says:

====================
net_sched: hfsc: Address reentrant enqueue adding class to eltree twice

Savino says:
    "We are writing to report that this recent patch
    (141d34391abbb315d68556b7c67ad97885407547)
    can be bypassed, and a UAF can still occur when HFSC is utilized with
    NETEM.

    The patch only checks the cl->cl_nactive field to determine whether
    it is the first insertion or not, but this field is only
    incremented by init_vf.

    By using HFSC_RSC (which uses init_ed), it is possible to bypass the
    check and insert the class twice in the eltree.
    Under normal conditions, this would lead to an infinite loop in
    hfsc_dequeue for the reasons we already explained in this report.

    However, if TBF is added as root qdisc and it is configured with a
    very low rate,
    it can be utilized to prevent packets from being dequeued.
    This behavior can be exploited to perform subsequent insertions in the
    HFSC eltree and cause a UAF."

To fix both the UAF and the infinite loop, with netem as an hfsc child,
check explicitly in hfsc_enqueue whether the class is already in the eltree
whenever the HFSC_RSC flag is set.

Also add a TDC test to reproduce the UAF scenario.
====================

Link: https://patch.msgid.link/20250522181448.1439717-1-pctammela@mojatatu.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>