CVE-2024-42077

{"id": "CVE-2024-42077", "cveTags": [], "metrics": {"cvssMetricV31": [{"type": "Primary", "source": "nvd@nist.gov", "cvssData": {"scope": "UNCHANGED", "version": "3.1", "baseScore": 5.5, "attackVector": "LOCAL", "baseSeverity": "MEDIUM", "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H", "integrityImpact": "NONE", "userInteraction": "NONE", "attackComplexity": "LOW", "availabilityImpact": "HIGH", "privilegesRequired": "LOW", "confidentialityImpact": "NONE"}, "impactScore": 3.6, "exploitabilityScore": 1.8}]}, "published": "2024-07-29T16:15:07.037", "references": [{"url": "https://git.kernel.org/stable/c/320273b5649bbcee87f9e65343077189699d2a7a", "tags": ["Patch"], "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/331d1079d58206ff7dc5518185f800b412f89bc6", "tags": ["Patch"], "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/9ea2d1c6789722d58ec191f14f9a02518d55b6b4", "tags": ["Patch"], "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/a68b896aa56e435506453ec8835bc991ec3ae687", "tags": ["Patch"], "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/be346c1a6eeb49d8fda827d2a9522124c2f72f36", "tags": ["Patch"], "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}, {"url": "https://git.kernel.org/stable/c/c05ffb693bfb42a48ef3ee88a55b57392984e111", "tags": ["Patch"], "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}], "vulnStatus": "Analyzed", "weaknesses": [{"type": "Primary", "source": "nvd@nist.gov", "description": [{"lang": "en", "value": "NVD-CWE-noinfo"}]}], "descriptions": [{"lang": "en", "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nocfs2: fix DIO failure due to insufficient transaction credits\n\nThe code in ocfs2_dio_end_io_write() estimates number of necessary\ntransaction credits using ocfs2_calc_extend_credits(). This however does\nnot take into account that the IO could be arbitrarily large and can\ncontain arbitrary number of extents.\n\nExtent tree manipulations do often extend the current transaction but not\nin all of the cases. For example if we have only single block extents in\nthe tree, ocfs2_mark_extent_written() will end up calling\nocfs2_replace_extent_rec() all the time and we will never extend the\ncurrent transaction and eventually exhaust all the transaction credits if\nthe IO contains many single block extents. Once that happens a\nWARN_ON(jbd2_handle_buffer_credits(handle) <= 0) is triggered in\njbd2_journal_dirty_metadata() and subsequently OCFS2 aborts in response to\nthis error. This was actually triggered by one of our customers on a\nheavily fragmented OCFS2 filesystem.\n\nTo fix the issue make sure the transaction always has enough credits for\none extent insert before each call of ocfs2_mark_extent_written().\n\nHeming Zhao said:\n\n------\nPANIC: \"Kernel panic - not syncing: OCFS2: (device dm-1): panic forced after error\"\n\nPID: xxx TASK: xxxx CPU: 5 COMMAND: \"SubmitThread-CA\"\n #0 machine_kexec at ffffffff8c069932\n #1 __crash_kexec at ffffffff8c1338fa\n #2 panic at ffffffff8c1d69b9\n #3 ocfs2_handle_error at ffffffffc0c86c0c [ocfs2]\n #4 __ocfs2_abort at ffffffffc0c88387 [ocfs2]\n #5 ocfs2_journal_dirty at ffffffffc0c51e98 [ocfs2]\n #6 ocfs2_split_extent at ffffffffc0c27ea3 [ocfs2]\n #7 ocfs2_change_extent_flag at ffffffffc0c28053 [ocfs2]\n #8 ocfs2_mark_extent_written at ffffffffc0c28347 [ocfs2]\n #9 ocfs2_dio_end_io_write at ffffffffc0c2bef9 [ocfs2]\n#10 ocfs2_dio_end_io at ffffffffc0c2c0f5 [ocfs2]\n#11 dio_complete at ffffffff8c2b9fa7\n#12 do_blockdev_direct_IO at ffffffff8c2bc09f\n#13 ocfs2_direct_IO at ffffffffc0c2b653 [ocfs2]\n#14 generic_file_direct_write at ffffffff8c1dcf14\n#15 __generic_file_write_iter at ffffffff8c1dd07b\n#16 ocfs2_file_write_iter at ffffffffc0c49f1f [ocfs2]\n#17 aio_write at ffffffff8c2cc72e\n#18 kmem_cache_alloc at ffffffff8c248dde\n#19 do_io_submit at ffffffff8c2ccada\n#20 do_syscall_64 at ffffffff8c004984\n#21 entry_SYSCALL_64_after_hwframe at ffffffff8c8000ba"}, {"lang": "es", "value": "En el kernel de Linux, se resolvi\u00f3 la siguiente vulnerabilidad: ocfs2: corrige la falla de DIO debido a cr\u00e9ditos de transacci\u00f3n insuficientes. El c\u00f3digo en ocfs2_dio_end_io_write() estima el n\u00famero de cr\u00e9ditos de transacci\u00f3n necesarios usando ocfs2_calc_extend_credits(). Sin embargo, esto no tiene en cuenta que el IO podr\u00eda ser arbitrariamente grande y contener un n\u00famero arbitrario de extensiones. Las manipulaciones del \u00e1rbol de extensi\u00f3n a menudo extienden la transacci\u00f3n actual, pero no en todos los casos. Por ejemplo, si solo tenemos extensiones de un solo bloque en el \u00e1rbol, ocfs2_mark_extent_write() terminar\u00e1 llamando a ocfs2_replace_extent_rec() todo el tiempo y nunca extenderemos la transacci\u00f3n actual y eventualmente agotaremos todos los cr\u00e9ditos de la transacci\u00f3n si el IO contiene muchas extensiones de un solo bloque. Una vez que eso sucede, se activa un WARN_ON(jbd2_handle_buffer_credits(handle) &lt;= 0) en jbd2_journal_dirty_metadata() y posteriormente OCFS2 cancela en respuesta a este error. En realidad, esto fue provocado por uno de nuestros clientes en un sistema de archivos OCFS2 muy fragmentado. Para solucionar el problema, aseg\u00farese de que la transacci\u00f3n siempre tenga suficientes cr\u00e9ditos para una inserci\u00f3n de extensi\u00f3n antes de cada llamada de ocfs2_mark_extent_writing(). Heming Zhao dijo: ------ P\u00c1NICO: \"P\u00e1nico del kernel - no se sincroniza: OCFS2: (dispositivo dm-1): p\u00e1nico forzado despu\u00e9s del error\" PID: xxx TAREA: xxxx CPU: 5 COMANDO: \"SubmitThread-CA\" # 0 machine_kexec en ffffffff8c069932 #1 __crash_kexec en ffffffff8c1338fa #2 p\u00e1nico en ffffffff8c1d69b9 #3 ocfs2_handle_error en ffffffffc0c86c0c [ocfs2] #4 __ocfs2_abort en ffffffffc0c88387 #5 ocfs2_journal_dirty en ffffffffc0c51e98 [ocfs2] #6 ocfs2_split_extent en ffffffffc0c27ea3 [ocfs2] #7 ocfs2_change_extent_flag en ffffffffc0c28053 [ocfs2] #8 ocfs2_mark_extent_writing en ffffffffc0c28347 [ocfs2] #9 ocfs2_dio_end_io_write en ffffffffc0c2bef9 [ocfs2] #10 ocfs2_dio_end_io en ffffffffc0c2c0f5 [ocfs2] #11 completo en ffffffff8c2b9fa7 #12 do_blockdev_direct_IO en ffffffff8c2bc09f #13 ocfs2_direct_IO en ffffffffc0c2b653 [ocfs2] #14 generic_file_direct_write en ffffffff8c1dcf14 #15 __generic_file_write_iter en ffffffff8c1dd07b #16 ocfs2_file_write_iter en ffffffffc0c49f1f [ocfs2] #17 aio_write en ffffffff8c2cc72e #18 kmem_cache_alloc en ffffffff8c248dde #19 _enviar en ffffffff8c2ccada #20 do_syscall_64 en ffffffff8c004984 #21 Entry_SYSCALL_64_after_hwframe en ffffffff8c8000ba"}], "lastModified": "2024-07-30T18:59:53.480", "configurations": [{"nodes": [{"negate": false, "cpeMatch": [{"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "vulnerable": true, "matchCriteriaId": "BB258587-714D-4846-9C1F-798BB73BF43E", "versionEndExcluding": "4.6"}, {"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "vulnerable": true, "matchCriteriaId": "E3CE7A55-F62F-405A-AED4-E9E38AE2F163", "versionEndExcluding": "5.10.221", "versionStartIncluding": "4.7"}, {"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "vulnerable": true, "matchCriteriaId": "10A39ACC-3005-40E8-875C-98A372D1FFD5", "versionEndExcluding": "5.15.162", "versionStartIncluding": "5.11"}, {"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "vulnerable": true, "matchCriteriaId": "748B6C4B-1F61-47F9-96CC-8899B8412D84", "versionEndExcluding": "6.1.97", "versionStartIncluding": "5.16"}, {"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "vulnerable": true, "matchCriteriaId": "D72E033B-5323-4C4D-8818-36E1EBC3535F", "versionEndExcluding": "6.6.37", "versionStartIncluding": "6.2"}, {"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*", "vulnerable": true, "matchCriteriaId": "E95105F2-32E3-4C5F-9D18-7AEFD0E6275C", "versionEndExcluding": "6.9.8", "versionStartIncluding": "6.7"}], "operator": "OR"}]}], "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"}