CVE-2024-40952
- Source
- https://nvd.nist.gov/vuln/detail/CVE-2024-40952
- Import Source
- https://storage.googleapis.com/osv-test-cve-osv-conversion/osv-output/CVE-2024-40952.json
- JSON Data
- https://api.test.osv.dev/v1/vulns/CVE-2024-40952
- Downstream
- Published
- 2024-07-12T13:15:17Z
- Modified
- 2025-08-09T20:01:27Z
- Severity
-
- 5.5 (Medium) CVSS_V3 - CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H CVSS Calculator
- Summary
- [none]
- Details
-
In the Linux kernel, the following vulnerability has been resolved:
ocfs2: fix NULL pointer dereference in ocfs2journaldirty()
bdev->bdsuper has been removed and commit 8887b94d9322 change the usage from bdev->bdsuper to bassocmap->host->isb. This introduces the following NULL pointer dereference in ocfs2journaldirty() since bassoc_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:ocfs2journaldirty+0x14f/0x160 [ocfs2] ... [ 134.365071] Call Trace: [ 134.365312] <TASK> [ 134.365524] ? _diebody+0x1e/0x60 [ 134.365868] ? pagefaultoops+0x13d/0x4f0 [ 134.366265] ? _pfxbitwaitio+0x10/0x10 [ 134.366659] ? schedule+0x27/0xb0 [ 134.366981] ? excpagefault+0x6a/0x140 [ 134.367356] ? asmexcpagefault+0x26/0x30 [ 134.367762] ? ocfs2journaldirty+0x14f/0x160 [ocfs2] [ 134.368305] ? ocfs2journaldirty+0x13d/0x160 [ocfs2] [ 134.368837] ocfs2createnewmetabhs.isra.51+0x139/0x2e0 [ocfs2] [ 134.369454] ocfs2growtree+0x688/0x8a0 [ocfs2] [ 134.369927] ocfs2splitandinsert.isra.67+0x35c/0x4a0 [ocfs2] [ 134.370521] ocfs2splitextent+0x314/0x4d0 [ocfs2] [ 134.371019] ocfs2changeextentflag+0x174/0x410 [ocfs2] [ 134.371566] ocfs2addrefcountflag+0x3fa/0x630 [ocfs2] [ 134.372117] ocfs2reflinkremapextent+0x21b/0x4c0 [ocfs2] [ 134.372994] ? inodeupdatetimestamps+0x4a/0x120 [ 134.373692] ? _pfxocfs2journalaccessdi+0x10/0x10 [ocfs2] [ 134.374545] ? _pfxocfs2journalaccessdi+0x10/0x10 [ocfs2] [ 134.375393] ocfs2reflinkremapblocks+0xe4/0x4e0 [ocfs2] [ 134.376197] ocfs2remapfilerange+0x1de/0x390 [ocfs2] [ 134.376971] ? securityfilepermission+0x29/0x50 [ 134.377644] vfsclonefilerange+0xfe/0x320 [ 134.378268] ioctlfileclone+0x45/0xa0 [ 134.378853] dovfsioctl+0x457/0x990 [ 134.379422] _x64sysioctl+0x6e/0xd0 [ 134.379987] dosyscall64+0x5d/0x170 [ 134.380550] entrySYSCALL64afterhwframe+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 <48> 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 ORIGRAX: 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] </TASK>
Fix it by only aborting transaction and journal in ocfs2journaldirty() now, and leave ocfs2_abort() later when detecting an aborted handle, e.g. start next transaction. Also log the handle details in this case.
- References