CVE-2024-40952 in Linux
Summary
by MITRE • 07/12/2024
In the Linux kernel, the following vulnerability has been resolved:
ocfs2: fix NULL pointer dereference in ocfs2_journal_dirty()
bdev->bd_super has been removed and commit 8887b94d9322 change the usage from bdev->bd_super to b_assoc_map->host->i_sb. This introduces the following NULL pointer dereference in ocfs2_journal_dirty() since b_assoc_map is still not initialized. This can be easily reproduced by running xfstests generic/186, which simulate no more credits.
[ 134.351592] BUG: kernel NULL pointer dereference, address: 0000000000000000
... [ 134.355341] RIP: 0010:ocfs2_journal_dirty+0x14f/0x160 [ocfs2]
... [ 134.365071] Call Trace:
[ 134.365312]
[ 134.365524] ? __die_body+0x1e/0x60
[ 134.365868] ? page_fault_oops+0x13d/0x4f0
[ 134.366265] ? __pfx_bit_wait_io+0x10/0x10
[ 134.366659] ? schedule+0x27/0xb0
[ 134.366981] ? exc_page_fault+0x6a/0x140
[ 134.367356] ? asm_exc_page_fault+0x26/0x30
[ 134.367762] ? ocfs2_journal_dirty+0x14f/0x160 [ocfs2]
[ 134.368305] ? ocfs2_journal_dirty+0x13d/0x160 [ocfs2]
[ 134.368837] ocfs2_create_new_meta_bhs.isra.51+0x139/0x2e0 [ocfs2]
[ 134.369454] ocfs2_grow_tree+0x688/0x8a0 [ocfs2]
[ 134.369927] ocfs2_split_and_insert.isra.67+0x35c/0x4a0 [ocfs2]
[ 134.370521] ocfs2_split_extent+0x314/0x4d0 [ocfs2]
[ 134.371019] ocfs2_change_extent_flag+0x174/0x410 [ocfs2]
[ 134.371566] ocfs2_add_refcount_flag+0x3fa/0x630 [ocfs2]
[ 134.372117] ocfs2_reflink_remap_extent+0x21b/0x4c0 [ocfs2]
[ 134.372994] ? inode_update_timestamps+0x4a/0x120
[ 134.373692] ? __pfx_ocfs2_journal_access_di+0x10/0x10 [ocfs2]
[ 134.374545] ? __pfx_ocfs2_journal_access_di+0x10/0x10 [ocfs2]
[ 134.375393] ocfs2_reflink_remap_blocks+0xe4/0x4e0 [ocfs2]
[ 134.376197] ocfs2_remap_file_range+0x1de/0x390 [ocfs2]
[ 134.376971] ? security_file_permission+0x29/0x50
[ 134.377644] vfs_clone_file_range+0xfe/0x320
[ 134.378268] ioctl_file_clone+0x45/0xa0
[ 134.378853] do_vfs_ioctl+0x457/0x990
[ 134.379422] __x64_sys_ioctl+0x6e/0xd0
[ 134.379987] do_syscall_64+0x5d/0x170
[ 134.380550] entry_SYSCALL_64_after_hwframe+0x76/0x7e
[ 134.381231] RIP: 0033:0x7fa4926397cb
[ 134.381786] Code: 73 01 c3 48 8b 0d bd 56 38 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa b8 10 00 00 00 0f 05 3d 01 f0 ff ff 73 01 c3 48 8b 0d 8d 56 38 00 f7 d8 64 89 01 48
[ 134.383930] RSP: 002b:00007ffc2b39f7b8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
[ 134.384854] RAX: ffffffffffffffda RBX: 0000000000000004 RCX: 00007fa4926397cb
[ 134.385734] RDX: 00007ffc2b39f7f0 RSI: 000000004020940d RDI: 0000000000000003
[ 134.386606] RBP: 0000000000000000 R08: 00111a82a4f015bb R09: 00007fa494221000
[ 134.387476] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
[ 134.388342] R13: 0000000000f10000 R14: 0000558e844e2ac8 R15: 0000000000f10000
[ 134.389207]
Fix it by only aborting transaction and journal in ocfs2_journal_dirty() now, and leave ocfs2_abort() later when detecting an aborted handle, e.g. start next transaction. Also log the handle details in this case.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 08/21/2024
The vulnerability described in CVE-2024-40952 affects the Linux kernel's OCFS2 (Oracle Cluster File System 2) implementation, specifically within the `ocfs2_journal_dirty()` function. This issue manifests as a NULL pointer dereference that occurs under certain conditions when the file system attempts to manage journal operations. The root cause stems from a recent change in how the kernel accesses superblock information, transitioning from `bdev->bd_super` to `b_assoc_map->host->i_sb`. While this change was intended to improve system behavior, it introduced a regression where `b_assoc_map` remains uninitialized during critical journal operations, leading to the kernel crashing upon dereferencing a NULL pointer.
The technical flaw occurs in the context of journal management for OCFS2 volumes, particularly when handling file operations that require journaling such as file cloning. The stack trace indicates that the crash originates from `ocfs2_journal_dirty()`, which is invoked during operations like `ocfs2_reflink_remap_blocks` and ultimately through `vfs_clone_file_range` and `ioctl_file_clone`. The function attempts to access `b_assoc_map->host->i_sb` without ensuring that `b_assoc_map` has been properly initialized, resulting in a kernel panic. This type of vulnerability aligns with CWE-476, which describes NULL pointer dereference, and represents a classic case of improper initialization leading to system instability. The issue is exacerbated by the fact that it can be easily reproduced using the xfstests generic/186 test suite, which simulates scenarios with no available credits, making it a significant concern for production systems relying on OCFS2.
The operational impact of this vulnerability is severe, as it can lead to complete system crashes and data unavailability in clustered environments using OCFS2. Systems running OCFS2 file systems are at risk of experiencing unexpected kernel oops and system panics, particularly under workloads involving file cloning or other operations that trigger journal dirtying. The vulnerability affects both single-node and clustered deployments, with the potential for cascading failures in high-availability setups where OCFS2 is used for shared storage. From an attacker perspective, this represents a denial-of-service vector that could be exploited to disrupt services or potentially escalate privileges if combined with other vulnerabilities. The fix implemented addresses this by modifying the error handling in `ocfs2_journal_dirty()` to avoid immediate kernel panic and instead defer the abort logic until a later point when proper handle validation can occur, logging the relevant handle details for debugging purposes.
The mitigation strategy involves applying the kernel patch that modifies the transaction handling logic in OCFS2 to prevent immediate NULL pointer dereference. The fix ensures that when `b_assoc_map` is not yet initialized, the function will abort the current transaction and journal without crashing the kernel, allowing the system to continue operating while logging appropriate diagnostics. This approach aligns with ATT&CK technique T1499.001, which involves operating system binary proxies, by ensuring that system stability is maintained during error conditions. Organizations should prioritize updating their kernel versions to include this fix, particularly those operating OCFS2 clusters in production environments. System administrators should also monitor for any kernel oops messages related to OCFS2 journal operations and ensure that all nodes in a cluster are updated consistently to prevent potential inconsistencies in journal handling across the cluster. The fix represents a defensive programming approach that prioritizes system resilience over immediate error reporting, which is critical for maintaining availability in enterprise storage environments.