LiveActive security incident?Get immediate response
CVE Record

CVE-2023-53564: ocfs2: fix defrag path triggering jbd2 ASSERT

In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix defrag path triggering jbd2 ASSERT code path: ocfs2_ioctl_move_extents ocfs2_move_extents ocfs2_defrag_extent __ocfs2_move_extent + ocfs2_journal_access_di + ocfs2_split_extent //sub-paths call jbd2_journal_restart + ocfs2_journal_dirty //crash by jbs2 ASSERT crash stacks: PID: 11297 TASK: ffff974a676dcd00 CPU: 67 COMMAND: "defragfs.ocfs2" #0 [ffffb25d8dad3900] machine_kexec at ffffffff8386fe01 #1 [ffffb25d8dad3958] __crash_kexec at ffffffff8395959d #2 [ffffb25d8dad3a20] crash_kexec at ffffffff8395a45d #3 [ffffb25d8dad3a38] oops_end at ffffffff83836d3f #4 [ffffb25d8dad3a58] do_trap at ffffffff83833205 #5 [ffffb25d8dad3aa0] do_invalid_op at ffffffff83833aa6 #6 [ffffb25d8dad3ac0] invalid_op at ffffffff84200d18 [exception RIP: jbd2_journal_dirty_metadata+0x2ba] RIP: ffffffffc09ca54a RSP: ffffb25d8dad3b70 RFLAGS: 00010207 RAX: 0000000000000000 RBX: ffff9706eedc5248 RCX: 0000000000000000 RDX: 0000000000000001 RSI: ffff97337029ea28 RDI: ffff9706eedc5250 RBP: ffff9703c3520200 R8: 000000000f46b0b2 R9: 0000000000000000 R10: 0000000000000001 R11: 00000001000000fe R12: ffff97337029ea28 R13: 0000000000000000 R14: ffff9703de59bf60 R15: ffff9706eedc5250 ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018 #7 [ffffb25d8dad3ba8] ocfs2_journal_dirty at ffffffffc137fb95 [ocfs2] #8 [ffffb25d8dad3be8] __ocfs2_move_extent at ffffffffc139a950 [ocfs2] #9 [ffffb25d8dad3c80] ocfs2_defrag_extent at ffffffffc139b2d2 [ocfs2] Analysis This bug has the same root cause of 'commit 7f27ec978b0e ("ocfs2: call ocfs2_journal_access_di() before ocfs2_journal_dirty() in ocfs2_write_end_nolock()")'. For this bug, jbd2_journal_restart() is called by ocfs2_split_extent() during defragmenting. How to fix For ocfs2_split_extent() can handle journal operations totally by itself. Caller doesn't need to call journal access/dirty pair, and caller only needs to call journal start/stop pair. The fix method is to remove journal access/dirty from __ocfs2_move_extent(). The discussion for this patch: https://oss.oracle.com/pipermail/ocfs2-devel/2023-February/000647.html

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 crash a system when OCFS2 defragmentation follows a specific extent-moving path. The available sources describe a reliability and denial-of-service risk, not data theft or remote code execution. Exposure is likely limited to systems using OCFS2 and its defragmentation tooling.

Executive priority

Treat this as a targeted availability risk. Prioritize patch validation for Linux systems using OCFS2 in production, especially where a kernel crash would disrupt critical services. It is not supported by the sources as an internet-wide emergency.

Technical view

During ocfs2_ioctl_move_extents, ocfs2_split_extent can restart journal handling, while __ocfs2_move_extent also used a journal access/dirty pair. That mismatch can trigger a jbd2 ASSERT in jbd2_journal_dirty_metadata and crash the kernel. The documented fix removes the unnecessary journal access/dirty calls from __ocfs2_move_extent.

Likely exposure

Linux systems running affected kernel versions with OCFS2 in use are the likely exposure. Systems not using OCFS2, or not running the affected defragmentation path, appear less exposed based on the supplied sources.

Exploitation context

The source bundle does not show active exploitation, KEV listing, public exploit status, or a remote attack path. The evidence points to a crash during OCFS2 defragmentation rather than a broadly reachable vulnerability.

Researcher notes

The key code path is ocfs2_ioctl_move_extents to __ocfs2_move_extent, with ocfs2_split_extent handling journal operations internally. Evidence is incomplete for CVSS, exploitability, and distribution-specific status, so validation should focus on kernel provenance and OCFS2 operational use.

Mitigation direction

  • Upgrade to a kernel containing the referenced stable fix commits.
  • Check Linux distribution advisories for backported OCFS2 fixes.
  • Avoid unnecessary OCFS2 defragmentation on unpatched systems.
  • Prioritize systems where OCFS2 availability matters operationally.

Validation and detection

  • Inventory Linux hosts for OCFS2 usage and affected kernel versions.
  • Confirm whether vendor kernels include the referenced stable commits.
  • Review crash logs for jbd2 ASSERT or ocfs2 defrag traces.
  • Verify maintenance procedures avoid defragfs.ocfs2 on unpatched systems.
Prepared
Confidence
medium
Sources
10

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-53564 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
9Source 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
LinuxLinux8f603e567aa7a243e68ca48b4f105b990851360f, 8f603e567aa7a243e68ca48b4f105b990851360f, 8f603e567aa7a243e68ca48b4f105b990851360f, 8f603e567aa7a243e68ca48b4f105b990851360f, 8f603e567aa7a243e68ca48b4f105b990851360f, 8f603e567aa7a243e68ca48b4f105b990851360f, 8f603e567aa7a243e68ca48b4f105b990851360f, 8f603e567aa7a243e68ca48b4f105b990851360funaffected
LinuxLinux3.0, 0, 4.14.308, 4.19.276, 5.4.235, 5.10.173, 5.15.99, 6.1.16, 6.2.3, 6.3affected
Weakness

CWE details

No CWE listed

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