cve/2024/CVE-2024-53057.md

### [CVE-2024-53057](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-53057)
![](https://img.shields.io/static/v1?label=Product&message=Linux&color=blue)
![](https://img.shields.io/static/v1?label=Version&message=&color=brightgreen)
![](https://img.shields.io/static/v1?label=Version&message=066a3b5b2346febf9a655b444567b7138e3bb939%20&color=brightgreen)
![](https://img.shields.io/static/v1?label=Version&message=2.6.25%20&color=brightgreen)
![](https://img.shields.io/static/v1?label=Vulnerability&message=n%2Fa&color=blue)

### Description

In the Linux kernel, the following vulnerability has been resolved:net/sched: stop qdisc_tree_reduce_backlog on TC_H_ROOTIn qdisc_tree_reduce_backlog, Qdiscs with major handle ffff: are assumedto be either root or ingress. This assumption is bogus since it's validto create egress qdiscs with major handle ffff:Budimir Markovic found that for qdiscs like DRR that maintain an activeclass list, it will cause a UAF with a dangling class pointer.In 066a3b5b2346, the concern was to avoid iterating over the ingressqdisc since its parent is itself. The proper fix is to stop when parentTC_H_ROOT is reached because the only way to retrieve ingress is when ahierarchy which does not contain a ffff: major handle call intoqdisc_lookup with TC_H_MAJ(TC_H_ROOT).In the scenario where major ffff: is an egress qdisc in any of the treelevels, the updates will also propagate to TC_H_ROOT, which then theiteration must stop. net/sched/sch_api.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)

### POC

#### Reference
No PoCs from references.

#### Github
- https://github.com/w4zu/Debian_security