GHSA-GW4Q-M5C4-P6FM
Vulnerability from github – Published: 2024-06-25 15:31 – Updated: 2025-11-04 00:30In 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: 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
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.
{
"affected": [],
"aliases": [
"CVE-2024-37078"
],
"database_specific": {
"cwe_ids": [],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-06-25T15:15:12Z",
"severity": "HIGH"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnilfs2: fix potential kernel bug due to lack of writeback flag waiting\n\nDestructive writes to a block device on which nilfs2 is mounted can cause\na kernel bug in the folio/page writeback start routine or writeback end\nroutine (__folio_start_writeback in the log below):\n\n kernel BUG at mm/page-writeback.c:3070!\n Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI\n ...\n RIP: 0010:__folio_start_writeback+0xbaa/0x10e0\n Code: 25 ff 0f 00 00 0f 84 18 01 00 00 e8 40 ca c6 ff e9 17 f6 ff ff\n e8 36 ca c6 ff 4c 89 f7 48 c7 c6 80 c0 12 84 e8 e7 b3 0f 00 90 \u003c0f\u003e\n 0b e8 1f ca c6 ff 4c 89 f7 48 c7 c6 a0 c6 12 84 e8 d0 b3 0f 00\n ...\n Call Trace:\n \u003cTASK\u003e\n nilfs_segctor_do_construct+0x4654/0x69d0 [nilfs2]\n nilfs_segctor_construct+0x181/0x6b0 [nilfs2]\n nilfs_segctor_thread+0x548/0x11c0 [nilfs2]\n kthread+0x2f0/0x390\n ret_from_fork+0x4b/0x80\n ret_from_fork_asm+0x1a/0x30\n \u003c/TASK\u003e\n\nThis is because when the log writer starts a writeback for segment summary\nblocks or a super root block that use the backing device\u0027s page cache, it\ndoes not wait for the ongoing folio/page writeback, resulting in an\ninconsistent writeback state.\n\nFix this issue by waiting for ongoing writebacks when putting\nfolios/pages on the backing device into writeback state.",
"id": "GHSA-gw4q-m5c4-p6fm",
"modified": "2025-11-04T00:30:49Z",
"published": "2024-06-25T15:31:09Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-37078"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0ecfe3a92869a59668d27228dabbd7965e83567f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1f3bff69f1214fe03a02bc650d5bbfaa6e65ae7d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/271dcd977ccda8c7a26e360425ae7b4db7d2ecc0"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/33900d7eae616647e179eee1c66ebe654ee39627"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/614d397be0cf43412b3f94a0f6460eddced8ce92"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/95f6f81e50d858a7c9aa7c795ec14a0ac3819118"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a4ca369ca221bb7e06c725792ac107f0e48e82e7"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a75b8f493dfc48aa38c518430bd9e03b53bffebe"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/01/msg00001.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H",
"type": "CVSS_V3"
}
]
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.