Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: gadget: f_tcm: synchronize delayed set_alt with teardown<br /> <br /> The f_tcm set_alt() path defers endpoint setup to a work item and<br /> completes the delayed status response from process context. The delayed<br /> work uses f_tcm private state and may complete the setup request after<br /> disconnect or function teardown has already moved on.<br /> <br /> Cancel and drain the delayed set_alt work when the function is unbound or<br /> freed. For disable paths, which are reached under the composite device<br /> lock, use a small state machine and a non-sleeping cancellation path<br /> instead of cancel_work_sync(). If the work is already running, mark it<br /> cancelled and let the worker own the cleanup; otherwise tcm_disable() can<br /> cancel the queued work and clean up immediately.<br /> <br /> Also serialize the final delayed-status completion with the cancellation<br /> check while holding the composite device lock. This prevents a disconnect<br /> from clearing delayed_status while the worker is about to complete the<br /> control request.<br /> <br /> Validation reproduced this kernel report:<br /> BUG: KASAN: slab-use-after-free in tcm_delayed_set_alt+0x6c/0xef0<br /> <br /> Call Trace:<br /> <br /> dump_stack_lvl+0x66/0xa0<br /> print_report+0xce/0x630<br /> ? tcm_delayed_set_alt+0x6c/0xef0<br /> ? srso_alias_return_thunk+0x5/0xfbef5<br /> ? __virt_addr_valid+0x188/0x320<br /> ? tcm_delayed_set_alt+0x6c/0xef0<br /> kasan_report+0xe0/0x110<br /> ? tcm_delayed_set_alt+0x6c/0xef0<br /> tcm_delayed_set_alt+0x6c/0xef0<br /> ? __pfx_tcm_delayed_set_alt+0x10/0x10<br /> ? process_one_work+0x4cb/0xb90<br /> ? rcu_is_watching+0x20/0x50<br /> ? tcm_delayed_set_alt+0x9/0xef0<br /> process_one_work+0x4d7/0xb90<br /> ? __pfx_process_one_work+0x10/0x10<br /> ? srso_alias_return_thunk+0x5/0xfbef5<br /> ? __list_add_valid_or_report+0x37/0xf0<br /> ? __pfx_tcm_delayed_set_alt+0x10/0x10<br /> ? srso_alias_return_thunk+0x5/0xfbef5<br /> worker_thread+0x2d8/0x570<br /> ? __pfx_worker_thread+0x10/0x10<br /> kthread+0x1ad/0x1f0<br /> ? __pfx_kthread+0x10/0x10<br /> ret_from_fork+0x3c9/0x540<br /> ? __pfx_ret_from_fork+0x10/0x10<br /> ? srso_alias_return_thunk+0x5/0xfbef5<br /> ? __switch_to+0x2e9/0x730<br /> ? __pfx_kthread+0x10/0x10<br /> ret_from_fork_asm+0x1a/0x30<br /> <br /> <br /> Allocated by task 544:<br /> kasan_save_stack+0x33/0x60<br /> kasan_save_track+0x14/0x30<br /> __kasan_kmalloc+0x8f/0xa0<br /> tcm_alloc+0x68/0x180<br /> usb_get_function+0x36/0x60<br /> config_usb_cfg_link+0x125/0x1b0<br /> configfs_symlink+0x322/0x890<br /> vfs_symlink+0xc2/0x270<br /> filename_symlinkat+0x295/0x2f0<br /> __x64_sys_symlinkat+0x62/0x90<br /> do_syscall_64+0x115/0x6a0<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> Freed by task 661:<br /> kasan_save_stack+0x33/0x60<br /> kasan_save_track+0x14/0x30<br /> kasan_save_free_info+0x3b/0x60<br /> __kasan_slab_free+0x43/0x70<br /> kfree+0x2f9/0x530<br /> config_usb_cfg_unlink+0x173/0x1e0<br /> configfs_unlink+0x1fa/0x340<br /> vfs_unlink+0x15c/0x510<br /> filename_unlinkat+0x2ba/0x450<br /> __x64_sys_unlinkat+0x63/0x90<br /> do_syscall_64+0x115/0x6a0<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: musb: omap2430: Do not put borrowed of_node in probe<br /> <br /> omap2430_probe() stores pdev-&gt;dev.of_node in a local np variable. This is<br /> a borrowed pointer and the probe function does not take a reference to<br /> it.<br /> <br /> The success and error paths nevertheless call of_node_put(np). This drops<br /> a reference that is owned by the platform device, and can leave<br /> pdev-&gt;dev.of_node with an unbalanced reference count.<br /> <br /> Do not put the borrowed platform device node from omap2430_probe().<br /> References taken for the child MUSB device are handled by the device core,<br /> and the ctrl-module phandle reference is still released separately.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> watchdog: airoha: Prevent division by zero when clock frequency is zero<br /> <br /> clk_get_rate() can return 0 when the clock provider is not properly<br /> configured or the clock is unmanaged. The driver uses wdt_freq as a<br /> divisor directly in airoha_wdt_probe() to compute max_timeout and in<br /> airoha_wdt_get_timeleft() to compute the remaining time, which results<br /> in a division by zero.<br /> <br /> Add a check for wdt_freq == 0 in probe and return -EINVAL with<br /> dev_err_probe() to prevent the division by zero and provide a<br /> diagnostic message.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> hwmon: (nzxt-kraken3) Stop device IO before calling hid_hw_stop<br /> <br /> Calling hid_hw_stop() does not stop the device IO.<br /> This results in a race condition between hid_input_report() and the point<br /> immediately following the execution of hid_device_io_start() within<br /> the driver probe function. If the probe operation fails after "io start"<br /> has been initiated, this race condition will result in a UAF vulnerability.<br /> <br /> Fix the problem by calling hid_device_io_stop() before calling<br /> hid_hw_stop().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> watchdog: pretimeout: Fix UAF in watchdog_unregister_governor()<br /> <br /> When a watchdog governor is unregistered, it updates existing watchdog<br /> devices that were using this governor by falling back to `default_gov`.<br /> <br /> If the governor being unregistered is currently set as `default_gov`,<br /> the `default_gov` is never cleared. This leads to 2 use-after-free<br /> issues:<br /> 1. New watchdog devices registered after this point will inherit the<br /> dangling `default_gov`.<br /> 2. Existing watchdog devices using the unregistered governor will have<br /> their `wdd-&gt;gov` reassigned to the dangling `default_gov`.<br /> <br /> Fix the UAF by clearing `default_gov` if it matches the governor being<br /> unregistered.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> hwmon: (nzxt-smart2) Stop device IO before calling hid_hw_stop<br /> <br /> Calling hid_hw_stop() does not stop the device IO.<br /> This results in a race condition between hid_input_report() and the point<br /> immediately following the execution of hid_device_io_start() within<br /> the driver probe function. If the probe operation fails after "io start"<br /> has been initiated, this race condition will result in a UAF vulnerability.<br /> <br /> Fix the problem by calling hid_device_io_stop() before calling<br /> hid_hw_stop().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> hwmon: (corsair-cpro) Stop device IO before calling hid_hw_stop<br /> <br /> Calling hid_hw_stop() does not stop the device IO.<br /> This results in a race condition between hid_input_report() and the point<br /> immediately following the execution of hid_device_io_start() within<br /> the driver probe function. If the probe operation fails after "io start"<br /> has been initiated, this race condition will result in a UAF vulnerability.<br /> <br /> Fix the problem by calling hid_device_io_stop() before calling<br /> hid_hw_stop().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> hwmon: (corsair-psu) Stop device IO before calling hid_hw_stop<br /> <br /> hid_hw_stop() does not stop the device IO.<br /> <br /> This results in a race condition between hid_input_report() and the point<br /> immediately following the execution of hid_device_io_start() within<br /> corsairpsu_probe(). If the probe operation fails after "io start" has<br /> been initiated, this race condition will result in a uaf vulnerability<br /> [1].<br /> <br /> CPU0 CPU1<br /> ==== ====<br /> corsairpsu_probe()<br /> hid_device_io_start()<br /> ... unlock driver_input_lock<br /> hid_hw_stop()<br /> kfree(hidraw) __hid_input_report()<br /> ... acquire driver_input_lock<br /> hid_report_raw_event()<br /> hidraw_report_event()<br /> ... access hidraw&amp;#39;s list_lock // trigger uaf<br /> <br /> Consequently, when corsairpsu_probe() fails and hid_hw_stop() needs to<br /> be executed, the io_started flag is first cleared while holding the<br /> driver_input_lock to prevent potential race conditions involving input<br /> reports.<br /> <br /> [1]<br /> BUG: KASAN: slab-use-after-free in rt_spin_lock+0x83/0x400 kernel/locking/spinlock_rt.c:56<br /> Call Trace:<br /> hidraw_report_event+0x5d/0x3a0 drivers/hid/hidraw.c:577<br /> hid_report_raw_event+0x311/0x1730 drivers/hid/hid-core.c:2076<br /> __hid_input_report drivers/hid/hid-core.c:2152 [inline]<br /> hid_input_report+0x44e/0x580 drivers/hid/hid-core.c:2174<br /> hid_irq_in+0x47e/0x6d0 drivers/hid/usbhid/hid-core.c:286<br /> __usb_hcd_giveback_urb+0x3b3/0x5e0 drivers/usb/core/hcd.c:1657<br /> dummy_timer+0x8a9/0x47d0 drivers/usb/gadget/udc/dummy_hcd.c:2005<br /> <br /> Allocated by task 10:<br /> hidraw_connect+0x57/0x430 drivers/hid/hidraw.c:606<br /> hid_connect+0x5bf/0x19d0 drivers/hid/hid-core.c:2277<br /> hid_hw_start+0xa8/0x120 drivers/hid/hid-core.c:2387<br /> corsairpsu_probe+0xd9/0x3c0 drivers/hwmon/corsair-psu.c:782<br /> <br /> Freed by task 10:<br /> hidraw_disconnect+0x4f/0x60 drivers/hid/hidraw.c:662<br /> hid_disconnect drivers/hid/hid-core.c:2362 [inline]<br /> hid_hw_stop+0x101/0x1e0 drivers/hid/hid-core.c:2407<br /> corsairpsu_probe+0x327/0x3c0 drivers/hwmon/corsair-psu.c:826<br /> <br /> Fix the problem by calling hid_device_io_stop() before calling<br /> hid_hw_stop().<br /> <br /> [groeck: Updated subject and description;<br /> call hid_device_io_stop() only if IO has been started]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: ath11k: fix NULL pointer dereference in ath11k_hal_srng_access_begin<br /> <br /> In ATH11K_QMI_EVENT_FW_READY, ATH11K_FLAG_REGISTERED is set<br /> unconditionally even when ath11k_core_qmi_firmware_ready() fails.<br /> This leaves the driver in an inconsistent state where<br /> initialization is considered complete although the firmware ready<br /> handling did not finish successfully. During the subsequent SSR,<br /> the driver enters the restart path based on this incorrect state<br /> and dereferences uninitialized srng members, resulting in a NULL<br /> pointer dereference.<br /> <br /> Call trace:<br /> ath11k_hal_srng_access_begin+0xc/0x60 [ath11k] (P)<br /> ath11k_ce_cleanup_pipes+0x17c/0x180 [ath11k]<br /> ath11k_core_restart+0x40/0x168 [ath11k]<br /> <br /> Fix this by:<br /> - skipping firmware_ready if ATH11K_FLAG_REGISTERED is already set<br /> - setting ATH11K_FLAG_REGISTERED only when firmware_ready succeeds<br /> - setting ATH11K_FLAG_QMI_FAIL and aborting the FW_READY handling<br /> on error<br /> <br /> Tested-on: WCN6750 hw1.0 AHB WLAN.MSL.2.0.c2-00204-QCAMSLSWPLZ-1

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: ath9k: hif_usb: don&amp;#39;t dereference hif_dev after re-arming firmware request<br /> <br /> ath9k_hif_request_firmware() re-arms an asynchronous firmware load via<br /> request_firmware_nowait(), passing hif_dev as the completion context, and<br /> then still dereferences hif_dev:<br /> <br /> dev_info(&amp;hif_dev-&gt;udev-&gt;dev, "ath9k_htc: Firmware %s requested\n",<br /> hif_dev-&gt;fw_name);<br /> <br /> The re-armed callback ath9k_hif_usb_firmware_cb() runs on the "events"<br /> workqueue and, when the firmware is missing, walks the retry chain into<br /> ath9k_hif_usb_firmware_fail() -&gt; complete_all(&amp;hif_dev-&gt;fw_done). That<br /> releases the wait_for_completion(&amp;hif_dev-&gt;fw_done) in a concurrent<br /> ath9k_hif_usb_disconnect(), which then kfree()s hif_dev. The trailing<br /> dev_info() in the frame that re-armed the request can therefore read freed<br /> memory (hif_dev-&gt;udev, the first field of struct hif_device_usb):<br /> <br /> BUG: KASAN: slab-use-after-free in ath9k_hif_request_firmware<br /> Read of size 8 ... by task kworker/...<br /> ath9k_hif_request_firmware<br /> ath9k_hif_usb_firmware_cb drivers/net/wireless/ath/ath9k/hif_usb.c:1247<br /> request_firmware_work_func<br /> Allocated by ...:<br /> ath9k_hif_usb_probe drivers/net/wireless/ath/ath9k/hif_usb.c<br /> Freed by ...:<br /> ath9k_hif_usb_disconnect -&gt; kfree drivers/net/wireless/ath/ath9k/hif_usb.c<br /> <br /> The fw_done barrier only makes disconnect wait for the firmware chain to<br /> *terminate*; it does not protect the outer ath9k_hif_request_firmware()<br /> frame that re-armed the request and keeps touching hif_dev afterwards.<br /> <br /> Drop the post-request dev_info(): it is the only use of hif_dev after the<br /> async request is armed, and it is purely informational (the dev_err() on the<br /> failure path runs only when request_firmware_nowait() did not arm a callback,<br /> so hif_dev is still alive there).<br /> <br /> This was first reported by syzbot as a single, non-reproduced crash that was<br /> later auto-obsoleted, and was independently rediscovered by the reFuzz fuzzer,<br /> which produced a C reproducer (USB-gadget connect/disconnect of an ath9k_htc<br /> device whose firmware download fails). The vulnerable code is unchanged and<br /> still present in v7.1-rc6, where the slab-use-after-free reproduces under KASAN<br /> once the (sub-microsecond) race window is widened.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: carl9170: bound memcpy length in cmd callback to prevent OOB read<br /> <br /> When the firmware sends a command response with a length mismatch,<br /> carl9170_cmd_callback() logs the mismatch and calls carl9170_restart()<br /> but then falls through to memcpy(ar-&gt;readbuf, buffer + 4, len - 4).<br /> Since len comes from the firmware and can exceed ar-&gt;readlen, this<br /> copies more data than the readbuf was allocated for.<br /> <br /> Bound the memcpy to min(len - 4, ar-&gt;readlen) so that the response<br /> is still completed -- avoiding repeated restarts from queued garbage --<br /> while preventing an overread past the response buffer.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: ath6kl: fix OOB read from firmware IE lengths in connect event<br /> <br /> The firmware-controlled beacon_ie_len, assoc_req_len, and assoc_resp_len<br /> fields in ath6kl_wmi_connect_event_rx() are not validated against the<br /> buffer length. Their sum (up to 765) can exceed the actual WMI event<br /> data, causing out-of-bounds reads during IE parsing and state corruption<br /> of wmi-&gt;is_wmm_enabled.<br /> <br /> Add a check that the total IE length fits within the buffer.