{ "schema_version": "1.6.1", "id": "RPI-CVE-2024-40943", "modified": "2026-10-09T11:39:44Z", "upstream": [ "CVE-2024-40943" ], "published": "2024-07-12T12:27:31Z", "summary": "ocfs2: fix races between hole punching and AIO+DIO", "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nocfs2: fix races between hole punching and AIO+DIO\n\nAfter commit \"ocfs2: return real error code in ocfs2_dio_wr_get_block\",\nfstests/generic/300 become from always failed to sometimes failed:\n\n========================================================================\n[ 473.293420 ] run fstests generic/300\n\n[ 475.296983 ] JBD2: Ignoring recovery information on journal\n[ 475.302473 ] ocfs2: Mounting device (253,1) on (node local, slot 0) with ordered data mode.\n[ 494.290998 ] OCFS2: ERROR (device dm-1): ocfs2_change_extent_flag: Owner 5668 has an extent at cpos 78723 which can no longer be found\n[ 494.291609 ] On-disk corruption discovered. Please run fsck.ocfs2 once the filesystem is unmounted.\n[ 494.292018 ] OCFS2: File system is now read-only.\n[ 494.292224 ] (kworker/19:11,2628,19):ocfs2_mark_extent_written:5272 ERROR: status = -30\n[ 494.292602 ] (kworker/19:11,2628,19):ocfs2_dio_end_io_write:2374 ERROR: status = -3\nfio: io_u error on file /mnt/scratch/racer: Read-only file system: write offset=460849152, buflen=131072\n=========================================================================\n\nIn __blockdev_direct_IO, ocfs2_dio_wr_get_block is called to add unwritten\nextents to a list. extents are also inserted into extent tree in\nocfs2_write_begin_nolock. Then another thread call fallocate to puch a\nhole at one of the unwritten extent. The extent at cpos was removed by\nocfs2_remove_extent(). At end io worker thread, ocfs2_search_extent_list\nfound there is no such extent at the cpos.\n\n T1 T2 T3\n inode lock\n ...\n insert extents\n ...\n inode unlock\nocfs2_fallocate\n __ocfs2_change_file_space\n inode lock\n lock ip_alloc_sem\n ocfs2_remove_inode_range inode\n ocfs2_remove_btree_range\n ocfs2_remove_extent\n ^---remove the extent at cpos 78723\n ...\n unlock ip_alloc_sem\n inode unlock\n ocfs2_dio_end_io\n ocfs2_dio_end_io_write\n lock ip_alloc_sem\n ocfs2_mark_extent_written\n ocfs2_change_extent_flag\n ocfs2_search_extent_list\n ^---failed to find extent\n ...\n unlock ip_alloc_sem\n\nIn most filesystems, fallocate is not compatible with racing with AIO+DIO,\nso fix it by adding to wait for all dio before fallocate/punch_hole like\next4.", "severity": [ { "type": "CVSS_V3", "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H" } ], "affected": [ { "package": { "ecosystem": "Raspberry Pi OS:12", "name": "linux" }, "versions": [ "1:6.1.21-1+rpt1", "1:6.1.47-1+rpt2", "1:6.1.47-1+rpt4", "1:6.1.54-1+rpt2", "1:6.1.58-1+rpt2", "1:6.1.63-1+rpt1", "1:6.1.73-1+rpt1", "1:6.6.20-1+rpt1", "1:6.6.28-1+rpt1", "1:6.6.31-1+rpt1" ], "ecosystem_specific": { "binaries": [ { "binary_name": "linux-image-6.1.0-rpi1-rpi-v6", "binary_version": "1:6.1.21-1+rpt1" }, { "binary_name": "linux-image-6.1.0-rpi1-rpi-v7", "binary_version": "1:6.1.21-1+rpt1" }, { "binary_name": "linux-image-6.1.0-rpi1-rpi-v7l", "binary_version": "1:6.1.21-1+rpt1" }, { "binary_name": "linux-image-6.1.0-rpi1-rpi-v8", "binary_version": "1:6.1.21-1+rpt1" }, { "binary_name": "linux-image-6.1.0-rpi2-rpi-v6", "binary_version": "1:6.1.47-1+rpt2" }, { "binary_name": "linux-image-6.1.0-rpi2-rpi-v7", "binary_version": "1:6.1.47-1+rpt2" }, { "binary_name": "linux-image-6.1.0-rpi2-rpi-v7l", "binary_version": "1:6.1.47-1+rpt2" }, { "binary_name": "linux-image-6.1.0-rpi2-rpi-v8", "binary_version": "1:6.1.47-1+rpt2" }, { "binary_name": "linux-image-6.1.0-rpi3-rpi-2712", "binary_version": "1:6.1.47-1+rpt4" }, { "binary_name": "linux-image-6.1.0-rpi3-rpi-v6", "binary_version": "1:6.1.47-1+rpt4" }, { "binary_name": "linux-image-6.1.0-rpi3-rpi-v7", "binary_version": "1:6.1.47-1+rpt4" }, { "binary_name": "linux-image-6.1.0-rpi3-rpi-v7l", "binary_version": "1:6.1.47-1+rpt4" }, { "binary_name": "linux-image-6.1.0-rpi3-rpi-v8", "binary_version": "1:6.1.47-1+rpt4" }, { "binary_name": "linux-image-6.1.0-rpi4-rpi-2712", "binary_version": "1:6.1.54-1+rpt2" }, { "binary_name": "linux-image-6.1.0-rpi4-rpi-v6", "binary_version": "1:6.1.54-1+rpt2" }, { "binary_name": "linux-image-6.1.0-rpi4-rpi-v7", "binary_version": "1:6.1.54-1+rpt2" }, { "binary_name": "linux-image-6.1.0-rpi4-rpi-v7l", "binary_version": "1:6.1.54-1+rpt2" }, { "binary_name": "linux-image-6.1.0-rpi4-rpi-v8", "binary_version": "1:6.1.54-1+rpt2" }, { "binary_name": "linux-image-6.1.0-rpi6-rpi-2712", "binary_version": "1:6.1.58-1+rpt2" }, { "binary_name": "linux-image-6.1.0-rpi6-rpi-v6", "binary_version": "1:6.1.58-1+rpt2" }, { "binary_name": "linux-image-6.1.0-rpi6-rpi-v7", "binary_version": "1:6.1.58-1+rpt2" }, { "binary_name": "linux-image-6.1.0-rpi6-rpi-v7l", "binary_version": "1:6.1.58-1+rpt2" }, { "binary_name": "linux-image-6.1.0-rpi6-rpi-v8", "binary_version": "1:6.1.58-1+rpt2" }, { "binary_name": "linux-image-6.1.0-rpi7-rpi-2712", "binary_version": "1:6.1.63-1+rpt1" }, { "binary_name": "linux-image-6.1.0-rpi7-rpi-v6", "binary_version": "1:6.1.63-1+rpt1" }, { "binary_name": "linux-image-6.1.0-rpi7-rpi-v7", "binary_version": "1:6.1.63-1+rpt1" }, { "binary_name": "linux-image-6.1.0-rpi7-rpi-v7l", "binary_version": "1:6.1.63-1+rpt1" }, { "binary_name": "linux-image-6.1.0-rpi7-rpi-v8", "binary_version": "1:6.1.63-1+rpt1" }, { "binary_name": "linux-image-6.1.0-rpi8-rpi-2712", "binary_version": "1:6.1.73-1+rpt1" }, { "binary_name": "linux-image-6.1.0-rpi8-rpi-v6", "binary_version": "1:6.1.73-1+rpt1" }, { "binary_name": "linux-image-6.1.0-rpi8-rpi-v7", "binary_version": "1:6.1.73-1+rpt1" }, { "binary_name": "linux-image-6.1.0-rpi8-rpi-v7l", "binary_version": "1:6.1.73-1+rpt1" }, { "binary_name": "linux-image-6.1.0-rpi8-rpi-v8", "binary_version": "1:6.1.73-1+rpt1" }, { "binary_name": "linux-image-6.6.20+rpt-rpi-2712", "binary_version": "1:6.6.20-1+rpt1" }, { "binary_name": "linux-image-6.6.20+rpt-rpi-v6", "binary_version": "1:6.6.20-1+rpt1" }, { "binary_name": "linux-image-6.6.20+rpt-rpi-v7", "binary_version": "1:6.6.20-1+rpt1" }, { "binary_name": "linux-image-6.6.20+rpt-rpi-v7l", "binary_version": "1:6.6.20-1+rpt1" }, { "binary_name": "linux-image-6.6.20+rpt-rpi-v8", "binary_version": "1:6.6.20-1+rpt1" }, { "binary_name": "linux-image-6.6.28+rpt-rpi-2712", "binary_version": "1:6.6.28-1+rpt1" }, { "binary_name": "linux-image-6.6.28+rpt-rpi-v6", "binary_version": "1:6.6.28-1+rpt1" }, { "binary_name": "linux-image-6.6.28+rpt-rpi-v7", "binary_version": "1:6.6.28-1+rpt1" }, { "binary_name": "linux-image-6.6.28+rpt-rpi-v7l", "binary_version": "1:6.6.28-1+rpt1" }, { "binary_name": "linux-image-6.6.28+rpt-rpi-v8", "binary_version": "1:6.6.28-1+rpt1" }, { "binary_name": "linux-image-6.6.31+rpt-rpi-2712", "binary_version": "1:6.6.31-1+rpt1" }, { "binary_name": "linux-image-6.6.31+rpt-rpi-v6", "binary_version": "1:6.6.31-1+rpt1" }, { "binary_name": "linux-image-6.6.31+rpt-rpi-v7", "binary_version": "1:6.6.31-1+rpt1" }, { "binary_name": "linux-image-6.6.31+rpt-rpi-v7l", "binary_version": "1:6.6.31-1+rpt1" }, { "binary_name": "linux-image-6.6.31+rpt-rpi-v8", "binary_version": "1:6.6.31-1+rpt1" } ] }, "database_specific": { "per_version": { "1:6.1.21-1+rpt1": { "linux_commit": "0afb5e98488aed7017b9bf321b575d0177feb7ed", "upstream_version": "6.1.21", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.1.95" }, "1:6.1.47-1+rpt2": { "linux_commit": "655fc658a15ae7a6f37103754adb39ba52a9a14e", "upstream_version": "6.1.47", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.1.95" }, "1:6.1.47-1+rpt4": { "linux_commit": "655fc658a15ae7a6f37103754adb39ba52a9a14e", "upstream_version": "6.1.47", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.1.95", "compiled_filter": false }, "1:6.1.54-1+rpt2": { "linux_commit": "2906f7abdc03d4a92b6b0e2e0c87ea2a9dffe8f7", "upstream_version": "6.1.54", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.1.95" }, "1:6.1.58-1+rpt2": { "linux_commit": "ccf1586ad0663fa91238ac56abf6340d6d740d18", "upstream_version": "6.1.58", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.1.95" }, "1:6.1.63-1+rpt1": { "linux_commit": null, "upstream_version": "6.1.63", "assessment": "upstream version (no usable Linux commit)", "upstream_fixed": "6.1.95" }, "1:6.1.73-1+rpt1": { "linux_commit": null, "upstream_version": "6.1.73", "assessment": "upstream version (no usable Linux commit)", "upstream_fixed": "6.1.95" }, "1:6.6.20-1+rpt1": { "linux_commit": "6f16847710cc0502450788b9f12f0a14d3429668", "upstream_version": "6.6.20", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.6.35" }, "1:6.6.28-1+rpt1": { "linux_commit": "0c341f47adc3578cd5f817aa20ee2b7f9ae6b23e", "upstream_version": "6.6.28", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.6.35" }, "1:6.6.31-1+rpt1": { "linux_commit": "c1432b4bae5b6582f4d32ba381459f33c34d1424", "upstream_version": "6.6.31", "assessment": "commit ancestry (strak rule)", "upstream_fixed": "6.6.35" } } } } ], "references": [ { "type": "ADVISORY", "url": "https://www.cve.org/CVERecord?id=CVE-2024-40943" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/3c26b5d21b1239e9c7fd31ba7d9b2d7bdbaa68d9" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/e8e2db1adac47970a6a9225f3858e9aa0e86287f" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/050ce8af6838c71e872e982b50d3f1bec21da40e" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/38825ff9da91d2854dcf6d9ac320a7e641e10f25" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/ea042dc2bea19d72e37c298bf65a9c341ef3fff3" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/3c361f313d696df72f9bccf058510e9ec737b9b1" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/117b9c009b72a6c2ebfd23484354dfee2d9570d2" }, { "type": "FIX", "url": "https://git.kernel.org/stable/c/952b023f06a24b2ad6ba67304c4c84d45bea2f18" } ], "database_specific": { "source": "https://git.kernel.org/pub/scm/linux/security/vulns.git", "upstream_modified": "2026-08-05T11:52:36Z", "severity": { "source": "kernel CNA", "cvss_v3_score": 7.8, "cvss_v3_severity": "High", "scenario": "AV:L - The race is driven entirely by local syscalls \u2014 `io_submit()`/`io_uring` O_DIRECT writes reaching `ocfs2_dio_wr_get_block()` and `fallocate(FALLOC_FL_PUNCH_HOLE)`/`OCFS2_IOC_UNRESVSP` reaching `__ocfs2_change_file_space()` on an already-mounted ocfs2 volume. No remote peer or packet data reaches the vulnerable path; ocfs2 is a shared-disk cluster filesystem, not a network server.\nAC:L - The attacker owns both sides of the race: one thread issues async O_DIRECT writes that return `-EIOCBQUEUED` and defer `ocfs2_dio_end_io_write()`, while another calls `fallocate(PUNCH_HOLE)` over the same range, and the sequence can be looped indefinitely at no cost until it lands. Nothing depends on state outside the attacker's influence \u2014 the `unwritten` feature bit required by `ocfs2_fallocate()` is the mkfs.ocfs2 default, and the upstream reproducer (fstests generic/300) hits it with an ordinary fio racer workload.\nPR:L - Only an unprivileged local account with write access to a file on the ocfs2 volume is needed \u2014 `ocfs2_fallocate()` has no capability check and `ocfs2_change_file_space()` gates solely on `S_ISREG` plus `FMODE_WRITE` on the caller's own fd. No CAP_SYS_ADMIN, no user-namespace trick, and no root is required, since the attacker races only on a file it already owns.\nUI:N - The attacker performs the whole sequence from its own processes with no action by any other user. The ocfs2 volume is already mounted in the normal deployment (a cluster shared-storage node), so no victim mount or file open is involved.\nS:U - The corrupted extent tree, the freed-then-rewritten clusters, and the forced-read-only superblock all live within the kernel's own security authority. No VM, IOMMU, or sandbox boundary is crossed.\nC:H - `ocfs2_change_extent_flag()` builds `split_rec.e_blkno` from the stale `ue_phys` captured before the punch and never validates it against the record it found (`fs/ocfs2/alloc.c:5232`), so once a re-write repopulates an unwritten extent at that `cpos` the split installs a mapping to clusters that `ocfs2_truncate_log_append()` already released to the global bitmap and handed to another inode. The attacker's file then aliases another user's data blocks \u2014 an arbitrary read of other users' file contents across every node of the cluster \u2014 and with `errors=continue` the volume keeps serving that inconsistent metadata.\nI:H - The punch frees the clusters into the truncate log and flushes them for reuse while the DIO's data BIOs are still in flight to those exact physical blocks, so attacker-controlled bytes overwrite whatever inode was subsequently allocated them, and the stale-`e_blkno` split additionally grants a persistent write alias into another user's file. The result is on-disk corruption that the kernel itself reports as requiring offline `fsck.ocfs2` to repair.\nA:H - `ocfs2_change_extent_flag()` calls `ocfs2_error()`, and `ocfs2_handle_error()` (`fs/ocfs2/super.c:2482`) either calls `panic()` under the cluster-typical `errors=panic` or, by default, sets `SB_RDONLY` and prints \"File system is now read-only\" \u2014 an unprivileged user can thus take the entire shared volume offline for every process on the node. Recovery requires unmounting cluster-wide and running fsck, and the trigger can be repeated at will." } } }