LiveActive security incident?Get immediate response
CVE Record

CVE-2023-53587: ring-buffer: Sync IRQ works before buffer destruction

In the Linux kernel, the following vulnerability has been resolved: ring-buffer: Sync IRQ works before buffer destruction If something was written to the buffer just before destruction, it may be possible (maybe not in a real system, but it did happen in ARCH=um with time-travel) to destroy the ringbuffer before the IRQ work ran, leading this KASAN report (or a crash without KASAN): BUG: KASAN: slab-use-after-free in irq_work_run_list+0x11a/0x13a Read of size 8 at addr 000000006d640a48 by task swapper/0 CPU: 0 PID: 0 Comm: swapper Tainted: G W O 6.3.0-rc1 #7 Stack: 60c4f20f 0c203d48 41b58ab3 60f224fc 600477fa 60f35687 60c4f20f 601273dd 00000008 6101eb00 6101eab0 615be548 Call Trace: [<60047a58>] show_stack+0x25e/0x282 [<60c609e0>] dump_stack_lvl+0x96/0xfd [<60c50d4c>] print_report+0x1a7/0x5a8 [<603078d3>] kasan_report+0xc1/0xe9 [<60308950>] __asan_report_load8_noabort+0x1b/0x1d [<60232844>] irq_work_run_list+0x11a/0x13a [<602328b4>] irq_work_tick+0x24/0x34 [<6017f9dc>] update_process_times+0x162/0x196 [<6019f335>] tick_sched_handle+0x1a4/0x1c3 [<6019fd9e>] tick_sched_timer+0x79/0x10c [<601812b9>] __hrtimer_run_queues.constprop.0+0x425/0x695 [<60182913>] hrtimer_interrupt+0x16c/0x2c4 [<600486a3>] um_timer+0x164/0x183 [...] Allocated by task 411: save_stack_trace+0x99/0xb5 stack_trace_save+0x81/0x9b kasan_save_stack+0x2d/0x54 kasan_set_track+0x34/0x3e kasan_save_alloc_info+0x25/0x28 ____kasan_kmalloc+0x8b/0x97 __kasan_kmalloc+0x10/0x12 __kmalloc+0xb2/0xe8 load_elf_phdrs+0xee/0x182 [...] The buggy address belongs to the object at 000000006d640800 which belongs to the cache kmalloc-1k of size 1024 The buggy address is located 584 bytes inside of freed 1024-byte region [000000006d640800, 000000006d640c00) Add the appropriate irq_work_sync() so the work finishes before the buffers are destroyed. Prior to the commit in the Fixes tag below, there was only a single global IRQ work, so this issue didn't exist.

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

Security readout for executives and security teams

Plain-English summary

A Linux kernel cleanup race can leave queued IRQ work pointing to a ring buffer after it has been freed. In observed testing it produced a KASAN use-after-free or crash. Business impact appears mainly availability and kernel stability risk, but public severity and exploitability are not established.

Executive priority

Treat as a kernel maintenance priority, not an emergency based on current evidence. Patch during the next appropriate kernel update window, faster for systems where kernel crashes would materially affect service availability.

Technical view

The fix adds irq_work_sync() before ring-buffer destruction so pending IRQ work completes before memory is freed. The issue arose after moving from a single global IRQ work item to per-buffer work, creating a destruction race. The source shows a slab-use-after-free in irq_work_run_list().

Likely exposure

Exposure is limited to systems running affected Linux kernel builds that include the vulnerable ring-buffer IRQ work behavior and lack the linked stable fixes. The supplied data lists multiple affected kernel lines from 3.10 through 6.4, but does not identify distributions, configurations, or reachable attack surfaces.

Exploitation context

No active exploitation is supported by the provided sources, and KEV is false. The report says the crash occurred in ARCH=um with time-travel and may or may not occur on a real system. Practical exploitability is not established in the supplied evidence.

Researcher notes

The evidence supports a use-after-free race in Linux ring-buffer teardown, fixed by synchronizing IRQ work before buffer destruction. There is no CVSS, CWE, distribution advisory, or confirmed real-world exploit path in the supplied bundle, so severity confidence is constrained.

Mitigation direction

  • Update to a vendor kernel containing the linked stable ring-buffer fix.
  • If no vendor package is available, track official Linux stable and distribution guidance.
  • Prioritize exposed or reliability-sensitive Linux hosts during normal kernel patch cycles.
  • Avoid claiming compensating controls unless your kernel vendor documents them.

Validation and detection

  • Inventory running Linux kernel versions and package provenance across affected assets.
  • Check vendor changelogs or source packages for the linked stable fix commits.
  • Review crash, KASAN, or kernel warning telemetry for ring-buffer and irq_work indicators.
  • Confirm post-update kernels boot cleanly and pass operational regression tests.
Prepared
Confidence
medium
Sources
11

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-53587 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
10Source 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
LinuxLinux15693458c4bc0693fd63a50d60f35b628fcf4e29, 15693458c4bc0693fd63a50d60f35b628fcf4e29, 15693458c4bc0693fd63a50d60f35b628fcf4e29, 15693458c4bc0693fd63a50d60f35b628fcf4e29, 15693458c4bc0693fd63a50d60f35b628fcf4e29, 15693458c4bc0693fd63a50d60f35b628fcf4e29, 15693458c4bc0693fd63a50d60f35b628fcf4e29, 15693458c4bc0693fd63a50d60f35b628fcf4e29, 15693458c4bc0693fd63a50d60f35b628fcf4e29unaffected
LinuxLinux3.10, 0, 4.14.315, 4.19.283, 5.4.243, 5.10.180, 5.15.111, 6.1.28, 6.2.15, 6.3.2, 6.4affected
Weakness

CWE details

No CWE listed

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