Cloudanix VulnDB

CVE-2023-54182

None

CVSS

—

EPSS

0.1%

Published

Dec 30, 2025

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A flaw in the Linux storage driver for certain filesystems can cause the whole system to crash when writing to a disk that was only partially marked read-only.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Moderate
Impact
Denial Of Service
Component
OS kernel
Class
Improper Input Validation
Remediation
Patch
Effort
Medium
Patch risk
Low

What it actually does

Improper validation of read-only status across multiple block devices in f2fs allows a remount to rw even when a secondary device remains read-only, leading to kernel panic during subsequent write operations in f2fs_write_inline_data.

Why it matters to the business

Systems using multi-device f2fs filesystems risk unexpected kernel crashes and data write failures when administrators attempt to remount volumes read-write without verifying all underlying devices, potentially causing service outages on storage subsystems.

How an attack unfolds

An attacker with local access creates or mounts a multi-device f2fs image, sets one secondary device read-only via blockdev, mounts the primary device, then issues a remount rw followed by writes that trigger the inconsistent state and crash the kernel.

How to fix it

Update the Linux kernel to a version containing commit e2759a59a4cc96af712084e9db7065c858c4fe9f or later that introduces f2fs_dev_is_readonly() checks in f2fs_remount(). Reboot after applying the fix and verify multi-device mount behavior.

How to confirm the fix worked

Confirm the presence of the fix commit in the running kernel source or binary, then test remount scenarios with mixed read-only secondary devices to ensure no panic occurs on writes.

Typical attack path

  1. Identify or prepare multi-device f2fs image
  2. Set secondary device read-only with blockdev --setro
  3. Mount primary device with f2fs
  4. Remount the filesystem read-write
  5. Perform write operations to trigger panic in write path

How to detect it

Review kernel logs for BUG reports in f2fs_write_inline_data or related writeback functions during remount and write activity on multi-device f2fs volumes; correlate with mount and blockdev command history.

What your security team should do

  • Prioritize kernel updates on all systems using f2fs multi-device configurations
  • Audit f2fs mount scripts and options for explicit read-only handling
  • Monitor kernel logs for f2fs writeback-related BUG reports
  • Restrict local unprivileged access to block device and mount operations where feasible

The record

In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to check readonly condition correctly With below case, it can mount multi-device image w/ rw option, however one of secondary device is set as ro, later update will cause panic, so let's introduce f2fs_dev_is_readonly(), and check multi-devices rw status in f2fs_remount() w/ it in order to avoid such inconsistent mount status. mkfs.f2fs -c /dev/zram1 /dev/zram0 -f blockdev --setro /dev/zram1 mount -t f2fs dev/zram0 /mnt/f2fs mount: /mnt/f2fs: WARNING: source write-protected, mounted read-only. mount -t f2fs -o remount,rw mnt/f2fs dd if=/dev/zero of=/mnt/f2fs/file bs=1M count=8192 kernel BUG at fs/f2fs/inline.c:258! RIP: 0010:f2fs_write_inline_data+0x23e/0x2d0 [f2fs] Call Trace: f2fs_write_single_data_page+0x26b/0x9f0 [f2fs] f2fs_write_cache_pages+0x389/0xa60 [f2fs] __f2fs_write_data_pages+0x26b/0x2d0 [f2fs] f2fs_write_data_pages+0x2e/0x40 [f2fs] do_writepages+0xd3/0x1b0 __writeback_single_inode+0x5b/0x420 writeback_sb_inodes+0x236/0x5a0 __writeback_inodes_wb+0x56/0xf0 wb_writeback+0x2a3/0x490 wb_do_writeback+0x2b2/0x330 wb_workfn+0x6a/0x260 process_one_work+0x270/0x5e0 worker_thread+0x52/0x3e0 kthread+0xf4/0x120 ret_from_fork+0x29/0x50

Affected packages

Ecosystem Package Introduced Fixed
Linux Kernel 0 5.15.113
Linux Kernel 5.2.0 5.15.113

Related vulnerabilities