CVE-2023-53584
published 2025-10-04CVE-2023-53584: 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…
PriorityP419medium5.5CVSS 3.1
AVLACLPRLUINSUCNINAH
EPSS
0.14%
4.2th percentile
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
Affected
10 ranges
| Vendor | Product | Version range | Fixed in |
|---|---|---|---|
| debian | linux | < linux 6.1.20-1 (bookworm) | linux 6.1.20-1 (bookworm) |
| linux | linux | — | — |
| linux | linux | >= 1e51764a3c2ac05a23a22b2a95ddee4d9bffb16d < 7750be5d3e18500b454714677463b500a0b8b0d8 | 7750be5d3e18500b454714677463b500a0b8b0d8 |
| linux | linux | >= 1e51764a3c2ac05a23a22b2a95ddee4d9bffb16d < bd188ff1c8a1935c93a1e3cacf3be62667fdf762 | bd188ff1c8a1935c93a1e3cacf3be62667fdf762 |
| linux | linux | >= 1e51764a3c2ac05a23a22b2a95ddee4d9bffb16d < 66f4742e93523ab2f062d9d9828b3e590bc61536 | 66f4742e93523ab2f062d9d9828b3e590bc61536 |
| linux | linux_kernel | >= 0 < 6.1.20-1 | 6.1.20-1 |
| linux | linux_kernel | >= 0 < 6.1.20-1 | 6.1.20-1 |
| linux | linux_kernel | >= 0 < 6.1.20-1 | 6.1.20-1 |
| linux | linux_kernel | >= 2.6.27 < 6.1.18 | 6.1.18 |
| linux | linux_kernel | >= 6.2 < 6.2.5 | 6.2.5 |
CVSS provenance
nvdv3.15.5MEDIUMCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
osv5.5MEDIUM
vendor_debian5.5MEDIUM
vendor_redhat5.5MEDIUM
Stop checking back — get the weekly exploitation signal.
Every Monday: what got weaponized or added to CISA KEV in the last seven days — each CVE cross-linked to its PoC, Nuclei template, and detection rule. Free, one email a week, unsubscribe in one click.
Red Hat
kernel: ubifs: ubifs_releasepage: Remove ubifs_assert(0) to valid this process
vendor_redhat·2025-10-04·CVSS 5.5
CVE-2023-53584 [MEDIUM] CWE-367 kernel: ubifs: ubifs_releasepage: Remove ubifs_assert(0) to valid this process
kernel: ubifs: ubifs_releasepage: Remove ubifs_assert(0) to valid this process
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) /
Debian
CVE-2023-53584: linux - In the Linux kernel, the following vulnerability has been resolved: ubifs: ubif...
vendor_debian·2023·CVSS 5.5
CVE-2023-53584 [MEDIUM] CVE-2023-53584: linux - In the Linux kernel, the following vulnerability has been resolved: ubifs: ubif...
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 >> P
GHSA
GHSA-r29j-x5gx-p5gg: In the Linux kernel, the following vulnerability has been resolved:
ubifs: ubifs_releasepage: Remove ubifs_assert(0) to valid this process
There are
ghsa_unreviewed·2025-10-04
CVE-2023-53584 [MEDIUM] CWE-617 GHSA-r29j-x5gx-p5gg: In the Linux kernel, the following vulnerability has been resolved:
ubifs: ubifs_releasepage: Remove ubifs_assert(0) to valid this process
There are
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_si
OSV
CVE-2023-53584: In the Linux kernel, the following vulnerability has been resolved: ubifs: ubifs_releasepage: Remove ubifs_assert(0) to valid this process There are t
osv·2025-10-04·CVSS 5.5
CVE-2023-53584 [MEDIUM] CVE-2023-53584: In the Linux kernel, the following vulnerability has been resolved: ubifs: ubifs_releasepage: Remove ubifs_assert(0) to valid this process There are t
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 >> P
No detection rules found.
No public exploits indexed.
2025-10-04
Published