Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nfsd: make sure exp active before svc_export_show<br /> <br /> The function `e_show` was called with protection from RCU. This only<br /> ensures that `exp` will not be freed. Therefore, the reference count for<br /> `exp` can drop to zero, which will trigger a refcount use-after-free<br /> warning when `exp_get` is called. To resolve this issue, use<br /> `cache_get_rcu` to ensure that `exp` remains active.<br /> <br /> ------------[ cut here ]------------<br /> refcount_t: addition on 0; use-after-free.<br /> WARNING: CPU: 3 PID: 819 at lib/refcount.c:25<br /> refcount_warn_saturate+0xb1/0x120<br /> CPU: 3 UID: 0 PID: 819 Comm: cat Not tainted 6.12.0-rc3+ #1<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS<br /> 1.16.1-2.fc37 04/01/2014<br /> RIP: 0010:refcount_warn_saturate+0xb1/0x120<br /> ...<br /> Call Trace:<br /> <br /> e_show+0x20b/0x230 [nfsd]<br /> seq_read_iter+0x589/0x770<br /> seq_read+0x1e5/0x270<br /> vfs_read+0x125/0x530<br /> ksys_read+0xc1/0x160<br /> do_syscall_64+0x5f/0x170<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iio: adc: ad7923: Fix buffer overflow for tx_buf and ring_xfer<br /> <br /> The AD7923 was updated to support devices with 8 channels, but the size<br /> of tx_buf and ring_xfer was not increased accordingly, leading to a<br /> potential buffer overflow in ad7923_update_scan_mode().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> s390/stacktrace: Use break instead of return statement<br /> <br /> arch_stack_walk_user_common() contains a return statement instead of a<br /> break statement in case store_ip() fails while trying to store a callchain<br /> entry of a user space process.<br /> This may lead to a missing pagefault_enable() call.<br /> <br /> If this happens any subsequent page fault of the process won&amp;#39;t be resolved<br /> by the page fault handler and this in turn will lead to the process being<br /> killed.<br /> <br /> Use a break instead of a return statement to fix this.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/xe/guc_submit: fix race around suspend_pending<br /> <br /> Currently in some testcases we can trigger:<br /> <br /> xe 0000:03:00.0: [drm] Assertion `exec_queue_destroyed(q)` failed!<br /> ....<br /> WARNING: CPU: 18 PID: 2640 at drivers/gpu/drm/xe/xe_guc_submit.c:1826 xe_guc_sched_done_handler+0xa54/0xef0 [xe]<br /> xe 0000:03:00.0: [drm] *ERROR* GT1: DEREGISTER_DONE: Unexpected engine state 0x00a1, guc_id=57<br /> <br /> Looking at a snippet of corresponding ftrace for this GuC id we can see:<br /> <br /> 162.673311: xe_sched_msg_add: dev=0000:03:00.0, gt=1 guc_id=57, opcode=3<br /> 162.673317: xe_sched_msg_recv: dev=0000:03:00.0, gt=1 guc_id=57, opcode=3<br /> 162.673319: xe_exec_queue_scheduling_disable: dev=0000:03:00.0, 1:0x2, gt=1, width=1, guc_id=57, guc_state=0x29, flags=0x0<br /> 162.674089: xe_exec_queue_kill: dev=0000:03:00.0, 1:0x2, gt=1, width=1, guc_id=57, guc_state=0x29, flags=0x0<br /> 162.674108: xe_exec_queue_close: dev=0000:03:00.0, 1:0x2, gt=1, width=1, guc_id=57, guc_state=0xa9, flags=0x0<br /> 162.674488: xe_exec_queue_scheduling_done: dev=0000:03:00.0, 1:0x2, gt=1, width=1, guc_id=57, guc_state=0xa9, flags=0x0<br /> 162.678452: xe_exec_queue_deregister: dev=0000:03:00.0, 1:0x2, gt=1, width=1, guc_id=57, guc_state=0xa1, flags=0x0<br /> <br /> It looks like we try to suspend the queue (opcode=3), setting<br /> suspend_pending and triggering a disable_scheduling. The user then<br /> closes the queue. However the close will also forcefully signal the<br /> suspend fence after killing the queue, later when the G2H response for<br /> disable_scheduling comes back we have now cleared suspend_pending when<br /> signalling the suspend fence, so the disable_scheduling now incorrectly<br /> tries to also deregister the queue. This leads to warnings since the queue<br /> has yet to even be marked for destruction. We also seem to trigger<br /> errors later with trying to double unregister the same queue.<br /> <br /> To fix this tweak the ordering when handling the response to ensure we<br /> don&amp;#39;t race with a disable_scheduling that didn&amp;#39;t actually intend to<br /> perform an unregister. The destruction path should now also correctly<br /> wait for any pending_disable before marking as destroyed.<br /> <br /> (cherry picked from commit f161809b362f027b6d72bd998e47f8f0bad60a2e)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu: fix usage slab after free<br /> <br /> [ +0.000021] BUG: KASAN: slab-use-after-free in drm_sched_entity_flush+0x6cb/0x7a0 [gpu_sched]<br /> [ +0.000027] Read of size 8 at addr ffff8881b8605f88 by task amd_pci_unplug/2147<br /> <br /> [ +0.000023] CPU: 6 PID: 2147 Comm: amd_pci_unplug Not tainted 6.10.0+ #1<br /> [ +0.000016] Hardware name: ASUS System Product Name/ROG STRIX B550-F GAMING (WI-FI), BIOS 1401 12/03/2020<br /> [ +0.000016] Call Trace:<br /> [ +0.000008] <br /> [ +0.000009] dump_stack_lvl+0x76/0xa0<br /> [ +0.000017] print_report+0xce/0x5f0<br /> [ +0.000017] ? drm_sched_entity_flush+0x6cb/0x7a0 [gpu_sched]<br /> [ +0.000019] ? srso_return_thunk+0x5/0x5f<br /> [ +0.000015] ? kasan_complete_mode_report_info+0x72/0x200<br /> [ +0.000016] ? drm_sched_entity_flush+0x6cb/0x7a0 [gpu_sched]<br /> [ +0.000019] kasan_report+0xbe/0x110<br /> [ +0.000015] ? drm_sched_entity_flush+0x6cb/0x7a0 [gpu_sched]<br /> [ +0.000023] __asan_report_load8_noabort+0x14/0x30<br /> [ +0.000014] drm_sched_entity_flush+0x6cb/0x7a0 [gpu_sched]<br /> [ +0.000020] ? srso_return_thunk+0x5/0x5f<br /> [ +0.000013] ? __kasan_check_write+0x14/0x30<br /> [ +0.000016] ? __pfx_drm_sched_entity_flush+0x10/0x10 [gpu_sched]<br /> [ +0.000020] ? srso_return_thunk+0x5/0x5f<br /> [ +0.000013] ? __kasan_check_write+0x14/0x30<br /> [ +0.000013] ? srso_return_thunk+0x5/0x5f<br /> [ +0.000013] ? enable_work+0x124/0x220<br /> [ +0.000015] ? __pfx_enable_work+0x10/0x10<br /> [ +0.000013] ? srso_return_thunk+0x5/0x5f<br /> [ +0.000014] ? free_large_kmalloc+0x85/0xf0<br /> [ +0.000016] drm_sched_entity_destroy+0x18/0x30 [gpu_sched]<br /> [ +0.000020] amdgpu_vce_sw_fini+0x55/0x170 [amdgpu]<br /> [ +0.000735] ? __kasan_check_read+0x11/0x20<br /> [ +0.000016] vce_v4_0_sw_fini+0x80/0x110 [amdgpu]<br /> [ +0.000726] amdgpu_device_fini_sw+0x331/0xfc0 [amdgpu]<br /> [ +0.000679] ? mutex_unlock+0x80/0xe0<br /> [ +0.000017] ? __pfx_amdgpu_device_fini_sw+0x10/0x10 [amdgpu]<br /> [ +0.000662] ? srso_return_thunk+0x5/0x5f<br /> [ +0.000014] ? __kasan_check_write+0x14/0x30<br /> [ +0.000013] ? srso_return_thunk+0x5/0x5f<br /> [ +0.000013] ? mutex_unlock+0x80/0xe0<br /> [ +0.000016] amdgpu_driver_release_kms+0x16/0x80 [amdgpu]<br /> [ +0.000663] drm_minor_release+0xc9/0x140 [drm]<br /> [ +0.000081] drm_release+0x1fd/0x390 [drm]<br /> [ +0.000082] __fput+0x36c/0xad0<br /> [ +0.000018] __fput_sync+0x3c/0x50<br /> [ +0.000014] __x64_sys_close+0x7d/0xe0<br /> [ +0.000014] x64_sys_call+0x1bc6/0x2680<br /> [ +0.000014] do_syscall_64+0x70/0x130<br /> [ +0.000014] ? srso_return_thunk+0x5/0x5f<br /> [ +0.000014] ? irqentry_exit_to_user_mode+0x60/0x190<br /> [ +0.000015] ? srso_return_thunk+0x5/0x5f<br /> [ +0.000014] ? irqentry_exit+0x43/0x50<br /> [ +0.000012] ? srso_return_thunk+0x5/0x5f<br /> [ +0.000013] ? exc_page_fault+0x7c/0x110<br /> [ +0.000015] entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> [ +0.000014] RIP: 0033:0x7ffff7b14f67<br /> [ +0.000013] Code: ff e8 0d 16 02 00 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 03 00 00 00 0f 05 3d 00 f0 ff ff 77 41 c3 48 83 ec 18 89 7c 24 0c e8 73 ba f7 ff<br /> [ +0.000026] RSP: 002b:00007fffffffe378 EFLAGS: 00000246 ORIG_RAX: 0000000000000003<br /> [ +0.000019] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007ffff7b14f67<br /> [ +0.000014] RDX: 0000000000000000 RSI: 00007ffff7f6f47a RDI: 0000000000000003<br /> [ +0.000014] RBP: 00007fffffffe3a0 R08: 0000555555569890 R09: 0000000000000000<br /> [ +0.000014] R10: 0000000000000000 R11: 0000000000000246 R12: 00007fffffffe5c8<br /> [ +0.000013] R13: 00005555555552a9 R14: 0000555555557d48 R15: 00007ffff7ffd040<br /> [ +0.000020] <br /> <br /> [ +0.000016] Allocated by task 383 on cpu 7 at 26.880319s:<br /> [ +0.000014] kasan_save_stack+0x28/0x60<br /> [ +0.000008] kasan_save_track+0x18/0x70<br /> [ +0.000007] kasan_save_alloc_info+0x38/0x60<br /> [ +0.000007] __kasan_kmalloc+0xc1/0xd0<br /> [ +0.000007] kmalloc_trace_noprof+0x180/0x380<br /> [ +0.000007] drm_sched_init+0x411/0xec0 [gpu_sched]<br /> [ +0.000012] amdgpu_device_init+0x695f/0xa610 [amdgpu]<br /> [ +0.000658] amdgpu_driver_load_kms+0x1a/0x120 [amdgpu]<br /> [ +0.000662] amdgpu_pci_p<br /> ---truncated---

