CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-49880 – ext4: fix off by one issue in alloc_flex_gd()
https://notcve.org/view.php?id=CVE-2024-49880
In the Linux kernel, the following vulnerability has been resolved: ext4: fix off by one issue in alloc_flex_gd() Wesley reported an issue: ================================================================== EXT4-fs (dm-5): resizing filesystem from 7168 to 786432 blocks ------------[ cut here ]------------ kernel BUG at fs/ext4/resize.c:324! CPU: 9 UID: 0 PID: 3576 Comm: resize2fs Not tainted 6.11.0+ #27 RIP: 0010:ext4_resize_fs+0x1212/0x12d0 Call Trace: __ext4_ioctl+0x4e0/0x1800 ext4_ioctl+0x12/0x20 __x64_sys_ioctl+0x99/0xd0 x64_sys_call+0x1206/0x20d0 do_syscall_64+0x72/0x110 entry_SYSCALL_64_after_hwframe+0x76/0x7e ================================================================== While reviewing the patch, Honza found that when adjusting resize_bg in alloc_flex_gd(), it was possible for flex_gd->resize_bg to be bigger than flexbg_size. The reproduction of the problem requires the following: o_group = flexbg_size * 2 * n; o_size = (o_group + 1) * group_size; n_group: [o_group + flexbg_size, o_group + flexbg_size * 2) o_size = (n_group + 1) * group_size; Take n=0,flexbg_size=16 as an example: last:15 |o---------------|--------------n-| o_group:0 resize to n_group:30 The corresponding reproducer is: img=test.img rm -f $img truncate -s 600M $img mkfs.ext4 -F $img -b 1024 -G 16 8M dev=`losetup -f --show $img` mkdir -p /tmp/test mount $dev /tmp/test resize2fs $dev 248M Delete the problematic plus 1 to fix the issue, and add a WARN_ON_ONCE() to prevent the issue from happening again. [ Note: another reproucer which this commit fixes is: img=test.img rm -f $img truncate -s 25MiB $img mkfs.ext4 -b 4096 -E nodiscard,lazy_itable_init=0,lazy_journal_init=0 $img truncate -s 3GiB $img dev=`losetup -f --show $img` mkdir -p /tmp/test mount $dev /tmp/test resize2fs $dev 3G umount $dev losetup -d $dev -- TYT ] • https://git.kernel.org/stable/c/665d3e0af4d35acf9a5f58dfd471bc27dbf55880 https://git.kernel.org/stable/c/0d80d2b8bf613398baf7185009e35f9d0459ecb0 https://git.kernel.org/stable/c/acb559d6826116cc113598640d105094620c2526 https://git.kernel.org/stable/c/6121258c2b33ceac3d21f6a221452692c465df88 •
CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-49879 – drm: omapdrm: Add missing check for alloc_ordered_workqueue
https://notcve.org/view.php?id=CVE-2024-49879
In the Linux kernel, the following vulnerability has been resolved: drm: omapdrm: Add missing check for alloc_ordered_workqueue As it may return NULL pointer and cause NULL pointer dereference. Add check for the return value of alloc_ordered_workqueue. • https://git.kernel.org/stable/c/2f95bc6d324a93b2411bcc5defe4d4414c45f325 https://git.kernel.org/stable/c/2bda89735199683b03f55b807bd1e31a3857520b https://git.kernel.org/stable/c/e60b0d3b5aa2e8d934deca9e11215af84e632bc9 https://git.kernel.org/stable/c/f37a1d9e5e22d5489309c3cd2db476dcdcc6530c https://git.kernel.org/stable/c/b57b53e8ffcdfda87d954fc4187426a54fe75a3d https://git.kernel.org/stable/c/0d71916694aceb207fefecf62dfa811ec1108bbd https://git.kernel.org/stable/c/334de68eda2b99892ba869c15cb59bc956fd9f42 https://git.kernel.org/stable/c/e794b7b9b92977365c693760a259f8eef •
CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-49878 – resource: fix region_intersects() vs add_memory_driver_managed()
https://notcve.org/view.php?id=CVE-2024-49878
In the Linux kernel, the following vulnerability has been resolved: resource: fix region_intersects() vs add_memory_driver_managed() On a system with CXL memory, the resource tree (/proc/iomem) related to CXL memory may look like something as follows. 490000000-50fffffff : CXL Window 0 490000000-50fffffff : region0 490000000-50fffffff : dax0.0 490000000-50fffffff : System RAM (kmem) Because drivers/dax/kmem.c calls add_memory_driver_managed() during onlining CXL memory, which makes "System RAM (kmem)" a descendant of "CXL Window X". This confuses region_intersects(), which expects all "System RAM" resources to be at the top level of iomem_resource. This can lead to bugs. For example, when the following command line is executed to write some memory in CXL memory range via /dev/mem, $ dd if=data of=/dev/mem bs=$((1 << 10)) seek=$((0x490000000 >> 10)) count=1 dd: error writing '/dev/mem': Bad address 1+0 records in 0+0 records out 0 bytes copied, 0.0283507 s, 0.0 kB/s the command fails as expected. However, the error code is wrong. It should be "Operation not permitted" instead of "Bad address". • https://git.kernel.org/stable/c/c221c0b0308fd01d9fb33a16f64d2fd95f8830a4 https://git.kernel.org/stable/c/1d5f85f1b7db79c75c9e07d6571ce2a7bdf725c4 https://git.kernel.org/stable/c/8a6fef7d22a1d952aed68584d3fcc0d018d2bdc3 https://git.kernel.org/stable/c/4b90d2eb451b357681063ba4552b10b39d7ad885 https://git.kernel.org/stable/c/393331e16ce205e036e58b3d8ca4ee2e635f21d9 https://git.kernel.org/stable/c/06ff97a20b8c9e9d256b0d2c3e87f78f8ccea3de https://git.kernel.org/stable/c/927abc5b7d6d2c2e936bec5a2f71d9512c5e72f7 https://git.kernel.org/stable/c/b4afe4183ec77f230851ea139d91e5cf2 •
CVSS: -EPSS: 0%CPEs: 11EXPL: 0CVE-2024-49877 – ocfs2: fix possible null-ptr-deref in ocfs2_set_buffer_uptodate
https://notcve.org/view.php?id=CVE-2024-49877
In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix possible null-ptr-deref in ocfs2_set_buffer_uptodate When doing cleanup, if flags without OCFS2_BH_READAHEAD, it may trigger NULL pointer dereference in the following ocfs2_set_buffer_uptodate() if bh is NULL. • https://git.kernel.org/stable/c/cf76c78595ca87548ca5e45c862ac9e0949c4687 https://git.kernel.org/stable/c/01f93d5e36753fc4d06ec67f05ce78c9c6f2dd56 https://git.kernel.org/stable/c/65cbd1279f4b999d56a838344a30642db24cd215 https://git.kernel.org/stable/c/97e1db17bc1ef4c2e1789bc9323c7be44fba53f8 https://git.kernel.org/stable/c/6c150df9c2e80b5cf86f5a0d98beb7390ad63bfc https://git.kernel.org/stable/c/61b84013e560382cbe7dd56758be3154d43a3988 https://git.kernel.org/stable/c/df944dc46d06af65a75191183d52be017e6b9dbe https://git.kernel.org/stable/c/01cb2e751cc61ade454c9bc1aaa2eac1f •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-49876 – drm/xe: fix UAF around queue destruction
https://notcve.org/view.php?id=CVE-2024-49876
In the Linux kernel, the following vulnerability has been resolved: drm/xe: fix UAF around queue destruction We currently do stuff like queuing the final destruction step on a random system wq, which will outlive the driver instance. With bad timing we can teardown the driver with one or more work workqueue still being alive leading to various UAF splats. Add a fini step to ensure user queues are properly torn down. At this point GuC should already be nuked so queue itself should no longer be referenced from hw pov. v2 (Matt B) - Looks much safer to use a waitqueue and then just wait for the xa_array to become empty before triggering the drain. (cherry picked from commit 861108666cc0e999cffeab6aff17b662e68774e3) • https://git.kernel.org/stable/c/dd08ebf6c3525a7ea2186e636df064ea47281987 https://git.kernel.org/stable/c/272b0e78874586d6ccae04079d75b27b47705544 https://git.kernel.org/stable/c/421c74670b0f9d5c007f1276d3647aa58f407fde https://git.kernel.org/stable/c/2d2be279f1ca9e7288282d4214f16eea8a727cdb •