Executive Summary

Informations
Name CVE-2024-46797 First vendor Publication 2024-09-18
Vendor Cve Last vendor Modification 2024-09-29

Security-Database Scoring CVSS v3

Cvss vector : CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Overall CVSS Score 5.5
Base Score 5.5 Environmental Score 5.5
impact SubScore 3.6 Temporal Score 5.5
Exploitabality Sub Score 1.8
 
Attack Vector Local Attack Complexity Low
Privileges Required Low User Interaction None
Scope Unchanged Confidentiality Impact None
Integrity Impact None Availability Impact High
Calculate full CVSS 3.0 Vectors scores

Security-Database Scoring CVSS v2

Cvss vector :
Cvss Base Score N/A Attack Range N/A
Cvss Impact Score N/A Attack Complexity N/A
Cvss Expoit Score N/A Authentication N/A
Calculate full CVSS 2.0 Vectors scores

Detail

In the Linux kernel, the following vulnerability has been resolved:

powerpc/qspinlock: Fix deadlock in MCS queue

If an interrupt occurs in queued_spin_lock_slowpath() after we increment qnodesp->count and before node->lock is initialized, another CPU might see stale lock values in get_tail_qnode(). If the stale lock value happens to match the lock on that CPU, then we write to the "next" pointer of the wrong qnode. This causes a deadlock as the former CPU, once it becomes the head of the MCS queue, will spin indefinitely until it's "next" pointer is set by its successor in the queue.

Running stress-ng on a 16 core (16EC/16VP) shared LPAR, results in occasional lockups similar to the following:

$ stress-ng --all 128 --vm-bytes 80% --aggressive \
--maximize --oomable --verify --syslog \
--metrics --times --timeout 5m

watchdog: CPU 15 Hard LOCKUP
......
NIP [c0000000000b78f4] queued_spin_lock_slowpath+0x1184/0x1490
LR [c000000001037c5c] _raw_spin_lock+0x6c/0x90
Call Trace:
0xc000002cfffa3bf0 (unreliable)
_raw_spin_lock+0x6c/0x90
raw_spin_rq_lock_nested.part.135+0x4c/0xd0
sched_ttwu_pending+0x60/0x1f0
__flush_smp_call_function_queue+0x1dc/0x670
smp_ipi_demux_relaxed+0xa4/0x100
xive_muxed_ipi_action+0x20/0x40
__handle_irq_event_percpu+0x80/0x240
handle_irq_event_percpu+0x2c/0x80
handle_percpu_irq+0x84/0xd0
generic_handle_irq+0x54/0x80
__do_irq+0xac/0x210
__do_IRQ+0x74/0xd0
0x0
do_IRQ+0x8c/0x170
hardware_interrupt_common_virt+0x29c/0x2a0
--- interrupt: 500 at queued_spin_lock_slowpath+0x4b8/0x1490
......
NIP [c0000000000b6c28] queued_spin_lock_slowpath+0x4b8/0x1490
LR [c000000001037c5c] _raw_spin_lock+0x6c/0x90
--- interrupt: 500
0xc0000029c1a41d00 (unreliable)
_raw_spin_lock+0x6c/0x90
futex_wake+0x100/0x260
do_futex+0x21c/0x2a0
sys_futex+0x98/0x270
system_call_exception+0x14c/0x2f0
system_call_vectored_common+0x15c/0x2ec

The following code flow illustrates how the deadlock occurs. For the sake of brevity, assume that both locks (A and B) are contended and we call the queued_spin_lock_slowpath() function.

CPU0 CPU1
---- ----
spin_lock_irqsave(A) |
spin_unlock_irqrestore(A) |
spin_lock(B) |
| |
? |
id = qnodesp->count++; |
(Note that nodes[0].lock == A) |
| |
? |
Interrupt |
(happens before "nodes[0].lock = B") |
| |
? |
spin_lock_irqsave(A) |
| |
? |
id = qnodesp->count++ |
nodes[1].lock = A |
| |
? |
Tail of MCS queue |
| spin_lock_irqsave(A)
? |
Head of MCS queue ?
| CPU0 is previous tail
? |
Spin indefinitely ?
(until "nodes[1].next != NULL") prev = get_tail_qnode(A, CPU0)
|
?
prev == &qnodes[CPU0].nodes[0]
(as qnodes ---truncated---

Original Source

Url : http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-46797

CWE : Common Weakness Enumeration

% Id Name
100 % CWE-667 Insufficient Locking

CPE : Common Platform Enumeration

TypeDescriptionCount
Application 8
Os 3676

Sources (Detail)

https://git.kernel.org/stable/c/734ad0af3609464f8f93e00b6c0de1e112f44559
https://git.kernel.org/stable/c/d84ab6661e8d09092de9b034b016515ef9b66085
https://git.kernel.org/stable/c/f06af737e4be28c0e926dc25d5f0a111da4e2987
Source Url

Alert History

If you want to see full details history, please login or register.
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
Date Informations
2025-03-29 03:40:40
  • Multiple Updates
2025-03-28 13:45:04
  • Multiple Updates
2025-03-28 03:18:45
  • Multiple Updates
2025-03-19 03:14:05
  • Multiple Updates
2025-03-18 03:27:01
  • Multiple Updates
2025-03-14 03:14:18
  • Multiple Updates
2025-03-06 14:10:50
  • Multiple Updates
2025-02-22 03:24:24
  • Multiple Updates
2025-01-08 03:05:25
  • Multiple Updates
2025-01-07 03:04:58
  • Multiple Updates
2024-12-25 03:03:35
  • Multiple Updates
2024-12-12 03:06:32
  • Multiple Updates
2024-11-23 03:03:30
  • Multiple Updates
2024-11-22 03:01:39
  • Multiple Updates
2024-11-20 02:59:58
  • Multiple Updates
2024-11-14 03:00:17
  • Multiple Updates
2024-11-09 03:00:17
  • Multiple Updates
2024-10-26 02:57:40
  • Multiple Updates
2024-10-25 02:59:32
  • Multiple Updates
2024-10-23 02:58:44
  • Multiple Updates
2024-10-02 17:27:39
  • Multiple Updates
2024-10-02 00:27:47
  • Multiple Updates
2024-09-29 21:27:28
  • Multiple Updates
2024-09-21 05:27:30
  • Multiple Updates
2024-09-20 17:27:27
  • Multiple Updates
2024-09-18 13:27:29
  • First insertion