LiveActive security incident?Get immediate response
CVE Record

CVE-2023-54113: rcu: dump vmalloc memory info safely

In the Linux kernel, the following vulnerability has been resolved: rcu: dump vmalloc memory info safely Currently, for double invoke call_rcu(), will dump rcu_head objects memory info, if the objects is not allocated from the slab allocator, the vmalloc_dump_obj() will be invoke and the vmap_area_lock spinlock need to be held, since the call_rcu() can be invoked in interrupt context, therefore, there is a possibility of spinlock deadlock scenarios. And in Preempt-RT kernel, the rcutorture test also trigger the following lockdep warning: BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48 in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 1, name: swapper/0 preempt_count: 1, expected: 0 RCU nest depth: 1, expected: 1 3 locks held by swapper/0/1: #0: ffffffffb534ee80 (fullstop_mutex){+.+.}-{4:4}, at: torture_init_begin+0x24/0xa0 #1: ffffffffb5307940 (rcu_read_lock){....}-{1:3}, at: rcu_torture_init+0x1ec7/0x2370 #2: ffffffffb536af40 (vmap_area_lock){+.+.}-{3:3}, at: find_vmap_area+0x1f/0x70 irq event stamp: 565512 hardirqs last enabled at (565511): [<ffffffffb379b138>] __call_rcu_common+0x218/0x940 hardirqs last disabled at (565512): [<ffffffffb5804262>] rcu_torture_init+0x20b2/0x2370 softirqs last enabled at (399112): [<ffffffffb36b2586>] __local_bh_enable_ip+0x126/0x170 softirqs last disabled at (399106): [<ffffffffb43fef59>] inet_register_protosw+0x9/0x1d0 Preemption disabled at: [<ffffffffb58040c3>] rcu_torture_init+0x1f13/0x2370 CPU: 0 PID: 1 Comm: swapper/0 Tainted: G W 6.5.0-rc4-rt2-yocto-preempt-rt+ #15 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.2-0-gea1b7a073390-prebuilt.qemu.org 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x68/0xb0 dump_stack+0x14/0x20 __might_resched+0x1aa/0x280 ? __pfx_rcu_torture_err_cb+0x10/0x10 rt_spin_lock+0x53/0x130 ? find_vmap_area+0x1f/0x70 find_vmap_area+0x1f/0x70 vmalloc_dump_obj+0x20/0x60 mem_dump_obj+0x22/0x90 __call_rcu_common+0x5bf/0x940 ? debug_smp_processor_id+0x1b/0x30 call_rcu_hurry+0x14/0x20 rcu_torture_init+0x1f82/0x2370 ? __pfx_rcu_torture_leak_cb+0x10/0x10 ? __pfx_rcu_torture_leak_cb+0x10/0x10 ? __pfx_rcu_torture_init+0x10/0x10 do_one_initcall+0x6c/0x300 ? debug_smp_processor_id+0x1b/0x30 kernel_init_freeable+0x2b9/0x540 ? __pfx_kernel_init+0x10/0x10 kernel_init+0x1f/0x150 ret_from_fork+0x40/0x50 ? __pfx_kernel_init+0x10/0x10 ret_from_fork_asm+0x1b/0x30 </TASK> The previous patch fixes this by using the deadlock-safe best-effort version of find_vm_area. However, in case of failure print the fact that the pointer was a vmalloc pointer so that we print at least something.

UnknownCVSS not scoredNot KEV-listedUpdated
Discuss exposureBack to CVEs
Glexia's TakeAutomated analysismoderate

Security readout for executives and security teams

Plain-English summary

This Linux kernel issue can deadlock when RCU diagnostic code tries to inspect vmalloc-backed memory from an unsafe context. Affected systems may hang under specific kernel conditions, especially real-time or debugging paths. Public sources do not show active exploitation or a CVSS score.

Executive priority

Treat as a targeted kernel stability issue, not an emergency internet-wide compromise based on current evidence. Patch through normal kernel maintenance, with higher priority for real-time systems where a deadlock can affect availability.

Technical view

A double call_rcu() path can call vmalloc_dump_obj(), which takes vmap_area_lock. Because call_rcu() may run in interrupt context, this can produce spinlock deadlock scenarios. PREEMPT_RT lockdep output shows sleeping-function warnings involving find_vmap_area(), vmalloc_dump_obj(), and __call_rcu_common().

Likely exposure

Exposure is limited to Linux kernels in the affected version set or downstream builds carrying the vulnerable RCU/vmalloc diagnostic behavior. PREEMPT_RT kernels and environments exercising RCU torture/debug paths appear most relevant from the provided evidence.

Exploitation context

The bundle cites no KEV listing, exploit activity, public exploit, or attacker workflow. The evidence describes a kernel deadlock risk triggered by unsafe lock acquisition during RCU memory-object dumping, not a demonstrated remote compromise path.

Researcher notes

The source evidence is kernel commit-oriented and lacks CVSS, CWE, exploitability analysis, and vendor-specific package mapping. The clearest technical impact is deadlock risk from calling vmalloc inspection code that may acquire vmap_area_lock in invalid context.

Mitigation direction

  • Upgrade to a Linux kernel containing the referenced stable fixes.
  • Check distribution advisories for backported fixes matching your shipped kernel.
  • Prioritize PREEMPT_RT and latency-sensitive Linux systems for review.
  • Avoid relying on upstream version numbers alone when vendors backport patches.

Validation and detection

  • Inventory Linux kernel versions across servers, appliances, containers hosts, and real-time builds.
  • Compare installed kernels with affected versions and referenced stable commits.
  • Review kernel logs for lockdep warnings involving vmap_area_lock or vmalloc_dump_obj.
  • Confirm vendor kernel changelogs mention the RCU vmalloc dump safety fix.
Prepared
Confidence
medium
Sources
7

Public sources used

Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.

Potential ATT&CK relevance

Conservative CVE-to-ATT&CK context

These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.

ATT&CK lookup starting points

Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.

cve · low confidence lookup

CVE-2023-54113 mapping review

Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.

Open ATT&CK lookup
Vulnerability profileCVE Program record
Severity
Unknown
CVSS
Not scored
Known Exploited
No
Published
Official CVE source material

CNA and ADP enrichment extracted from CVE v5

These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.

0CVSS vectors
3Timeline events
0ADP providers
6Source links

Vulnerability timeline

Timeline events are normalized from CVE metadata, CNA source timelines, ADP timelines, and KEV metadata when present.

  1. CVE reservedCVE Program

    The CVE ID was reserved by the assigning CNA.

  2. CVE publishedCVE Program

    The CVE record was published.

  3. CVE updatedCVE Program

    The CVE record metadata indicates this as the latest update time.

Source materials

Affected products

Products and packages named in the record

VendorProductVersion / packageStatus
LinuxLinux98f180837a896ecedf8f7e12af22b57f271d43c9, 98f180837a896ecedf8f7e12af22b57f271d43c9, 98f180837a896ecedf8f7e12af22b57f271d43c9, 98f180837a896ecedf8f7e12af22b57f271d43c9, 98f180837a896ecedf8f7e12af22b57f271d43c9unaffected
LinuxLinux5.12, 0, 5.15.132, 6.1.53, 6.4.16, 6.5.3, 6.6affected
Weakness

CWE details

No CWE listed

CWE links open Glexia weakness intelligence pages with official CWE context, developer remediation guidance, and related CVE mappings.