diff options
author | Paolo Abeni <pabeni@redhat.com> | 2025-05-28 08:55:37 +0200 |
---|---|---|
committer | Paolo Abeni <pabeni@redhat.com> | 2025-05-28 08:55:37 +0200 |
commit | fc6895345fe682e68bc594a186cbf90d35b3bf7c (patch) | |
tree | 2fe30b4d54a65895576f9c93aa8c01678131fceb /scripts/lib/kdoc/kdoc_files.py | |
parent | 67af4ec948e8ce3ea53a9cf614d01fddf172e56d (diff) | |
parent | 2945ff733dee951ed64d0f13cba22348bfc1f438 (diff) |
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>
Diffstat (limited to 'scripts/lib/kdoc/kdoc_files.py')
0 files changed, 0 insertions, 0 deletions