Описание
In the Linux kernel, the following vulnerability has been resolved:
mm: vmalloc: check if a hash-index is in cpu_possible_mask
The problem is that there are systems where cpu_possible_mask has gaps
between set CPUs, for example SPARC. In this scenario addr_to_vb_xa()
hash function can return an index which accesses to not-possible and not
setup CPU area using per_cpu() macro. This results in an oops on SPARC.
A per-cpu vmap_block_queue is also used as hash table, incorrectly
assuming the cpu_possible_mask has no gaps. Fix it by adjusting an index
to a next possible CPU.
A vulnerability was found in the Linux kernel that involves improper handling of per-CPU data in systems where cpu_possible_mask has gaps between CPUs. This can lead to an index which accesses non-existent or unset CPU areas and potentially causes kernel crashes.
Отчет
A moderate severity vulnerability was found in the Linux kernel's vmalloc memory management subsystem, affecting the Red Hat Enterprise Linux 9 kernel. A per-CPU vmap_block_queue is used as a hash table in the vmalloc code under the incorrect assumption that cpu_possible_mask has no gaps between set CPUs. On systems where such gaps exist, such as SPARC, the addr_to_vb_xa() hash function can return an index that accesses a not-possible and not-set-up CPU area through the per_cpu() macro, resulting in a kernel oops. The consequence is a kernel crash and denial of service (Red Hat CVSS 3.1 score 5.5, AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H); the flaw does not impact confidentiality or integrity. Within the current Red Hat product scope, the kernel and kernel-rt components in the Red Hat Enterprise Linux 9 rhel-9.5 stream are affected and a fix is being pursued through the delegated kernel maintenance workflow, while the RHEL 9.2 and RHEL 9.4 z-streams and the Red Hat Enterprise Linux 8 update streams (including kernel-rt) were assessed as not affected. The Hosted OpenShift (ARO/OSD) clusters are not affected, the Red Hat Enterprise Linux 7 and 6 ELS streams are out of active support scope (OOSS), and Fedora (Community Projects) ships affected kernels. Red Hat's moderate rating differs from the CVE.org rating of 7.8 because the technical evidence supports an availability-only impact from a local kernel crash rather than the high confidentiality and integrity impacts stated in the CVE.org vector.
Меры по смягчению последствий
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 | Out of support scope | ||
| Red Hat Enterprise Linux 7 | kernel | Out of support scope | ||
| Red Hat Enterprise Linux 7 | kernel-rt | Out of support scope | ||
| Red Hat Enterprise Linux 8 | kernel | Not affected | ||
| Red Hat Enterprise Linux 8 | kernel-rt | Not affected | ||
| Red Hat Enterprise Linux 9 | kernel-rt | Not affected | ||
| Red Hat Enterprise Linux 9 | kernel | Fixed | RHSA-2024:9315 | 12.11.2024 |
| Red Hat Enterprise Linux 9 | kernel | Fixed | RHSA-2024:9315 | 12.11.2024 |
Показывать по
Дополнительная информация
Статус:
EPSS
5.5 Medium
CVSS3
Связанные уязвимости
In the Linux kernel, the following vulnerability has been resolved: mm: vmalloc: check if a hash-index is in cpu_possible_mask The problem is that there are systems where cpu_possible_mask has gaps between set CPUs, for example SPARC. In this scenario addr_to_vb_xa() hash function can return an index which accesses to not-possible and not setup CPU area using per_cpu() macro. This results in an oops on SPARC. A per-cpu vmap_block_queue is also used as hash table, incorrectly assuming the cpu_possible_mask has no gaps. Fix it by adjusting an index to a next possible CPU.
In the Linux kernel, the following vulnerability has been resolved: mm: vmalloc: check if a hash-index is in cpu_possible_mask The problem is that there are systems where cpu_possible_mask has gaps between set CPUs, for example SPARC. In this scenario addr_to_vb_xa() hash function can return an index which accesses to not-possible and not setup CPU area using per_cpu() macro. This results in an oops on SPARC. A per-cpu vmap_block_queue is also used as hash table, incorrectly assuming the cpu_possible_mask has no gaps. Fix it by adjusting an index to a next possible CPU.
In the Linux kernel, the following vulnerability has been resolved: m ...
In the Linux kernel, the following vulnerability has been resolved: mm: vmalloc: check if a hash-index is in cpu_possible_mask The problem is that there are systems where cpu_possible_mask has gaps between set CPUs, for example SPARC. In this scenario addr_to_vb_xa() hash function can return an index which accesses to not-possible and not setup CPU area using per_cpu() macro. This results in an oops on SPARC. A per-cpu vmap_block_queue is also used as hash table, incorrectly assuming the cpu_possible_mask has no gaps. Fix it by adjusting an index to a next possible CPU.
Уязвимость компонента SPARC. A ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании
EPSS
5.5 Medium
CVSS3