CVSS: -EPSS: %CPEs: 2EXPL: 0CVE-2024-50221 – drm/amd/pm: Vangogh: Fix kernel memory out of bounds write
https://notcve.org/view.php?id=CVE-2024-50221
In the Linux kernel, the following vulnerability has been resolved: drm/amd/pm: Vangogh: Fix kernel memory out of bounds write KASAN reports that the GPU metrics table allocated in vangogh_tables_init() is not large enough for the memset done in smu_cmn_init_soft_gpu_metrics(). Condensed report follows: [ 33.861314] BUG: KASAN: slab-out-of-bounds in smu_cmn_init_soft_gpu_metrics+0x73/0x200 [amdgpu] [ 33.861799] Write of size 168 at addr ffff888129f59500 by task mangoapp/1067 ... [ 33.861808] CPU: 6 UID: 1000 PID: 1067 Comm: mangoapp Tainted: G W 6.12.0-rc4 #356 1a56f59a8b5182eeaf67eb7cb8b13594dd23b544 [ 33.861816] Tainted: [W]=WARN [ 33.861818] Hardware name: Valve Galileo/Galileo, BIOS F7G0107 12/01/2023 [ 33.861822] Call Trace: [ 33.861826] <TASK> [ 33.861829] dump_stack_lvl+0x66/0x90 [ 33.861838] print_report+0xce/0x620 [ 33.861853] kasan_report+0xda/0x110 [ 33.862794] kasan_check_range+0xfd/0x1a0 [ 33.862799] __asan_memset+0x23/0x40 [ 33.862803] smu_cmn_init_soft_gpu_metrics+0x73/0x200 [amdgpu 13b1bc364ec578808f676eba412c20eaab792779] [ 33.863306] vangogh_get_gpu_metrics_v2_4+0x123/0xad0 [amdgpu 13b1bc364ec578808f676eba412c20eaab792779] [ 33.864257] vangogh_common_get_gpu_metrics+0xb0c/0xbc0 [amdgpu 13b1bc364ec578808f676eba412c20eaab792779] [ 33.865682] amdgpu_dpm_get_gpu_metrics+0xcc/0x110 [amdgpu 13b1bc364ec578808f676eba412c20eaab792779] [ 33.866160] amdgpu_get_gpu_metrics+0x154/0x2d0 [amdgpu 13b1bc364ec578808f676eba412c20eaab792779] [ 33.867135] dev_attr_show+0x43/0xc0 [ 33.867147] sysfs_kf_seq_show+0x1f1/0x3b0 [ 33.867155] seq_read_iter+0x3f8/0x1140 [ 33.867173] vfs_read+0x76c/0xc50 [ 33.867198] ksys_read+0xfb/0x1d0 [ 33.867214] do_syscall_64+0x90/0x160 ... [ 33.867353] Allocated by task 378 on cpu 7 at 22.794876s: [ 33.867358] kasan_save_stack+0x33/0x50 [ 33.867364] kasan_save_track+0x17/0x60 [ 33.867367] __kasan_kmalloc+0x87/0x90 [ 33.867371] vangogh_init_smc_tables+0x3f9/0x840 [amdgpu] [ 33.867835] smu_sw_init+0xa32/0x1850 [amdgpu] [ 33.868299] amdgpu_device_init+0x467b/0x8d90 [amdgpu] [ 33.868733] amdgpu_driver_load_kms+0x19/0xf0 [amdgpu] [ 33.869167] amdgpu_pci_probe+0x2d6/0xcd0 [amdgpu] [ 33.869608] local_pci_probe+0xda/0x180 [ 33.869614] pci_device_probe+0x43f/0x6b0 Empirically we can confirm that the former allocates 152 bytes for the table, while the latter memsets the 168 large block. Root cause appears that when GPU metrics tables for v2_4 parts were added it was not considered to enlarge the table to fit. The fix in this patch is rather "brute force" and perhaps later should be done in a smarter way, by extracting and consolidating the part version to size logic to a common helper, instead of brute forcing the largest possible allocation. Nevertheless, for now this works and fixes the out of bounds write. v2: * Drop impossible v3_0 case. (Mario) (cherry picked from commit 0880f58f9609f0200483a49429af0f050d281703) • https://git.kernel.org/stable/c/41cec40bc9baba83d36a0718ea94bfe63189274a https://git.kernel.org/stable/c/f8fd9f0d57af4f8f48b383ec28287af85b47cb9f https://git.kernel.org/stable/c/4aa923a6e6406b43566ef6ac35a3d9a3197fa3e8 •
CVSS: -EPSS: %CPEs: 5EXPL: 0CVE-2024-50219 – mm/page_alloc: let GFP_ATOMIC order-0 allocs access highatomic reserves
https://notcve.org/view.php?id=CVE-2024-50219
In the Linux kernel, the following vulnerability has been resolved: mm/page_alloc: let GFP_ATOMIC order-0 allocs access highatomic reserves Under memory pressure it's possible for GFP_ATOMIC order-0 allocations to fail even though free pages are available in the highatomic reserves. GFP_ATOMIC allocations cannot trigger unreserve_highatomic_pageblock() since it's only run from reclaim. Given that such allocations will pass the watermarks in __zone_watermark_unusable_free(), it makes sense to fallback to highatomic reserves the same way that ALLOC_OOM can. This fixes order-0 page allocation failures observed on Cloudflare's fleet when handling network packets: kswapd1: page allocation failure: order:0, mode:0x820(GFP_ATOMIC), nodemask=(null),cpuset=/,mems_allowed=0-7 CPU: 10 PID: 696 Comm: kswapd1 Kdump: loaded Tainted: G O 6.6.43-CUSTOM #1 Hardware name: MACHINE Call Trace: <IRQ> dump_stack_lvl+0x3c/0x50 warn_alloc+0x13a/0x1c0 __alloc_pages_slowpath.constprop.0+0xc9d/0xd10 __alloc_pages+0x327/0x340 __napi_alloc_skb+0x16d/0x1f0 bnxt_rx_page_skb+0x96/0x1b0 [bnxt_en] bnxt_rx_pkt+0x201/0x15e0 [bnxt_en] __bnxt_poll_work+0x156/0x2b0 [bnxt_en] bnxt_poll+0xd9/0x1c0 [bnxt_en] __napi_poll+0x2b/0x1b0 bpf_trampoline_6442524138+0x7d/0x1000 __napi_poll+0x5/0x1b0 net_rx_action+0x342/0x740 handle_softirqs+0xcf/0x2b0 irq_exit_rcu+0x6c/0x90 sysvec_apic_timer_interrupt+0x72/0x90 </IRQ> [mfleming@cloudflare.com: update comment] Link: https://lkml.kernel.org/r/20241015125158.3597702-1-matt@readmodwrite.com • https://git.kernel.org/stable/c/1d91df85f399adbe4f318f3e74ac5a5d84c0ca7c https://git.kernel.org/stable/c/4c4e238d3adad3c94bb255d0f117d3685bbfdd33 https://git.kernel.org/stable/c/189b954469cf82f8b8cf496f8de94b006d2d4746 https://git.kernel.org/stable/c/b958948ae1cb3e39c48e9f805436fd652103c71e https://git.kernel.org/stable/c/d0fdacfb85a3e1223b894cc6e60091ec91049e9e https://git.kernel.org/stable/c/281dd25c1a018261a04d1b8bf41a0674000bfe38 •
CVSS: -EPSS: %CPEs: 8EXPL: 0CVE-2024-50218 – ocfs2: pass u64 to ocfs2_truncate_inline maybe overflow
https://notcve.org/view.php?id=CVE-2024-50218
In the Linux kernel, the following vulnerability has been resolved: ocfs2: pass u64 to ocfs2_truncate_inline maybe overflow Syzbot reported a kernel BUG in ocfs2_truncate_inline. There are two reasons for this: first, the parameter value passed is greater than ocfs2_max_inline_data_with_xattr, second, the start and end parameters of ocfs2_truncate_inline are "unsigned int". So, we need to add a sanity check for byte_start and byte_len right before ocfs2_truncate_inline() in ocfs2_remove_inode_range(), if they are greater than ocfs2_max_inline_data_with_xattr return -EINVAL. • https://git.kernel.org/stable/c/1afc32b952335f665327a1a9001ba1b44bb76fd9 https://git.kernel.org/stable/c/27d95867bee806cdc448d122bd99f1d8b0544035 https://git.kernel.org/stable/c/95fbed8ae8c32c0977e6be1721c190d8fea23f2f https://git.kernel.org/stable/c/70767689ec6ee5f05fb0a2c17d7ec1927946e486 https://git.kernel.org/stable/c/ecd62f684386fa64f9c0cea92eea361f4e6444c2 https://git.kernel.org/stable/c/2fe5d62e122b040ce7fc4d31aa7fa96ae328cefc https://git.kernel.org/stable/c/88f97a4b5843ce21c1286e082c02a5fb4d8eb473 https://git.kernel.org/stable/c/0b6b8c2055784261de3fb641c5d0d6396 •
CVSS: -EPSS: %CPEs: 2EXPL: 0CVE-2024-50217 – btrfs: fix use-after-free of block device file in __btrfs_free_extra_devids()
https://notcve.org/view.php?id=CVE-2024-50217
In the Linux kernel, the following vulnerability has been resolved: btrfs: fix use-after-free of block device file in __btrfs_free_extra_devids() Mounting btrfs from two images (which have the same one fsid and two different dev_uuids) in certain executing order may trigger an UAF for variable 'device->bdev_file' in __btrfs_free_extra_devids(). And following are the details: 1. Attach image_1 to loop0, attach image_2 to loop1, and scan btrfs devices by ioctl(BTRFS_IOC_SCAN_DEV): / btrfs_device_1 → loop0 fs_device \ btrfs_device_2 → loop1 2. mount /dev/loop0 /mnt btrfs_open_devices btrfs_device_1->bdev_file = btrfs_get_bdev_and_sb(loop0) btrfs_device_2->bdev_file = btrfs_get_bdev_and_sb(loop1) btrfs_fill_super open_ctree fail: btrfs_close_devices // -ENOMEM btrfs_close_bdev(btrfs_device_1) fput(btrfs_device_1->bdev_file) // btrfs_device_1->bdev_file is freed btrfs_close_bdev(btrfs_device_2) fput(btrfs_device_2->bdev_file) 3. mount /dev/loop1 /mnt btrfs_open_devices btrfs_get_bdev_and_sb(&bdev_file) // EIO, btrfs_device_1->bdev_file is not assigned, // which points to a freed memory area btrfs_device_2->bdev_file = btrfs_get_bdev_and_sb(loop1) btrfs_fill_super open_ctree btrfs_free_extra_devids if (btrfs_device_1->bdev_file) fput(btrfs_device_1->bdev_file) // UAF ! Fix it by setting 'device->bdev_file' as 'NULL' after closing the btrfs_device in btrfs_close_one_device(). • https://git.kernel.org/stable/c/142388194191a3edc9ba01cfcfd8b691e0971fb2 https://git.kernel.org/stable/c/47a83f8df39545f3f552bb6a1b6d9c30e37621dd https://git.kernel.org/stable/c/aec8e6bf839101784f3ef037dcdb9432c3f32343 •
CVSS: -EPSS: %CPEs: 3EXPL: 0CVE-2024-50216 – xfs: fix finding a last resort AG in xfs_filestream_pick_ag
https://notcve.org/view.php?id=CVE-2024-50216
In the Linux kernel, the following vulnerability has been resolved: xfs: fix finding a last resort AG in xfs_filestream_pick_ag When the main loop in xfs_filestream_pick_ag fails to find a suitable AG it tries to just pick the online AG. But the loop for that uses args->pag as loop iterator while the later code expects pag to be set. Fix this by reusing the max_pag case for this last resort, and also add a check for impossible case of no AG just to make sure that the uninitialized pag doesn't even escape in theory. • https://git.kernel.org/stable/c/f8f1ed1ab3babad46b25e2dbe8de43b33fe7aaa6 https://git.kernel.org/stable/c/77ddc732416b017180893cbb2356e9f0a414c575 https://git.kernel.org/stable/c/a023408925acd64db5c8980373fcb3e28ec6fd29 https://git.kernel.org/stable/c/dc60992ce76fbc2f71c2674f435ff6bde2108028 •