CVE-2023-53584 ubifs: ubifs_releasepage: Remove ubifs_assert(0) to valid this process

Medium 5.5 Published 4 Oct 2025 Updated 11 May 2026

A race condition in the Linux kernel UBIFS filesystem triggers an assertion failure, causing the filesystem to switch to read-only mode and resulting in a denial of service.

Exploited in the wild: Not known
Login needed: Any signed-in user
Attackable: Local or same network only
Victim action needed: Not needed
Fix: Available

What is CVE-2023-53584?

CVE-2023-53584 is a medium-severity denial of service vulnerability in Linux kernel, published on 4 Oct 2025. It can only be exploited from the same machine or local network, with no action from the victim.

Official description

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

ubifs: ubifs_releasepage: Remove ubifs_assert(0) to valid this process

There are two states for ubifs writing pages: 1. Dirty, Private 2. Not Dirty, Not Private

The normal process cannot go to ubifs_releasepage() which means there exists pages being private but not dirty. Reproducer[1] shows that it could occur (which maybe related to [2]) with following process:

PA PB PC lock(page)[PA] ubifs_write_end attach_page_private // set Private __set_page_dirty_nobuffers // set Dirty unlock(page)

write_cache_pages[PA] lock(page) clear_page_dirty_for_io(page) // clear Dirty ubifs_writepage

do_truncation[PB] truncate_setsize i_size_write(inode, newsize) // newsize = 0

i_size = i_size_read(inode) // i_size = 0 end_index = i_size >> PAGE_SHIFT if (page->index > end_index) goto out // jump out: unlock(page) // Private, Not Dirty

generic_fadvise[PC] lock(page) invalidate_inode_page try_to_release_page ubifs_releasepage ubifs_assert(c, 0) // bad assertion! unlock(page) truncate_pagecache[PB]

Then we may get following assertion failed: UBIFS error (ubi0:0 pid 1683): ubifs_assert_failed [ubifs]: UBIFS assert failed: 0, in fs/ubifs/file.c:1513 UBIFS warning (ubi0:0 pid 1683): ubifs_ro_mode [ubifs]: switched to read-only mode, error -22 CPU: 2 PID: 1683 Comm: aa Not tainted 5.16.0-rc5-00184-g0bca5994cacc-dirty #308 Call Trace: dump_stack+0x13/0x1b ubifs_ro_mode+0x54/0x60 [ubifs] ubifs_assert_failed+0x4b/0x80 [ubifs] ubifs_releasepage+0x67/0x1d0 [ubifs] try_to_release_page+0x57/0xe0 invalidate_inode_page+0xfb/0x130 __invalidate_mapping_pages+0xb9/0x280 invalidate_mapping_pagevec+0x12/0x20 generic_fadvise+0x303/0x3c0 ksys_fadvise64_64+0x4c/0xb0

[1] https://bugzilla.kernel.org/show_bug.cgi?id=215373 [2] https://linux-mtd.infradead.narkive.com/NQoBeT1u/patch-rfc-ubifs-fix-assert-failed-in-ubifs-set-page-dirty

Weakness: CWE-617

Which versions are affected by CVE-2023-53584?

It affects 1 product.

Products include Linux kernel.

How do I fix CVE-2023-53584?

Apply the vendor's patch.

Upgrade, then put limits on request size, rate and nesting depth so one client cannot exhaust the service. More about Denial of service.

Is CVE-2023-53584 being exploited?

There is no known exploitation of CVE-2023-53584 in the wild and no public exploit code.

All Linux kernel vulnerabilities

Sources

Also known as BELL-CVE-2023-53584, DEBIAN-CVE-2023-53584, GHSA-r29j-x5gx-p5gg, ROOT-OS-DEBIAN-11-CVE-2023-53584, ROOT-OS-UBUNTU-2204-CVE-2023-53584, UBUNTU-CVE-2023-53584.