{"cve":"CVE-2026-46050","nvd":{"published":"2026-05-27T14:17:24.547","modified":"2026-10-15T02:19:40.513","status":"Modified","description":"In the Linux kernel, the following vulnerability has been resolved:\n\nmd/raid10: fix deadlock with check operation and nowait requests\n\nWhen an array check is running it will raise the barrier at which point\nnormal requests will become blocked and increment the nr_pending value to\nsignal there is work pending inside of wait_barrier(). NOWAIT requests\ndo not block and so will return immediately with an error, and additionally\ndo not increment nr_pending in wait_barrier(). Upstream change commit\n43806c3d5b9b (\"raid10: cleanup memleak at raid10_make_request\") added a\ncall to raid_end_bio_io() to fix a memory leak when NOWAIT requests hit\nthis condition. raid_end_bio_io() eventually calls allow_barrier() and\nit will unconditionally do an atomic_dec_and_test(&conf->nr_pending) even\nthough the corresponding increment on nr_pending didn't happen in the\nNOWAIT case.\n\nThis can be easily seen by starting a check operation while an application\nis doing nowait IO on the same array. This results in a deadlocked state\ndue to nr_pending value underflowing and so the md resync thread gets stuck\nwaiting for nr_pending to == 0.\n\nOutput of r10conf state of the array when we hit this condition:\n\ncrash> struct r10conf\n\tbarrier = 1,\n        nr_pending = {\n          counter = -41\n        },\n        nr_waiting = 15,\n        nr_queued = 0,\n\nExample of md_sync thread stuck waiting on raise_barrier() and other\nrequests stuck in wait_barrier():\n\nmd1_resync\n[<0>] raise_barrier+0xce/0x1c0\n[<0>] raid10_sync_request+0x1ca/0x1ed0\n[<0>] md_do_sync+0x779/0x1110\n[<0>] md_thread+0x90/0x160\n[<0>] kthread+0xbe/0xf0\n[<0>] ret_from_fork+0x34/0x50\n[<0>] ret_from_fork_asm+0x1a/0x30\n\nkworker/u1040:2+flush-253:4\n[<0>] wait_barrier+0x1de/0x220\n[<0>] regular_request_wait+0x30/0x180\n[<0>] raid10_make_request+0x261/0x1000\n[<0>] md_handle_request+0x13b/0x230\n[<0>] __submit_bio+0x107/0x1f0\n[<0>] submit_bio_noacct_nocheck+0x16f/0x390\n[<0>] ext4_io_submit+0x24/0x40\n[<0>] ext4_do_writepages+0x254/0xc80\n[<0>] ext4_writepages+0x84/0x120\n[<0>] do_writepages+0x7a/0x260\n[<0>] __writeback_single_inode+0x3d/0x300\n[<0>] writeback_sb_inodes+0x1dd/0x470\n[<0>] __writeback_inodes_wb+0x4c/0xe0\n[<0>] wb_writeback+0x18b/0x2d0\n[<0>] wb_workfn+0x2a1/0x400\n[<0>] process_one_work+0x149/0x330\n[<0>] worker_thread+0x2d2/0x410\n[<0>] kthread+0xbe/0xf0\n[<0>] ret_from_fork+0x34/0x50\n[<0>] ret_from_fork_asm+0x1a/0x30","cvss_v4":null,"cvss_v3":{"version":"3.1","vector":"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H","score":5.5},"cwes":["CWE-667"],"references":["https://git.kernel.org/stable/c/1cdff2937c618f81058422bbdc4974a3e7ec9379","https://git.kernel.org/stable/c/2249983d971e6839b36284e6610390b2c217dfa1","https://git.kernel.org/stable/c/42fe37c90184cd1568838b84b488934c3671c963","https://git.kernel.org/stable/c/7d96f3120a7fb7210d21b520c5b6f495da6ba436","https://git.kernel.org/stable/c/965d6162dd88cc7cc193cf7f5bfc132d8bbf0523"],"products":["linux:linux_kernel"],"source":"nvd","synced_at":"2026-10-19T22:36:28.938604137+00:00"},"epss":{"cve":"CVE-2026-46050","score":0.00095,"percentile":0.00602,"date":"2026-10-25"},"kev":null,"osv":[],"attribution":["This product uses the NVD API but is not endorsed or certified by the NVD.","EPSS scores: FIRST Exploit Prediction Scoring System, https://www.first.org/epss","Known exploited vulnerabilities: CISA Known Exploited Vulnerabilities Catalog, https://www.cisa.gov/known-exploited-vulnerabilities-catalog","Package advisories: OSV (https://osv.dev), from the GitHub Advisory Database, PyPA, Go, RustSec and other ecosystem databases, under CC-BY 4.0 or CC0","CVE records: the CVE Program's CVE List (https://www.cve.org), under its terms of use (https://www.cve.org/Legal/TermsOfUse). CVE is a registered trademark of The MITRE Corporation; this product is not affiliated with the CVE Program."]}