Linux Kernel up to 6.6.50/6.10.9 queued_spin_lock_slowpath initialization

Summaryinfo

A vulnerability labeled as problematic has been found in Linux Kernel up to 6.6.50/6.10.9. Affected is the function queued_spin_lock_slowpath. The manipulation results in initialization. This vulnerability is known as CVE-2024-46797. No exploit is available. The affected component should be upgraded.

Detailsinfo

A vulnerability was found in Linux Kernel up to 6.6.50/6.10.9. It has been classified as problematic. Affected is the function queued_spin_lock_slowpath. The manipulation with an unknown input leads to a initialization vulnerability. CWE is classifying the issue as CWE-665. The product does not initialize or incorrectly initializes a resource, which might leave the resource in an unexpected state when it is accessed or used. This is going to have an impact on availability. CVE summarizes:

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---

The advisory is shared for download at git.kernel.org. This vulnerability is traded as CVE-2024-46797 since 09/11/2024. The exploitability is told to be difficult. There are known technical details, but no exploit is available.

The vulnerability scanner Nessus provides a plugin with the ID 212724 (Ubuntu 22.04 LTS / 24.04 LTS : Linux kernel vulnerabilities (USN-7154-1)), which helps to determine the existence of the flaw in a target environment.

Upgrading to version 6.6.51 or 6.10.10 eliminates this vulnerability. Applying the patch d84ab6661e8d/f06af737e4be/734ad0af3609 is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.

The vulnerability is also documented in the databases at Tenable (212724) and CERT Bund (WID-SEC-2024-2173). Once again VulDB remains the best source for vulnerability data.

Affected

• Debian Linux
• Google Cloud Platform
• Amazon Linux 2
• Red Hat Enterprise Linux
• Ubuntu Linux
• SUSE Linux
• IBM InfoSphere Guardium
• Oracle Linux
• RESF Rocky Linux
• Open Source Linux Kernel
• SolarWinds Security Event Manager

Productinfo

Type

• Operating System

Vendor

• Linux

Name

• Kernel

Version

• 6.6.0
• 6.6.1
• 6.6.2
• 6.6.3
• 6.6.4
• 6.6.5
• 6.6.6
• 6.6.7
• 6.6.8
• 6.6.9
• 6.6.10
• 6.6.11
• 6.6.12
• 6.6.13
• 6.6.14
• 6.6.15
• 6.6.16
• 6.6.17
• 6.6.18
• 6.6.19
• 6.6.20
• 6.6.21
• 6.6.22
• 6.6.23
• 6.6.24
• 6.6.25
• 6.6.26
• 6.6.27
• 6.6.28
• 6.6.29
• 6.6.30
• 6.6.31
• 6.6.32
• 6.6.33
• 6.6.34
• 6.6.35
• 6.6.36
• 6.6.37
• 6.6.38
• 6.6.39
• 6.6.40
• 6.6.41
• 6.6.42
• 6.6.43
• 6.6.44
• 6.6.45
• 6.6.46
• 6.6.47
• 6.6.48
• 6.6.49
• 6.6.50
• 6.10.0
• 6.10.1
• 6.10.2
• 6.10.3
• 6.10.4
• 6.10.5
• 6.10.6
• 6.10.7
• 6.10.8
• 6.10.9

License

• open-source

Website

• Vendor: https://www.kernel.org/

CPE 2.3info

• 🔍
• 🔍
• 🔍

CPE 2.2info

• 🔍
• 🔍
• 🔍

CVSSv4info

CVSSv3info

CVSSv2info

Exploitinginfo

Threat Intelligenceinfo

Countermeasuresinfo

Timelineinfo

Sourcesinfo

Entryinfo

Once again VulDB remains the best source for vulnerability data.

Discussion