CVE-2024-37078: nilfs2: fix potential kernel bug due to lack of writeback flag waiting
In the Linux kernel, the following vulnerability has been resolved:
nilfs2: fix potential kernel bug due to lack of writeback flag waiting
Destructive writes to a block device on which nilfs2 is mounted can cause
a kernel bug in the folio/page writeback start routine or writeback end
routine (__folio_start_writeback in the log below):
kernel BUG at mm/page-writeback.c:3070!
Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI
...
RIP: 0010:__folio_start_writeback+0xbaa/0x10e0
Code: 25 ff 0f 00 00 0f 84 18 01 00 00 e8 40 ca c6 ff e9 17 f6 ff ff
e8 36 ca c6 ff 4c 89 f7 48 c7 c6 80 c0 12 84 e8 e7 b3 0f 00 90 <0f>
0b e8 1f ca c6 ff 4c 89 f7 48 c7 c6 a0 c6 12 84 e8 d0 b3 0f 00
...
Call Trace:
<TASK>
nilfs_segctor_do_construct+0x4654/0x69d0 [nilfs2]
nilfs_segctor_construct+0x181/0x6b0 [nilfs2]
nilfs_segctor_thread+0x548/0x11c0 [nilfs2]
kthread+0x2f0/0x390
ret_from_fork+0x4b/0x80
ret_from_fork_asm+0x1a/0x30
</TASK>
This is because when the log writer starts a writeback for segment summary
blocks or a super root block that use the backing device's page cache, it
does not wait for the ongoing folio/page writeback, resulting in an
inconsistent writeback state.
Fix this issue by waiting for ongoing writebacks when putting
folios/pages on the backing device into writeback state.
Security readout for executives and security teams
Plain-English summary
CVE-2024-37078 is a Linux kernel nilfs2 filesystem bug that can crash the kernel when destructive writes hit a block device that is still mounted with nilfs2. Business impact is mainly availability: affected systems could panic or fail, but the sources do not show remote exploitation or active attacks.
Executive priority
Treat this as a targeted availability issue. Patch during normal kernel maintenance unless nilfs2 is deployed on critical hosts or block-device access is weakly controlled; those systems deserve faster remediation because a kernel crash can disrupt services.
Technical view
nilfs2 starts writeback for segment summary or super root blocks using the backing device page cache without waiting for ongoing folio/page writeback. That can create inconsistent writeback state and trigger a kernel BUG in page-writeback routines. The upstream fix waits for ongoing writebacks before setting folios/pages into writeback state.
Likely exposure
Exposure is likely limited to Linux systems using mounted nilfs2 filesystems where a local user, privileged process, or misconfigured workload can perform destructive writes to the same block device. nilfs2 is not commonly enabled in typical enterprise server builds, so asset inventory matters.
Exploitation context
The CVE source describes a crash condition caused by destructive writes to a mounted nilfs2 block device. CISA KEV is false in the bundle, and no cited source states active exploitation. The available evidence supports local availability risk, not confirmed remote compromise.
Researcher notes
The source bundle provides upstream stable fix commits and a Debian LTS advisory, but no CVSS, CWE, or exploit confirmation. Affected version data is broad, so validate against kernel source, distro backports, and actual nilfs2 usage before declaring exposure.
Mitigation direction
Apply kernel updates containing the listed stable nilfs2 fixes or distro backports.
Check Linux distribution advisories for exact fixed package versions.
Avoid mounting nilfs2 on systems exposed to untrusted local workloads.
Restrict direct block-device write access while filesystems are mounted.
Prioritize hosts where storage disruption affects production availability.
Validation and detection
Inventory systems with nilfs2 support enabled or nilfs2 filesystems mounted.
Compare running kernel builds against vendor fixed versions or listed stable commits.
Review logs for kernel BUG traces involving page-writeback and nilfs2 segment construction.
Confirm untrusted users and containers lack direct write access to mounted block devices.
Track Debian LTS or other distro advisories for package-specific remediation status.
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-2024-37078 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
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.