Описание
In the Linux kernel, the following vulnerability has been resolved:
net/sched: hhf: cap hh_flows_limit at change time
hhf_change() stores TCA_HHF_HH_FLOWS_LIMIT with no upper bound. A huge
hh_flows_limit lets each new heavy-hitter flow pass the
hh_flows_current_cnt check in alloc_new_hh() and forces a fixed-size
kzalloc(GFP_ATOMIC) per flow under spoofed traffic, for unbounded memory
growth.
Bound the attribute with NLA_POLICY_MAX() at 2*HH_FLOWS_CNT (the
hhf_init() default) and report the rejected value via extack. The
deprecated nested parse is kept: legacy tc does not set NLA_F_NESTED on
TCA_OPTIONS. Configs relying on hh_limit above the default were relying
on unbounded, unsafe behaviour and are not supported going forward.
hhf_init() also ran hhf_change() before setting the default
hh_flows_limit, so a user-supplied hh_limit at add time was clobbered
back to 2048. Set the default before hhf_change() so the configured
value sticks.
This is a follow-up to commit eb56a495f59b ("net/sched: hhf: clamp
quantum in change and init paths"), which bounded the quantum of the
same qdisc; the hh_flows_limit bound is the remaining unbounded knob of
that series' scope.
Conditions to recreate the bug: CAP_NET_ADMIN in a user namespace;
tc qdisc change dev X root hhf hh_limit 4294967295 succeeds and the
value is echoed by tc qdisc show, unbounding heavy-hitter flow
allocations; also tc qdisc add dev X root hhf hh_limit 500 stores 2048
instead of 500.
A flaw was found in the Linux kernel's Heavy-Hitter Filter (HHF) network packet scheduler. A local user with network administration privileges, such as within a container or user namespace, can set an excessively large flow limit due to missing upper-bound validation. When the system subsequently handles network traffic containing multiple new flows, it allocates memory without restriction. This issue allows an attacker to cause excessive memory consumption, resulting in a system crash and Denial of Service (DoS).
Отчет
A low impact vulnerability was found in the Linux kernel's Heavy-Hitter Filter (HHF) network packet scheduler as shipped in Red Hat Enterprise Linux 8, including the RHEL CoreOS 8 kernel used in OpenShift Container Platform 4.12. The hh_flows_limit qdisc parameter (TCA_HHF_HH_FLOWS_LIMIT) was stored without an upper-bound check, so a local user with network administration privileges (CAP_NET_ADMIN, which an unprivileged user can obtain inside a user namespace or container) can configure an excessively large flow limit. When the system subsequently handles traffic containing many new flows, the kernel performs a fixed-size memory allocation for each newly classified heavy-hitter flow without an effective cap, allowing unbounded kernel memory consumption that can result in memory exhaustion, a system crash, and denial of service. The flaw provides no memory corruption, information disclosure, or privilege escalation primitive; its impact is limited to availability, and exploitation requires local access together with network administration privileges. For this reason Red Hat rates the impact as Low, lower than the Moderate severity indicated by the CVSS:3.1 base score of 5.5. The affected Red Hat Enterprise Linux 8 kernel and kernel-rt update streams and the RHEL CoreOS 8 component of OpenShift Container Platform 4.12 are currently marked affected with the fix deferred because of the low severity of this availability-only issue; the residual risk is that a local user holding the required privileges can still cause kernel memory exhaustion and denial of service on those systems. All other Red Hat products and update streams, including Red Hat Enterprise Linux 6, 7, 9, and 10, Red Hat In-Vehicle OS, and OpenShift Container Platform releases based on RHEL CoreOS 9, are marked not affected because the vulnerable code is not present in their kernels.
Меры по смягчению последствий
Only a user with the CAP_NET_ADMIN capability can trigger this flaw, because exploitation requires configuring the HHF queueing discipline through the tc utility. Avoiding the use of the HHF qdisc, or leaving its hh_limit parameter at the default value (2048), prevents the unbounded per-flow memory allocation. Additionally, on systems where untrusted local users can obtain CAP_NET_ADMIN inside user namespaces or containers, disabling or limiting the creation of unprivileged user namespaces (for example by setting the user.max_user_namespaces sysctl to 0) prevents such users from triggering this issue.
Затронутые пакеты
| Платформа | Пакет | Состояние | Рекомендация | Релиз |
|---|---|---|---|---|
| Red Hat Enterprise Linux 10 | kernel | Not affected | ||
| Red Hat Enterprise Linux 6 | kernel | Not affected | ||
| Red Hat Enterprise Linux 7 | kernel | Not affected | ||
| Red Hat Enterprise Linux 7 | kernel-rt | Not affected | ||
| Red Hat Enterprise Linux 8 | kernel | Fix deferred | ||
| Red Hat Enterprise Linux 8 | kernel-rt | Fix deferred | ||
| Red Hat Enterprise Linux 9 | kernel | Not affected | ||
| Red Hat Enterprise Linux 9 | kernel-rt | Not affected | ||
| Red Hat OpenShift Container Platform 4 | openshift/ose-rhel-coreos-8 | Fix deferred | ||
| Red Hat OpenShift Container Platform 4 | openshift/ose-rhel-coreos-9 | Not affected |
Показывать по
Дополнительная информация
Статус:
EPSS
5.5 Medium
CVSS3
Связанные уязвимости
In the Linux kernel, the following vulnerability has been resolved: net/sched: hhf: cap hh_flows_limit at change time hhf_change() stores TCA_HHF_HH_FLOWS_LIMIT with no upper bound. A huge hh_flows_limit lets each new heavy-hitter flow pass the hh_flows_current_cnt check in alloc_new_hh() and forces a fixed-size kzalloc(GFP_ATOMIC) per flow under spoofed traffic, for unbounded memory growth. Bound the attribute with NLA_POLICY_MAX() at 2*HH_FLOWS_CNT (the hhf_init() default) and report the rejected value via extack. The deprecated nested parse is kept: legacy tc does not set NLA_F_NESTED on TCA_OPTIONS. Configs relying on hh_limit above the default were relying on unbounded, unsafe behaviour and are not supported going forward. hhf_init() also ran hhf_change() before setting the default hh_flows_limit, so a user-supplied hh_limit at add time was clobbered back to 2048. Set the default before hhf_change() so the configured value sticks. This is a follow-up to commit eb56a495f59b ("ne...
In the Linux kernel, the following vulnerability has been resolved: net/sched: hhf: cap hh_flows_limit at change time hhf_change() stores TCA_HHF_HH_FLOWS_LIMIT with no upper bound. A huge hh_flows_limit lets each new heavy-hitter flow pass the hh_flows_current_cnt check in alloc_new_hh() and forces a fixed-size kzalloc(GFP_ATOMIC) per flow under spoofed traffic, for unbounded memory growth. Bound the attribute with NLA_POLICY_MAX() at 2*HH_FLOWS_CNT (the hhf_init() default) and report the rejected value via extack. The deprecated nested parse is kept: legacy tc does not set NLA_F_NESTED on TCA_OPTIONS. Configs relying on hh_limit above the default were relying on unbounded, unsafe behaviour and are not supported going forward. hhf_init() also ran hhf_change() before setting the default hh_flows_limit, so a user-supplied hh_limit at add time was clobbered back to 2048. Set the default before hhf_change() so the configured value sticks. This is a follow-up to commit eb56a495f59b ("
In the Linux kernel, the following vulnerability has been resolved: n ...
In the Linux kernel, the following vulnerability has been resolved: net/sched: hhf: cap hh_flows_limit at change time hhf_change() stores TCA_HHF_HH_FLOWS_LIMIT with no upper bound. A huge hh_flows_limit lets each new heavy-hitter flow pass the hh_flows_current_cnt check in alloc_new_hh() and forces a fixed-size kzalloc(GFP_ATOMIC) per flow under spoofed traffic, for unbounded memory growth. Bound the attribute with NLA_POLICY_MAX() at 2*HH_FLOWS_CNT (the hhf_init() default) and report the rejected value via extack. The deprecated nested parse is kept: legacy tc does not set NLA_F_NESTED on TCA_OPTIONS. Configs relying on hh_limit above the default were relying on unbounded, unsafe behaviour and are not supported going forward. hhf_init() also ran hhf_change() before setting the default hh_flows_limit, so a user-supplied hh_limit at add time was clobbered back to 2048. Set the default before hhf_change() so the configured value sticks. This is a follow-up to commit eb56a495f59b...
EPSS
5.5 Medium
CVSS3