A vulnerability classified as critical was found in Overtek OT-E801G OTE801G65.1.1.0. This vulnerability affects unknown code of the file /diag_ping.cmd?action=test&amp;interface=ppp0.1&amp;ipaddr=8.8.8.8%26%26cat%20/etc/passwd&amp;ipversion=4&amp;sessionKey=test. The manipulation leads to os command injection. The attack can be initiated remotely. The exploit has been disclosed to the public and may be used. The vendor was contacted early about this disclosure but did not respond in any way.

A vulnerability classified as problematic has been found in Amcrest IP2M-841B, IP2M-841W, IPC-IP2M-841B, IPC-IP3M-943B, IPC-IP3M-943S, IPC-IP3M-HX2B and IPC-IPM-721S up to 20241211. This affects an unknown part of the file /web_caps/webCapsConfig of the component Web Interface. The manipulation leads to information disclosure. It is possible to initiate the attack remotely. The exploit has been disclosed to the public and may be used. The vendor was contacted early about this disclosure but did not respond in any way.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: ath12k: Skip Rx TID cleanup for self peer<br /> <br /> During peer create, dp setup for the peer is done where Rx TID is<br /> updated for all the TIDs. Peer object for self peer will not go through<br /> dp setup.<br /> <br /> When core halts, dp cleanup is done for all the peers. While cleanup,<br /> rx_tid::ab is accessed which causes below stack trace for self peer.<br /> <br /> WARNING: CPU: 6 PID: 12297 at drivers/net/wireless/ath/ath12k/dp_rx.c:851<br /> Call Trace:<br /> __warn+0x7b/0x1a0<br /> ath12k_dp_rx_frags_cleanup+0xd2/0xe0 [ath12k]<br /> report_bug+0x10b/0x200<br /> handle_bug+0x3f/0x70<br /> exc_invalid_op+0x13/0x60<br /> asm_exc_invalid_op+0x16/0x20<br /> ath12k_dp_rx_frags_cleanup+0xd2/0xe0 [ath12k]<br /> ath12k_dp_rx_frags_cleanup+0xca/0xe0 [ath12k]<br /> ath12k_dp_rx_peer_tid_cleanup+0x39/0xa0 [ath12k]<br /> ath12k_mac_peer_cleanup_all+0x61/0x100 [ath12k]<br /> ath12k_core_halt+0x3b/0x100 [ath12k]<br /> ath12k_core_reset+0x494/0x4c0 [ath12k]<br /> <br /> sta object in peer will be updated when remote peer is created. Hence<br /> use peer::sta to detect the self peer and skip the cleanup.<br /> <br /> Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.0.1-00029-QCAHKSWPL_SILICONZ-1<br /> Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> udmabuf: change folios array from kmalloc to kvmalloc<br /> <br /> When PAGE_SIZE 4096, MAX_PAGE_ORDER 10, 64bit machine,<br /> page_alloc only support 4MB.<br /> If above this, trigger this warn and return NULL.<br /> <br /> udmabuf can change size limit, if change it to 3072(3GB), and then alloc<br /> 3GB udmabuf, will fail create.<br /> <br /> [ 4080.876581] ------------[ cut here ]------------<br /> [ 4080.876843] WARNING: CPU: 3 PID: 2015 at mm/page_alloc.c:4556 __alloc_pages+0x2c8/0x350<br /> [ 4080.878839] RIP: 0010:__alloc_pages+0x2c8/0x350<br /> [ 4080.879470] Call Trace:<br /> [ 4080.879473] <br /> [ 4080.879473] ? __alloc_pages+0x2c8/0x350<br /> [ 4080.879475] ? __warn.cold+0x8e/0xe8<br /> [ 4080.880647] ? __alloc_pages+0x2c8/0x350<br /> [ 4080.880909] ? report_bug+0xff/0x140<br /> [ 4080.881175] ? handle_bug+0x3c/0x80<br /> [ 4080.881556] ? exc_invalid_op+0x17/0x70<br /> [ 4080.881559] ? asm_exc_invalid_op+0x1a/0x20<br /> [ 4080.882077] ? udmabuf_create+0x131/0x400<br /> <br /> Because MAX_PAGE_ORDER, kmalloc can max alloc 4096 * (1

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> HID: hyperv: streamline driver probe to avoid devres issues<br /> <br /> It was found that unloading &amp;#39;hid_hyperv&amp;#39; module results in a devres<br /> complaint:<br /> <br /> ...<br /> hv_vmbus: unregistering driver hid_hyperv<br /> ------------[ cut here ]------------<br /> WARNING: CPU: 2 PID: 3983 at drivers/base/devres.c:691 devres_release_group+0x1f2/0x2c0<br /> ...<br /> Call Trace:<br /> <br /> ? devres_release_group+0x1f2/0x2c0<br /> ? __warn+0xd1/0x1c0<br /> ? devres_release_group+0x1f2/0x2c0<br /> ? report_bug+0x32a/0x3c0<br /> ? handle_bug+0x53/0xa0<br /> ? exc_invalid_op+0x18/0x50<br /> ? asm_exc_invalid_op+0x1a/0x20<br /> ? devres_release_group+0x1f2/0x2c0<br /> ? devres_release_group+0x90/0x2c0<br /> ? rcu_is_watching+0x15/0xb0<br /> ? __pfx_devres_release_group+0x10/0x10<br /> hid_device_remove+0xf5/0x220<br /> device_release_driver_internal+0x371/0x540<br /> ? klist_put+0xf3/0x170<br /> bus_remove_device+0x1f1/0x3f0<br /> device_del+0x33f/0x8c0<br /> ? __pfx_device_del+0x10/0x10<br /> ? cleanup_srcu_struct+0x337/0x500<br /> hid_destroy_device+0xc8/0x130<br /> mousevsc_remove+0xd2/0x1d0 [hid_hyperv]<br /> device_release_driver_internal+0x371/0x540<br /> driver_detach+0xc5/0x180<br /> bus_remove_driver+0x11e/0x2a0<br /> ? __mutex_unlock_slowpath+0x160/0x5e0<br /> vmbus_driver_unregister+0x62/0x2b0 [hv_vmbus]<br /> ...<br /> <br /> And the issue seems to be that the corresponding devres group is not<br /> allocated. Normally, devres_open_group() is called from<br /> __hid_device_probe() but Hyper-V HID driver overrides &amp;#39;hid_dev-&gt;driver&amp;#39;<br /> with &amp;#39;mousevsc_hid_driver&amp;#39; stub and basically re-implements<br /> __hid_device_probe() by calling hid_parse() and hid_hw_start() but not<br /> devres_open_group(). hid_device_probe() does not call __hid_device_probe()<br /> for it. Later, when the driver is removed, hid_device_remove() calls<br /> devres_release_group() as it doesn&amp;#39;t check whether hdev-&gt;driver was<br /> initially overridden or not.<br /> <br /> The issue seems to be related to the commit 62c68e7cee33 ("HID: ensure<br /> timely release of driver-allocated resources") but the commit itself seems<br /> to be correct.<br /> <br /> Fix the issue by dropping the &amp;#39;hid_dev-&gt;driver&amp;#39; override and using<br /> hid_register_driver()/hid_unregister_driver() instead. Alternatively, it<br /> would have been possible to rely on the default handling but<br /> HID_CONNECT_DEFAULT implies HID_CONNECT_HIDRAW and it doesn&amp;#39;t seem to work<br /> for mousevsc as-is.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rcu/nocb: Fix missed RCU barrier on deoffloading<br /> <br /> Currently, running rcutorture test with torture_type=rcu fwd_progress=8<br /> n_barrier_cbs=8 nocbs_nthreads=8 nocbs_toggle=100 onoff_interval=60<br /> test_boost=2, will trigger the following warning:<br /> <br /> WARNING: CPU: 19 PID: 100 at kernel/rcu/tree_nocb.h:1061 rcu_nocb_rdp_deoffload+0x292/0x2a0<br /> RIP: 0010:rcu_nocb_rdp_deoffload+0x292/0x2a0<br /> Call Trace:<br /> <br /> ? __warn+0x7e/0x120<br /> ? rcu_nocb_rdp_deoffload+0x292/0x2a0<br /> ? report_bug+0x18e/0x1a0<br /> ? handle_bug+0x3d/0x70<br /> ? exc_invalid_op+0x18/0x70<br /> ? asm_exc_invalid_op+0x1a/0x20<br /> ? rcu_nocb_rdp_deoffload+0x292/0x2a0<br /> rcu_nocb_cpu_deoffload+0x70/0xa0<br /> rcu_nocb_toggle+0x136/0x1c0<br /> ? __pfx_rcu_nocb_toggle+0x10/0x10<br /> kthread+0xd1/0x100<br /> ? __pfx_kthread+0x10/0x10<br /> ret_from_fork+0x2f/0x50<br /> ? __pfx_kthread+0x10/0x10<br /> ret_from_fork_asm+0x1a/0x30<br /> <br /> <br /> CPU0 CPU2 CPU3<br /> //rcu_nocb_toggle //nocb_cb_wait //rcutorture<br /> <br /> // deoffload CPU1 // process CPU1&amp;#39;s rdp<br /> rcu_barrier()<br /> rcu_segcblist_entrain()<br /> rcu_segcblist_add_len(1);<br /> // len == 2<br /> // enqueue barrier<br /> // callback to CPU1&amp;#39;s<br /> // rdp-&gt;cblist<br /> rcu_do_batch()<br /> // invoke CPU1&amp;#39;s rdp-&gt;cblist<br /> // callback<br /> rcu_barrier_callback()<br /> rcu_barrier()<br /> mutex_lock(&amp;rcu_state.barrier_mutex);<br /> // still see len == 2<br /> // enqueue barrier callback<br /> // to CPU1&amp;#39;s rdp-&gt;cblist<br /> rcu_segcblist_entrain()<br /> rcu_segcblist_add_len(1);<br /> // len == 3<br /> // decrement len<br /> rcu_segcblist_add_len(-2);<br /> kthread_parkme()<br /> <br /> // CPU1&amp;#39;s rdp-&gt;cblist len == 1<br /> // Warn because there is<br /> // still a pending barrier<br /> // trigger warning<br /> WARN_ON_ONCE(rcu_segcblist_n_cbs(&amp;rdp-&gt;cblist));<br /> cpus_read_unlock();<br /> <br /> // wait CPU1 to comes online and<br /> // invoke barrier callback on<br /> // CPU1 rdp&amp;#39;s-&gt;cblist<br /> wait_for_completion(&amp;rcu_state.barrier_completion);<br /> // deoffload CPU4<br /> cpus_read_lock()<br /> rcu_barrier()<br /> mutex_lock(&amp;rcu_state.barrier_mutex);<br /> // block on barrier_mutex<br /> // wait rcu_barrier() on<br /> // CPU3 to unlock barrier_mutex<br /> // but CPU3 unlock barrier_mutex<br /> // need to wait CPU1 comes online<br /> // when CPU1 going online will block on cpus_write_lock<br /> <br /> The above scenario will not only trigger a WARN_ON_ONCE(), but also<br /> trigger a deadlock.<br /> <br /> Thanks to nocb locking, a second racing rcu_barrier() on an offline CPU<br /> will either observe the decremented callback counter down to 0 and spare<br /> the callback enqueue, or rcuo will observe the new callback and keep<br /> rdp-&gt;nocb_cb_sleep to false.<br /> <br /> Therefore check rdp-&gt;nocb_cb_sleep before parking to make sure no<br /> further rcu_barrier() is waiting on the rdp.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drivers: soc: xilinx: add the missing kfree in xlnx_add_cb_for_suspend()<br /> <br /> If we fail to allocate memory for cb_data by kmalloc, the memory<br /> allocation for eve_data is never freed, add the missing kfree()<br /> in the error handling path.