{"dataType": "CVE_RECORD", "dataVersion": "5.1", "cveMetadata": {"cveId": "CVE-2021-46987", "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "state": "PUBLISHED", "assignerShortName": "Linux", "dateReserved": "2024-02-27T18:42:55.947Z", "datePublished": "2024-02-28T08:13:14.690Z", "dateUpdated": "2024-11-04T11:57:11.896Z"}, "containers": {"cna": {"providerMetadata": {"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "shortName": "Linux", "dateUpdated": "2024-11-04T11:57:11.896Z"}, "descriptions": [{"lang": "en", "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: fix deadlock when cloning inline extents and using qgroups\n\nThere are a few exceptional cases where cloning an inline extent needs to\ncopy the inline extent data into a page of the destination inode.\n\nWhen this happens, we end up starting a transaction while having a dirty\npage for the destination inode and while having the range locked in the\ndestination's inode iotree too. Because when reserving metadata space\nfor a transaction we may need to flush existing delalloc in case there is\nnot enough free space, we have a mechanism in place to prevent a deadlock,\nwhich was introduced in commit 3d45f221ce627d (\"btrfs: fix deadlock when\ncloning inline extent and low on free metadata space\").\n\nHowever when using qgroups, a transaction also reserves metadata qgroup\nspace, which can also result in flushing delalloc in case there is not\nenough available space at the moment. When this happens we deadlock, since\nflushing delalloc requires locking the file range in the inode's iotree\nand the range was already locked at the very beginning of the clone\noperation, before attempting to start the transaction.\n\nWhen this issue happens, stack traces like the following are reported:\n\n [72747.556262] task:kworker/u81:9 state:D stack: 0 pid: 225 ppid: 2 flags:0x00004000\n [72747.556268] Workqueue: writeback wb_workfn (flush-btrfs-1142)\n [72747.556271] Call Trace:\n [72747.556273] __schedule+0x296/0x760\n [72747.556277] schedule+0x3c/0xa0\n [72747.556279] io_schedule+0x12/0x40\n [72747.556284] __lock_page+0x13c/0x280\n [72747.556287] ? generic_file_readonly_mmap+0x70/0x70\n [72747.556325] extent_write_cache_pages+0x22a/0x440 [btrfs]\n [72747.556331] ? __set_page_dirty_nobuffers+0xe7/0x160\n [72747.556358] ? set_extent_buffer_dirty+0x5e/0x80 [btrfs]\n [72747.556362] ? update_group_capacity+0x25/0x210\n [72747.556366] ? cpumask_next_and+0x1a/0x20\n [72747.556391] extent_writepages+0x44/0xa0 [btrfs]\n [72747.556394] do_writepages+0x41/0xd0\n [72747.556398] __writeback_single_inode+0x39/0x2a0\n [72747.556403] writeback_sb_inodes+0x1ea/0x440\n [72747.556407] __writeback_inodes_wb+0x5f/0xc0\n [72747.556410] wb_writeback+0x235/0x2b0\n [72747.556414] ? get_nr_inodes+0x35/0x50\n [72747.556417] wb_workfn+0x354/0x490\n [72747.556420] ? newidle_balance+0x2c5/0x3e0\n [72747.556424] process_one_work+0x1aa/0x340\n [72747.556426] worker_thread+0x30/0x390\n [72747.556429] ? create_worker+0x1a0/0x1a0\n [72747.556432] kthread+0x116/0x130\n [72747.556435] ? kthread_park+0x80/0x80\n [72747.556438] ret_from_fork+0x1f/0x30\n\n [72747.566958] Workqueue: btrfs-flush_delalloc btrfs_work_helper [btrfs]\n [72747.566961] Call Trace:\n [72747.566964] __schedule+0x296/0x760\n [72747.566968] ? finish_wait+0x80/0x80\n [72747.566970] schedule+0x3c/0xa0\n [72747.566995] wait_extent_bit.constprop.68+0x13b/0x1c0 [btrfs]\n [72747.566999] ? finish_wait+0x80/0x80\n [72747.567024] lock_extent_bits+0x37/0x90 [btrfs]\n [72747.567047] btrfs_invalidatepage+0x299/0x2c0 [btrfs]\n [72747.567051] ? find_get_pages_range_tag+0x2cd/0x380\n [72747.567076] __extent_writepage+0x203/0x320 [btrfs]\n [72747.567102] extent_write_cache_pages+0x2bb/0x440 [btrfs]\n [72747.567106] ? update_load_avg+0x7e/0x5f0\n [72747.567109] ? enqueue_entity+0xf4/0x6f0\n [72747.567134] extent_writepages+0x44/0xa0 [btrfs]\n [72747.567137] ? enqueue_task_fair+0x93/0x6f0\n [72747.567140] do_writepages+0x41/0xd0\n [72747.567144] __filemap_fdatawrite_range+0xc7/0x100\n [72747.567167] btrfs_run_delalloc_work+0x17/0x40 [btrfs]\n [72747.567195] btrfs_work_helper+0xc2/0x300 [btrfs]\n [72747.567200] process_one_work+0x1aa/0x340\n [72747.567202] worker_thread+0x30/0x390\n [72747.567205] ? create_worker+0x1a0/0x1a0\n [72747.567208] kthread+0x116/0x130\n [72747.567211] ? kthread_park+0x80/0x80\n [72747.567214] ret_from_fork+0x1f/0x30\n\n [72747.569686] task:fsstress state:D stack: \n---truncated---"}], "affected": [{"product": "Linux", "vendor": "Linux", "defaultStatus": "unaffected", "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git", "programFiles": ["fs/btrfs/ctree.h", "fs/btrfs/inode.c", "fs/btrfs/ioctl.c", "fs/btrfs/qgroup.c", "fs/btrfs/send.c"], "versions": [{"version": "c53e9653605d", "lessThan": "d5347827d0b4", "status": "affected", "versionType": "git"}, {"version": "c53e9653605d", "lessThan": "96157707c042", "status": "affected", "versionType": "git"}, {"version": "c53e9653605d", "lessThan": "f9baa501b4fd", "status": "affected", "versionType": "git"}]}, {"product": "Linux", "vendor": "Linux", "defaultStatus": "affected", "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git", "programFiles": ["fs/btrfs/ctree.h", "fs/btrfs/inode.c", "fs/btrfs/ioctl.c", "fs/btrfs/qgroup.c", "fs/btrfs/send.c"], "versions": [{"version": "5.9", "status": "affected"}, {"version": "0", "lessThan": "5.9", "status": "unaffected", "versionType": "semver"}, {"version": "5.11.22", "lessThanOrEqual": "5.11.*", "status": "unaffected", "versionType": "semver"}, {"version": "5.12.5", "lessThanOrEqual": "5.12.*", "status": "unaffected", "versionType": "semver"}, {"version": "5.13", "lessThanOrEqual": "*", "status": "unaffected", "versionType": "original_commit_for_fix"}]}], "references": [{"url": "https://git.kernel.org/stable/c/d5347827d0b4b2250cbce6eccaa1c81dc78d8651"}, {"url": "https://git.kernel.org/stable/c/96157707c0420e3d3edfe046f1cc797fee117ade"}, {"url": "https://git.kernel.org/stable/c/f9baa501b4fd6962257853d46ddffbc21f27e344"}], "title": "btrfs: fix deadlock when cloning inline extents and using qgroups", "x_generator": {"engine": "bippy-9e1c9544281a"}}, "adp": [{"title": "CISA ADP Vulnrichment", "metrics": [{"other": {"type": "ssvc", "content": {"id": "CVE-2021-46987", "role": "CISA Coordinator", "options": [{"Exploitation": "none"}, {"Automatable": "no"}, {"Technical Impact": "partial"}], "version": "2.0.3", "timestamp": "2024-02-28T21:09:31.550377Z"}}}], "providerMetadata": {"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0", "shortName": "CISA-ADP", "dateUpdated": "2024-06-04T17:13:14.390Z"}}, {"providerMetadata": {"orgId": "af854a3a-2127-422b-91ae-364da2661108", "shortName": "CVE", "dateUpdated": "2024-08-04T05:24:38.449Z"}, "title": "CVE Program Container", "references": [{"url": "https://git.kernel.org/stable/c/d5347827d0b4b2250cbce6eccaa1c81dc78d8651", "tags": ["x_transferred"]}, {"url": "https://git.kernel.org/stable/c/96157707c0420e3d3edfe046f1cc797fee117ade", "tags": ["x_transferred"]}, {"url": "https://git.kernel.org/stable/c/f9baa501b4fd6962257853d46ddffbc21f27e344", "tags": ["x_transferred"]}]}]}}

