Skip to content

[FIPS 9.2] net_sched: hfsc: Address reentrant enqueue adding class to eltree twice #514

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
wants to merge 2 commits into
base: fips-9-compliant/5.14.0-284.30.1
Choose a base branch
from
Open

[FIPS 9.2] net_sched: hfsc: Address reentrant enqueue adding class to eltree twice #514

wants to merge 2 commits into from
+8 −1

Conversation

pvts-mat
Copy link
Contributor

[FIPS 9.2]
CVE-2025-37890
VULN-68297

Problem

https://access.redhat.com/security/cve/CVE-2025-37890

A use-after-free vulnerability has been identified in the Linux kernel's HFSC (Hierarchical Fair Service Curve) queuing discipline when it is configured with NETEM (Network Emulation) as a child. This flaw can lead to a kernel panic or crash due to incorrect assumptions about the queue state. Exploitation of this vulnerability requires local access with CAP_NET_ADMIN privileges and control over the qdisc (queueing discipline) setup. A local attacker could leverage this flaw to achieve denial of service or escalate privileges. Given that it affects kernel memory structures, successful exploitation could result in memory corruption, data leaks, or arbitrary write capabilities, leading to a full kernel crash.

Applicability: yes

The patch relates to the sch_hfsc module, enabled with the NET_SCH_HFSC option. It's set to m in all configs of FIPS 9.2:

