CVE-2024-26768
published 2024-04-03CVE-2024-26768: In the Linux kernel, the following vulnerability has been resolved: LoongArch: Change acpi_core_pic[NR_CPUS] to acpi_core_pic[MAX_CORE_PIC] With default…
PriorityP339high7.2CVSS 3.1
AVNACLPRHUINSUCHIHAH
EPSS
0.60%
48.6th percentile
In the Linux kernel, the following vulnerability has been resolved:
LoongArch: Change acpi_core_pic[NR_CPUS] to acpi_core_pic[MAX_CORE_PIC]
With default config, the value of NR_CPUS is 64. When HW platform has
more then 64 cpus, system will crash on these platforms. MAX_CORE_PIC
is the maximum cpu number in MADT table (max physical number) which can
exceed the supported maximum cpu number (NR_CPUS, max logical number),
but kernel should not crash. Kernel should boot cpus with NR_CPUS, let
the remainder cpus stay in BIOS.
The potential crash reason is that the array acpi_core_pic[NR_CPUS] can
be overflowed when parsing MADT table, and it is obvious that CORE_PIC
should be corresponding to physical core rather than logical core, so it
is better to define the array as acpi_core_pic[MAX_CORE_PIC].
With the patch, system can boot up 64 vcpus with qemu parameter -smp 128,
otherwise system will crash with the following message.
[ 0.000000] CPU 0 Unable to handle kernel paging request at virtual address 0000420000004259, era == 90000000037a5f0c, ra == 90000000037a46ec
[ 0.000000] Oops[#1]:
[ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 6.8.0-rc2+ #192
[ 0.000000] Hardware name: QEMU QEMU Virtual Machine, BIOS unknown 2/2/2022
[ 0.000000] pc 90000000037a5f0c ra 90000000037a46ec tp 9000000003c90000 sp 9000000003c93d60
[ 0.000000] a0 0000000000000019 a1 9000000003d93bc0 a2 0000000000000000 a3 9000000003c93bd8
[ 0.000000] a4 9000000003c93a74 a5 9000000083c93a67 a6 9000000003c938f0 a7 0000000000000005
[ 0.000000] t0 0000420000004201 t1 0000000000000000 t2 0000000000000001 t3 0000000000000001
[ 0.000000] t4 0000000000000003 t5 0000000000000000 t6 0000000000000030 t7 0000000000000063
[ 0.000000] t8 0000000000000014 u0 ffffffffffffffff s9 0000000000000000 s0 9000000003caee98
[ 0.000000] s1 90000000041b0480 s2 9000000003c93da0 s3 9000000003c93d98 s4 9000000003c93d90
[ 0.000000] s5 9000000003caa000 s6 000000000a7fd000 s7 000000000f556b60 s8 000000000e0a4330
[ 0.000000] ra:
Affected
12 ranges
| Vendor | Product | Version range | Fixed in |
|---|---|---|---|
| debian | linux | < linux 6.7.7-1 (forky) | linux 6.7.7-1 (forky) |
| linux | linux | — | — |
| linux | linux | >= fa96b57c149061f71a70bd6582d995f6424fbbf4 < 88e189bd16e5889e44a41b3309558ebab78b9280 | 88e189bd16e5889e44a41b3309558ebab78b9280 |
| linux | linux | >= fa96b57c149061f71a70bd6582d995f6424fbbf4 < 0f6810e39898af2d2cabd9313e4dbc945fb5dfdd | 0f6810e39898af2d2cabd9313e4dbc945fb5dfdd |
| linux | linux | >= fa96b57c149061f71a70bd6582d995f6424fbbf4 < 4551b30525cf3d2f026b92401ffe241eb04dfebe | 4551b30525cf3d2f026b92401ffe241eb04dfebe |
| linux | linux_kernel | — | — |
| linux | linux_kernel | — | — |
| linux | linux_kernel | — | — |
| linux | linux_kernel | >= 0 < 6.7.7-1 | 6.7.7-1 |
| linux | linux_kernel | >= 0 < 6.7.7-1 | 6.7.7-1 |
| linux | linux_kernel | >= 5.19 < 6.6.19 | 6.6.19 |
| linux | linux_kernel | >= 6.7 < 6.7.7 | 6.7.7 |
CVSS provenance
nvdv3.17.2HIGHCVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H
osv6.5MEDIUM
vendor_debian6.5MEDIUM
vendor_redhat6.5MEDIUM
Stop checking back — get the weekly exploitation signal.
Every Monday: what got weaponized or added to CISA KEV in the last seven days — each CVE cross-linked to its PoC, Nuclei template, and detection rule. Free, one email a week, unsubscribe in one click.
VulDB
Linux Kernel up to 6.6.18/6.7.6 LoongArch stack-based overflow (88e189bd16e5/0f6810e39898/4551b30525cf / WID-SEC-2024-0773)
vuldb·2026-10-19·CVSS 7.2
CVE-2024-26768 [HIGH] Linux Kernel up to 6.6.18/6.7.6 LoongArch stack-based overflow (88e189bd16e5/0f6810e39898/4551b30525cf / WID-SEC-2024-0773)
A vulnerability was found in Linux Kernel up to 6.6.18/6.7.6. It has been declared as critical. This affects an unknown part of the component LoongArch. The manipulation results in stack-based buffer overflow.
This vulnerability is reported as CVE-2024-26768. The attacker must have access to the local network to execute the attack. No exploit exists.
It is recommended to upgrade the affected component.
OSV
CVE-2024-26768: In the Linux kernel, the following vulnerability has been resolved: LoongArch: Change acpi_core_pic[NR_CPUS] to acpi_core_pic[MAX_CORE_PIC] With defau
osv·2024-04-03·CVSS 6.5
CVE-2024-26768 [MEDIUM] CVE-2024-26768: In the Linux kernel, the following vulnerability has been resolved: LoongArch: Change acpi_core_pic[NR_CPUS] to acpi_core_pic[MAX_CORE_PIC] With defau
In the Linux kernel, the following vulnerability has been resolved: LoongArch: Change acpi_core_pic[NR_CPUS] to acpi_core_pic[MAX_CORE_PIC] With default config, the value of NR_CPUS is 64. When HW platform has more then 64 cpus, system will crash on these platforms. MAX_CORE_PIC is the maximum cpu number in MADT table (max physical number) which can exceed the supported maximum cpu number (NR_CPUS, max logical number), but kernel should not crash. Kernel should boot cpus with NR_CPUS, let the remainder cpus stay in BIOS. The potential crash reason is that the array acpi_core_pic[NR_CPUS] can be overflowed when parsing MADT table, and it is obvious that CORE_PIC should be corresponding to physical core rather than logical core, so it is better to define the array as acpi_core_pic[MAX_CORE_P
GHSA
GHSA-hg7x-x4qq-cq6w: In the Linux kernel, the following vulnerability has been resolved:
LoongArch: Change acpi_core_pic[NR_CPUS] to acpi_core_pic[MAX_CORE_PIC]
With def
ghsa_unreviewed·2024-04-03
CVE-2024-26768 [MEDIUM] CWE-120 GHSA-hg7x-x4qq-cq6w: In the Linux kernel, the following vulnerability has been resolved:
LoongArch: Change acpi_core_pic[NR_CPUS] to acpi_core_pic[MAX_CORE_PIC]
With def
In the Linux kernel, the following vulnerability has been resolved:
LoongArch: Change acpi_core_pic[NR_CPUS] to acpi_core_pic[MAX_CORE_PIC]
With default config, the value of NR_CPUS is 64. When HW platform has
more then 64 cpus, system will crash on these platforms. MAX_CORE_PIC
is the maximum cpu number in MADT table (max physical number) which can
exceed the supported maximum cpu number (NR_CPUS, max logical number),
but kernel should not crash. Kernel should boot cpus with NR_CPUS, let
the remainder cpus stay in BIOS.
The potential crash reason is that the array acpi_core_pic[NR_CPUS] can
be overflowed when parsing MADT table, and it is obvious that CORE_PIC
should be corresponding to physical core rather than logical core, so it
is better to define the array as acpi_core_pic[MAX_COR
Red Hat
kernel: LoongArch: Change acpi_core_pic[NR_CPUS] to acpi_core_pic[MAX_CORE_PIC]
vendor_redhat·2024-04-03·CVSS 6.5
CVE-2024-26768 [MEDIUM] CWE-121 kernel: LoongArch: Change acpi_core_pic[NR_CPUS] to acpi_core_pic[MAX_CORE_PIC]
kernel: LoongArch: Change acpi_core_pic[NR_CPUS] to acpi_core_pic[MAX_CORE_PIC]
In the Linux kernel, the following vulnerability has been resolved:
LoongArch: Change acpi_core_pic[NR_CPUS] to acpi_core_pic[MAX_CORE_PIC]
With default config, the value of NR_CPUS is 64. When HW platform has
more then 64 cpus, system will crash on these platforms. MAX_CORE_PIC
is the maximum cpu number in MADT table (max physical number) which can
exceed the supported maximum cpu number (NR_CPUS, max logical number),
but kernel should not crash. Kernel should boot cpus with NR_CPUS, let
the remainder cpus stay in BIOS.
The potential crash reason is that the array acpi_core_pic[NR_CPUS] can
be overflowed when parsing MADT table, and it is obvious that CORE_PIC
should be corresponding to physical core rather t
Debian
CVE-2024-26768: linux - In the Linux kernel, the following vulnerability has been resolved: LoongArch: ...
vendor_debian·2024·CVSS 6.5
CVE-2024-26768 [MEDIUM] CVE-2024-26768: linux - In the Linux kernel, the following vulnerability has been resolved: LoongArch: ...
In the Linux kernel, the following vulnerability has been resolved: LoongArch: Change acpi_core_pic[NR_CPUS] to acpi_core_pic[MAX_CORE_PIC] With default config, the value of NR_CPUS is 64. When HW platform has more then 64 cpus, system will crash on these platforms. MAX_CORE_PIC is the maximum cpu number in MADT table (max physical number) which can exceed the supported maximum cpu number (NR_CPUS, max logical number), but kernel should not crash. Kernel should boot cpus with NR_CPUS, let the remainder cpus stay in BIOS. The potential crash reason is that the array acpi_core_pic[NR_CPUS] can be overflowed when parsing MADT table, and it is obvious that CORE_PIC should be corresponding to physical core rather than logical core, so it is better to define the array as acpi_core_pic[MAX_CORE_P
No detection rules found.
No public exploits indexed.
https://git.kernel.org/stable/c/0f6810e39898af2d2cabd9313e4dbc945fb5dfddhttps://git.kernel.org/stable/c/4551b30525cf3d2f026b92401ffe241eb04dfebehttps://git.kernel.org/stable/c/88e189bd16e5889e44a41b3309558ebab78b9280https://git.kernel.org/stable/c/0f6810e39898af2d2cabd9313e4dbc945fb5dfddhttps://git.kernel.org/stable/c/4551b30525cf3d2f026b92401ffe241eb04dfebehttps://git.kernel.org/stable/c/88e189bd16e5889e44a41b3309558ebab78b9280
2024-04-03
Published