Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: gadget: u_ether: Fix NULL pointer deref in eth_get_drvinfo<br /> <br /> Commit ec35c1969650 ("usb: gadget: f_ncm: Fix net_device lifecycle with<br /> device_move") reparents the gadget device to /sys/devices/virtual during<br /> unbind, clearing the gadget pointer. If the userspace tool queries on<br /> the surviving interface during this detached window, this leads to a<br /> NULL pointer dereference.<br /> <br /> Unable to handle kernel NULL pointer dereference<br /> Call trace:<br /> eth_get_drvinfo+0x50/0x90<br /> ethtool_get_drvinfo+0x5c/0x1f0<br /> __dev_ethtool+0xaec/0x1fe0<br /> dev_ethtool+0x134/0x2e0<br /> dev_ioctl+0x338/0x560<br /> <br /> Add a NULL check for dev-&gt;gadget in eth_get_drvinfo(). When detached,<br /> skip copying the fw_version and bus_info strings, which is natively<br /> handled by ethtool_get_drvinfo for empty strings.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: gadget: uvc: fix NULL pointer dereference during unbind race<br /> <br /> Commit b81ac4395bbe ("usb: gadget: uvc: allow for application to cleanly<br /> shutdown") introduced two stages of synchronization waits totaling 1500ms<br /> in uvc_function_unbind() to prevent several types of kernel panics.<br /> However, this timing-based approach is insufficient during power<br /> management (PM) transitions.<br /> <br /> When the PM subsystem starts freezing user space processes, the<br /> wait_event_interruptible_timeout() is aborted early, which allows the<br /> unbind thread to proceed and nullify the gadget pointer<br /> (cdev-&gt;gadget = NULL):<br /> <br /> [ 814.123447][ T947] configfs-gadget.g1 gadget.0: uvc: uvc_function_unbind()<br /> [ 814.178583][ T3173] PM: suspend entry (deep)<br /> [ 814.192487][ T3173] Freezing user space processes<br /> [ 814.197668][ T947] configfs-gadget.g1 gadget.0: uvc: uvc_function_unbind no clean disconnect, wait for release<br /> <br /> When the PM subsystem resumes or aborts the suspend and tasks are<br /> restarted, the V4L2 release path is executed and attempts to access the<br /> already nullified gadget pointer, triggering a kernel panic:<br /> <br /> [ 814.292597][ C0] PM: pm_system_irq_wakeup: 479 triggered dhdpcie_host_wake<br /> [ 814.386727][ T3173] Restarting tasks ...<br /> [ 814.403522][ T4558] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000030<br /> [ 814.404021][ T4558] pc : usb_gadget_deactivate+0x14/0xf4<br /> [ 814.404031][ T4558] lr : usb_function_deactivate+0x54/0x94<br /> [ 814.404078][ T4558] Call trace:<br /> [ 814.404080][ T4558] usb_gadget_deactivate+0x14/0xf4<br /> [ 814.404083][ T4558] usb_function_deactivate+0x54/0x94<br /> [ 814.404087][ T4558] uvc_function_disconnect+0x1c/0x5c<br /> [ 814.404092][ T4558] uvc_v4l2_release+0x44/0xac<br /> [ 814.404095][ T4558] v4l2_release+0xcc/0x130<br /> <br /> Address the race condition and NULL pointer dereference by:<br /> <br /> 1. State Synchronization (flag + mutex)<br /> Introduce a &amp;#39;func_unbound&amp;#39; flag in struct uvc_device. This allows<br /> uvc_function_disconnect() to safely skip accessing the nullified<br /> cdev-&gt;gadget pointer. As suggested by Alan Stern, this flag is protected<br /> by a new mutex (uvc-&gt;lock) to ensure proper memory ordering and prevent<br /> instruction reordering or speculative loads. This mutex is also used to<br /> protect &amp;#39;func_connected&amp;#39; for consistent state management.<br /> <br /> 2. Explicit Synchronization (completion)<br /> Use a completion to synchronize uvc_function_unbind() with the<br /> uvc_vdev_release() callback. This prevents Use-After-Free (UAF) by<br /> ensuring struct uvc_device is freed after all video device resources<br /> are released.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sched_ext: Fix stale direct dispatch state in ddsp_dsq_id<br /> <br /> @p-&gt;scx.ddsp_dsq_id can be left set (non-SCX_DSQ_INVALID) triggering a<br /> spurious warning in mark_direct_dispatch() when the next wakeup&amp;#39;s<br /> ops.select_cpu() calls scx_bpf_dsq_insert(), such as:<br /> <br /> WARNING: kernel/sched/ext.c:1273 at scx_dsq_insert_commit+0xcd/0x140<br /> <br /> The root cause is that ddsp_dsq_id was only cleared in dispatch_enqueue(),<br /> which is not reached in all paths that consume or cancel a direct dispatch<br /> verdict.<br /> <br /> Fix it by clearing it at the right places:<br /> <br /> - direct_dispatch(): cache the direct dispatch state in local variables<br /> and clear it before dispatch_enqueue() on the synchronous path. For<br /> the deferred path, the direct dispatch state must remain set until<br /> process_ddsp_deferred_locals() consumes them.<br /> <br /> - process_ddsp_deferred_locals(): cache the dispatch state in local<br /> variables and clear it before calling dispatch_to_local_dsq(), which<br /> may migrate the task to another rq.<br /> <br /> - do_enqueue_task(): clear the dispatch state on the enqueue path<br /> (local/global/bypass fallbacks), where the direct dispatch verdict is<br /> ignored.<br /> <br /> - dequeue_task_scx(): clear the dispatch state after dispatch_dequeue()<br /> to handle both the deferred dispatch cancellation and the holding_cpu<br /> race, covering all cases where a pending direct dispatch is<br /> cancelled.<br /> <br /> - scx_disable_task(): clear the direct dispatch state when<br /> transitioning a task out of the current scheduler. Waking tasks may<br /> have had the direct dispatch state set by the outgoing scheduler&amp;#39;s<br /> ops.select_cpu() and then been queued on a wake_list via<br /> ttwu_queue_wakelist(), when SCX_OPS_ALLOW_QUEUED_WAKEUP is set. Such<br /> tasks are not on the runqueue and are not iterated by scx_bypass(),<br /> so their direct dispatch state won&amp;#39;t be cleared. Without this clear,<br /> any subsequent SCX scheduler that tries to direct dispatch the task<br /> will trigger the WARN_ON_ONCE() in mark_direct_dispatch().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> misc: fastrpc: possible double-free of cctx-&gt;remote_heap<br /> <br /> fastrpc_init_create_static_process() may free cctx-&gt;remote_heap on the<br /> err_map path but does not clear the pointer. Later, fastrpc_rpmsg_remove()<br /> frees cctx-&gt;remote_heap again if it is non-NULL, which can lead to a<br /> double-free if the INIT_CREATE_STATIC ioctl hits the error path and the rpmsg<br /> device is subsequently removed/unbound.<br /> Clear cctx-&gt;remote_heap after freeing it in the error path to prevent the<br /> later cleanup from freeing it again.<br /> <br /> This issue was found by an in-house analysis workflow that extracts AST-based<br /> information and runs static checks, with LLM assistance for triage, and was<br /> confirmed by manual code review.<br /> No hardware testing was performed.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> thermal: core: Address thermal zone removal races with resume<br /> <br /> Since thermal_zone_pm_complete() and thermal_zone_device_resume()<br /> re-initialize the poll_queue delayed work for the given thermal zone,<br /> the cancel_delayed_work_sync() in thermal_zone_device_unregister()<br /> may miss some already running work items and the thermal zone may<br /> be freed prematurely [1].<br /> <br /> There are two failing scenarios that both start with<br /> running thermal_pm_notify_complete() right before invoking<br /> thermal_zone_device_unregister() for one of the thermal zones.<br /> <br /> In the first scenario, there is a work item already running for<br /> the given thermal zone when thermal_pm_notify_complete() calls<br /> thermal_zone_pm_complete() for that thermal zone and it continues to<br /> run when thermal_zone_device_unregister() starts. Since the poll_queue<br /> delayed work has been re-initialized by thermal_pm_notify_complete(), the<br /> running work item will be missed by the cancel_delayed_work_sync() in<br /> thermal_zone_device_unregister() and if it continues to run past the<br /> freeing of the thermal zone object, a use-after-free will occur.<br /> <br /> In the second scenario, thermal_zone_device_resume() queued up by<br /> thermal_pm_notify_complete() runs right after the thermal_zone_exit()<br /> called by thermal_zone_device_unregister() has returned. The poll_queue<br /> delayed work is re-initialized by it before cancel_delayed_work_sync() is<br /> called by thermal_zone_device_unregister(), so it may continue to run<br /> after the freeing of the thermal zone object, which also leads to a<br /> use-after-free.<br /> <br /> Address the first failing scenario by ensuring that no thermal work<br /> items will be running when thermal_pm_notify_complete() is called.<br /> For this purpose, first move the cancel_delayed_work() call from<br /> thermal_zone_pm_complete() to thermal_zone_pm_prepare() to prevent<br /> new work from entering the workqueue going forward. Next, switch<br /> over to using a dedicated workqueue for thermal events and update<br /> the code in thermal_pm_notify() to flush that workqueue after<br /> thermal_pm_notify_prepare() has returned which will take care of<br /> all leftover thermal work already on the workqueue (that leftover<br /> work would do nothing useful anyway because all of the thermal zones<br /> have been flagged as suspended).<br /> <br /> The second failing scenario is addressed by adding a tz-&gt;state check<br /> to thermal_zone_device_resume() to prevent it from re-initializing<br /> the poll_queue delayed work if the thermal zone is going away.<br /> <br /> Note that the above changes will also facilitate relocating the suspend<br /> and resume of thermal zones closer to the suspend and resume of devices,<br /> respectively.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: gadget: f_rndis: Fix net_device lifecycle with device_move<br /> <br /> The net_device is allocated during function instance creation and<br /> registered during the bind phase with the gadget device as its sysfs<br /> parent. When the function unbinds, the parent device is destroyed, but<br /> the net_device survives, resulting in dangling sysfs symlinks:<br /> <br /> console:/ # ls -l /sys/class/net/usb0<br /> lrwxrwxrwx ... /sys/class/net/usb0 -&gt;<br /> /sys/devices/platform/.../gadget.0/net/usb0<br /> console:/ # ls -l /sys/devices/platform/.../gadget.0/net/usb0<br /> ls: .../gadget.0/net/usb0: No such file or directory<br /> <br /> Use device_move() to reparent the net_device between the gadget device<br /> tree and /sys/devices/virtual across bind and unbind cycles. During the<br /> final unbind, calling device_move(NULL) moves the net_device to the<br /> virtual device tree before the gadget device is destroyed. On rebinding,<br /> device_move() reparents the device back under the new gadget, ensuring<br /> proper sysfs topology and power management ordering.<br /> <br /> To maintain compatibility with legacy composite drivers (e.g., multi.c),<br /> the borrowed_net flag is used to indicate whether the network device is<br /> shared and pre-registered during the legacy driver&amp;#39;s bind phase.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: gadget: f_hid: move list and spinlock inits from bind to alloc<br /> <br /> There was an issue when you did the following:<br /> - setup and bind an hid gadget<br /> - open /dev/hidg0<br /> - use the resulting fd in EPOLL_CTL_ADD<br /> - unbind the UDC<br /> - bind the UDC<br /> - use the fd in EPOLL_CTL_DEL<br /> <br /> When CONFIG_DEBUG_LIST was enabled, a list_del corruption was reported<br /> within remove_wait_queue (via ep_remove_wait_queue). After some<br /> debugging I found out that the queues, which f_hid registers via<br /> poll_wait were the problem. These were initialized using<br /> init_waitqueue_head inside hidg_bind. So effectively, the bind function<br /> re-initialized the queues while there were still items in them.<br /> <br /> The solution is to move the initialization from hidg_bind to hidg_alloc<br /> to extend their lifetimes to the lifetime of the function instance.<br /> <br /> Additionally, I found many other possibly problematic init calls in the<br /> bind function, which I moved as well.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: gadget: f_uac1_legacy: validate control request size<br /> <br /> f_audio_complete() copies req-&gt;length bytes into a 4-byte stack<br /> variable:<br /> <br /> u32 data = 0;<br /> memcpy(&amp;data, req-&gt;buf, req-&gt;length);<br /> <br /> req-&gt;length is derived from the host-controlled USB request path,<br /> which can lead to a stack out-of-bounds write.<br /> <br /> Validate req-&gt;actual against the expected payload size for the<br /> supported control selectors and decode only the expected amount<br /> of data.<br /> <br /> This avoids copying a host-influenced length into a fixed-size<br /> stack object.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: gadget: f_ecm: Fix net_device lifecycle with device_move<br /> <br /> The net_device is allocated during function instance creation and<br /> registered during the bind phase with the gadget device as its sysfs<br /> parent. When the function unbinds, the parent device is destroyed, but<br /> the net_device survives, resulting in dangling sysfs symlinks:<br /> <br /> console:/ # ls -l /sys/class/net/usb0<br /> lrwxrwxrwx ... /sys/class/net/usb0 -&gt;<br /> /sys/devices/platform/.../gadget.0/net/usb0<br /> console:/ # ls -l /sys/devices/platform/.../gadget.0/net/usb0<br /> ls: .../gadget.0/net/usb0: No such file or directory<br /> <br /> Use device_move() to reparent the net_device between the gadget device<br /> tree and /sys/devices/virtual across bind and unbind cycles. During the<br /> final unbind, calling device_move(NULL) moves the net_device to the<br /> virtual device tree before the gadget device is destroyed. On rebinding,<br /> device_move() reparents the device back under the new gadget, ensuring<br /> proper sysfs topology and power management ordering.<br /> <br /> To maintain compatibility with legacy composite drivers (e.g., multi.c),<br /> the bound flag is used to indicate whether the network device is shared<br /> and pre-registered during the legacy driver&amp;#39;s bind phase.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: gadget: f_eem: Fix net_device lifecycle with device_move<br /> <br /> The net_device is allocated during function instance creation and<br /> registered during the bind phase with the gadget device as its sysfs<br /> parent. When the function unbinds, the parent device is destroyed, but<br /> the net_device survives, resulting in dangling sysfs symlinks:<br /> <br /> console:/ # ls -l /sys/class/net/usb0<br /> lrwxrwxrwx ... /sys/class/net/usb0 -&gt;<br /> /sys/devices/platform/.../gadget.0/net/usb0<br /> console:/ # ls -l /sys/devices/platform/.../gadget.0/net/usb0<br /> ls: .../gadget.0/net/usb0: No such file or directory<br /> <br /> Use device_move() to reparent the net_device between the gadget device<br /> tree and /sys/devices/virtual across bind and unbind cycles. During the<br /> final unbind, calling device_move(NULL) moves the net_device to the<br /> virtual device tree before the gadget device is destroyed. On rebinding,<br /> device_move() reparents the device back under the new gadget, ensuring<br /> proper sysfs topology and power management ordering.<br /> <br /> To maintain compatibility with legacy composite drivers (e.g., multi.c),<br /> the bound flag is used to indicate whether the network device is shared<br /> and pre-registered during the legacy driver&amp;#39;s bind phase.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: gadget: f_subset: Fix net_device lifecycle with device_move<br /> <br /> The net_device is allocated during function instance creation and<br /> registered during the bind phase with the gadget device as its sysfs<br /> parent. When the function unbinds, the parent device is destroyed, but<br /> the net_device survives, resulting in dangling sysfs symlinks:<br /> <br /> console:/ # ls -l /sys/class/net/usb0<br /> lrwxrwxrwx ... /sys/class/net/usb0 -&gt;<br /> /sys/devices/platform/.../gadget.0/net/usb0<br /> console:/ # ls -l /sys/devices/platform/.../gadget.0/net/usb0<br /> ls: .../gadget.0/net/usb0: No such file or directory<br /> <br /> Use device_move() to reparent the net_device between the gadget device<br /> tree and /sys/devices/virtual across bind and unbind cycles. During the<br /> final unbind, calling device_move(NULL) moves the net_device to the<br /> virtual device tree before the gadget device is destroyed. On rebinding,<br /> device_move() reparents the device back under the new gadget, ensuring<br /> proper sysfs topology and power management ordering.<br /> <br /> To maintain compatibility with legacy composite drivers (e.g., multi.c),<br /> the bound flag is used to indicate whether the network device is shared<br /> and pre-registered during the legacy driver&amp;#39;s bind phase.

*** Pendiente de traducción *** A vulnerability was detected in AcademySoftwareFoundation OpenImageIO up to 3.2.0.1-dev. This vulnerability affects unknown code of the file src/dds.imageio/ddsinput.cpp of the component DDS Image Handler. The manipulation results in out-of-bounds write. The attack needs to be approached locally. The exploit is now public and may be used. The patch is identified as 94ec2deec3e3bf2f2e2ff84d008e27425d626fe2. Applying a patch is advised to resolve this issue.