Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
CVE ID: CVE-2024-50208 State: PUBLISHED Published: 2024-11-08T06:07:58.607Z Last Updated: 2025-11-03T22:27:02.268Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: RDMA/bnxt_re: Fix a bug while setting up Level-2 PBL pages Avoid memory corruption while setting up Level-2 PBL pages for the non MR resources when num_pages > 256K. There will be a single PDE page address (contiguous pages in the case of > PAGE_SIZE), but, current logic assumes multiple pages, leading to invalid memory access after 256K PBL entries in the PDE. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.
n the PDE. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/df6fed0a2a1a5e57f033bca40dc316b18e0d0ce6 - https://git.kernel.org/stable/c/de5857fa7bcc9a496a914c7e21390be873109f26 - https://git.kernel.org/stable/c/ea701c1849e7250ea41a4f7493e0a5f136c1d47e - https://git.kernel.org/stable/c/87cb3b0054e53e0155b630bdf8fb714ded62565f - https://git.kernel.org/stable/c/daac56dd98e1ba814c878ac0acd482a37f2ab94b - https://git.kernel.org/stable/c/7988bdbbb85ac85a847baf09879edcd0f70521dc
CVE ID: CVE-2024-50209 State: PUBLISHED Published: 2024-11-08T06:07:59.470Z Last Updated: 2025-11-03T22:27:03.748Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: RDMA/bnxt_re: Add a check for memory allocation __alloc_pbl() can return error when memory allocation fails. Driver is not checking the status on one of the instances. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/dbe51dd516e6d4e655f31c8a1cbc050dde7ba97b - https://git.kernel.org/stable/c/322a19baaaa25a1fe8ce9fceaed9409ad847844c - https://git.kernel.org/stable/c/76dd679c3b148d23f72dcf6c3cde3d5f7
rg/stable/c/322a19baaaa25a1fe8ce9fceaed9409ad847844c - https://git.kernel.org/stable/c/76dd679c3b148d23f72dcf6c3cde3d5f746b2c07 - https://git.kernel.org/stable/c/c71957271f2e8133a6aa82001c2fa671d5008129 - https://git.kernel.org/stable/c/ba9045887b435a4c5551245ae034b8791b4e4aaa - https://git.kernel.org/stable/c/c5c1ae73b7741fa3b58e6e001b407825bb971225
CVE ID: CVE-2024-50210 State: PUBLISHED Published: 2024-11-08T06:08:00.319Z Last Updated: 2025-11-03T22:27:05.200Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: posix-clock: posix-clock: Fix unbalanced locking in pc_clock_settime() If get_clock_desc() succeeds, it calls fget() for the clockid's fd, and get the clk->rwsem read lock, so the error path should release the lock to make the lock balance and fput the clockid's fd to make the refcount balance and release the fd related resource. However the below commit left the error path locked behind resulting in unbalanced locking. Check timespec64_valid_strict() before get_clock_
mit left the error path locked behind resulting in unbalanced locking. Check timespec64_valid_strict() before get_clock_desc() to fix it, because the "ts" is not changed after that. [pabeni@redhat.com: fixed commit message typo] Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/d005400262ddaf1ca1666bbcd1acf42fe81d57ce - https://git.kernel.org/stable/c/a8219446b95a859488feaade674d13f9efacfa32 - https://git.kernel.org/stable/c/c7fcfdba35abc9f39b83080c2bce398dad13a943 - https://git.kernel.org/stable/c/e56e0ec1b79f5a6272c6e78b36e9d593aa0449af - https://git.kernel.org/stable/c/5f063bbf1ee6b01611c016b54e050a41506eb794 - https:
0ec1b79f5a6272c6e78b36e9d593aa0449af - https://git.kernel.org/stable/c/5f063bbf1ee6b01611c016b54e050a41506eb794 - https://git.kernel.org/stable/c/1ba33b327c3f88a7baee598979d73ab5b44d41cc - https://git.kernel.org/stable/c/b27330128eca25179637c1816d5a72d6cc408c66 - https://git.kernel.org/stable/c/6e62807c7fbb3c758d233018caf94dfea9c65dbd
CVE ID: CVE-2024-50211 State: PUBLISHED Published: 2024-11-08T06:10:08.444Z Last Updated: 2025-10-01T20:27:05.842Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: udf: refactor inode_bmap() to handle error Refactor inode_bmap() to handle error since udf_next_aext() can return error now. On situations like ftruncate, udf_extend_file() can now detect errors and bail out early without resorting to checking for particular offsets and assuming internal behavior of these functions. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/493447dd8336607fce426f7879e581095f6c606e - https://git.ker
P Vulnrichment: References: - https://git.kernel.org/stable/c/493447dd8336607fce426f7879e581095f6c606e - https://git.kernel.org/stable/c/b22d9a5698abf04341f8fbc30141e0673863c3a6 - https://git.kernel.org/stable/c/c226964ec786f3797ed389a16392ce4357697d24
CVE ID: CVE-2024-50212 State: PUBLISHED Published: 2024-11-09T10:14:24.249Z Last Updated: 2025-05-04T09:48:52.296Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: lib: alloc_tag_module_unload must wait for pending kfree_rcu calls Ben Greear reports following splat: ------------[ cut here ]------------ net/netfilter/nf_nat_core.c:1114 module nf_nat func:nf_nat_register_fn has 256 allocated at module unload WARNING: CPU: 1 PID: 10421 at lib/alloc_tag.c:168 alloc_tag_module_unload+0x22b/0x3f0 Modules linked in: nf_nat(-) btrfs ufs qnx4 hfsplus hfs minix vfat msdos fat ... Hardware name: Default string Default string/SKYBAY, BIOS 5.
_nat(-) btrfs ufs qnx4 hfsplus hfs minix vfat msdos fat ... Hardware name: Default string Default string/SKYBAY, BIOS 5.12 08/04/2020 RIP: 0010:alloc_tag_module_unload+0x22b/0x3f0 codetag_unload_module+0x19b/0x2a0 ? codetag_load_module+0x80/0x80 nf_nat module exit calls kfree_rcu on those addresses, but the free operation is likely still pending by the time alloc_tag checks for leaks. Wait for outstanding kfree_rcu operations to complete before checking resolves this warning. Reproducer: unshare -n iptables-nft -t nat -A PREROUTING -p tcp grep nf_nat /proc/allocinfo # will list 4 allocations rmmod nft_chain_nat rmmod nf_nat # will WARN. [akpm@linux-foundation.org: add comment] References: -
list 4 allocations rmmod nft_chain_nat rmmod nf_nat # will WARN. [akpm@linux-foundation.org: add comment] References: - https://git.kernel.org/stable/c/24211fb49c9ac1b576470b7e393a5a0b50af2707 - https://git.kernel.org/stable/c/dc783ba4b9df3fb3e76e968b2cbeb9960069263c
CVE ID: CVE-2024-50213 State: PUBLISHED Published: 2024-11-09T10:14:25.218Z Last Updated: 2025-10-01T20:27:05.607Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: drm/tests: hdmi: Fix memory leaks in drm_display_mode_from_cea_vic() modprobe drm_hdmi_state_helper_test and then rmmod it, the following memory leak occurs. The `mode` allocated in drm_mode_duplicate() called by drm_display_mode_from_cea_vic() is not freed, which cause the memory leak: unreferenced object 0xffffff80ccd18100 (size 128): comm "kunit_try_catch", pid 1851, jiffies 4295059695 hex dump (first 32 bytes): 57 62 00 00 80 02 90 02 f0 02 20 03 00 00 e0 01 Wb....
y_catch", pid 1851, jiffies 4295059695 hex dump (first 32 bytes): 57 62 00 00 80 02 90 02 f0 02 20 03 00 00 e0 01 Wb........ ..... ea 01 ec 01 0d 02 00 00 0a 00 00 00 00 00 00 00 ................ backtrace (crc c2f1aa95): [<000000000f10b11b>] kmemleak_alloc+0x34/0x40 [<000000001cd4cf73>] __kmalloc_cache_noprof+0x26c/0x2f4 [<00000000f1f3cffa>] drm_mode_duplicate+0x44/0x19c [<000000008cbeef13>] drm_display_mode_from_cea_vic+0x88/0x98 [<0000000019daaacf>] 0xffffffedc11ae69c [<000000000aad0f85>] kunit_try_run_case+0x13c/0x3ac [<00000000a9210bac>] kunit_generic_run_threadfn_adapter+0x80/0xec [<000000000a0b2e9e>] kthread+0x2e8/0x374 [<00000000bd668858>] ret_from_fork+0x10/0x20 ...... Free `mode` b
ter+0x80/0xec [<000000000a0b2e9e>] kthread+0x2e8/0x374 [<00000000bd668858>] ret_from_fork+0x10/0x20 ...... Free `mode` by using drm_kunit_display_mode_from_cea_vic() to fix it. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/3bc3fae8a0f22e0e713729b50e2111f6a8c64724 - https://git.kernel.org/stable/c/add4163aca0d4a86e9fe4aa513865e4237db8aef
CVE ID: CVE-2024-50214 State: PUBLISHED Published: 2024-11-09T10:14:26.138Z Last Updated: 2025-10-01T20:27:05.457Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: drm/connector: hdmi: Fix memory leak in drm_display_mode_from_cea_vic() modprobe drm_connector_test and then rmmod drm_connector_test, the following memory leak occurs. The `mode` allocated in drm_mode_duplicate() called by drm_display_mode_from_cea_vic() is not freed, which cause the memory leak: unreferenced object 0xffffff80cb0ee400 (size 128): comm "kunit_try_catch", pid 1948, jiffies 4294950339 hex dump (first 32 bytes): 14 44 02 00 80 07 d8 07 04 08 98 08 00 00 3
m "kunit_try_catch", pid 1948, jiffies 4294950339 hex dump (first 32 bytes): 14 44 02 00 80 07 d8 07 04 08 98 08 00 00 38 04 .D............8. 3c 04 41 04 65 04 00 00 05 00 00 00 00 00 00 00 <.A.e........... backtrace (crc 90e9585c): [<00000000ec42e3d7>] kmemleak_alloc+0x34/0x40 [<00000000d0ef055a>] __kmalloc_cache_noprof+0x26c/0x2f4 [<00000000c2062161>] drm_mode_duplicate+0x44/0x19c [<00000000f96c74aa>] drm_display_mode_from_cea_vic+0x88/0x98 [<00000000d8f2c8b4>] 0xffffffdc982a4868 [<000000005d164dbc>] kunit_try_run_case+0x13c/0x3ac [<000000006fb23398>] kunit_generic_run_threadfn_adapter+0x80/0xec [<000000006ea56ca0>] kthread+0x2e8/0x374 [<000000000676063f>] ret_from_fork+0x10/0x20 ...... Fr
readfn_adapter+0x80/0xec [<000000006ea56ca0>] kthread+0x2e8/0x374 [<000000000676063f>] ret_from_fork+0x10/0x20 ...... Free `mode` by using drm_kunit_display_mode_from_cea_vic() to fix it. Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/df2b00685cd33cd85be8910c7d6d22c4ebbf18bb - https://git.kernel.org/stable/c/926163342a2e7595d950e84c17c693b1272bd491
CVE ID: CVE-2024-50215 State: PUBLISHED Published: 2024-11-09T10:14:27.043Z Last Updated: 2025-11-03T22:27:06.690Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: nvmet-auth: assign dh_key to NULL after kfree_sensitive ctrl->dh_key might be used across multiple calls to nvmet_setup_dhgroup() for the same controller. So it's better to nullify it after release on error path in order to avoid double free later in nvmet_destroy_auth(). Found by Linux Verification Center (linuxtesting.org) with Svace. Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/c94e965f7663
lyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/c94e965f766321641ec38e4eece9ce8884543244 - https://git.kernel.org/stable/c/c60af16e1d6cc2237d58336546d6adfc067b6b8f - https://git.kernel.org/stable/c/e61bd51e44409495d75847e9230736593e4c8710 - https://git.kernel.org/stable/c/d2f551b1f72b4c508ab9298419f6feadc3b5d791
CVE ID: CVE-2024-50216 State: PUBLISHED Published: 2024-11-09T10:14:27.875Z Last Updated: 2025-05-04T09:48:59.033Z Vendors: Linux Products: Linux Description: 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. References: - https:
mpossible case of no AG just to make sure that the uninitialized pag doesn't even escape in theory. References: - https://git.kernel.org/stable/c/77ddc732416b017180893cbb2356e9f0a414c575 - https://git.kernel.org/stable/c/a023408925acd64db5c8980373fcb3e28ec6fd29 - https://git.kernel.org/stable/c/dc60992ce76fbc2f71c2674f435ff6bde2108028
CVE ID: CVE-2024-50217 State: PUBLISHED Published: 2024-11-09T10:14:28.798Z Last Updated: 2025-05-04T09:49:00.857Z Vendors: Linux Products: Linux Description: 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 → loo
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->bd
&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(). Additional Analyst Notes: - CISA ADP Vulnrichment: - CVE Program Container: References: - https://git.kernel.org/stable/c/47a83f8df39545f3f552bb6a1b6d9c30e37621dd - https://git.kernel.org/stable/c/aec8e6bf839101784f3ef037dcdb9432c3f32343
CVE ID: CVE-2024-50218 State: PUBLISHED Published: 2024-11-09T10:14:29.708Z Last Updated: 2025-11-03T22:27:08.148Z Vendors: Linux Products: Linux Description: 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
tart 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. Additional Analyst Notes: - CVE Program Container: References: - 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/st
1aa7fa96ae328cefc - https://git.kernel.org/stable/c/88f97a4b5843ce21c1286e082c02a5fb4d8eb473 - https://git.kernel.org/stable/c/0b6b8c2055784261de3fb641c5d0d63964318e8f - https://git.kernel.org/stable/c/bc0a2f3a73fcdac651fca64df39306d1e5ebe3b0
CVE ID: CVE-2024-50219 State: REJECTED Published: 2024-11-09T10:14:30.646Z Last Updated: 2024-11-11T14:05:10.413Z Description: No description available.
CVE ID: CVE-2024-50220 State: PUBLISHED Published: 2024-11-09T10:14:31.548Z Last Updated: 2025-05-04T09:49:03.947Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: fork: do not invoke uffd on fork if error occurs Patch series "fork: do not expose incomplete mm on fork". During fork we may place the virtual memory address space into an inconsistent state before the fork operation is complete. In addition, we may encounter an error during the fork operation that indicates that the virtual memory address space is invalidated. As a result, we should not be exposing it in any way to external machinery that might interact with the mm o
nvalidated. As a result, we should not be exposing it in any way to external machinery that might interact with the mm or VMAs, machinery that is not designed to deal with incomplete state. We specifically update the fork logic to defer khugepaged and ksm to the end of the operation and only to be invoked if no error arose, and disallow uffd from observing fork events should an error have occurred. This patch (of 2): Currently on fork we expose the virtual address space of a process to userland unconditionally if uffd is registered in VMAs, regardless of whether an error arose in the fork. This is performed in dup_userfaultfd_complete() which is invoked unconditionally, and performs two duti
ose in the fork. This is performed in dup_userfaultfd_complete() which is invoked unconditionally, and performs two duties - invoking registered handlers for the UFFD_EVENT_FORK event via dup_fctx(), and clearing down userfaultfd_fork_ctx objects established in dup_userfaultfd(). This is problematic, because the virtual address space may not yet be correctly initialised if an error arose. The change in commit d24062914837 ("fork: use __mt_dup() to duplicate maple tree in dup_mmap()") makes this more pertinent as we may be in a state where entries in the maple tree are not yet consistent. We address this by, on fork error, ensuring that we roll back state that we would otherwise expect to cle
et consistent. We address this by, on fork error, ensuring that we roll back state that we would otherwise expect to clean up through the event being handled by userland and perform the memory freeing duty otherwise performed by dup_userfaultfd_complete(). We do this by implementing a new function, dup_userfaultfd_fail(), which performs the same loop, only decrementing reference counts. Note that we perform mmgrab() on the parent and child mm's, however userfaultfd_ctx_put() will mmdrop() this once the reference count drops to zero, so we will avoid memory leaks correctly here. References: - https://git.kernel.org/stable/c/92b472945dbf8abc020e9259c0088026f7027dfc - https://git.kernel.org/sta
ere. References: - https://git.kernel.org/stable/c/92b472945dbf8abc020e9259c0088026f7027dfc - https://git.kernel.org/stable/c/f64e67e5d3a45a4a04286c47afade4b518acd47b - https://project-zero.issues.chromium.org/issues/373391951
CVE ID: CVE-2024-50221 State: PUBLISHED Published: 2024-11-09T10:14:32.390Z Last Updated: 2025-05-04T09:49:05.636Z Vendors: Linux Products: Linux Description: 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 Ta
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 13b1
200 [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.86
40 [ 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 byte
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 0880f58f9609f02004
nd fixes the out of bounds write. v2: * Drop impossible v3_0 case. (Mario) (cherry picked from commit 0880f58f9609f0200483a49429af0f050d281703) Additional Analyst Notes: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/f111de0f010308949254ee1cc45df8e6b8e1d7d4 - https://git.kernel.org/stable/c/f8fd9f0d57af4f8f48b383ec28287af85b47cb9f - https://git.kernel.org/stable/c/4aa923a6e6406b43566ef6ac35a3d9a3197fa3e8
CVE ID: CVE-2024-50222 State: PUBLISHED Published: 2024-11-09T10:14:33.266Z Last Updated: 2025-10-01T20:27:05.080Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: iov_iter: fix copy_page_from_iter_atomic() if KMAP_LOCAL_FORCE_MAP generic/077 on x86_32 CONFIG_DEBUG_KMAP_LOCAL_FORCE_MAP=y with highmem, on huge=always tmpfs, issues a warning and then hangs (interruptibly): WARNING: CPU: 5 PID: 3517 at mm/highmem.c:622 kunmap_local_indexed+0x62/0xc9 CPU: 5 UID: 0 PID: 3517 Comm: cp Not tainted 6.12.0-rc4 #2 ... copy_page_from_iter_atomic+0xa6/0x5ec generic_perform_write+0xf6/0x1b4 shmem_file_write_iter+0x54/0x67 Fix copy_page_from_i