$ grep 'NET_SCH_HFSC\b' configs/*.config

configs/kernel-aarch64-64k-debug-rhel.config:CONFIG_NET_SCH_HFSC=m
configs/kernel-aarch64-64k-rhel.config:CONFIG_NET_SCH_HFSC=m
configs/kernel-aarch64-debug-rhel.config:CONFIG_NET_SCH_HFSC=m
configs/kernel-aarch64-rhel.config:CONFIG_NET_SCH_HFSC=m
configs/kernel-ppc64le-debug-rhel.config:CONFIG_NET_SCH_HFSC=m
configs/kernel-ppc64le-rhel.config:CONFIG_NET_SCH_HFSC=m
configs/kernel-s390x-debug-rhel.config:CONFIG_NET_SCH_HFSC=m
configs/kernel-s390x-rhel.config:CONFIG_NET_SCH_HFSC=m
configs/kernel-s390x-zfcpdump-rhel.config:CONFIG_NET_SCH_HFSC=m
configs/kernel-x86_64-debug-rhel.config:CONFIG_NET_SCH_HFSC=m
configs/kernel-x86_64-rhel.config:CONFIG_NET_SCH_HFSC=m

The commit 37d9cf1 marked as introducing the bug is present in fips-9-compliant/5.14.0-284.30.1's history. The mainline fix 141d343 is not present nor was it backported. For the full picture please refer to the "Appendix: Bug timeline" section in #510.

Solution

The same situation as in #490, which see.

kABI check: passed

$ DEBUG=1 CVE=CVE-2025-37890 ./ninja.sh _kabi_checked__x86_64--test--fips9c-CVE-2025-37890

[0/1] Check ABI of kernel [fips9c-CVE-2025-37890]
++ uname -m
+ python3 /data/src/ctrliq-github/kernel-dist-git-el-9.2/SOURCES/check-kabi -k /data/src/ctrliq-github/kernel-dist-git-el-9.2/SOURCES/Module.kabi_x86_64 -s vms/x86_64--build--ciqlts9_2/build_files/kernel-src-tree-fips9c-CVE-2025-37890/Module.symvers
kABI check passed
+ touch state/kernels/fips9c-CVE-2025-37890/x86_64/kabi_checked

Boot test: passed

boot-test.log

Kselftests: passed relative

Coverage

Only the net-related tests were run.

  • net/forwarding (except ipip_hier_gre_keys.sh, gre_inner_v6_multipath.sh, sch_tbf_ets.sh, mirror_gre_bridge_1d_vlan.sh, mirror_gre_vlan_bridge_1q.sh, sch_tbf_prio.sh, bridge_igmp.sh, sch_tbf_root.sh, tc_actions.sh, sch_ets.sh, vxlan_bridge_1d_ipv6.sh, sch_red.sh, q_in_vni.sh, dual_vxlan_bridge.sh, tc_police.sh),
  • net/mptcp (except mptcp_join.sh, simult_flows.sh, userspace_pm.sh),
  • net (except ip_defrag.sh, txtimestamp.sh, udpgro_fwd.sh, fib_nexthops.sh, gro.sh, xfrm_policy.sh, reuseport_addr_any.sh, udpgso_bench.sh),
  • netfilter (except nft_trans_stress.sh)

Reference

kselftests–fips9c–run1.log
kselftests–fips9c–run2.log

Patch

kselftests–fips9c-CVE-2025-37890–run1.log
kselftests–fips9c-CVE-2025-37890–run2.log

Comparison

The results for the reference and the patch are the same:

$ ktests.xsh diff -d kselftests*.log

Column    File
--------  -------------------------------------------
Status0   kselftests--fips9c--run1.log
Status1   kselftests--fips9c--run2.log
Status2   kselftests--fips9c-CVE-2025-37890--run1.log
Status3   kselftests--fips9c-CVE-2025-37890--run2.log

Specific tests: skipped

@pvts-mat
net_sched: hfsc: Fix a UAF vulnerability in class with netem as child…
b83eaea 
… qdisc

jira VULN-68297
cve CVE-2025-37890
commit-author Victor Nogueira <[email protected]>
commit 141d343

As described in Gerrard's report [1], we have a UAF case when an hfsc class
has a netem child qdisc. The crux of the issue is that hfsc is assuming
that checking for cl->qdisc->q.qlen == 0 guarantees that it hasn't inserted
the class in the vttree or eltree (which is not true for the netem
duplicate case).

This patch checks the n_active class variable to make sure that the code
won't insert the class in the vttree or eltree twice, catering for the
reentrant case.

[1] https://lore.kernel.org/netdev/CAHcdcOm+03OD2j6R0=YHKqmy=VgJ8xEOKuP6c7mSgnp-TEJJbw@mail.gmail.com/

Fixes: 37d9cf1 ("sched: Fix detection of empty queues in child qdiscs")
	Reported-by: Gerrard Tai <[email protected]>
	Acked-by: Jamal Hadi Salim <[email protected]>
	Signed-off-by: Victor Nogueira <[email protected]>
Link: https://patch.msgid.link/[email protected]
	Signed-off-by: Jakub Kicinski <[email protected]>
(cherry picked from commit 141d343)
	Signed-off-by: Marcin Wcisło <[email protected]>
@pvts-mat
net_sched: hfsc: Address reentrant enqueue adding class to eltree twice
d7fd1e8 
jira VULN-68297
cve-bf CVE-2025-37890
commit-author Pedro Tammela <[email protected]>
commit ac9fe7d

Savino says:
    "We are writing to report that this recent patch
    (141d343) [1]
    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 [2], but this field is only
    incremented by init_vf [3].

    By using HFSC_RSC (which uses init_ed) [4], 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 [5].

    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.

[1] https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=141d34391abbb315d68556b7c67ad97885407547
[2] https://elixir.bootlin.com/linux/v6.15-rc5/source/net/sched/sch_hfsc.c#L1572
[3] https://elixir.bootlin.com/linux/v6.15-rc5/source/net/sched/sch_hfsc.c#L677
[4] https://elixir.bootlin.com/linux/v6.15-rc5/source/net/sched/sch_hfsc.c#L1574
[5] https://lore.kernel.org/netdev/8DuRWwfqjoRDLDmBMlIfbrsZg9Gx50DHJc1ilxsEBNe2D6NMoigR_eIRIG0LOjMc3r10nUUZtArXx4oZBIdUfZQrwjcQhdinnMis_0G7VEk=@willsroot.io/T/#u

Fixes: 37d9cf1 ("sched: Fix detection of empty queues in child qdiscs")
	Reported-by: Savino Dicanosa <[email protected]>
	Reported-by: William Liu <[email protected]>
	Acked-by: Jamal Hadi Salim <[email protected]>
	Tested-by: Victor Nogueira <[email protected]>
	Signed-off-by: Pedro Tammela <[email protected]>
Link: https://patch.msgid.link/[email protected]
	Signed-off-by: Paolo Abeni <[email protected]>

(cherry picked from commit ac9fe7d)
	Signed-off-by: Marcin Wcisło <[email protected]>
bmastbergen
bmastbergen approved these changes Aug 20, 2025
View reviewed changes
Copy link
Collaborator

@bmastbergen bmastbergen left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🥌

thefossguy-ciq
thefossguy-ciq approved these changes Aug 20, 2025
View reviewed changes
Copy link

@thefossguy-ciq thefossguy-ciq left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🚤

@pvts-mat
Copy link
Contributor Author

Looks like the pushed solution for CVE-2025-37890 addresses also the CVE-2025-38001 I'm finding on my todo list

https://www.cve.org/CVERecord?id=CVE-2025-38001

In the Linux kernel, the following vulnerability has been resolved: netsched: hfsc: Address reentrant enqueue adding class to eltree twice Savino says: "We are writing to report that this recent patch (141d343) [1] can be bypassed […]

This commit was already included as the CVE-2025-37890 bugfix. I guess the message header of d7fd1e8 should be changed from

jira VULN-68297
cve-bf CVE-2025-37890
commit-author Pedro Tammela <[email protected]>
commit ac9fe7dd8e730a103ae4481147395cc73492d786

to

jira VULN-68297
jira VULN-68366
cve-bf CVE-2025-37890
cve CVE-2025-38001
commit-author Pedro Tammela <[email protected]>
commit ac9fe7dd8e730a103ae4481147395cc73492d786

This would be then inconsistent though with 6228d81 for the LTS 9.2 which was already merged. I don't know if it matters or not. @PlaidCat?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@bmastbergen bmastbergen bmastbergen approved these changes

@thefossguy-ciq thefossguy-ciq thefossguy-ciq approved these changes

@shreeya-patel98 shreeya-patel98 shreeya-patel98 approved these changes

@kerneltoast kerneltoast Awaiting requested review from kerneltoast

@PlaidCat PlaidCat Awaiting requested review from PlaidCat

Assignees
No one assigned
Labels
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
4 participants
@pvts-mat @bmastbergen @thefossguy-ciq @shreeya-patel98