Описание
In the Linux kernel, the following vulnerability has been resolved:
wifi: mac80211: reset the AP_VLAN tailroom counter on ifdown
On ifup, AP_VLAN interfaces get crypto_tx_tailroom_needed_cnt from
the AP interface, but it's never decremented again unless the AP is
also brought down. Thus, bringing the same AP_VLAN up again will
increment the counter again and eventually hit the sanity check:
WARN_ON_ONCE(sdata->crypto_tx_tailroom_needed_cnt !=
master->crypto_tx_tailroom_needed_cnt);
Reset it on ifdown to avoid that.
A flaw was found in the Linux kernel's mac80211 wireless subsystem. A local user with network administration privileges can cause a Denial of Service (DoS) by repeatedly activating and deactivating Access Point Virtual Local Area Network (AP_VLAN) interfaces. When an AP_VLAN interface is stopped, the kernel fails to reset an internal cryptographic buffer counter. Bringing the interface back up causes this counter to continuously increment, eventually triggering a kernel sanity check failure and potential system crash.
Отчет
A low impact flaw was found in the Linux kernel's mac80211 wireless subsystem. When an AP_VLAN interface is brought down, the crypto_tx_tailroom_needed_cnt counter it acquired from the master AP interface during ifup is not reset. A local user with network administration privileges (CAP_NET_ADMIN) can exploit this by repeatedly bringing an AP_VLAN interface up and down, causing the counter to increment on each cycle until it no longer matches the master interface's value and triggers the WARN_ON_ONCE sanity check in mac80211. The demonstrated impact is limited to incorrect state accounting and a kernel warning; a system crash and denial of service is possible only on systems configured to panic on warnings (for example with panic_on_warn enabled). Although the Red Hat CVSS:3.1 base score is 5.5 (Moderate), Red Hat Product Security assessed the overall impact of this flaw as low, because exploitation requires local administrative privileges and there is no confidentiality, integrity, or privilege escalation impact. This flaw affects the kernel and kernel-rt packages in Red Hat Enterprise Linux 8, 9, and 10, Red Hat In-Vehicle OS 2, and the RHEL CoreOS-based nodes of OpenShift Container Platform 4 and 5. For these products the fix is currently deferred: the issue is a low-impact, privilege-gated kernel warning that can only be triggered by a local user who already controls network interface administration, and the residual risk is limited to a kernel warning, or a panic only on hosts where panic-on-warning is enabled and such a user repeatedly toggles AP_VLAN interfaces. Red Hat Enterprise Linux 7 is not affected because the vulnerable code is not present in that stream, and Red Hat Enterprise Linux 6 is out of support scope.
Меры по смягчению последствий
Mitigation for this issue is either not available or the currently available options do not meet the Red Hat Product Security criteria comprising ease of use and deployment, applicability to widespread installation base, or stability.
Затронутые пакеты
| Платформа | Пакет | Состояние | Рекомендация | Релиз |
|---|---|---|---|---|
| Red Hat Enterprise Linux 10 | kernel | Fix deferred | ||
| Red Hat Enterprise Linux 6 | kernel | Out of support scope | ||
| 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 | Fix deferred | ||
| Red Hat Enterprise Linux 9 | kernel-rt | Fix deferred | ||
| Red Hat OpenShift Container Platform 4 | openshift/ose-rhel-coreos-8 | Fix deferred | ||
| Red Hat OpenShift Container Platform 4 | openshift/ose-rhel-coreos-9 | Fix deferred |
Показывать по
Дополнительная информация
Статус:
EPSS
5.5 Medium
CVSS3
Связанные уязвимости
In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: reset the AP_VLAN tailroom counter on ifdown On ifup, AP_VLAN interfaces get crypto_tx_tailroom_needed_cnt from the AP interface, but it's never decremented again unless the AP is also brought down. Thus, bringing the same AP_VLAN up again will increment the counter again and eventually hit the sanity check: WARN_ON_ONCE(sdata->crypto_tx_tailroom_needed_cnt != master->crypto_tx_tailroom_needed_cnt); Reset it on ifdown to avoid that.
In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: reset the AP_VLAN tailroom counter on ifdown On ifup, AP_VLAN interfaces get crypto_tx_tailroom_needed_cnt from the AP interface, but it's never decremented again unless the AP is also brought down. Thus, bringing the same AP_VLAN up again will increment the counter again and eventually hit the sanity check: WARN_ON_ONCE(sdata->crypto_tx_tailroom_needed_cnt != master->crypto_tx_tailroom_needed_cnt); Reset it on ifdown to avoid that.
wifi: mac80211: reset the AP_VLAN tailroom counter on ifdown
In the Linux kernel, the following vulnerability has been resolved: w ...
In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: reset the AP_VLAN tailroom counter on ifdown On ifup, AP_VLAN interfaces get crypto_tx_tailroom_needed_cnt from the AP interface, but it's never decremented again unless the AP is also brought down. Thus, bringing the same AP_VLAN up again will increment the counter again and eventually hit the sanity check: WARN_ON_ONCE(sdata->crypto_tx_tailroom_needed_cnt != master->crypto_tx_tailroom_needed_cnt); Reset it on ifdown to avoid that.
EPSS
5.5 Medium
CVSS3