Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: rtw89: fix use-after-free in rtw89_core_tx_kick_off_and_wait()<br /> <br /> There is a bug observed when rtw89_core_tx_kick_off_and_wait() tries to<br /> access already freed skb_data:<br /> <br /> BUG: KFENCE: use-after-free write in rtw89_core_tx_kick_off_and_wait drivers/net/wireless/realtek/rtw89/core.c:1110<br /> <br /> CPU: 6 UID: 0 PID: 41377 Comm: kworker/u64:24 Not tainted 6.17.0-rc1+ #1 PREEMPT(lazy)<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS edk2-20250523-14.fc42 05/23/2025<br /> Workqueue: events_unbound cfg80211_wiphy_work [cfg80211]<br /> <br /> Use-after-free write at 0x0000000020309d9d (in kfence-#251):<br /> rtw89_core_tx_kick_off_and_wait drivers/net/wireless/realtek/rtw89/core.c:1110<br /> rtw89_core_scan_complete drivers/net/wireless/realtek/rtw89/core.c:5338<br /> rtw89_hw_scan_complete_cb drivers/net/wireless/realtek/rtw89/fw.c:7979<br /> rtw89_chanctx_proceed_cb drivers/net/wireless/realtek/rtw89/chan.c:3165<br /> rtw89_chanctx_proceed drivers/net/wireless/realtek/rtw89/chan.h:141<br /> rtw89_hw_scan_complete drivers/net/wireless/realtek/rtw89/fw.c:8012<br /> rtw89_mac_c2h_scanofld_rsp drivers/net/wireless/realtek/rtw89/mac.c:5059<br /> rtw89_fw_c2h_work drivers/net/wireless/realtek/rtw89/fw.c:6758<br /> process_one_work kernel/workqueue.c:3241<br /> worker_thread kernel/workqueue.c:3400<br /> kthread kernel/kthread.c:463<br /> ret_from_fork arch/x86/kernel/process.c:154<br /> ret_from_fork_asm arch/x86/entry/entry_64.S:258<br /> <br /> kfence-#251: 0x0000000056e2393d-0x000000009943cb62, size=232, cache=skbuff_head_cache<br /> <br /> allocated by task 41377 on cpu 6 at 77869.159548s (0.009551s ago):<br /> __alloc_skb net/core/skbuff.c:659<br /> __netdev_alloc_skb net/core/skbuff.c:734<br /> ieee80211_nullfunc_get net/mac80211/tx.c:5844<br /> rtw89_core_send_nullfunc drivers/net/wireless/realtek/rtw89/core.c:3431<br /> rtw89_core_scan_complete drivers/net/wireless/realtek/rtw89/core.c:5338<br /> rtw89_hw_scan_complete_cb drivers/net/wireless/realtek/rtw89/fw.c:7979<br /> rtw89_chanctx_proceed_cb drivers/net/wireless/realtek/rtw89/chan.c:3165<br /> rtw89_chanctx_proceed drivers/net/wireless/realtek/rtw89/chan.c:3194<br /> rtw89_hw_scan_complete drivers/net/wireless/realtek/rtw89/fw.c:8012<br /> rtw89_mac_c2h_scanofld_rsp drivers/net/wireless/realtek/rtw89/mac.c:5059<br /> rtw89_fw_c2h_work drivers/net/wireless/realtek/rtw89/fw.c:6758<br /> process_one_work kernel/workqueue.c:3241<br /> worker_thread kernel/workqueue.c:3400<br /> kthread kernel/kthread.c:463<br /> ret_from_fork arch/x86/kernel/process.c:154<br /> ret_from_fork_asm arch/x86/entry/entry_64.S:258<br /> <br /> freed by task 1045 on cpu 9 at 77869.168393s (0.001557s ago):<br /> ieee80211_tx_status_skb net/mac80211/status.c:1117<br /> rtw89_pci_release_txwd_skb drivers/net/wireless/realtek/rtw89/pci.c:564<br /> rtw89_pci_release_tx_skbs.isra.0 drivers/net/wireless/realtek/rtw89/pci.c:651<br /> rtw89_pci_release_tx drivers/net/wireless/realtek/rtw89/pci.c:676<br /> rtw89_pci_napi_poll drivers/net/wireless/realtek/rtw89/pci.c:4238<br /> __napi_poll net/core/dev.c:7495<br /> net_rx_action net/core/dev.c:7557 net/core/dev.c:7684<br /> handle_softirqs kernel/softirq.c:580<br /> do_softirq.part.0 kernel/softirq.c:480<br /> __local_bh_enable_ip kernel/softirq.c:407<br /> rtw89_pci_interrupt_threadfn drivers/net/wireless/realtek/rtw89/pci.c:927<br /> irq_thread_fn kernel/irq/manage.c:1133<br /> irq_thread kernel/irq/manage.c:1257<br /> kthread kernel/kthread.c:463<br /> ret_from_fork arch/x86/kernel/process.c:154<br /> ret_from_fork_asm arch/x86/entry/entry_64.S:258<br /> <br /> It is a consequence of a race between the waiting and the signaling side<br /> of the completion:<br /> <br /> Waiting thread Completing thread<br /> <br /> rtw89_core_tx_kick_off_and_wait()<br /> rcu_assign_pointer(skb_data-&gt;wait, wait)<br /> /* start waiting */<br /> wait_for_completion_timeout()<br /> rtw89_pci_tx_status()<br /> rtw89_core_tx_wait_complete()<br /> rcu_read_lock()<br /> /* signals completion and<br /> <br /> ---truncated---

