{"api_version":"1","generated_at":"2026-05-27T22:56:53+00:00","cve":"CVE-2026-46066","urls":{"html":"https://cve.report/CVE-2026-46066","api":"https://cve.report/api/cve/CVE-2026-46066.json","docs":"https://cve.report/api","cve_org":"https://www.cve.org/CVERecord?id=CVE-2026-46066","nvd":"https://nvd.nist.gov/vuln/detail/CVE-2026-46066"},"summary":{"title":"ceph: fix num_ops off-by-one when crypto allocation fails","description":"In the Linux kernel, the following vulnerability has been resolved:\n\nceph: fix num_ops off-by-one when crypto allocation fails\n\nmove_dirty_folio_in_page_array() may fail if the file is encrypted, the\ndirty folio is not the first in the batch, and it fails to allocate a\nbounce buffer to hold the ciphertext. When that happens,\nceph_process_folio_batch() simply redirties the folio and flushes the\ncurrent batch -- it can retry that folio in a future batch.\n\nHowever, if this failed folio is not contiguous with the last folio that\ndid make it into the batch, then ceph_process_folio_batch() has already\nincremented `ceph_wbc->num_ops`; because it doesn't follow through and\nadd the discontiguous folio to the array, ceph_submit_write() -- which\nexpects that `ceph_wbc->num_ops` accurately reflects the number of\ncontiguous ranges (and therefore the required number of \"write extent\"\nops) in the writeback -- will panic the kernel:\n\n    BUG_ON(ceph_wbc->op_idx + 1 != req->r_num_ops);\n\nThis issue can be reproduced on affected kernels by writing to\nfscrypt-enabled CephFS file(s) with a 4KiB-written/4KiB-skipped/repeat\npattern (total filesize should not matter) and gradually increasing the\nsystem's memory pressure until a bounce buffer allocation fails.\n\nFix this crash by decrementing `ceph_wbc->num_ops` back to the correct\nvalue when move_dirty_folio_in_page_array() fails, but the folio already\nstarted counting a new (i.e. still-empty) extent.\n\nThe defect corrected by this patch has existed since 2022 (see first\n`Fixes:`), but another bug blocked multi-folio encrypted writeback until\nrecently (see second `Fixes:`). The second commit made it into 6.18.16,\n6.19.6, and 7.0-rc1, unmasking the panic in those versions. This patch\ntherefore fixes a regression (panic) introduced by cac190c7674f.","state":"PUBLISHED","assigner":"Linux","published_at":"2026-05-27 14:17:27","updated_at":"2026-05-27 14:48:03"},"problem_types":[],"metrics":[],"references":[{"url":"https://git.kernel.org/stable/c/a0d9555bf9eaeba34fe6b6bb86f442fe08ba3842","name":"https://git.kernel.org/stable/c/a0d9555bf9eaeba34fe6b6bb86f442fe08ba3842","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://git.kernel.org/stable/c/ba12c1e578890f6337a415b7dedf476c6d455105","name":"https://git.kernel.org/stable/c/ba12c1e578890f6337a415b7dedf476c6d455105","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://git.kernel.org/stable/c/6200f41d6fcf2ac7e24866431e381cbc914560e4","name":"https://git.kernel.org/stable/c/6200f41d6fcf2ac7e24866431e381cbc914560e4","refsource":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-46066","name":"CVE Program record","refsource":"CVE.ORG","tags":["canonical"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-46066","name":"NVD vulnerability detail","refsource":"NVD","tags":["canonical","analysis"]}],"affected":[{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected d55207717ded95c8f2760a30e93319fa313186e6 6200f41d6fcf2ac7e24866431e381cbc914560e4 git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected d55207717ded95c8f2760a30e93319fa313186e6 ba12c1e578890f6337a415b7dedf476c6d455105 git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected d55207717ded95c8f2760a30e93319fa313186e6 a0d9555bf9eaeba34fe6b6bb86f442fe08ba3842 git","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"affected 6.6","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 6.6 semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 6.18.30 6.18.* semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 7.0.4 7.0.* semver","platforms":[]},{"source":"CNA","vendor":"Linux","product":"Linux","version":"unaffected 7.1-rc1 * original_commit_for_fix","platforms":[]}],"timeline":[],"solutions":[],"workarounds":[],"exploits":[],"credits":[],"nvd_cpes":[],"vendor_comments":[],"enrichments":{"kev":null,"epss":null,"legacy_qids":[]},"source_records":{"cve_program":{"containers":{"cna":{"affected":[{"defaultStatus":"unaffected","product":"Linux","programFiles":["fs/ceph/addr.c"],"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","versions":[{"lessThan":"6200f41d6fcf2ac7e24866431e381cbc914560e4","status":"affected","version":"d55207717ded95c8f2760a30e93319fa313186e6","versionType":"git"},{"lessThan":"ba12c1e578890f6337a415b7dedf476c6d455105","status":"affected","version":"d55207717ded95c8f2760a30e93319fa313186e6","versionType":"git"},{"lessThan":"a0d9555bf9eaeba34fe6b6bb86f442fe08ba3842","status":"affected","version":"d55207717ded95c8f2760a30e93319fa313186e6","versionType":"git"}]},{"defaultStatus":"affected","product":"Linux","programFiles":["fs/ceph/addr.c"],"repo":"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git","vendor":"Linux","versions":[{"status":"affected","version":"6.6"},{"lessThan":"6.6","status":"unaffected","version":"0","versionType":"semver"},{"lessThanOrEqual":"6.18.*","status":"unaffected","version":"6.18.30","versionType":"semver"},{"lessThanOrEqual":"7.0.*","status":"unaffected","version":"7.0.4","versionType":"semver"},{"lessThanOrEqual":"*","status":"unaffected","version":"7.1-rc1","versionType":"original_commit_for_fix"}]}],"cpeApplicability":[{"nodes":[{"cpeMatch":[{"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionEndExcluding":"6.18.30","versionStartIncluding":"6.6","vulnerable":true},{"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionEndExcluding":"7.0.4","versionStartIncluding":"6.6","vulnerable":true},{"criteria":"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*","versionEndExcluding":"7.1-rc1","versionStartIncluding":"6.6","vulnerable":true}],"negate":false,"operator":"OR"}]}],"descriptions":[{"lang":"en","value":"In the Linux kernel, the following vulnerability has been resolved:\n\nceph: fix num_ops off-by-one when crypto allocation fails\n\nmove_dirty_folio_in_page_array() may fail if the file is encrypted, the\ndirty folio is not the first in the batch, and it fails to allocate a\nbounce buffer to hold the ciphertext. When that happens,\nceph_process_folio_batch() simply redirties the folio and flushes the\ncurrent batch -- it can retry that folio in a future batch.\n\nHowever, if this failed folio is not contiguous with the last folio that\ndid make it into the batch, then ceph_process_folio_batch() has already\nincremented `ceph_wbc->num_ops`; because it doesn't follow through and\nadd the discontiguous folio to the array, ceph_submit_write() -- which\nexpects that `ceph_wbc->num_ops` accurately reflects the number of\ncontiguous ranges (and therefore the required number of \"write extent\"\nops) in the writeback -- will panic the kernel:\n\n    BUG_ON(ceph_wbc->op_idx + 1 != req->r_num_ops);\n\nThis issue can be reproduced on affected kernels by writing to\nfscrypt-enabled CephFS file(s) with a 4KiB-written/4KiB-skipped/repeat\npattern (total filesize should not matter) and gradually increasing the\nsystem's memory pressure until a bounce buffer allocation fails.\n\nFix this crash by decrementing `ceph_wbc->num_ops` back to the correct\nvalue when move_dirty_folio_in_page_array() fails, but the folio already\nstarted counting a new (i.e. still-empty) extent.\n\nThe defect corrected by this patch has existed since 2022 (see first\n`Fixes:`), but another bug blocked multi-folio encrypted writeback until\nrecently (see second `Fixes:`). The second commit made it into 6.18.16,\n6.19.6, and 7.0-rc1, unmasking the panic in those versions. This patch\ntherefore fixes a regression (panic) introduced by cac190c7674f."}],"providerMetadata":{"dateUpdated":"2026-05-27T12:57:41.865Z","orgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","shortName":"Linux"},"references":[{"url":"https://git.kernel.org/stable/c/6200f41d6fcf2ac7e24866431e381cbc914560e4"},{"url":"https://git.kernel.org/stable/c/ba12c1e578890f6337a415b7dedf476c6d455105"},{"url":"https://git.kernel.org/stable/c/a0d9555bf9eaeba34fe6b6bb86f442fe08ba3842"}],"title":"ceph: fix num_ops off-by-one when crypto allocation fails","x_generator":{"engine":"bippy-1.2.0"}}},"cveMetadata":{"assignerOrgId":"416baaa9-dc9f-4396-8d5f-8c081fb06d67","assignerShortName":"Linux","cveId":"CVE-2026-46066","datePublished":"2026-05-27T12:57:41.865Z","dateReserved":"2026-05-13T15:03:33.095Z","dateUpdated":"2026-05-27T12:57:41.865Z","state":"PUBLISHED"},"dataType":"CVE_RECORD","dataVersion":"5.2"},"nvd":{"publishedDate":"2026-05-27 14:17:27","lastModifiedDate":"2026-05-27 14:48:03","problem_types":[],"metrics":[],"configurations":[]},"legacy_mitre":{"record":{"CveYear":"2026","CveId":"46066","Ordinal":"1","Title":"ceph: fix num_ops off-by-one when crypto allocation fails","CVE":"CVE-2026-46066","Year":"2026"},"notes":[{"CveYear":"2026","CveId":"46066","Ordinal":"1","NoteData":"In the Linux kernel, the following vulnerability has been resolved:\n\nceph: fix num_ops off-by-one when crypto allocation fails\n\nmove_dirty_folio_in_page_array() may fail if the file is encrypted, the\ndirty folio is not the first in the batch, and it fails to allocate a\nbounce buffer to hold the ciphertext. When that happens,\nceph_process_folio_batch() simply redirties the folio and flushes the\ncurrent batch -- it can retry that folio in a future batch.\n\nHowever, if this failed folio is not contiguous with the last folio that\ndid make it into the batch, then ceph_process_folio_batch() has already\nincremented `ceph_wbc->num_ops`; because it doesn't follow through and\nadd the discontiguous folio to the array, ceph_submit_write() -- which\nexpects that `ceph_wbc->num_ops` accurately reflects the number of\ncontiguous ranges (and therefore the required number of \"write extent\"\nops) in the writeback -- will panic the kernel:\n\n    BUG_ON(ceph_wbc->op_idx + 1 != req->r_num_ops);\n\nThis issue can be reproduced on affected kernels by writing to\nfscrypt-enabled CephFS file(s) with a 4KiB-written/4KiB-skipped/repeat\npattern (total filesize should not matter) and gradually increasing the\nsystem's memory pressure until a bounce buffer allocation fails.\n\nFix this crash by decrementing `ceph_wbc->num_ops` back to the correct\nvalue when move_dirty_folio_in_page_array() fails, but the folio already\nstarted counting a new (i.e. still-empty) extent.\n\nThe defect corrected by this patch has existed since 2022 (see first\n`Fixes:`), but another bug blocked multi-folio encrypted writeback until\nrecently (see second `Fixes:`). The second commit made it into 6.18.16,\n6.19.6, and 7.0-rc1, unmasking the panic in those versions. This patch\ntherefore fixes a regression (panic) introduced by cac190c7674f.","Type":"Description","Title":"ceph: fix num_ops off-by-one when crypto allocation fails"}]}}}