Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommufd: Fix out_fput in iommufd_fault_alloc()<br /> <br /> As fput() calls the file-&gt;f_op-&gt;release op, where fault obj and ictx are<br /> getting released, there is no need to release these two after fput() one<br /> more time, which would result in imbalanced refcounts:<br /> refcount_t: decrement hit 0; leaking memory.<br /> WARNING: CPU: 48 PID: 2369 at lib/refcount.c:31 refcount_warn_saturate+0x60/0x230<br /> Call trace:<br /> refcount_warn_saturate+0x60/0x230 (P)<br /> refcount_warn_saturate+0x60/0x230 (L)<br /> iommufd_fault_fops_release+0x9c/0xe0 [iommufd]<br /> ...<br /> VFS: Close: file count is 0 (f_op=iommufd_fops [iommufd])<br /> WARNING: CPU: 48 PID: 2369 at fs/open.c:1507 filp_flush+0x3c/0xf0<br /> Call trace:<br /> filp_flush+0x3c/0xf0 (P)<br /> filp_flush+0x3c/0xf0 (L)<br /> __arm64_sys_close+0x34/0x98<br /> ...<br /> imbalanced put on file reference count<br /> WARNING: CPU: 48 PID: 2369 at fs/file.c:74 __file_ref_put+0x100/0x138<br /> Call trace:<br /> __file_ref_put+0x100/0x138 (P)<br /> __file_ref_put+0x100/0x138 (L)<br /> __fput_sync+0x4c/0xd0<br /> <br /> Drop those two lines to fix the warnings above.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: fix OOB devmap writes when deleting elements<br /> <br /> Jordy reported issue against XSKMAP which also applies to DEVMAP - the<br /> index used for accessing map entry, due to being a signed integer,<br /> causes the OOB writes. Fix is simple as changing the type from int to<br /> u32, however, when compared to XSKMAP case, one more thing needs to be<br /> addressed.<br /> <br /> When map is released from system via dev_map_free(), we iterate through<br /> all of the entries and an iterator variable is also an int, which<br /> implies OOB accesses. Again, change it to be u32.<br /> <br /> Example splat below:<br /> <br /> [ 160.724676] BUG: unable to handle page fault for address: ffffc8fc2c001000<br /> [ 160.731662] #PF: supervisor read access in kernel mode<br /> [ 160.736876] #PF: error_code(0x0000) - not-present page<br /> [ 160.742095] PGD 0 P4D 0<br /> [ 160.744678] Oops: Oops: 0000 [#1] PREEMPT SMP<br /> [ 160.749106] CPU: 1 UID: 0 PID: 520 Comm: kworker/u145:12 Not tainted 6.12.0-rc1+ #487<br /> [ 160.757050] Hardware name: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0008.031920191559 03/19/2019<br /> [ 160.767642] Workqueue: events_unbound bpf_map_free_deferred<br /> [ 160.773308] RIP: 0010:dev_map_free+0x77/0x170<br /> [ 160.777735] Code: 00 e8 fd 91 ed ff e8 b8 73 ed ff 41 83 7d 18 19 74 6e 41 8b 45 24 49 8b bd f8 00 00 00 31 db 85 c0 74 48 48 63 c3 48 8d 04 c7 8b 28 48 85 ed 74 30 48 8b 7d 18 48 85 ff 74 05 e8 b3 52 fa ff<br /> [ 160.796777] RSP: 0018:ffffc9000ee1fe38 EFLAGS: 00010202<br /> [ 160.802086] RAX: ffffc8fc2c001000 RBX: 0000000080000000 RCX: 0000000000000024<br /> [ 160.809331] RDX: 0000000000000000 RSI: 0000000000000024 RDI: ffffc9002c001000<br /> [ 160.816576] RBP: 0000000000000000 R08: 0000000000000023 R09: 0000000000000001<br /> [ 160.823823] R10: 0000000000000001 R11: 00000000000ee6b2 R12: dead000000000122<br /> [ 160.831066] R13: ffff88810c928e00 R14: ffff8881002df405 R15: 0000000000000000<br /> [ 160.838310] FS: 0000000000000000(0000) GS:ffff8897e0c40000(0000) knlGS:0000000000000000<br /> [ 160.846528] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 160.852357] CR2: ffffc8fc2c001000 CR3: 0000000005c32006 CR4: 00000000007726f0<br /> [ 160.859604] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> [ 160.866847] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> [ 160.874092] PKRU: 55555554<br /> [ 160.876847] Call Trace:<br /> [ 160.879338] <br /> [ 160.881477] ? __die+0x20/0x60<br /> [ 160.884586] ? page_fault_oops+0x15a/0x450<br /> [ 160.888746] ? search_extable+0x22/0x30<br /> [ 160.892647] ? search_bpf_extables+0x5f/0x80<br /> [ 160.896988] ? exc_page_fault+0xa9/0x140<br /> [ 160.900973] ? asm_exc_page_fault+0x22/0x30<br /> [ 160.905232] ? dev_map_free+0x77/0x170<br /> [ 160.909043] ? dev_map_free+0x58/0x170<br /> [ 160.912857] bpf_map_free_deferred+0x51/0x90<br /> [ 160.917196] process_one_work+0x142/0x370<br /> [ 160.921272] worker_thread+0x29e/0x3b0<br /> [ 160.925082] ? rescuer_thread+0x4b0/0x4b0<br /> [ 160.929157] kthread+0xd4/0x110<br /> [ 160.932355] ? kthread_park+0x80/0x80<br /> [ 160.936079] ret_from_fork+0x2d/0x50<br /> [ 160.943396] ? kthread_park+0x80/0x80<br /> [ 160.950803] ret_from_fork_asm+0x11/0x20<br /> [ 160.958482]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/dp_mst: Fix MST sideband message body length check<br /> <br /> Fix the MST sideband message body length check, which must be at least 1<br /> byte accounting for the message body CRC (aka message data CRC) at the<br /> end of the message.<br /> <br /> This fixes a case where an MST branch device returns a header with a<br /> correct header CRC (indicating a correctly received body length), with<br /> the body length being incorrectly set to 0. This will later lead to a<br /> memory corruption in drm_dp_sideband_append_payload() and the following<br /> errors in dmesg:<br /> <br /> UBSAN: array-index-out-of-bounds in drivers/gpu/drm/display/drm_dp_mst_topology.c:786:25<br /> index -1 is out of range for type &amp;#39;u8 [48]&amp;#39;<br /> Call Trace:<br /> drm_dp_sideband_append_payload+0x33d/0x350 [drm_display_helper]<br /> drm_dp_get_one_sb_msg+0x3ce/0x5f0 [drm_display_helper]<br /> drm_dp_mst_hpd_irq_handle_event+0xc8/0x1580 [drm_display_helper]<br /> <br /> memcpy: detected field-spanning write (size 18446744073709551615) of single field "&amp;msg-&gt;msg[msg-&gt;curlen]" at drivers/gpu/drm/display/drm_dp_mst_topology.c:791 (size 256)<br /> Call Trace:<br /> drm_dp_sideband_append_payload+0x324/0x350 [drm_display_helper]<br /> drm_dp_get_one_sb_msg+0x3ce/0x5f0 [drm_display_helper]<br /> drm_dp_mst_hpd_irq_handle_event+0xc8/0x1580 [drm_display_helper]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nilfs2: fix potential out-of-bounds memory access in nilfs_find_entry()<br /> <br /> Syzbot reported that when searching for records in a directory where the<br /> inode&amp;#39;s i_size is corrupted and has a large value, memory access outside<br /> the folio/page range may occur, or a use-after-free bug may be detected if<br /> KASAN is enabled.<br /> <br /> This is because nilfs_last_byte(), which is called by nilfs_find_entry()<br /> and others to calculate the number of valid bytes of directory data in a<br /> page from i_size and the page index, loses the upper 32 bits of the 64-bit<br /> size information due to an inappropriate type of local variable to which<br /> the i_size value is assigned.<br /> <br /> This caused a large byte offset value due to underflow in the end address<br /> calculation in the calling nilfs_find_entry(), resulting in memory access<br /> that exceeds the folio/page size.<br /> <br /> Fix this issue by changing the type of the local variable causing the bit<br /> loss from "unsigned int" to "u64". The return value of nilfs_last_byte()<br /> is also of type "unsigned int", but it is truncated so as not to exceed<br /> PAGE_SIZE and no bit loss occurs, so no change is required.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: ufs: core: sysfs: Prevent div by zero<br /> <br /> Prevent a division by 0 when monitoring is not enabled.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: qla2xxx: Fix use after free on unload<br /> <br /> System crash is observed with stack trace warning of use after<br /> free. There are 2 signals to tell dpc_thread to terminate (UNLOADING<br /> flag and kthread_stop).<br /> <br /> On setting the UNLOADING flag when dpc_thread happens to run at the time<br /> and sees the flag, this causes dpc_thread to exit and clean up<br /> itself. When kthread_stop is called for final cleanup, this causes use<br /> after free.<br /> <br /> Remove UNLOADING signal to terminate dpc_thread. Use the kthread_stop<br /> as the main signal to exit dpc_thread.<br /> <br /> [596663.812935] kernel BUG at mm/slub.c:294!<br /> [596663.812950] invalid opcode: 0000 [#1] SMP PTI<br /> [596663.812957] CPU: 13 PID: 1475935 Comm: rmmod Kdump: loaded Tainted: G IOE --------- - - 4.18.0-240.el8.x86_64 #1<br /> [596663.812960] Hardware name: HP ProLiant DL380p Gen8, BIOS P70 08/20/2012<br /> [596663.812974] RIP: 0010:__slab_free+0x17d/0x360<br /> <br /> ...<br /> [596663.813008] Call Trace:<br /> [596663.813022] ? __dentry_kill+0x121/0x170<br /> [596663.813030] ? _cond_resched+0x15/0x30<br /> [596663.813034] ? _cond_resched+0x15/0x30<br /> [596663.813039] ? wait_for_completion+0x35/0x190<br /> [596663.813048] ? try_to_wake_up+0x63/0x540<br /> [596663.813055] free_task+0x5a/0x60<br /> [596663.813061] kthread_stop+0xf3/0x100<br /> [596663.813103] qla2x00_remove_one+0x284/0x440 [qla2xxx]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: ath12k: fix atomic calls in ath12k_mac_op_set_bitrate_mask()<br /> <br /> When I try to manually set bitrates:<br /> <br /> iw wlan0 set bitrates legacy-2.4 1<br /> <br /> I get sleeping from invalid context error, see below. Fix that by switching to<br /> use recently introduced ieee80211_iterate_stations_mtx().<br /> <br /> Do note that WCN6855 firmware is still crashing, I&amp;#39;m not sure if that firmware<br /> even supports bitrate WMI commands and should we consider disabling<br /> ath12k_mac_op_set_bitrate_mask() for WCN6855? But that&amp;#39;s for another patch.<br /> <br /> BUG: sleeping function called from invalid context at drivers/net/wireless/ath/ath12k/wmi.c:420<br /> in_atomic(): 0, irqs_disabled(): 0, non_block: 0, pid: 2236, name: iw<br /> preempt_count: 0, expected: 0<br /> RCU nest depth: 1, expected: 0<br /> 3 locks held by iw/2236:<br /> #0: ffffffffabc6f1d8 (cb_lock){++++}-{3:3}, at: genl_rcv+0x14/0x40<br /> #1: ffff888138410810 (&amp;rdev-&gt;wiphy.mtx){+.+.}-{3:3}, at: nl80211_pre_doit+0x54d/0x800 [cfg80211]<br /> #2: ffffffffab2cfaa0 (rcu_read_lock){....}-{1:2}, at: ieee80211_iterate_stations_atomic+0x2f/0x200 [mac80211]<br /> CPU: 3 UID: 0 PID: 2236 Comm: iw Not tainted 6.11.0-rc7-wt-ath+ #1772<br /> Hardware name: Intel(R) Client Systems NUC8i7HVK/NUC8i7HVB, BIOS HNKBLi70.86A.0067.2021.0528.1339 05/28/2021<br /> Call Trace:<br /> <br /> dump_stack_lvl+0xa4/0xe0<br /> dump_stack+0x10/0x20<br /> __might_resched+0x363/0x5a0<br /> ? __alloc_skb+0x165/0x340<br /> __might_sleep+0xad/0x160<br /> ath12k_wmi_cmd_send+0xb1/0x3d0 [ath12k]<br /> ? ath12k_wmi_init_wcn7850+0xa40/0xa40 [ath12k]<br /> ? __netdev_alloc_skb+0x45/0x7b0<br /> ? __asan_memset+0x39/0x40<br /> ? ath12k_wmi_alloc_skb+0xf0/0x150 [ath12k]<br /> ? reacquire_held_locks+0x4d0/0x4d0<br /> ath12k_wmi_set_peer_param+0x340/0x5b0 [ath12k]<br /> ath12k_mac_disable_peer_fixed_rate+0xa3/0x110 [ath12k]<br /> ? ath12k_mac_vdev_stop+0x4f0/0x4f0 [ath12k]<br /> ieee80211_iterate_stations_atomic+0xd4/0x200 [mac80211]<br /> ath12k_mac_op_set_bitrate_mask+0x5d2/0x1080 [ath12k]<br /> ? ath12k_mac_vif_chan+0x320/0x320 [ath12k]<br /> drv_set_bitrate_mask+0x267/0x470 [mac80211]<br /> ieee80211_set_bitrate_mask+0x4cc/0x8a0 [mac80211]<br /> ? __this_cpu_preempt_check+0x13/0x20<br /> nl80211_set_tx_bitrate_mask+0x2bc/0x530 [cfg80211]<br /> ? nl80211_parse_tx_bitrate_mask+0x2320/0x2320 [cfg80211]<br /> ? trace_contention_end+0xef/0x140<br /> ? rtnl_unlock+0x9/0x10<br /> ? nl80211_pre_doit+0x557/0x800 [cfg80211]<br /> genl_family_rcv_msg_doit+0x1f0/0x2e0<br /> ? genl_family_rcv_msg_attrs_parse.isra.0+0x250/0x250<br /> ? ns_capable+0x57/0xd0<br /> genl_family_rcv_msg+0x34c/0x600<br /> ? genl_family_rcv_msg_dumpit+0x310/0x310<br /> ? __lock_acquire+0xc62/0x1de0<br /> ? he_set_mcs_mask.isra.0+0x8d0/0x8d0 [cfg80211]<br /> ? nl80211_parse_tx_bitrate_mask+0x2320/0x2320 [cfg80211]<br /> ? cfg80211_external_auth_request+0x690/0x690 [cfg80211]<br /> genl_rcv_msg+0xa0/0x130<br /> netlink_rcv_skb+0x14c/0x400<br /> ? genl_family_rcv_msg+0x600/0x600<br /> ? netlink_ack+0xd70/0xd70<br /> ? rwsem_optimistic_spin+0x4f0/0x4f0<br /> ? genl_rcv+0x14/0x40<br /> ? down_read_killable+0x580/0x580<br /> ? netlink_deliver_tap+0x13e/0x350<br /> ? __this_cpu_preempt_check+0x13/0x20<br /> genl_rcv+0x23/0x40<br /> netlink_unicast+0x45e/0x790<br /> ? netlink_attachskb+0x7f0/0x7f0<br /> netlink_sendmsg+0x7eb/0xdb0<br /> ? netlink_unicast+0x790/0x790<br /> ? __this_cpu_preempt_check+0x13/0x20<br /> ? selinux_socket_sendmsg+0x31/0x40<br /> ? netlink_unicast+0x790/0x790<br /> __sock_sendmsg+0xc9/0x160<br /> ____sys_sendmsg+0x620/0x990<br /> ? kernel_sendmsg+0x30/0x30<br /> ? __copy_msghdr+0x410/0x410<br /> ? __kasan_check_read+0x11/0x20<br /> ? mark_lock+0xe6/0x1470<br /> ___sys_sendmsg+0xe9/0x170<br /> ? copy_msghdr_from_user+0x120/0x120<br /> ? __lock_acquire+0xc62/0x1de0<br /> ? do_fault_around+0x2c6/0x4e0<br /> ? do_user_addr_fault+0x8c1/0xde0<br /> ? reacquire_held_locks+0x220/0x4d0<br /> ? do_user_addr_fault+0x8c1/0xde0<br /> ? __kasan_check_read+0x11/0x20<br /> ? __fdget+0x4e/0x1d0<br /> ? sockfd_lookup_light+0x1a/0x170<br /> __sys_sendmsg+0xd2/0x180<br /> ? __sys_sendmsg_sock+0x20/0x20<br /> ? reacquire_held_locks+0x4d0/0x4d0<br /> ? debug_smp_processor_id+0x17/0x20<br /> __x64_sys_sendmsg+0x72/0xb0<br /> ? lockdep_hardirqs_on+0x7d/0x100<br /> x64_sys_call+0x894/0x9f0<br /> do_syscall_64+0x64/0x130<br /> entry_SYSCALL_64_after_<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/mempolicy: fix migrate_to_node() assuming there is at least one VMA in a MM<br /> <br /> We currently assume that there is at least one VMA in a MM, which isn&amp;#39;t<br /> true.<br /> <br /> So we might end up having find_vma() return NULL, to then de-reference<br /> NULL. So properly handle find_vma() returning NULL.<br /> <br /> This fixes the report:<br /> <br /> Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN PTI<br /> KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]<br /> CPU: 1 UID: 0 PID: 6021 Comm: syz-executor284 Not tainted 6.12.0-rc7-syzkaller-00187-gf868cd251776 #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/30/2024<br /> RIP: 0010:migrate_to_node mm/mempolicy.c:1090 [inline]<br /> RIP: 0010:do_migrate_pages+0x403/0x6f0 mm/mempolicy.c:1194<br /> Code: ...<br /> RSP: 0018:ffffc9000375fd08 EFLAGS: 00010246<br /> RAX: 0000000000000000 RBX: ffffc9000375fd78 RCX: 0000000000000000<br /> RDX: ffff88807e171300 RSI: dffffc0000000000 RDI: ffff88803390c044<br /> RBP: ffff88807e171428 R08: 0000000000000014 R09: fffffbfff2039ef1<br /> R10: ffffffff901cf78f R11: 0000000000000000 R12: 0000000000000003<br /> R13: ffffc9000375fe90 R14: ffffc9000375fe98 R15: ffffc9000375fdf8<br /> FS: 00005555919e1380(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00005555919e1ca8 CR3: 000000007f12a000 CR4: 00000000003526f0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> kernel_migrate_pages+0x5b2/0x750 mm/mempolicy.c:1709<br /> __do_sys_migrate_pages mm/mempolicy.c:1727 [inline]<br /> __se_sys_migrate_pages mm/mempolicy.c:1723 [inline]<br /> __x64_sys_migrate_pages+0x96/0x100 mm/mempolicy.c:1723<br /> do_syscall_x64 arch/x86/entry/common.c:52 [inline]<br /> do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> [akpm@linux-foundation.org: add unlikely()]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/gup: handle NULL pages in unpin_user_pages()<br /> <br /> The recent addition of "pofs" (pages or folios) handling to gup has a<br /> flaw: it assumes that unpin_user_pages() handles NULL pages in the pages**<br /> array. That&amp;#39;s not the case, as I discovered when I ran on a new<br /> configuration on my test machine.<br /> <br /> Fix this by skipping NULL pages in unpin_user_pages(), just like<br /> unpin_folios() already does.<br /> <br /> Details: when booting on x86 with "numa=fake=2 movablecore=4G" on Linux<br /> 6.12, and running this:<br /> <br /> tools/testing/selftests/mm/gup_longterm<br /> <br /> ...I get the following crash:<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000008<br /> RIP: 0010:sanity_check_pinned_pages+0x3a/0x2d0<br /> ...<br /> Call Trace:<br /> <br /> ? __die_body+0x66/0xb0<br /> ? page_fault_oops+0x30c/0x3b0<br /> ? do_user_addr_fault+0x6c3/0x720<br /> ? irqentry_enter+0x34/0x60<br /> ? exc_page_fault+0x68/0x100<br /> ? asm_exc_page_fault+0x22/0x30<br /> ? sanity_check_pinned_pages+0x3a/0x2d0<br /> unpin_user_pages+0x24/0xe0<br /> check_and_migrate_movable_pages_or_folios+0x455/0x4b0<br /> __gup_longterm_locked+0x3bf/0x820<br /> ? mmap_read_lock_killable+0x12/0x50<br /> ? __pfx_mmap_read_lock_killable+0x10/0x10<br /> pin_user_pages+0x66/0xa0<br /> gup_test_ioctl+0x358/0xb20<br /> __se_sys_ioctl+0x6b/0xc0<br /> do_syscall_64+0x7b/0x150<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sched/numa: fix memory leak due to the overwritten vma-&gt;numab_state<br /> <br /> [Problem Description]<br /> When running the hackbench program of LTP, the following memory leak is<br /> reported by kmemleak.<br /> <br /> # /opt/ltp/testcases/bin/hackbench 20 thread 1000<br /> Running with 20*40 (== 800) tasks.<br /> <br /> # dmesg | grep kmemleak<br /> ...<br /> kmemleak: 480 new suspected memory leaks (see /sys/kernel/debug/kmemleak)<br /> kmemleak: 665 new suspected memory leaks (see /sys/kernel/debug/kmemleak)<br /> <br /> # cat /sys/kernel/debug/kmemleak<br /> unreferenced object 0xffff888cd8ca2c40 (size 64):<br /> comm "hackbench", pid 17142, jiffies 4299780315<br /> hex dump (first 32 bytes):<br /> ac 74 49 00 01 00 00 00 4c 84 49 00 01 00 00 00 .tI.....L.I.....<br /> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br /> backtrace (crc bff18fd4):<br /> [] __kmalloc_cache_noprof+0x2f9/0x3f0<br /> [] task_numa_work+0x725/0xa00<br /> [] task_work_run+0x58/0x90<br /> [] syscall_exit_to_user_mode+0x1c8/0x1e0<br /> [] do_syscall_64+0x85/0x150<br /> [] entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> ...<br /> <br /> This issue can be consistently reproduced on three different servers:<br /> * a 448-core server<br /> * a 256-core server<br /> * a 192-core server<br /> <br /> [Root Cause]<br /> Since multiple threads are created by the hackbench program (along with<br /> the command argument &amp;#39;thread&amp;#39;), a shared vma might be accessed by two or<br /> more cores simultaneously. When two or more cores observe that<br /> vma-&gt;numab_state is NULL at the same time, vma-&gt;numab_state will be<br /> overwritten.<br /> <br /> Although current code ensures that only one thread scans the VMAs in a<br /> single &amp;#39;numa_scan_period&amp;#39;, there might be a chance for another thread<br /> to enter in the next &amp;#39;numa_scan_period&amp;#39; while we have not gotten till<br /> numab_state allocation [1].<br /> <br /> Note that the command `/opt/ltp/testcases/bin/hackbench 50 process 1000`<br /> cannot the reproduce the issue. It is verified with 200+ test runs.<br /> <br /> [Solution]<br /> Use the cmpxchg atomic operation to ensure that only one thread executes<br /> the vma-&gt;numab_state assignment.<br /> <br /> [1] https://lore.kernel.org/lkml/1794be3c-358c-4cdc-a43d-a1f841d91ef7@amd.com/

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> af_packet: avoid erroring out after sock_init_data() in packet_create()<br /> <br /> After sock_init_data() the allocated sk object is attached to the provided<br /> sock object. On error, packet_create() frees the sk object leaving the<br /> dangling pointer in the sock object on return. Some other code may try<br /> to use this pointer and cause use-after-free.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Fix out-of-bounds access in &amp;#39;dcn21_link_encoder_create&amp;#39;<br /> <br /> An issue was identified in the dcn21_link_encoder_create function where<br /> an out-of-bounds access could occur when the hpd_source index was used<br /> to reference the link_enc_hpd_regs array. This array has a fixed size<br /> and the index was not being checked against the array&amp;#39;s bounds before<br /> accessing it.<br /> <br /> This fix adds a conditional check to ensure that the hpd_source index is<br /> within the valid range of the link_enc_hpd_regs array. If the index is<br /> out of bounds, the function now returns NULL to prevent undefined<br /> behavior.<br /> <br /> References:<br /> <br /> [ 65.920507] ------------[ cut here ]------------<br /> [ 65.920510] UBSAN: array-index-out-of-bounds in drivers/gpu/drm/amd/amdgpu/../display/dc/resource/dcn21/dcn21_resource.c:1312:29<br /> [ 65.920519] index 7 is out of range for type &amp;#39;dcn10_link_enc_hpd_registers [5]&amp;#39;<br /> [ 65.920523] CPU: 3 PID: 1178 Comm: modprobe Tainted: G OE 6.8.0-cleanershaderfeatureresetasdntipmi200nv2132 #13<br /> [ 65.920525] Hardware name: AMD Majolica-RN/Majolica-RN, BIOS WMJ0429N_Weekly_20_04_2 04/29/2020<br /> [ 65.920527] Call Trace:<br /> [ 65.920529] <br /> [ 65.920532] dump_stack_lvl+0x48/0x70<br /> [ 65.920541] dump_stack+0x10/0x20<br /> [ 65.920543] __ubsan_handle_out_of_bounds+0xa2/0xe0<br /> [ 65.920549] dcn21_link_encoder_create+0xd9/0x140 [amdgpu]<br /> [ 65.921009] link_create+0x6d3/0xed0 [amdgpu]<br /> [ 65.921355] create_links+0x18a/0x4e0 [amdgpu]<br /> [ 65.921679] dc_create+0x360/0x720 [amdgpu]<br /> [ 65.921999] ? dmi_matches+0xa0/0x220<br /> [ 65.922004] amdgpu_dm_init+0x2b6/0x2c90 [amdgpu]<br /> [ 65.922342] ? console_unlock+0x77/0x120<br /> [ 65.922348] ? dev_printk_emit+0x86/0xb0<br /> [ 65.922354] dm_hw_init+0x15/0x40 [amdgpu]<br /> [ 65.922686] amdgpu_device_init+0x26a8/0x33a0 [amdgpu]<br /> [ 65.922921] amdgpu_driver_load_kms+0x1b/0xa0 [amdgpu]<br /> [ 65.923087] amdgpu_pci_probe+0x1b7/0x630 [amdgpu]<br /> [ 65.923087] local_pci_probe+0x4b/0xb0<br /> [ 65.923087] pci_device_probe+0xc8/0x280<br /> [ 65.923087] really_probe+0x187/0x300<br /> [ 65.923087] __driver_probe_device+0x85/0x130<br /> [ 65.923087] driver_probe_device+0x24/0x110<br /> [ 65.923087] __driver_attach+0xac/0x1d0<br /> [ 65.923087] ? __pfx___driver_attach+0x10/0x10<br /> [ 65.923087] bus_for_each_dev+0x7d/0xd0<br /> [ 65.923087] driver_attach+0x1e/0x30<br /> [ 65.923087] bus_add_driver+0xf2/0x200<br /> [ 65.923087] driver_register+0x64/0x130<br /> [ 65.923087] ? __pfx_amdgpu_init+0x10/0x10 [amdgpu]<br /> [ 65.923087] __pci_register_driver+0x61/0x70<br /> [ 65.923087] amdgpu_init+0x7d/0xff0 [amdgpu]<br /> [ 65.923087] do_one_initcall+0x49/0x310<br /> [ 65.923087] ? kmalloc_trace+0x136/0x360<br /> [ 65.923087] do_init_module+0x6a/0x270<br /> [ 65.923087] load_module+0x1fce/0x23a0<br /> [ 65.923087] init_module_from_file+0x9c/0xe0<br /> [ 65.923087] ? init_module_from_file+0x9c/0xe0<br /> [ 65.923087] idempotent_init_module+0x179/0x230<br /> [ 65.923087] __x64_sys_finit_module+0x5d/0xa0<br /> [ 65.923087] do_syscall_64+0x76/0x120<br /> [ 65.923087] entry_SYSCALL_64_after_hwframe+0x6e/0x76<br /> [ 65.923087] RIP: 0033:0x7f2d80f1e88d<br /> [ 65.923087] Code: 5b 41 5c c3 66 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 3d 01 f0 ff ff 73 01 c3 48 8b 0d 73 b5 0f 00 f7 d8 64 89 01 48<br /> [ 65.923087] RSP: 002b:00007ffc7bc1aa78 EFLAGS: 00000246 ORIG_RAX: 0000000000000139<br /> [ 65.923087] RAX: ffffffffffffffda RBX: 0000564c9c1db130 RCX: 00007f2d80f1e88d<br /> [ 65.923087] RDX: 0000000000000000 RSI: 0000564c9c1e5480 RDI: 000000000000000f<br /> [ 65.923087] RBP: 0000000000040000 R08: 0000000000000000 R09: 0000000000000002<br /> [ 65.923087] R10: 000000000000000f R11: 0000000000000246 R12: 0000564c9c1e5480<br /> [ 65.923087] R13: 0000564c9c1db260 R14: 0000000000000000 R15: 0000564c9c1e54b0<br /> [ 65.923087] <br /> [ 65.923927] ---[ end trace ]---