Vulnerabilities

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 ]---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> kcsan: Turn report_filterlist_lock into a raw_spinlock<br /> <br /> Ran Xiaokai reports that with a KCSAN-enabled PREEMPT_RT kernel, we can see<br /> splats like:<br /> <br /> | BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48<br /> | in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 0, name: swapper/1<br /> | preempt_count: 10002, expected: 0<br /> | RCU nest depth: 0, expected: 0<br /> | no locks held by swapper/1/0.<br /> | irq event stamp: 156674<br /> | hardirqs last enabled at (156673): [] do_idle+0x1f9/0x240<br /> | hardirqs last disabled at (156674): [] sysvec_apic_timer_interrupt+0x14/0xc0<br /> | softirqs last enabled at (0): [] copy_process+0xfc7/0x4b60<br /> | softirqs last disabled at (0): [] 0x0<br /> | Preemption disabled at:<br /> | [] paint_ptr+0x2a/0x90<br /> | CPU: 1 UID: 0 PID: 0 Comm: swapper/1 Not tainted 6.11.0+ #3<br /> | Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.0-0-ga698c8995f-prebuilt.qemu.org 04/01/2014<br /> | Call Trace:<br /> | <br /> | dump_stack_lvl+0x7e/0xc0<br /> | dump_stack+0x1d/0x30<br /> | __might_resched+0x1a2/0x270<br /> | rt_spin_lock+0x68/0x170<br /> | kcsan_skip_report_debugfs+0x43/0xe0<br /> | print_report+0xb5/0x590<br /> | kcsan_report_known_origin+0x1b1/0x1d0<br /> | kcsan_setup_watchpoint+0x348/0x650<br /> | __tsan_unaligned_write1+0x16d/0x1d0<br /> | hrtimer_interrupt+0x3d6/0x430<br /> | __sysvec_apic_timer_interrupt+0xe8/0x3a0<br /> | sysvec_apic_timer_interrupt+0x97/0xc0<br /> | <br /> <br /> On a detected data race, KCSAN&amp;#39;s reporting logic checks if it should<br /> filter the report. That list is protected by the report_filterlist_lock<br /> *non-raw* spinlock which may sleep on RT kernels.<br /> <br /> Since KCSAN may report data races in any context, convert it to a<br /> raw_spinlock.<br /> <br /> This requires being careful about when to allocate memory for the filter<br /> list itself which can be done via KCSAN&amp;#39;s debugfs interface. Concurrent<br /> modification of the filter list via debugfs should be rare: the chosen<br /> strategy is to optimistically pre-allocate memory before the critical<br /> section and discard if unused.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xsk: fix OOB map writes when deleting elements<br /> <br /> Jordy says:<br /> <br /> "<br /> In the xsk_map_delete_elem function an unsigned integer<br /> (map-&gt;max_entries) is compared with a user-controlled signed integer<br /> (k). Due to implicit type conversion, a large unsigned value for<br /> map-&gt;max_entries can bypass the intended bounds check:<br /> <br /> if (k &gt;= map-&gt;max_entries)<br /> return -EINVAL;<br /> <br /> This allows k to hold a negative value (between -2147483648 and -2),<br /> which is then used as an array index in m-&gt;xsk_map[k], which results<br /> in an out-of-bounds access.<br /> <br /> spin_lock_bh(&amp;m-&gt;lock);<br /> map_entry = &amp;m-&gt;xsk_map[k]; // Out-of-bounds map_entry<br /> old_xs = unrcu_pointer(xchg(map_entry, NULL)); // Oob write<br /> if (old_xs)<br /> xsk_map_sock_delete(old_xs, map_entry);<br /> spin_unlock_bh(&amp;m-&gt;lock);<br /> <br /> The xchg operation can then be used to cause an out-of-bounds write.<br /> Moreover, the invalid map_entry passed to xsk_map_sock_delete can lead<br /> to further memory corruption.<br /> "<br /> <br /> It indeed results in following splat:<br /> <br /> [76612.897343] BUG: unable to handle page fault for address: ffffc8fc2e461108<br /> [76612.904330] #PF: supervisor write access in kernel mode<br /> [76612.909639] #PF: error_code(0x0002) - not-present page<br /> [76612.914855] PGD 0 P4D 0<br /> [76612.917431] Oops: Oops: 0002 [#1] PREEMPT SMP<br /> [76612.921859] CPU: 11 UID: 0 PID: 10318 Comm: a.out Not tainted 6.12.0-rc1+ #470<br /> [76612.929189] Hardware name: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0008.031920191559 03/19/2019<br /> [76612.939781] RIP: 0010:xsk_map_delete_elem+0x2d/0x60<br /> [76612.944738] Code: 00 00 41 54 55 53 48 63 2e 3b 6f 24 73 38 4c 8d a7 f8 00 00 00 48 89 fb 4c 89 e7 e8 2d bf 05 00 48 8d b4 eb 00 01 00 00 31 ff 87 3e 48 85 ff 74 05 e8 16 ff ff ff 4c 89 e7 e8 3e bc 05 00 31<br /> [76612.963774] RSP: 0018:ffffc9002e407df8 EFLAGS: 00010246<br /> [76612.969079] RAX: 0000000000000000 RBX: ffffc9002e461000 RCX: 0000000000000000<br /> [76612.976323] RDX: 0000000000000001 RSI: ffffc8fc2e461108 RDI: 0000000000000000<br /> [76612.983569] RBP: ffffffff80000001 R08: 0000000000000000 R09: 0000000000000007<br /> [76612.990812] R10: ffffc9002e407e18 R11: ffff888108a38858 R12: ffffc9002e4610f8<br /> [76612.998060] R13: ffff888108a38858 R14: 00007ffd1ae0ac78 R15: ffffc9002e4610c0<br /> [76613.005303] FS: 00007f80b6f59740(0000) GS:ffff8897e0ec0000(0000) knlGS:0000000000000000<br /> [76613.013517] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [76613.019349] CR2: ffffc8fc2e461108 CR3: 000000011e3ef001 CR4: 00000000007726f0<br /> [76613.026595] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> [76613.033841] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> [76613.041086] PKRU: 55555554<br /> [76613.043842] Call Trace:<br /> [76613.046331] <br /> [76613.048468] ? __die+0x20/0x60<br /> [76613.051581] ? page_fault_oops+0x15a/0x450<br /> [76613.055747] ? search_extable+0x22/0x30<br /> [76613.059649] ? search_bpf_extables+0x5f/0x80<br /> [76613.063988] ? exc_page_fault+0xa9/0x140<br /> [76613.067975] ? asm_exc_page_fault+0x22/0x30<br /> [76613.072229] ? xsk_map_delete_elem+0x2d/0x60<br /> [76613.076573] ? xsk_map_delete_elem+0x23/0x60<br /> [76613.080914] __sys_bpf+0x19b7/0x23c0<br /> [76613.084555] __x64_sys_bpf+0x1a/0x20<br /> [76613.088194] do_syscall_64+0x37/0xb0<br /> [76613.091832] entry_SYSCALL_64_after_hwframe+0x4b/0x53<br /> [76613.096962] RIP: 0033:0x7f80b6d1e88d<br /> [76613.100592] 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 /> [76613.119631] RSP: 002b:00007ffd1ae0ac68 EFLAGS: 00000206 ORIG_RAX: 0000000000000141<br /> [76613.131330] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f80b6d1e88d<br /> [76613.142632] RDX: 0000000000000098 RSI: 00007ffd1ae0ad20 RDI: 0000000000000003<br /> [76613.153967] RBP: 00007ffd1ae0adc0 R08: 0000000000000000 R09: 0000000000000000<br /> [76613.166030] R10: 00007f80b6f77040 R11: 0000000000000206 R12: 00007ffd1ae0aed8<br /> [76613.177130] R13: 000055ddf42ce1e9 R14: 000055ddf42d0d98 R15: 00<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: rtw88: use ieee80211_purge_tx_queue() to purge TX skb<br /> <br /> When removing kernel modules by:<br /> rmmod rtw88_8723cs rtw88_8703b rtw88_8723x rtw88_sdio rtw88_core<br /> <br /> Driver uses skb_queue_purge() to purge TX skb, but not report tx status<br /> causing "Have pending ack frames!" warning. Use ieee80211_purge_tx_queue()<br /> to correct this.<br /> <br /> Since ieee80211_purge_tx_queue() doesn&amp;#39;t take locks, to prevent racing<br /> between TX work and purge TX queue, flush and destroy TX work in advance.<br /> <br /> wlan0: deauthenticating from aa:f5:fd:60:4c:a8 by local<br /> choice (Reason: 3=DEAUTH_LEAVING)<br /> ------------[ cut here ]------------<br /> Have pending ack frames!<br /> WARNING: CPU: 3 PID: 9232 at net/mac80211/main.c:1691<br /> ieee80211_free_ack_frame+0x5c/0x90 [mac80211]<br /> CPU: 3 PID: 9232 Comm: rmmod Tainted: G C<br /> 6.10.1-200.fc40.aarch64 #1<br /> Hardware name: pine64 Pine64 PinePhone Braveheart<br /> (1.1)/Pine64 PinePhone Braveheart (1.1), BIOS 2024.01 01/01/2024<br /> pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> pc : ieee80211_free_ack_frame+0x5c/0x90 [mac80211]<br /> lr : ieee80211_free_ack_frame+0x5c/0x90 [mac80211]<br /> sp : ffff80008c1b37b0<br /> x29: ffff80008c1b37b0 x28: ffff000003be8000 x27: 0000000000000000<br /> x26: 0000000000000000 x25: ffff000003dc14b8 x24: ffff80008c1b37d0<br /> x23: ffff000000ff9f80 x22: 0000000000000000 x21: 000000007fffffff<br /> x20: ffff80007c7e93d8 x19: ffff00006e66f400 x18: 0000000000000000<br /> x17: ffff7ffffd2b3000 x16: ffff800083fc0000 x15: 0000000000000000<br /> x14: 0000000000000000 x13: 2173656d61726620 x12: 6b636120676e6964<br /> x11: 0000000000000000 x10: 000000000000005d x9 : ffff8000802af2b0<br /> x8 : ffff80008c1b3430 x7 : 0000000000000001 x6 : 0000000000000001<br /> x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000<br /> x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff000003be8000<br /> Call trace:<br /> ieee80211_free_ack_frame+0x5c/0x90 [mac80211]<br /> idr_for_each+0x74/0x110<br /> ieee80211_free_hw+0x44/0xe8 [mac80211]<br /> rtw_sdio_remove+0x9c/0xc0 [rtw88_sdio]<br /> sdio_bus_remove+0x44/0x180<br /> device_remove+0x54/0x90<br /> device_release_driver_internal+0x1d4/0x238<br /> driver_detach+0x54/0xc0<br /> bus_remove_driver+0x78/0x108<br /> driver_unregister+0x38/0x78<br /> sdio_unregister_driver+0x2c/0x40<br /> rtw_8723cs_driver_exit+0x18/0x1000 [rtw88_8723cs]<br /> __do_sys_delete_module.isra.0+0x190/0x338<br /> __arm64_sys_delete_module+0x1c/0x30<br /> invoke_syscall+0x74/0x100<br /> el0_svc_common.constprop.0+0x48/0xf0<br /> do_el0_svc+0x24/0x38<br /> el0_svc+0x3c/0x158<br /> el0t_64_sync_handler+0x120/0x138<br /> el0t_64_sync+0x194/0x198<br /> ---[ end trace 0000000000000000 ]---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> jfs: fix shift-out-of-bounds in dbSplit<br /> <br /> When dmt_budmin is less than zero, it causes errors<br /> in the later stages. Added a check to return an error beforehand<br /> in dbAllocCtl itself.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> jfs: array-index-out-of-bounds fix in dtReadFirst<br /> <br /> The value of stbl can be sometimes out of bounds due<br /> to a bad filesystem. Added a check with appopriate return<br /> of error code in that case.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: ath10k: avoid NULL pointer error during sdio remove<br /> <br /> When running &amp;#39;rmmod ath10k&amp;#39;, ath10k_sdio_remove() will free sdio<br /> workqueue by destroy_workqueue(). But if CONFIG_INIT_ON_FREE_DEFAULT_ON<br /> is set to yes, kernel panic will happen:<br /> Call trace:<br /> destroy_workqueue+0x1c/0x258<br /> ath10k_sdio_remove+0x84/0x94<br /> sdio_bus_remove+0x50/0x16c<br /> device_release_driver_internal+0x188/0x25c<br /> device_driver_detach+0x20/0x2c<br /> <br /> This is because during &amp;#39;rmmod ath10k&amp;#39;, ath10k_sdio_remove() will call<br /> ath10k_core_destroy() before destroy_workqueue(). wiphy_dev_release()<br /> will finally be called in ath10k_core_destroy(). This function will free<br /> struct cfg80211_registered_device *rdev and all its members, including<br /> wiphy, dev and the pointer of sdio workqueue. Then the pointer of sdio<br /> workqueue will be set to NULL due to CONFIG_INIT_ON_FREE_DEFAULT_ON.<br /> <br /> After device release, destroy_workqueue() will use NULL pointer then the<br /> kernel panic happen.<br /> <br /> Call trace:<br /> ath10k_sdio_remove<br /> -&gt;ath10k_core_unregister<br /> ……<br /> -&gt;ath10k_core_stop<br /> -&gt;ath10k_hif_stop<br /> -&gt;ath10k_sdio_irq_disable<br /> -&gt;ath10k_hif_power_down<br /> -&gt;del_timer_sync(&amp;ar_sdio-&gt;sleep_timer)<br /> -&gt;ath10k_core_destroy<br /> -&gt;ath10k_mac_destroy<br /> -&gt;ieee80211_free_hw<br /> -&gt;wiphy_free<br /> ……<br /> -&gt;wiphy_dev_release<br /> -&gt;destroy_workqueue<br /> <br /> Need to call destroy_workqueue() before ath10k_core_destroy(), free<br /> the work queue buffer first and then free pointer of work queue by<br /> ath10k_core_destroy(). This order matches the error path order in<br /> ath10k_sdio_probe().<br /> <br /> No work will be queued on sdio workqueue between it is destroyed and<br /> ath10k_core_destroy() is called. Based on the call_stack above, the<br /> reason is:<br /> Only ath10k_sdio_sleep_timer_handler(), ath10k_sdio_hif_tx_sg() and<br /> ath10k_sdio_irq_disable() will queue work on sdio workqueue.<br /> Sleep timer will be deleted before ath10k_core_destroy() in<br /> ath10k_hif_power_down().<br /> ath10k_sdio_irq_disable() only be called in ath10k_hif_stop().<br /> ath10k_core_unregister() will call ath10k_hif_power_down() to stop hif<br /> bus, so ath10k_sdio_hif_tx_sg() won&amp;#39;t be called anymore.<br /> <br /> Tested-on: QCA6174 hw3.2 SDIO WLAN.RMH.4.4.1-00189