CVE-2026-43299 (GCVE-0-2026-43299)
Vulnerability from cvelistv5 – Published: 2026-05-08 13:11 – Updated: 2026-05-08 13:11
VLAI?
Title
btrfs: do not ASSERT() when the fs flips RO inside btrfs_repair_io_failure()
Summary
In the Linux kernel, the following vulnerability has been resolved:
btrfs: do not ASSERT() when the fs flips RO inside btrfs_repair_io_failure()
[BUG]
There is a bug report that when btrfs hits ENOSPC error in a critical
path, btrfs flips RO (this part is expected, although the ENOSPC bug
still needs to be addressed).
The problem is after the RO flip, if there is a read repair pending, we
can hit the ASSERT() inside btrfs_repair_io_failure() like the following:
BTRFS info (device vdc): relocating block group 30408704 flags metadata|raid1
------------[ cut here ]------------
BTRFS: Transaction aborted (error -28)
WARNING: fs/btrfs/extent-tree.c:3235 at __btrfs_free_extent.isra.0+0x453/0xfd0, CPU#1: btrfs/383844
Modules linked in: kvm_intel kvm irqbypass
[...]
---[ end trace 0000000000000000 ]---
BTRFS info (device vdc state EA): 2 enospc errors during balance
BTRFS info (device vdc state EA): balance: ended with status: -30
BTRFS error (device vdc state EA): parent transid verify failed on logical 30556160 mirror 2 wanted 8 found 6
BTRFS error (device vdc state EA): bdev /dev/nvme0n1 errs: wr 0, rd 0, flush 0, corrupt 10, gen 0
[...]
assertion failed: !(fs_info->sb->s_flags & SB_RDONLY) :: 0, in fs/btrfs/bio.c:938
------------[ cut here ]------------
assertion failed: !(fs_info->sb->s_flags & SB_RDONLY) :: 0, in fs/btrfs/bio.c:938
kernel BUG at fs/btrfs/bio.c:938!
Oops: invalid opcode: 0000 [#1] SMP NOPTI
CPU: 0 UID: 0 PID: 868 Comm: kworker/u8:13 Tainted: G W N 6.19.0-rc6+ #4788 PREEMPT(full)
Tainted: [W]=WARN, [N]=TEST
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.17.0-0-gb52ca86e094d-prebuilt.qemu.org 04/01/2014
Workqueue: btrfs-endio simple_end_io_work
RIP: 0010:btrfs_repair_io_failure.cold+0xb2/0x120
RSP: 0000:ffffc90001d2bcf0 EFLAGS: 00010246
RAX: 0000000000000051 RBX: 0000000000001000 RCX: 0000000000000000
RDX: 0000000000000000 RSI: ffffffff8305cf42 RDI: 00000000ffffffff
RBP: 0000000000000002 R08: 00000000fffeffff R09: ffffffff837fa988
R10: ffffffff8327a9e0 R11: 6f69747265737361 R12: ffff88813018d310
R13: ffff888168b8a000 R14: ffffc90001d2bd90 R15: ffff88810a169000
FS: 0000000000000000(0000) GS:ffff8885e752c000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
------------[ cut here ]------------
[CAUSE]
The cause of -ENOSPC error during the test case btrfs/124 is still
unknown, although it's known that we still have cases where metadata can
be over-committed but can not be fulfilled correctly, thus if we hit
such ENOSPC error inside a critical path, we have no choice but abort
the current transaction.
This will mark the fs read-only.
The problem is inside the btrfs_repair_io_failure() path that we require
the fs not to be mount read-only. This is normally fine, but if we are
doing a read-repair meanwhile the fs flips RO due to a critical error,
we can enter btrfs_repair_io_failure() with super block set to
read-only, thus triggering the above crash.
[FIX]
Just replace the ASSERT() with a proper return if the fs is already
read-only.
Severity ?
No CVSS data available.
Assigner
References
Impacted products
{
"containers": {
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"fs/btrfs/bio.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "f6df18c001e3dcebc08482d0adeacd0cfea08593",
"status": "affected",
"version": "1da177e4c3f41524e886b7f1b8a0c1fc7321cac2",
"versionType": "git"
},
{
"lessThan": "8ceaad6cd6e7fa5f73b0b2796a2e85d75d37e9f3",
"status": "affected",
"version": "1da177e4c3f41524e886b7f1b8a0c1fc7321cac2",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"fs/btrfs/bio.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThanOrEqual": "6.19.*",
"status": "unaffected",
"version": "6.19.6",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "7.0",
"versionType": "original_commit_for_fix"
}
]
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.19.6",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "7.0",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: do not ASSERT() when the fs flips RO inside btrfs_repair_io_failure()\n\n[BUG]\nThere is a bug report that when btrfs hits ENOSPC error in a critical\npath, btrfs flips RO (this part is expected, although the ENOSPC bug\nstill needs to be addressed).\n\nThe problem is after the RO flip, if there is a read repair pending, we\ncan hit the ASSERT() inside btrfs_repair_io_failure() like the following:\n\n BTRFS info (device vdc): relocating block group 30408704 flags metadata|raid1\n ------------[ cut here ]------------\n BTRFS: Transaction aborted (error -28)\n WARNING: fs/btrfs/extent-tree.c:3235 at __btrfs_free_extent.isra.0+0x453/0xfd0, CPU#1: btrfs/383844\n Modules linked in: kvm_intel kvm irqbypass\n [...]\n ---[ end trace 0000000000000000 ]---\n BTRFS info (device vdc state EA): 2 enospc errors during balance\n BTRFS info (device vdc state EA): balance: ended with status: -30\n BTRFS error (device vdc state EA): parent transid verify failed on logical 30556160 mirror 2 wanted 8 found 6\n BTRFS error (device vdc state EA): bdev /dev/nvme0n1 errs: wr 0, rd 0, flush 0, corrupt 10, gen 0\n [...]\n assertion failed: !(fs_info-\u003esb-\u003es_flags \u0026 SB_RDONLY) :: 0, in fs/btrfs/bio.c:938\n ------------[ cut here ]------------\n assertion failed: !(fs_info-\u003esb-\u003es_flags \u0026 SB_RDONLY) :: 0, in fs/btrfs/bio.c:938\n kernel BUG at fs/btrfs/bio.c:938!\n Oops: invalid opcode: 0000 [#1] SMP NOPTI\n CPU: 0 UID: 0 PID: 868 Comm: kworker/u8:13 Tainted: G W N 6.19.0-rc6+ #4788 PREEMPT(full)\n Tainted: [W]=WARN, [N]=TEST\n Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.17.0-0-gb52ca86e094d-prebuilt.qemu.org 04/01/2014\n Workqueue: btrfs-endio simple_end_io_work\n RIP: 0010:btrfs_repair_io_failure.cold+0xb2/0x120\n RSP: 0000:ffffc90001d2bcf0 EFLAGS: 00010246\n RAX: 0000000000000051 RBX: 0000000000001000 RCX: 0000000000000000\n RDX: 0000000000000000 RSI: ffffffff8305cf42 RDI: 00000000ffffffff\n RBP: 0000000000000002 R08: 00000000fffeffff R09: ffffffff837fa988\n R10: ffffffff8327a9e0 R11: 6f69747265737361 R12: ffff88813018d310\n R13: ffff888168b8a000 R14: ffffc90001d2bd90 R15: ffff88810a169000\n FS: 0000000000000000(0000) GS:ffff8885e752c000(0000) knlGS:0000000000000000\n CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n ------------[ cut here ]------------\n\n[CAUSE]\nThe cause of -ENOSPC error during the test case btrfs/124 is still\nunknown, although it\u0027s known that we still have cases where metadata can\nbe over-committed but can not be fulfilled correctly, thus if we hit\nsuch ENOSPC error inside a critical path, we have no choice but abort\nthe current transaction.\n\nThis will mark the fs read-only.\n\nThe problem is inside the btrfs_repair_io_failure() path that we require\nthe fs not to be mount read-only. This is normally fine, but if we are\ndoing a read-repair meanwhile the fs flips RO due to a critical error,\nwe can enter btrfs_repair_io_failure() with super block set to\nread-only, thus triggering the above crash.\n\n[FIX]\nJust replace the ASSERT() with a proper return if the fs is already\nread-only."
}
],
"providerMetadata": {
"dateUpdated": "2026-05-08T13:11:20.872Z",
"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"shortName": "Linux"
},
"references": [
{
"url": "https://git.kernel.org/stable/c/f6df18c001e3dcebc08482d0adeacd0cfea08593"
},
{
"url": "https://git.kernel.org/stable/c/8ceaad6cd6e7fa5f73b0b2796a2e85d75d37e9f3"
}
],
"title": "btrfs: do not ASSERT() when the fs flips RO inside btrfs_repair_io_failure()",
"x_generator": {
"engine": "bippy-1.2.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"assignerShortName": "Linux",
"cveId": "CVE-2026-43299",
"datePublished": "2026-05-08T13:11:20.872Z",
"dateReserved": "2026-05-01T14:12:56.000Z",
"dateUpdated": "2026-05-08T13:11:20.872Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2",
"vulnerability-lookup:meta": {
"nvd": "{\"cve\":{\"id\":\"CVE-2026-43299\",\"sourceIdentifier\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"published\":\"2026-05-08T14:16:37.100\",\"lastModified\":\"2026-05-08T14:16:37.100\",\"vulnStatus\":\"Received\",\"cveTags\":[],\"descriptions\":[{\"lang\":\"en\",\"value\":\"In the Linux kernel, the following vulnerability has been resolved:\\n\\nbtrfs: do not ASSERT() when the fs flips RO inside btrfs_repair_io_failure()\\n\\n[BUG]\\nThere is a bug report that when btrfs hits ENOSPC error in a critical\\npath, btrfs flips RO (this part is expected, although the ENOSPC bug\\nstill needs to be addressed).\\n\\nThe problem is after the RO flip, if there is a read repair pending, we\\ncan hit the ASSERT() inside btrfs_repair_io_failure() like the following:\\n\\n BTRFS info (device vdc): relocating block group 30408704 flags metadata|raid1\\n ------------[ cut here ]------------\\n BTRFS: Transaction aborted (error -28)\\n WARNING: fs/btrfs/extent-tree.c:3235 at __btrfs_free_extent.isra.0+0x453/0xfd0, CPU#1: btrfs/383844\\n Modules linked in: kvm_intel kvm irqbypass\\n [...]\\n ---[ end trace 0000000000000000 ]---\\n BTRFS info (device vdc state EA): 2 enospc errors during balance\\n BTRFS info (device vdc state EA): balance: ended with status: -30\\n BTRFS error (device vdc state EA): parent transid verify failed on logical 30556160 mirror 2 wanted 8 found 6\\n BTRFS error (device vdc state EA): bdev /dev/nvme0n1 errs: wr 0, rd 0, flush 0, corrupt 10, gen 0\\n [...]\\n assertion failed: !(fs_info-\u003esb-\u003es_flags \u0026 SB_RDONLY) :: 0, in fs/btrfs/bio.c:938\\n ------------[ cut here ]------------\\n assertion failed: !(fs_info-\u003esb-\u003es_flags \u0026 SB_RDONLY) :: 0, in fs/btrfs/bio.c:938\\n kernel BUG at fs/btrfs/bio.c:938!\\n Oops: invalid opcode: 0000 [#1] SMP NOPTI\\n CPU: 0 UID: 0 PID: 868 Comm: kworker/u8:13 Tainted: G W N 6.19.0-rc6+ #4788 PREEMPT(full)\\n Tainted: [W]=WARN, [N]=TEST\\n Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.17.0-0-gb52ca86e094d-prebuilt.qemu.org 04/01/2014\\n Workqueue: btrfs-endio simple_end_io_work\\n RIP: 0010:btrfs_repair_io_failure.cold+0xb2/0x120\\n RSP: 0000:ffffc90001d2bcf0 EFLAGS: 00010246\\n RAX: 0000000000000051 RBX: 0000000000001000 RCX: 0000000000000000\\n RDX: 0000000000000000 RSI: ffffffff8305cf42 RDI: 00000000ffffffff\\n RBP: 0000000000000002 R08: 00000000fffeffff R09: ffffffff837fa988\\n R10: ffffffff8327a9e0 R11: 6f69747265737361 R12: ffff88813018d310\\n R13: ffff888168b8a000 R14: ffffc90001d2bd90 R15: ffff88810a169000\\n FS: 0000000000000000(0000) GS:ffff8885e752c000(0000) knlGS:0000000000000000\\n CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\\n ------------[ cut here ]------------\\n\\n[CAUSE]\\nThe cause of -ENOSPC error during the test case btrfs/124 is still\\nunknown, although it\u0027s known that we still have cases where metadata can\\nbe over-committed but can not be fulfilled correctly, thus if we hit\\nsuch ENOSPC error inside a critical path, we have no choice but abort\\nthe current transaction.\\n\\nThis will mark the fs read-only.\\n\\nThe problem is inside the btrfs_repair_io_failure() path that we require\\nthe fs not to be mount read-only. This is normally fine, but if we are\\ndoing a read-repair meanwhile the fs flips RO due to a critical error,\\nwe can enter btrfs_repair_io_failure() with super block set to\\nread-only, thus triggering the above crash.\\n\\n[FIX]\\nJust replace the ASSERT() with a proper return if the fs is already\\nread-only.\"}],\"metrics\":{},\"references\":[{\"url\":\"https://git.kernel.org/stable/c/8ceaad6cd6e7fa5f73b0b2796a2e85d75d37e9f3\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"},{\"url\":\"https://git.kernel.org/stable/c/f6df18c001e3dcebc08482d0adeacd0cfea08593\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"}]}}"
}
}
Loading…
Loading…
Experimental. This forecast is provided for visualization only and may change without notice. Do not use it for operational decisions.
Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.
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.
Loading…
Loading…