Описание
In the Linux kernel, the following vulnerability has been resolved:
irqchip/gic-v4: Don't allow a VMOVP on a dying VPE
Kunkun Jiang reported that there is a small window of opportunity for
userspace to force a change of affinity for a VPE while the VPE has already
been unmapped, but the corresponding doorbell interrupt still visible in
/proc/irq/.
Plug the race by checking the value of vmapp_count, which tracks whether
the VPE is mapped ot not, and returning an error in this case.
This involves making vmapp_count common to both GICv4.1 and its v4.0
ancestor.
A flaw was found in the Linux kernel. A race condition exists in the irqchip/gic-v4 component, where a local user can force a change of affinity for a Virtual Processing Element (VPE) after it has been unmapped. This occurs because the corresponding doorbell interrupt remains visible, creating a window for exploitation. This vulnerability could lead to a denial of service.
Меры по смягчению последствий
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 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-rt | Fixed | RHSA-2024:10944 | 11.12.2024 |
| Red Hat Enterprise Linux 8 | kernel | Fixed | RHSA-2024:10943 | 11.12.2024 |
| Red Hat Enterprise Linux 9 | kernel | Fixed | RHSA-2024:11486 | 19.12.2024 |
| Red Hat Enterprise Linux 9 | kernel | Fixed | RHSA-2024:11486 | 19.12.2024 |
| Red Hat Enterprise Linux 9.4 Extended Update Support | kernel | Fixed | RHSA-2025:3935 | 16.04.2025 |
Показывать по
Дополнительная информация
Статус:
EPSS
4.7 Medium
CVSS3
Связанные уязвимости
In the Linux kernel, the following vulnerability has been resolved: irqchip/gic-v4: Don't allow a VMOVP on a dying VPE Kunkun Jiang reported that there is a small window of opportunity for userspace to force a change of affinity for a VPE while the VPE has already been unmapped, but the corresponding doorbell interrupt still visible in /proc/irq/. Plug the race by checking the value of vmapp_count, which tracks whether the VPE is mapped ot not, and returning an error in this case. This involves making vmapp_count common to both GICv4.1 and its v4.0 ancestor.
In the Linux kernel, the following vulnerability has been resolved: irqchip/gic-v4: Don't allow a VMOVP on a dying VPE Kunkun Jiang reported that there is a small window of opportunity for userspace to force a change of affinity for a VPE while the VPE has already been unmapped, but the corresponding doorbell interrupt still visible in /proc/irq/. Plug the race by checking the value of vmapp_count, which tracks whether the VPE is mapped ot not, and returning an error in this case. This involves making vmapp_count common to both GICv4.1 and its v4.0 ancestor.
In the Linux kernel, the following vulnerability has been resolved: i ...
In the Linux kernel, the following vulnerability has been resolved: irqchip/gic-v4: Don't allow a VMOVP on a dying VPE Kunkun Jiang reported that there is a small window of opportunity for userspace to force a change of affinity for a VPE while the VPE has already been unmapped, but the corresponding doorbell interrupt still visible in /proc/irq/. Plug the race by checking the value of vmapp_count, which tracks whether the VPE is mapped ot not, and returning an error in this case. This involves making vmapp_count common to both GICv4.1 and its v4.0 ancestor.
EPSS
4.7 Medium
CVSS3