Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: ftgmac100: fix ring allocation unwind on open failure<br /> <br /> ftgmac100_alloc_rings() allocates rx_skbs, tx_skbs, rxdes, txdes, and<br /> rx_scratch in stages. On intermediate failures it returned -ENOMEM<br /> directly, leaking resources allocated earlier in the function.<br /> <br /> Rework the failure path to use staged local unwind labels and free<br /> allocated resources in reverse order before returning -ENOMEM. This<br /> matches common netdev allocation cleanup style.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vxlan: validate ND option lengths in vxlan_na_create<br /> <br /> vxlan_na_create() walks ND options according to option-provided<br /> lengths. A malformed option can make the parser advance beyond the<br /> computed option span or use a too-short source LLADDR option payload.<br /> <br /> Validate option lengths against the remaining NS option area before<br /> advancing, and only read source LLADDR when the option is large enough<br /> for an Ethernet address.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: tegra - Add missing CRYPTO_ALG_ASYNC<br /> <br /> The tegra crypto driver failed to set the CRYPTO_ALG_ASYNC on its<br /> asynchronous algorithms, causing the crypto API to select them for users<br /> that request only synchronous algorithms. This causes crashes (at<br /> least). Fix this by adding the flag like what the other drivers do.<br /> Also remove the unnecessary CRYPTO_ALG_TYPE_* flags, since those just<br /> get ignored and overridden by the registration function anyway.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> counter: rz-mtu3-cnt: prevent counter from being toggled multiple times<br /> <br /> Runtime PM counter is incremented / decremented each time the sysfs<br /> enable file is written to.<br /> <br /> If user writes 0 to the sysfs enable file multiple times, runtime PM<br /> usage count underflows, generating the following message.<br /> <br /> rz-mtu3-counter rz-mtu3-counter.0: Runtime PM usage count underflow!<br /> <br /> At the same time, hardware registers end up being accessed with clocks<br /> off in rz_mtu3_terminate_counter() to disable an already disabled<br /> channel.<br /> <br /> If user writes 1 to the sysfs enable file multiple times, runtime PM<br /> usage count will be incremented each time, requiring the same number of<br /> 0 writes to get it back to 0.<br /> <br /> If user writes 0 to the sysfs enable file while PWM is in progress, PWM<br /> is stopped without counter being the owner of the underlying MTU3<br /> channel.<br /> <br /> Check against the cached count_is_enabled value and exit if the user<br /> is trying to set the same enable value.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> counter: rz-mtu3-cnt: do not use struct rz_mtu3_channel&amp;#39;s dev member<br /> <br /> The counter driver can use HW channels 1 and 2, while the PWM driver can<br /> use HW channels 0, 1, 2, 3, 4, 6, 7.<br /> <br /> The dev member is assigned both by the counter driver and the PWM driver<br /> for channels 1 and 2, to their own struct device instance, overwriting<br /> the previous value.<br /> <br /> The sub-drivers race to assign their own struct device pointer to the<br /> same struct rz_mtu3_channel&amp;#39;s dev member.<br /> <br /> The dev member of struct rz_mtu3_channel is used by the counter<br /> sub-driver for runtime PM.<br /> <br /> Depending on the probe order of the counter and PWM sub-drivers, the<br /> dev member may point to the wrong struct device instance, causing the<br /> counter sub-driver to do runtime PM actions on the wrong device.<br /> <br /> To fix this, use the parent pointer of the counter, which is assigned<br /> during probe to the correct struct device, not the struct device pointer<br /> inside the shared struct rz_mtu3_channel.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> gpio: Fix resource leaks on errors in gpiochip_add_data_with_key()<br /> <br /> Since commit aab5c6f20023 ("gpio: set device type for GPIO chips"),<br /> `gdev-&gt;dev.release` is unset. As a result, the reference count to<br /> `gdev-&gt;dev` isn&amp;#39;t dropped on the error handling paths.<br /> <br /> Drop the reference on errors.<br /> <br /> Also reorder the instructions to make the error handling simpler.<br /> Now gpiochip_add_data_with_key() roughly looks like:<br /> <br /> &gt;&gt;&gt; Some memory allocation. Go to ERR ZONE 1 on errors.<br /> &gt;&gt;&gt; device_initialize().<br /> <br /> gpiodev_release() takes over the responsibility for freeing the<br /> resources of `gdev-&gt;dev`. The subsequent error handling paths<br /> shouldn&amp;#39;t go through ERR ZONE 1 again which leads to double free.<br /> <br /> &gt;&gt;&gt; Some initialization mainly on `gdev`.<br /> &gt;&gt;&gt; The rest of initialization. Go to ERR ZONE 2 on errors.<br /> &gt;&gt;&gt; Chip registration success and exit.<br /> <br /> &gt;&gt;&gt; ERR ZONE 2. gpio_device_put() and exit.<br /> &gt;&gt;&gt; ERR ZONE 1.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: typec: ucsi: validate connector number in ucsi_notify_common()<br /> <br /> The connector number extracted from CCI via UCSI_CCI_CONNECTOR() is a<br /> 7-bit field (0-127) that is used to index into the connector array in<br /> ucsi_connector_change(). However, the array is only allocated for the<br /> number of connectors reported by the device (typically 2-4 entries).<br /> <br /> A malicious or malfunctioning device could report an out-of-range<br /> connector number in the CCI, causing an out-of-bounds array access in<br /> ucsi_connector_change().<br /> <br /> Add a bounds check in ucsi_notify_common(), the central point where CCI<br /> is parsed after arriving from hardware, so that bogus connector numbers<br /> are rejected before they propagate further.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: gadget: u_ether: Fix race between gether_disconnect and eth_stop<br /> <br /> A race condition between gether_disconnect() and eth_stop() leads to a<br /> NULL pointer dereference. Specifically, if eth_stop() is triggered<br /> concurrently while gether_disconnect() is tearing down the endpoints,<br /> eth_stop() attempts to access the cleared endpoint descriptor, causing<br /> the following NPE:<br /> <br /> Unable to handle kernel NULL pointer dereference<br /> Call trace:<br /> __dwc3_gadget_ep_enable+0x60/0x788<br /> dwc3_gadget_ep_enable+0x70/0xe4<br /> usb_ep_enable+0x60/0x15c<br /> eth_stop+0xb8/0x108<br /> <br /> Because eth_stop() crashes while holding the dev-&gt;lock, the thread<br /> running gether_disconnect() fails to acquire the same lock and spins<br /> forever, resulting in a hardlockup:<br /> <br /> Core - Debugging Information for Hardlockup core(7)<br /> Call trace:<br /> queued_spin_lock_slowpath+0x94/0x488<br /> _raw_spin_lock+0x64/0x6c<br /> gether_disconnect+0x19c/0x1e8<br /> ncm_set_alt+0x68/0x1a0<br /> composite_setup+0x6a0/0xc50<br /> <br /> The root cause is that the clearing of dev-&gt;port_usb in<br /> gether_disconnect() is delayed until the end of the function.<br /> <br /> Move the clearing of dev-&gt;port_usb to the very beginning of<br /> gether_disconnect() while holding dev-&gt;lock. This cuts off the link<br /> immediately, ensuring eth_stop() will see dev-&gt;port_usb as NULL and<br /> safely bail out.

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.

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.

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().

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.