{"dataType": "CVE_RECORD", "containers": {"adp": [{"title": "CVE Program Container", "references": [{"url": "https://git.kernel.org/stable/c/d5347827d0b4b2250cbce6eccaa1c81dc78d8651", "tags": ["x_transferred"]}, {"url": "https://git.kernel.org/stable/c/96157707c0420e3d3edfe046f1cc797fee117ade", "tags": ["x_transferred"]}, {"url": "https://git.kernel.org/stable/c/f9baa501b4fd6962257853d46ddffbc21f27e344", "tags": ["x_transferred"]}], "providerMetadata": {"orgId": "af854a3a-2127-422b-91ae-364da2661108", "shortName": "CVE", "dateUpdated": "2024-08-04T05:24:38.449Z"}}, {"metrics": [{"other": {"type": "ssvc", "content": {"id": "CVE-2021-46987", "role": "CISA Coordinator", "options": [{"Exploitation": "none"}, {"Automatable": "no"}, {"Technical Impact": "partial"}], "version": "2.0.3", "timestamp": "2024-02-28T21:09:31.550377Z"}}}], "providerMetadata": {"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0", "shortName": "CISA-ADP", "dateUpdated": "2024-05-23T19:01:13.876Z"}, "title": "CISA ADP Vulnrichment"}], "cna": {"title": "btrfs: fix deadlock when cloning inline extents and using qgroups", "affected": [{"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git", "vendor": "Linux", "product": "Linux", "versions": [{"status": "affected", "version": "c53e9653605d", "lessThan": "d5347827d0b4", "versionType": "git"}, {"status": "affected", "version": "c53e9653605d", "lessThan": "96157707c042", "versionType": "git"}, {"status": "affected", "version": "c53e9653605d", "lessThan": "f9baa501b4fd", "versionType": "git"}], "programFiles": ["fs/btrfs/ctree.h", "fs/btrfs/inode.c", "fs/btrfs/ioctl.c", "fs/btrfs/qgroup.c", "fs/btrfs/send.c"], "defaultStatus": "unaffected"}, {"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git", "vendor": "Linux", "product": "Linux", "versions": [{"status": "affected", "version": "5.9"}, {"status": "unaffected", "version": "0", "lessThan": "5.9", "versionType": "semver"}, {"status": "unaffected", "version": "5.11.22", "versionType": "semver", "lessThanOrEqual": "5.11.*"}, {"status": "unaffected", "version": "5.12.5", "versionType": "semver", "lessThanOrEqual": "5.12.*"}, {"status": "unaffected", "version": "5.13", "versionType": "original_commit_for_fix", "lessThanOrEqual": "*"}], "programFiles": ["fs/btrfs/ctree.h", "fs/btrfs/inode.c", "fs/btrfs/ioctl.c", "fs/btrfs/qgroup.c", "fs/btrfs/send.c"], "defaultStatus": "affected"}], "references": [{"url": "https://git.kernel.org/stable/c/d5347827d0b4b2250cbce6eccaa1c81dc78d8651"}, {"url": "https://git.kernel.org/stable/c/96157707c0420e3d3edfe046f1cc797fee117ade"}, {"url": "https://git.kernel.org/stable/c/f9baa501b4fd6962257853d46ddffbc21f27e344"}], "x_generator": {"engine": "bippy-9e1c9544281a"}, "descriptions": [{"lang": "en", "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: fix deadlock when cloning inline extents and using qgroups\n\nThere are a few exceptional cases where cloning an inline extent needs to\ncopy the inline extent data into a page of the destination inode.\n\nWhen this happens, we end up starting a transaction while having a dirty\npage for the destination inode and while having the range locked in the\ndestination's inode iotree too. Because when reserving metadata space\nfor a transaction we may need to flush existing delalloc in case there is\nnot enough free space, we have a mechanism in place to prevent a deadlock,\nwhich was introduced in commit 3d45f221ce627d (\"btrfs: fix deadlock when\ncloning inline extent and low on free metadata space\").\n\nHowever when using qgroups, a transaction also reserves metadata qgroup\nspace, which can also result in flushing delalloc in case there is not\nenough available space at the moment. When this happens we deadlock, since\nflushing delalloc requires locking the file range in the inode's iotree\nand the range was already locked at the very beginning of the clone\noperation, before attempting to start the transaction.\n\nWhen this issue happens, stack traces like the following are reported:\n\n [72747.556262] task:kworker/u81:9 state:D stack: 0 pid: 225 ppid: 2 flags:0x00004000\n [72747.556268] Workqueue: writeback wb_workfn (flush-btrfs-1142)\n [72747.556271] Call Trace:\n [72747.556273] __schedule+0x296/0x760\n [72747.556277] schedule+0x3c/0xa0\n [72747.556279] io_schedule+0x12/0x40\n [72747.556284] __lock_page+0x13c/0x280\n [72747.556287] ? generic_file_readonly_mmap+0x70/0x70\n [72747.556325] extent_write_cache_pages+0x22a/0x440 [btrfs]\n [72747.556331] ? __set_page_dirty_nobuffers+0xe7/0x160\n [72747.556358] ? set_extent_buffer_dirty+0x5e/0x80 [btrfs]\n [72747.556362] ? update_group_capacity+0x25/0x210\n [72747.556366] ? cpumask_next_and+0x1a/0x20\n [72747.556391] extent_writepages+0x44/0xa0 [btrfs]\n [72747.556394] do_writepages+0x41/0xd0\n [72747.556398] __writeback_single_inode+0x39/0x2a0\n [72747.556403] writeback_sb_inodes+0x1ea/0x440\n [72747.556407] __writeback_inodes_wb+0x5f/0xc0\n [72747.556410] wb_writeback+0x235/0x2b0\n [72747.556414] ? get_nr_inodes+0x35/0x50\n [72747.556417] wb_workfn+0x354/0x490\n [72747.556420] ? newidle_balance+0x2c5/0x3e0\n [72747.556424] process_one_work+0x1aa/0x340\n [72747.556426] worker_thread+0x30/0x390\n [72747.556429] ? create_worker+0x1a0/0x1a0\n [72747.556432] kthread+0x116/0x130\n [72747.556435] ? kthread_park+0x80/0x80\n [72747.556438] ret_from_fork+0x1f/0x30\n\n [72747.566958] Workqueue: btrfs-flush_delalloc btrfs_work_helper [btrfs]\n [72747.566961] Call Trace:\n [72747.566964] __schedule+0x296/0x760\n [72747.566968] ? finish_wait+0x80/0x80\n [72747.566970] schedule+0x3c/0xa0\n [72747.566995] wait_extent_bit.constprop.68+0x13b/0x1c0 [btrfs]\n [72747.566999] ? finish_wait+0x80/0x80\n [72747.567024] lock_extent_bits+0x37/0x90 [btrfs]\n [72747.567047] btrfs_invalidatepage+0x299/0x2c0 [btrfs]\n [72747.567051] ? find_get_pages_range_tag+0x2cd/0x380\n [72747.567076] __extent_writepage+0x203/0x320 [btrfs]\n [72747.567102] extent_write_cache_pages+0x2bb/0x440 [btrfs]\n [72747.567106] ? update_load_avg+0x7e/0x5f0\n [72747.567109] ? enqueue_entity+0xf4/0x6f0\n [72747.567134] extent_writepages+0x44/0xa0 [btrfs]\n [72747.567137] ? enqueue_task_fair+0x93/0x6f0\n [72747.567140] do_writepages+0x41/0xd0\n [72747.567144] __filemap_fdatawrite_range+0xc7/0x100\n [72747.567167] btrfs_run_delalloc_work+0x17/0x40 [btrfs]\n [72747.567195] btrfs_work_helper+0xc2/0x300 [btrfs]\n [72747.567200] process_one_work+0x1aa/0x340\n [72747.567202] worker_thread+0x30/0x390\n [72747.567205] ? create_worker+0x1a0/0x1a0\n [72747.567208] kthread+0x116/0x130\n [72747.567211] ? kthread_park+0x80/0x80\n [72747.567214] ret_from_fork+0x1f/0x30\n\n [72747.569686] task:fsstress state:D stack: \n---truncated---"}], "providerMetadata": {"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "shortName": "Linux", "dateUpdated": "2024-11-04T11:57:11.896Z"}}}, "cveMetadata": {"cveId": "CVE-2021-46987", "state": "PUBLISHED", "dateUpdated": "2024-11-04T11:57:11.896Z", "dateReserved": "2024-02-27T18:42:55.947Z", "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "datePublished": "2024-02-28T08:13:14.690Z", "assignerShortName": "Linux"}, "dataVersion": "5.1"}

{"cveTags": [], "descriptions": [{"lang": "en", "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: fix deadlock when cloning inline extents and using qgroups\n\nThere are a few exceptional cases where cloning an inline extent needs to\ncopy the inline extent data into a page of the destination inode.\n\nWhen this happens, we end up starting a transaction while having a dirty\npage for the destination inode and while having the range locked in the\ndestination's inode iotree too. Because when reserving metadata space\nfor a transaction we may need to flush existing delalloc in case there is\nnot enough free space, we have a mechanism in place to prevent a deadlock,\nwhich was introduced in commit 3d45f221ce627d (\"btrfs: fix deadlock when\ncloning inline extent and low on free metadata space\").\n\nHowever when using qgroups, a transaction also reserves metadata qgroup\nspace, which can also result in flushing delalloc in case there is not\nenough available space at the moment. When this happens we deadlock, since\nflushing delalloc requires locking the file range in the inode's iotree\nand the range was already locked at the very beginning of the clone\noperation, before attempting to start the transaction.\n\nWhen this issue happens, stack traces like the following are reported:\n\n [72747.556262] task:kworker/u81:9 state:D stack: 0 pid: 225 ppid: 2 flags:0x00004000\n [72747.556268] Workqueue: writeback wb_workfn (flush-btrfs-1142)\n [72747.556271] Call Trace:\n [72747.556273] __schedule+0x296/0x760\n [72747.556277] schedule+0x3c/0xa0\n [72747.556279] io_schedule+0x12/0x40\n [72747.556284] __lock_page+0x13c/0x280\n [72747.556287] ? generic_file_readonly_mmap+0x70/0x70\n [72747.556325] extent_write_cache_pages+0x22a/0x440 [btrfs]\n [72747.556331] ? __set_page_dirty_nobuffers+0xe7/0x160\n [72747.556358] ? set_extent_buffer_dirty+0x5e/0x80 [btrfs]\n [72747.556362] ? update_group_capacity+0x25/0x210\n [72747.556366] ? cpumask_next_and+0x1a/0x20\n [72747.556391] extent_writepages+0x44/0xa0 [btrfs]\n [72747.556394] do_writepages+0x41/0xd0\n [72747.556398] __writeback_single_inode+0x39/0x2a0\n [72747.556403] writeback_sb_inodes+0x1ea/0x440\n [72747.556407] __writeback_inodes_wb+0x5f/0xc0\n [72747.556410] wb_writeback+0x235/0x2b0\n [72747.556414] ? get_nr_inodes+0x35/0x50\n [72747.556417] wb_workfn+0x354/0x490\n [72747.556420] ? newidle_balance+0x2c5/0x3e0\n [72747.556424] process_one_work+0x1aa/0x340\n [72747.556426] worker_thread+0x30/0x390\n [72747.556429] ? create_worker+0x1a0/0x1a0\n [72747.556432] kthread+0x116/0x130\n [72747.556435] ? kthread_park+0x80/0x80\n [72747.556438] ret_from_fork+0x1f/0x30\n\n [72747.566958] Workqueue: btrfs-flush_delalloc btrfs_work_helper [btrfs]\n [72747.566961] Call Trace:\n [72747.566964] __schedule+0x296/0x760\n [72747.566968] ? finish_wait+0x80/0x80\n [72747.566970] schedule+0x3c/0xa0\n [72747.566995] wait_extent_bit.constprop.68+0x13b/0x1c0 [btrfs]\n [72747.566999] ? finish_wait+0x80/0x80\n [72747.567024] lock_extent_bits+0x37/0x90 [btrfs]\n [72747.567047] btrfs_invalidatepage+0x299/0x2c0 [btrfs]\n [72747.567051] ? find_get_pages_range_tag+0x2cd/0x380\n [72747.567076] __extent_writepage+0x203/0x320 [btrfs]\n [72747.567102] extent_write_cache_pages+0x2bb/0x440 [btrfs]\n [72747.567106] ? update_load_avg+0x7e/0x5f0\n [72747.567109] ? enqueue_entity+0xf4/0x6f0\n [72747.567134] extent_writepages+0x44/0xa0 [btrfs]\n [72747.567137] ? enqueue_task_fair+0x93/0x6f0\n [72747.567140] do_writepages+0x41/0xd0\n [72747.567144] __filemap_fdatawrite_range+0xc7/0x100\n [72747.567167] btrfs_run_delalloc_work+0x17/0x40 [btrfs]\n [72747.567195] btrfs_work_helper+0xc2/0x300 [btrfs]\n [72747.567200] process_one_work+0x1aa/0x340\n [72747.567202] worker_thread+0x30/0x390\n [72747.567205] ? create_worker+0x1a0/0x1a0\n [72747.567208] kthread+0x116/0x130\n [72747.567211] ? kthread_park+0x80/0x80\n [72747.567214] ret_from_fork+0x1f/0x30\n\n [72747.569686] task:fsstress state:D stack: \n---truncated---"}, {"lang": "es", "value": "En el kernel de Linux, se resolvi\u00f3 la siguiente vulnerabilidad: btrfs: soluciona el punto muerto al clonar extensiones en l\u00ednea y usar qgroups. Hay algunos casos excepcionales en los que la clonaci\u00f3n de una extensi\u00f3n en l\u00ednea necesita copiar los datos de la extensi\u00f3n en l\u00ednea en una p\u00e1gina del inodo de destino. Cuando esto sucede, terminamos iniciando una transacci\u00f3n mientras tenemos una p\u00e1gina sucia para el inodo de destino y tambi\u00e9n tenemos el rango bloqueado en el iotree del inodo de destino. Debido a que al reservar espacio de metadatos para una transacci\u00f3n, es posible que necesitemos vaciar la delalloc existente en caso de que no haya suficiente espacio libre, contamos con un mecanismo para evitar un punto muerto, que se introdujo en el commit 3d45f221ce627d (\"btrfs: corrige el punto muerto al clonar en l\u00ednea extensi\u00f3n y poco espacio libre para metadatos\"). Sin embargo, cuando se utilizan qgroups, una transacci\u00f3n tambi\u00e9n reserva espacio de metadatos en qgroup, lo que tambi\u00e9n puede provocar la eliminaci\u00f3n de delalloc en caso de que no haya suficiente espacio disponible en este momento. Cuando esto sucede, nos bloqueamos, ya que vaciar delalloc requiere bloquear el rango de archivos en el iotree del inodo y el rango ya estaba bloqueado al comienzo de la operaci\u00f3n de clonaci\u00f3n, antes de intentar iniciar la transacci\u00f3n. Cuando ocurre este problema, se informan seguimientos de pila como los siguientes: [72747.556262] task:kworker/u81:9 state:D stack: 0 pid: 225 ppid: 2 flags:0x00004000 [72747.556268] Workqueue: writeback wb_workfn (flush-btrfs- 1142) [72747.556271] Seguimiento de llamadas: [72747.556273] __schedule+0x296/0x760 [72747.556277] Schedule+0x3c/0xa0 [72747.556279] io_schedule+0x12/0x40 [72747.556284] __ lock_page+0x13c/0x280 [72747.556287] ? generic_file_readonly_mmap+0x70/0x70 [72747.556325] extend_write_cache_pages+0x22a/0x440 [btrfs] [72747.556331] ? __set_page_dirty_nobuffers+0xe7/0x160 [72747.556358] ? set_extent_buffer_dirty+0x5e/0x80 [btrfs] [72747.556362] ? update_group_capacity+0x25/0x210 [72747.556366] ? cpumask_next_and+0x1a/0x20 [72747.556391] extend_writepages+0x44/0xa0 [btrfs] [72747.556394] do_writepages+0x41/0xd0 [72747.556398] __writeback_single_inode+0x39/0x2a0 [72747 .556403] writeback_sb_inodes+0x1ea/0x440 [72747.556407] __writeback_inodes_wb+0x5f/0xc0 [72747.556410 ] wb_writeback+0x235/0x2b0 [72747.556414] ? get_nr_inodes+0x35/0x50 [72747.556417] wb_workfn+0x354/0x490 [72747.556420] ? newidle_balance+0x2c5/0x3e0 [72747.556424] proceso_one_work+0x1aa/0x340 [72747.556426] trabajador_thread+0x30/0x390 [72747.556429] ? create_worker+0x1a0/0x1a0 [72747.556432] kthread+0x116/0x130 [72747.556435] ? kthread_park+0x80/0x80 [72747.556438] ret_from_fork+0x1f/0x30 [72747.566958] Cola de trabajo: btrfs-flush_delalloc btrfs_work_helper [btrfs] [72747.566961] Seguimiento de llamadas: [72747.566964] __s programar+0x296/0x760 [72747.566968] ? terminar_esperar+0x80/0x80 [72747.566970] programar+0x3c/0xa0 [72747.566995] esperar_extent_bit.constprop.68+0x13b/0x1c0 [btrfs] [72747.566999] ? Finish_wait+0x80/0x80 [72747.567024] lock_extent_bits+0x37/0x90 [btrfs] [72747.567047] btrfs_invalidatepage+0x299/0x2c0 [btrfs] [72747.567051]? find_get_pages_range_tag+0x2cd/0x380 [72747.567076] __extent_writepage+0x203/0x320 [btrfs] [72747.567102] extend_write_cache_pages+0x2bb/0x440 [btrfs] [72747.567106] ? update_load_avg+0x7e/0x5f0 [72747.567109] ? enqueue_entity+0xf4/0x6f0 [72747.567134] extend_writepages+0x44/0xa0 [btrfs] [72747.567137]? enqueue_task_fair+0x93/0x6f0 [72747.567140] do_writepages+0x41/0xd0 [72747.567144] __filemap_fdatawrite_range+0xc7/0x100 [72747.567167] btrfs_run_delalloc_work+0x17/0x40 [btrfs ] [72747.567195] btrfs_work_helper+0xc2/0x300 [btrfs] [72747.567200] proceso_one_work+0x1aa/ 0x340 [72747.567202] hilo_trabajador+0x30/0x390 [72747.567205] ? create_worker+0x1a0/0x1a0 [72747.567208] kthread+0x116/0x130 [72747.567211]? kthread_park+0x80/0x80 [72747.567214] ret_from_fork+0x1f/0x30 [72747.569686] tarea:fsstress estado:D pila: ---truncado---"}], "id": "CVE-2021-46987", "lastModified": "2024-02-28T14:06:45.783", "metrics": {}, "published": "2024-02-28T09:15:37.583", "references": [{"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "url": "https://git.kernel.org/stable/c/96157707c0420e3d3edfe046f1cc797fee117ade"}, {"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "url": "https://git.kernel.org/stable/c/d5347827d0b4b2250cbce6eccaa1c81dc78d8651"}, {"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "url": "https://git.kernel.org/stable/c/f9baa501b4fd6962257853d46ddffbc21f27e344"}], "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67", "vulnStatus": "Awaiting Analysis"}

{"bugzilla": {"description": "kernel: btrfs: fix deadlock when cloning inline extents and using qgroups", "id": "2266752", "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2266752"}, "csaw": false, "cvss3": {"cvss3_base_score": "5.5", "cvss3_scoring_vector": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H", "status": "draft"}, "cwe": "CWE-833", "details": ["In the Linux kernel, the following vulnerability has been resolved:\nbtrfs: fix deadlock when cloning inline extents and using qgroups\nThere are a few exceptional cases where cloning an inline extent needs to\ncopy the inline extent data into a page of the destination inode.\nWhen this happens, we end up starting a transaction while having a dirty\npage for the destination inode and while having the range locked in the\ndestination's inode iotree too. Because when reserving metadata space\nfor a transaction we may need to flush existing delalloc in case there is\nnot enough free space, we have a mechanism in place to prevent a deadlock,\nwhich was introduced in commit 3d45f221ce627d (\"btrfs: fix deadlock when\ncloning inline extent and low on free metadata space\").\nHowever when using qgroups, a transaction also reserves metadata qgroup\nspace, which can also result in flushing delalloc in case there is not\nenough available space at the moment. When this happens we deadlock, since\nflushing delalloc requires locking the file range in the inode's iotree\nand the range was already locked at the very beginning of the clone\noperation, before attempting to start the transaction.\nWhen this issue happens, stack traces like the following are reported:\n[72747.556262] task:kworker/u81:9 state:D stack: 0 pid: 225 ppid: 2 flags:0x00004000\n[72747.556268] Workqueue: writeback wb_workfn (flush-btrfs-1142)\n[72747.556271] Call Trace:\n[72747.556273] __schedule+0x296/0x760\n[72747.556277] schedule+0x3c/0xa0\n[72747.556279] io_schedule+0x12/0x40\n[72747.556284] __lock_page+0x13c/0x280\n[72747.556287] ? generic_file_readonly_mmap+0x70/0x70\n[72747.556325] extent_write_cache_pages+0x22a/0x440 [btrfs]\n[72747.556331] ? __set_page_dirty_nobuffers+0xe7/0x160\n[72747.556358] ? set_extent_buffer_dirty+0x5e/0x80 [btrfs]\n[72747.556362] ? update_group_capacity+0x25/0x210\n[72747.556366] ? cpumask_next_and+0x1a/0x20\n[72747.556391] extent_writepages+0x44/0xa0 [btrfs]\n[72747.556394] do_writepages+0x41/0xd0\n[72747.556398] __writeback_single_inode+0x39/0x2a0\n[72747.556403] writeback_sb_inodes+0x1ea/0x440\n[72747.556407] __writeback_inodes_wb+0x5f/0xc0\n[72747.556410] wb_writeback+0x235/0x2b0\n[72747.556414] ? get_nr_inodes+0x35/0x50\n[72747.556417] wb_workfn+0x354/0x490\n[72747.556420] ? newidle_balance+0x2c5/0x3e0\n[72747.556424] process_one_work+0x1aa/0x340\n[72747.556426] worker_thread+0x30/0x390\n[72747.556429] ? create_worker+0x1a0/0x1a0\n[72747.556432] kthread+0x116/0x130\n[72747.556435] ? kthread_park+0x80/0x80\n[72747.556438] ret_from_fork+0x1f/0x30\n[72747.566958] Workqueue: btrfs-flush_delalloc btrfs_work_helper [btrfs]\n[72747.566961] Call Trace:\n[72747.566964] __schedule+0x296/0x760\n[72747.566968] ? finish_wait+0x80/0x80\n[72747.566970] schedule+0x3c/0xa0\n[72747.566995] wait_extent_bit.constprop.68+0x13b/0x1c0 [btrfs]\n[72747.566999] ? finish_wait+0x80/0x80\n[72747.567024] lock_extent_bits+0x37/0x90 [btrfs]\n[72747.567047] btrfs_invalidatepage+0x299/0x2c0 [btrfs]\n[72747.567051] ? find_get_pages_range_tag+0x2cd/0x380\n[72747.567076] __extent_writepage+0x203/0x320 [btrfs]\n[72747.567102] extent_write_cache_pages+0x2bb/0x440 [btrfs]\n[72747.567106] ? update_load_avg+0x7e/0x5f0\n[72747.567109] ? enqueue_entity+0xf4/0x6f0\n[72747.567134] extent_writepages+0x44/0xa0 [btrfs]\n[72747.567137] ? enqueue_task_fair+0x93/0x6f0\n[72747.567140] do_writepages+0x41/0xd0\n[72747.567144] __filemap_fdatawrite_range+0xc7/0x100\n[72747.567167] btrfs_run_delalloc_work+0x17/0x40 [btrfs]\n[72747.567195] btrfs_work_helper+0xc2/0x300 [btrfs]\n[72747.567200] process_one_work+0x1aa/0x340\n[72747.567202] worker_thread+0x30/0x390\n[72747.567205] ? create_worker+0x1a0/0x1a0\n[72747.567208] kthread+0x116/0x130\n[72747.567211] ? kthread_park+0x80/0x80\n[72747.567214] ret_from_fork+0x1f/0x30\n[72747.569686] task:fsstress state:D stack: \n---truncated---", "A vulnerability was found in the Linux kernel\u2019s btrfs module, where there are a few exceptional cases when cloning an inline extent needs to copy the inline extent data into a page of the destination inode.\u00a0 When this happens, a transaction starts while having a dirty page for the destination inode and while having the range locked in the destination's inode iotree. When reserving metadata space for a transaction, flushing the existing delalloc is needed in case there is not enough free space. There is a mechanism in place to prevent a deadlock, which was introduced in commit 3d45f221ce627d (\"btrfs: fix deadlock when cloning inline extent and low on free metadata space\").\nHowever, when using qgroups, a transaction also reserves metadata qgroup space, which can also result in flushing delalloc in case there is not enough available space. When this happens, a deadlock occurs, since flushing delalloc requires locking the file range in the inode's iotree and the range was already locked at the very beginning of the clone operation, before attempting to start the transaction."], "mitigation": {"lang": "en:us", "value": "Mitigation for this issue is either not available or the currently available options do not meet the Red Hat Product Security criteria comprising ease of use and deployment, applicability to widespread installation base or stability."}, "name": "CVE-2021-46987", "package_state": [{"cpe": "cpe:/o:redhat:enterprise_linux:6", "fix_state": "Out of support scope", "package_name": "kernel", "product_name": "Red Hat Enterprise Linux 6"}, {"cpe": "cpe:/o:redhat:enterprise_linux:7", "fix_state": "Out of support scope", "package_name": "kernel", "product_name": "Red Hat Enterprise Linux 7"}, {"cpe": "cpe:/o:redhat:enterprise_linux:7", "fix_state": "Out of support scope", "package_name": "kernel-rt", "product_name": "Red Hat Enterprise Linux 7"}, {"cpe": "cpe:/o:redhat:enterprise_linux:8", "fix_state": "Not affected", "package_name": "kernel", "product_name": "Red Hat Enterprise Linux 8"}, {"cpe": "cpe:/o:redhat:enterprise_linux:8", "fix_state": "Not affected", "package_name": "kernel-rt", "product_name": "Red Hat Enterprise Linux 8"}, {"cpe": "cpe:/o:redhat:enterprise_linux:9", "fix_state": "Not affected", "package_name": "kernel", "product_name": "Red Hat Enterprise Linux 9"}, {"cpe": "cpe:/o:redhat:enterprise_linux:9", "fix_state": "Not affected", "package_name": "kernel-rt", "product_name": "Red Hat Enterprise Linux 9"}], "public_date": "2024-02-28T00:00:00Z", "references": ["https://www.cve.org/CVERecord?id=CVE-2021-46987\nhttps://nvd.nist.gov/vuln/detail/CVE-2021-46987\nhttps://lore.kernel.org/linux-cve-announce/2024022825-CVE-2021-46987-f73f@gregkh/T/#u"], "statement": "Red Hat Enterprise Linux 8 and 9 are not affected by this CVE, as they do not include Btrfs filesystem support (CONFIG_BTRFS_FS is not set).", "threat_severity": "Moderate", "upstream_fix": "kernel 5.11.22, kernel 5.12.5, kernel 5.13"}