CVE-2025-38001

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net_sched: hfsc: Address reentrant enqueue adding class to eltree twice<br /> <br /> Savino says:<br /> "We are writing to report that this recent patch<br /> (141d34391abbb315d68556b7c67ad97885407547) [1]<br /> can be bypassed, and a UAF can still occur when HFSC is utilized with<br /> NETEM.<br /> <br /> The patch only checks the cl-&gt;cl_nactive field to determine whether<br /> it is the first insertion or not [2], but this field is only<br /> incremented by init_vf [3].<br /> <br /> By using HFSC_RSC (which uses init_ed) [4], it is possible to bypass the<br /> check and insert the class twice in the eltree.<br /> Under normal conditions, this would lead to an infinite loop in<br /> hfsc_dequeue for the reasons we already explained in this report [5].<br /> <br /> However, if TBF is added as root qdisc and it is configured with a<br /> very low rate,<br /> it can be utilized to prevent packets from being dequeued.<br /> This behavior can be exploited to perform subsequent insertions in the<br /> HFSC eltree and cause a UAF."<br /> <br /> To fix both the UAF and the infinite loop, with netem as an hfsc child,<br /> check explicitly in hfsc_enqueue whether the class is already in the eltree<br /> whenever the HFSC_RSC flag is set.<br /> <br /> [1] https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=141d34391abbb315d68556b7c67ad97885407547<br /> [2] https://elixir.bootlin.com/linux/v6.15-rc5/source/net/sched/sch_hfsc.c#L1572<br /> [3] https://elixir.bootlin.com/linux/v6.15-rc5/source/net/sched/sch_hfsc.c#L677<br /> [4] https://elixir.bootlin.com/linux/v6.15-rc5/source/net/sched/sch_hfsc.c#L1574<br /> [5] https://lore.kernel.org/netdev/8DuRWwfqjoRDLDmBMlIfbrsZg9Gx50DHJc1ilxsEBNe2D6NMoigR_eIRIG0LOjMc3r10nUUZtArXx4oZBIdUfZQrwjcQhdinnMis_0G7VEk=@willsroot.io/T/#u