This issue affects Apache Spark versions before 3.4.4, 3.5.2 and 4.0.0.<br /> <br /> <br /> <br /> Apache Spark versions before 4.0.0, 3.5.2 and 3.4.4 use an insecure default network encryption cipher for RPC communication between nodes.<br /> <br /> When spark.network.crypto.enabled is set to true (it is set to false by default), but spark.network.crypto.cipher is not explicitly configured, Spark defaults to AES in CTR mode (AES/CTR/NoPadding), which provides encryption without authentication.<br /> <br /> This vulnerability allows a man-in-the-middle attacker to modify encrypted RPC traffic undetected by flipping bits in ciphertext, potentially compromising heartbeat messages or application data and affecting the integrity of Spark workflows.<br /> <br /> <br /> To mitigate this issue, users should either configure spark.network.crypto.cipher to AES/GCM/NoPadding to enable authenticated encryption or<br /> <br /> enable SSL encryption by setting spark.ssl.enabled to true, which provides stronger transport security.

A path traversal issue exists in WXR9300BE6P series firmware versions prior to Ver.1.10. Arbitrary file may be altered by an administrative user who logs in to the affected product. Moreover, arbitrary OS command may be executed via some file alteration.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Check the helper function is valid in get_helper_proto<br /> <br /> kernel test robot reported verifier bug [1] where the helper func<br /> pointer could be NULL due to disabled config option.<br /> <br /> As Alexei suggested we could check on that in get_helper_proto<br /> directly. Marking tail_call helper func with BPF_PTR_POISON,<br /> because it is unused by design.<br /> <br /> [1] https://lore.kernel.org/oe-lkp/202507160818.68358831-lkp@intel.com

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: ath11k: fix NULL dereference in ath11k_qmi_m3_load()<br /> <br /> If ab-&gt;fw.m3_data points to data, then fw pointer remains null.<br /> Further, if m3_mem is not allocated, then fw is dereferenced to be<br /> passed to ath11k_err function.<br /> <br /> Replace fw-&gt;size by m3_len.<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with SVACE.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm: swap: check for stable address space before operating on the VMA<br /> <br /> It is possible to hit a zero entry while traversing the vmas in unuse_mm()<br /> called from swapoff path and accessing it causes the OOPS:<br /> <br /> Unable to handle kernel NULL pointer dereference at virtual address<br /> 0000000000000446--&gt; Loading the memory from offset 0x40 on the<br /> XA_ZERO_ENTRY as address.<br /> Mem abort info:<br /> ESR = 0x0000000096000005<br /> EC = 0x25: DABT (current EL), IL = 32 bits<br /> SET = 0, FnV = 0<br /> EA = 0, S1PTW = 0<br /> FSC = 0x05: level 1 translation fault<br /> <br /> The issue is manifested from the below race between the fork() on a<br /> process and swapoff:<br /> fork(dup_mmap()) swapoff(unuse_mm)<br /> --------------- -----------------<br /> 1) Identical mtree is built using<br /> __mt_dup().<br /> <br /> 2) copy_pte_range()--&gt;<br /> copy_nonpresent_pte():<br /> The dst mm is added into the<br /> mmlist to be visible to the<br /> swapoff operation.<br /> <br /> 3) Fatal signal is sent to the parent<br /> process(which is the current during the<br /> fork) thus skip the duplication of the<br /> vmas and mark the vma range with<br /> XA_ZERO_ENTRY as a marker for this process<br /> that helps during exit_mmap().<br /> <br /> 4) swapoff is tried on the<br /> &amp;#39;mm&amp;#39; added to the &amp;#39;mmlist&amp;#39; as<br /> part of the 2.<br /> <br /> 5) unuse_mm(), that iterates<br /> through the vma&amp;#39;s of this &amp;#39;mm&amp;#39;<br /> will hit the non-NULL zero entry<br /> and operating on this zero entry<br /> as a vma is resulting into the<br /> oops.<br /> <br /> The proper fix would be around not exposing this partially-valid tree to<br /> others when droping the mmap lock, which is being solved with [1]. A<br /> simpler solution would be checking for MMF_UNSTABLE, as it is set if<br /> mm_struct is not fully initialized in dup_mmap().<br /> <br /> Thanks to Liam/Lorenzo/David for all the suggestions in fixing this<br /> issue.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: rc: fix races with imon_disconnect()<br /> <br /> Syzbot reports a KASAN issue as below:<br /> BUG: KASAN: use-after-free in __create_pipe include/linux/usb.h:1945 [inline]<br /> BUG: KASAN: use-after-free in send_packet+0xa2d/0xbc0 drivers/media/rc/imon.c:627<br /> Read of size 4 at addr ffff8880256fb000 by task syz-executor314/4465<br /> <br /> CPU: 2 PID: 4465 Comm: syz-executor314 Not tainted 6.0.0-rc1-syzkaller #0<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.14.0-2 04/01/2014<br /> Call Trace:<br /> <br /> __dump_stack lib/dump_stack.c:88 [inline]<br /> dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106<br /> print_address_description mm/kasan/report.c:317 [inline]<br /> print_report.cold+0x2ba/0x6e9 mm/kasan/report.c:433<br /> kasan_report+0xb1/0x1e0 mm/kasan/report.c:495<br /> __create_pipe include/linux/usb.h:1945 [inline]<br /> send_packet+0xa2d/0xbc0 drivers/media/rc/imon.c:627<br /> vfd_write+0x2d9/0x550 drivers/media/rc/imon.c:991<br /> vfs_write+0x2d7/0xdd0 fs/read_write.c:576<br /> ksys_write+0x127/0x250 fs/read_write.c:631<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> The iMON driver improperly releases the usb_device reference in<br /> imon_disconnect without coordinating with active users of the<br /> device.<br /> <br /> Specifically, the fields usbdev_intf0 and usbdev_intf1 are not<br /> protected by the users counter (ictx-&gt;users). During probe,<br /> imon_init_intf0 or imon_init_intf1 increments the usb_device<br /> reference count depending on the interface. However, during<br /> disconnect, usb_put_dev is called unconditionally, regardless of<br /> actual usage.<br /> <br /> As a result, if vfd_write or other operations are still in<br /> progress after disconnect, this can lead to a use-after-free of<br /> the usb_device pointer.<br /> <br /> Thread 1 vfd_write Thread 2 imon_disconnect<br /> ...<br /> if<br /> usb_put_dev(ictx-&gt;usbdev_intf0)<br /> else<br /> usb_put_dev(ictx-&gt;usbdev_intf1)<br /> ...<br /> while<br /> send_packet<br /> if<br /> pipe = usb_sndintpipe(<br /> ictx-&gt;usbdev_intf0) UAF<br /> else<br /> pipe = usb_sndctrlpipe(<br /> ictx-&gt;usbdev_intf0, 0) UAF<br /> <br /> Guard access to usbdev_intf0 and usbdev_intf1 after disconnect by<br /> checking ictx-&gt;disconnected in all writer paths. Add early return<br /> with -ENODEV in send_packet(), vfd_write(), lcd_write() and<br /> display_open() if the device is no longer present.<br /> <br /> Set and read ictx-&gt;disconnected under ictx-&gt;lock to ensure memory<br /> synchronization. Acquire the lock in imon_disconnect() before setting<br /> the flag to synchronize with any ongoing operations.<br /> <br /> Ensure writers exit early and safely after disconnect before the USB<br /> core proceeds with cleanup.<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with Syzkaller.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: tuner: xc5000: Fix use-after-free in xc5000_release<br /> <br /> The original code uses cancel_delayed_work() in xc5000_release(), which<br /> does not guarantee that the delayed work item timer_sleep has fully<br /> completed if it was already running. This leads to use-after-free scenarios<br /> where xc5000_release() may free the xc5000_priv while timer_sleep is still<br /> active and attempts to dereference the xc5000_priv.<br /> <br /> A typical race condition is illustrated below:<br /> <br /> CPU 0 (release thread) | CPU 1 (delayed work callback)<br /> xc5000_release() | xc5000_do_timer_sleep()<br /> cancel_delayed_work() |<br /> hybrid_tuner_release_state(priv) |<br /> kfree(priv) |<br /> | priv = container_of() // UAF<br /> <br /> Replace cancel_delayed_work() with cancel_delayed_work_sync() to ensure<br /> that the timer_sleep is properly canceled before the xc5000_priv memory<br /> is deallocated.<br /> <br /> A deadlock concern was considered: xc5000_release() is called in a process<br /> context and is not holding any locks that the timer_sleep work item might<br /> also need. Therefore, the use of the _sync() variant is safe here.<br /> <br /> This bug was initially identified through static analysis.<br /> <br /> [hverkuil: fix typo in Subject: tunner -&gt; tuner]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: i2c: tc358743: Fix use-after-free bugs caused by orphan timer in probe<br /> <br /> The state-&gt;timer is a cyclic timer that schedules work_i2c_poll and<br /> delayed_work_enable_hotplug, while rearming itself. Using timer_delete()<br /> fails to guarantee the timer isn&amp;#39;t still running when destroyed, similarly<br /> cancel_delayed_work() cannot ensure delayed_work_enable_hotplug has<br /> terminated if already executing. During probe failure after timer<br /> initialization, these may continue running as orphans and reference the<br /> already-freed tc358743_state object through tc358743_irq_poll_timer.<br /> <br /> The following is the trace captured by KASAN.<br /> <br /> BUG: KASAN: slab-use-after-free in __run_timer_base.part.0+0x7d7/0x8c0<br /> Write of size 8 at addr ffff88800ded83c8 by task swapper/1/0<br /> ...<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x55/0x70<br /> print_report+0xcf/0x610<br /> ? __pfx_sched_balance_find_src_group+0x10/0x10<br /> ? __run_timer_base.part.0+0x7d7/0x8c0<br /> kasan_report+0xb8/0xf0<br /> ? __run_timer_base.part.0+0x7d7/0x8c0<br /> __run_timer_base.part.0+0x7d7/0x8c0<br /> ? rcu_sched_clock_irq+0xb06/0x27d0<br /> ? __pfx___run_timer_base.part.0+0x10/0x10<br /> ? try_to_wake_up+0xb15/0x1960<br /> ? tmigr_update_events+0x280/0x740<br /> ? _raw_spin_lock_irq+0x80/0xe0<br /> ? __pfx__raw_spin_lock_irq+0x10/0x10<br /> tmigr_handle_remote_up+0x603/0x7e0<br /> ? __pfx_tmigr_handle_remote_up+0x10/0x10<br /> ? sched_balance_trigger+0x98/0x9f0<br /> ? sched_tick+0x221/0x5a0<br /> ? _raw_spin_lock_irq+0x80/0xe0<br /> ? __pfx__raw_spin_lock_irq+0x10/0x10<br /> ? tick_nohz_handler+0x339/0x440<br /> ? __pfx_tmigr_handle_remote_up+0x10/0x10<br /> __walk_groups.isra.0+0x42/0x150<br /> tmigr_handle_remote+0x1f4/0x2e0<br /> ? __pfx_tmigr_handle_remote+0x10/0x10<br /> ? ktime_get+0x60/0x140<br /> ? lapic_next_event+0x11/0x20<br /> ? clockevents_program_event+0x1d4/0x2a0<br /> ? hrtimer_interrupt+0x322/0x780<br /> handle_softirqs+0x16a/0x550<br /> irq_exit_rcu+0xaf/0xe0<br /> sysvec_apic_timer_interrupt+0x70/0x80<br /> <br /> ...<br /> <br /> Allocated by task 141:<br /> kasan_save_stack+0x24/0x50<br /> kasan_save_track+0x14/0x30<br /> __kasan_kmalloc+0x7f/0x90<br /> __kmalloc_node_track_caller_noprof+0x198/0x430<br /> devm_kmalloc+0x7b/0x1e0<br /> tc358743_probe+0xb7/0x610 i2c_device_probe+0x51d/0x880<br /> really_probe+0x1ca/0x5c0<br /> __driver_probe_device+0x248/0x310<br /> driver_probe_device+0x44/0x120<br /> __device_attach_driver+0x174/0x220<br /> bus_for_each_drv+0x100/0x190<br /> __device_attach+0x206/0x370<br /> bus_probe_device+0x123/0x170<br /> device_add+0xd25/0x1470<br /> i2c_new_client_device+0x7a0/0xcd0<br /> do_one_initcall+0x89/0x300<br /> do_init_module+0x29d/0x7f0<br /> load_module+0x4f48/0x69e0<br /> init_module_from_file+0xe4/0x150<br /> idempotent_init_module+0x320/0x670<br /> __x64_sys_finit_module+0xbd/0x120<br /> do_syscall_64+0xac/0x280<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> Freed by task 141:<br /> kasan_save_stack+0x24/0x50<br /> kasan_save_track+0x14/0x30<br /> kasan_save_free_info+0x3a/0x60<br /> __kasan_slab_free+0x3f/0x50<br /> kfree+0x137/0x370<br /> release_nodes+0xa4/0x100<br /> devres_release_group+0x1b2/0x380<br /> i2c_device_probe+0x694/0x880<br /> really_probe+0x1ca/0x5c0<br /> __driver_probe_device+0x248/0x310<br /> driver_probe_device+0x44/0x120<br /> __device_attach_driver+0x174/0x220<br /> bus_for_each_drv+0x100/0x190<br /> __device_attach+0x206/0x370<br /> bus_probe_device+0x123/0x170<br /> device_add+0xd25/0x1470<br /> i2c_new_client_device+0x7a0/0xcd0<br /> do_one_initcall+0x89/0x300<br /> do_init_module+0x29d/0x7f0<br /> load_module+0x4f48/0x69e0<br /> init_module_from_file+0xe4/0x150<br /> idempotent_init_module+0x320/0x670<br /> __x64_sys_finit_module+0xbd/0x120<br /> do_syscall_64+0xac/0x280<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> ...<br /> <br /> Replace timer_delete() with timer_delete_sync() and cancel_delayed_work()<br /> with cancel_delayed_work_sync() to ensure proper termination of timer and<br /> work items before resource cleanup.<br /> <br /> This bug was initially identified through static analysis. For reproduction<br /> and testing, I created a functional emulation of the tc358743 device via a<br /> kernel module and introduced faults through the debugfs interface.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: b2c2: Fix use-after-free causing by irq_check_work in flexcop_pci_remove<br /> <br /> The original code uses cancel_delayed_work() in flexcop_pci_remove(), which<br /> does not guarantee that the delayed work item irq_check_work has fully<br /> completed if it was already running. This leads to use-after-free scenarios<br /> where flexcop_pci_remove() may free the flexcop_device while irq_check_work<br /> is still active and attempts to dereference the device.<br /> <br /> A typical race condition is illustrated below:<br /> <br /> CPU 0 (remove) | CPU 1 (delayed work callback)<br /> flexcop_pci_remove() | flexcop_pci_irq_check_work()<br /> cancel_delayed_work() |<br /> flexcop_device_kfree(fc_pci-&gt;fc_dev) |<br /> | fc = fc_pci-&gt;fc_dev; // UAF<br /> <br /> This is confirmed by a KASAN report:<br /> <br /> ==================================================================<br /> BUG: KASAN: slab-use-after-free in __run_timer_base.part.0+0x7d7/0x8c0<br /> Write of size 8 at addr ffff8880093aa8c8 by task bash/135<br /> ...<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x55/0x70<br /> print_report+0xcf/0x610<br /> ? __run_timer_base.part.0+0x7d7/0x8c0<br /> kasan_report+0xb8/0xf0<br /> ? __run_timer_base.part.0+0x7d7/0x8c0<br /> __run_timer_base.part.0+0x7d7/0x8c0<br /> ? __pfx___run_timer_base.part.0+0x10/0x10<br /> ? __pfx_read_tsc+0x10/0x10<br /> ? ktime_get+0x60/0x140<br /> ? lapic_next_event+0x11/0x20<br /> ? clockevents_program_event+0x1d4/0x2a0<br /> run_timer_softirq+0xd1/0x190<br /> handle_softirqs+0x16a/0x550<br /> irq_exit_rcu+0xaf/0xe0<br /> sysvec_apic_timer_interrupt+0x70/0x80<br /> <br /> ...<br /> <br /> Allocated by task 1:<br /> kasan_save_stack+0x24/0x50<br /> kasan_save_track+0x14/0x30<br /> __kasan_kmalloc+0x7f/0x90<br /> __kmalloc_noprof+0x1be/0x460<br /> flexcop_device_kmalloc+0x54/0xe0<br /> flexcop_pci_probe+0x1f/0x9d0<br /> local_pci_probe+0xdc/0x190<br /> pci_device_probe+0x2fe/0x470<br /> really_probe+0x1ca/0x5c0<br /> __driver_probe_device+0x248/0x310<br /> driver_probe_device+0x44/0x120<br /> __driver_attach+0xd2/0x310<br /> bus_for_each_dev+0xed/0x170<br /> bus_add_driver+0x208/0x500<br /> driver_register+0x132/0x460<br /> do_one_initcall+0x89/0x300<br /> kernel_init_freeable+0x40d/0x720<br /> kernel_init+0x1a/0x150<br /> ret_from_fork+0x10c/0x1a0<br /> ret_from_fork_asm+0x1a/0x30<br /> <br /> Freed by task 135:<br /> kasan_save_stack+0x24/0x50<br /> kasan_save_track+0x14/0x30<br /> kasan_save_free_info+0x3a/0x60<br /> __kasan_slab_free+0x3f/0x50<br /> kfree+0x137/0x370<br /> flexcop_device_kfree+0x32/0x50<br /> pci_device_remove+0xa6/0x1d0<br /> device_release_driver_internal+0xf8/0x210<br /> pci_stop_bus_device+0x105/0x150<br /> pci_stop_and_remove_bus_device_locked+0x15/0x30<br /> remove_store+0xcc/0xe0<br /> kernfs_fop_write_iter+0x2c3/0x440<br /> vfs_write+0x871/0xd70<br /> ksys_write+0xee/0x1c0<br /> do_syscall_64+0xac/0x280<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> ...<br /> <br /> Replace cancel_delayed_work() with cancel_delayed_work_sync() to ensure<br /> that the delayed work item is properly canceled and any executing delayed<br /> work has finished before the device memory is deallocated.<br /> <br /> This bug was initially identified through static analysis. To reproduce<br /> and test it, I simulated the B2C2 FlexCop PCI device in QEMU and introduced<br /> artificial delays within the flexcop_pci_irq_check_work() function to<br /> increase the likelihood of triggering the bug.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: usb-audio: fix race condition to UAF in snd_usbmidi_free<br /> <br /> The previous commit 0718a78f6a9f ("ALSA: usb-audio: Kill timer properly at<br /> removal") patched a UAF issue caused by the error timer.<br /> <br /> However, because the error timer kill added in this patch occurs after the<br /> endpoint delete, a race condition to UAF still occurs, albeit rarely.<br /> <br /> Additionally, since kill-cleanup for urb is also missing, freed memory can<br /> be accessed in interrupt context related to urb, which can cause UAF.<br /> <br /> Therefore, to prevent this, error timer and urb must be killed before<br /> freeing the heap memory.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> can: etas_es58x: populate ndo_change_mtu() to prevent buffer overflow<br /> <br /> Sending an PF_PACKET allows to bypass the CAN framework logic and to<br /> directly reach the xmit() function of a CAN driver. The only check<br /> which is performed by the PF_PACKET framework is to make sure that<br /> skb-&gt;len fits the interface&amp;#39;s MTU.<br /> <br /> Unfortunately, because the etas_es58x driver does not populate its<br /> net_device_ops-&gt;ndo_change_mtu(), it is possible for an attacker to<br /> configure an invalid MTU by doing, for example:<br /> <br /> $ ip link set can0 mtu 9999<br /> <br /> After doing so, the attacker could open a PF_PACKET socket using the<br /> ETH_P_CANXL protocol:<br /> <br /> socket(PF_PACKET, SOCK_RAW, htons(ETH_P_CANXL));<br /> <br /> to inject a malicious CAN XL frames. For example:<br /> <br /> struct canxl_frame frame = {<br /> .flags = 0xff,<br /> .len = 2048,<br /> };<br /> <br /> The CAN drivers&amp;#39; xmit() function are calling can_dev_dropped_skb() to<br /> check that the skb is valid, unfortunately under above conditions, the<br /> malicious packet is able to go through can_dev_dropped_skb() checks:<br /> <br /> 1. the skb-&gt;protocol is set to ETH_P_CANXL which is valid (the<br /> function does not check the actual device capabilities).<br /> <br /> 2. the length is a valid CAN XL length.<br /> <br /> And so, es58x_start_xmit() receives a CAN XL frame which it is not<br /> able to correctly handle and will thus misinterpret it as a CAN(FD)<br /> frame.<br /> <br /> This can result in a buffer overflow. For example, using the es581.4<br /> variant, the frame will be dispatched to es581_4_tx_can_msg(), go<br /> through the last check at the beginning of this function:<br /> <br /> if (can_is_canfd_skb(skb))<br /> return -EMSGSIZE;<br /> <br /> and reach this line:<br /> <br /> memcpy(tx_can_msg-&gt;data, cf-&gt;data, cf-&gt;len);<br /> <br /> Here, cf-&gt;len corresponds to the flags field of the CAN XL frame. In<br /> our previous example, we set canxl_frame-&gt;flags to 0xff. Because the<br /> maximum expected length is 8, a buffer overflow of 247 bytes occurs!<br /> <br /> Populate net_device_ops-&gt;ndo_change_mtu() to ensure that the<br /> interface&amp;#39;s MTU can not be set to anything bigger than CAN_MTU or<br /> CANFD_MTU (depending on the device capabilities). By fixing the root<br /> cause, this prevents the buffer overflow.