Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fuse-uring: fix data races on ring-&gt;ready<br /> <br /> On weakly-ordered architectures, the store to fiq-&gt;ops can be<br /> reordered past the store to ring-&gt;ready, allowing a CPU that sees<br /> ring-&gt;ready == true via fuse_uring_ready() to dispatch requests<br /> through a stale fiq-&gt;ops pointer. Upgrade the store to<br /> smp_store_release() and the load in fuse_uring_ready() to<br /> smp_load_acquire() so that the preceding WRITE_ONCE(fiq-&gt;ops, ...)<br /> is visible to any CPU that observes ring-&gt;ready == true.<br /> <br /> Additionally, fuse_uring_do_register() publishes ring-&gt;ready with<br /> WRITE_ONCE() but the fast-path check reads it with a plain load.<br /> This is a marked-vs-unmarked access that KCSAN will flag. Wrap it in<br /> READ_ONCE() to mark it without adding unnecessary ordering.<br /> <br /> Also wrap the fc-&gt;ring load in fuse_uring_ready() in READ_ONCE() to<br /> prevent the compiler from reloading it between the NULL check and the<br /> dereference.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: gadget: udc: bdc: free IRQ and drain func_wake_notify before teardown<br /> <br /> The Broadcom BDC UDC driver registers its IRQ handler with<br /> devm_request_irq() in bdc_udc_init(), so the IRQ is released by devm<br /> only after bdc_remove() returns. devm releases resources in reverse<br /> LIFO order, but bdc_remove() runs bdc_udc_exit() and bdc_hw_exit() -&gt;<br /> bdc_mem_free() manually before returning: bdc_udc_exit() tears down<br /> individual endpoint objects via bdc_free_ep(), while bdc_hw_exit() -&gt;<br /> bdc_mem_free() frees and NULLs the DMA-coherent status-report ring<br /> (bdc-&gt;srr.sr_bds) and kfree()s bdc-&gt;bdc_ep_array. Both happen while<br /> the IRQ handler (bdc_udc_interrupt, requested with IRQF_SHARED)<br /> remains deliverable in the window up to the post-remove devm<br /> free_irq().<br /> <br /> On receipt of a shared interrupt in that window, bdc_udc_interrupt()<br /> dereferences bdc-&gt;srr.sr_bds[bdc-&gt;srr.dqp_index] (NULL or freed DMA)<br /> and dispatches sr_handler callbacks that index into bdc_ep_array,<br /> causing a NULL-deref or use-after-free.<br /> <br /> The same window affects the delayed_work bdc-&gt;func_wake_notify, which is<br /> armed from the IRQ handler via bdc_sr_uspc() -&gt; handle_link_state_change()<br /> -&gt; schedule_delayed_work() and may self-rearm from its own callback<br /> bdc_func_wake_timer(). No cancel exists anywhere in the driver, so a<br /> queued work item that fires after bdc_remove() returns and the bdc<br /> structure is devm-freed dereferences freed memory.<br /> <br /> Replace devm_request_irq() with request_irq() and add an explicit<br /> free_irq(bdc-&gt;irq, bdc) in bdc_remove(). Clear BDC_GIE before<br /> free_irq() to stop the device from asserting interrupts, then<br /> free_irq() drains any in-flight handler, then cancel_delayed_work_sync()<br /> drains the func_wake_notify delayed work. This ordering ensures the<br /> IRQ handler and delayed work cannot interfere with the subsequent<br /> endpoint and DMA teardown in bdc_udc_exit() and bdc_hw_exit(). Wire the<br /> matching free_irq() into the bdc_udc_init() error path so the IRQ is<br /> released on probe failure, and route the bdc_init_ep() failure through<br /> err0 instead of returning directly.<br /> <br /> This issue was found by an in-house static analysis tool.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: gadget: f_midi: cancel pending IN work before freeing the midi object<br /> <br /> The f_midi driver embeds a work item (midi-&gt;work) whose handler,<br /> f_midi_in_work(), dereferences the enclosing struct f_midi through<br /> container_of(). This work is armed from two sites: f_midi_complete(),<br /> on a normal IN-endpoint completion, and f_midi_in_trigger(), on an ALSA<br /> rawmidi output-stream start.<br /> <br /> Neither f_midi_disable() nor f_midi_unbind() cancels midi-&gt;work.<br /> f_midi_disable() only disables the endpoints and drains the in_req_fifo;<br /> it does not synchronize the work item, and the sound card is released<br /> asynchronously to the final free of the midi object.<br /> <br /> The midi object is reference-counted (midi-&gt;free_ref) and is freed in<br /> f_midi_free() only once both the usb_function reference and the rawmidi<br /> private_data reference have been dropped. In f_midi_unbind(),<br /> f_midi_disable() runs before the sound card is released, so while the<br /> USB endpoints are already disabled the rawmidi device is still usable by<br /> an open substream. A concurrent userspace write on such a substream can<br /> reach f_midi_in_trigger() and queue midi-&gt;work again after<br /> f_midi_disable() has returned. A work item armed this way may still be<br /> pending when the last reference drops and f_midi_free() proceeds to<br /> kfree(midi), letting f_midi_in_work() dereference the struct after it<br /> has been freed, a use-after-free.<br /> <br /> For this reason cancelling midi-&gt;work in f_midi_disable() would not be<br /> sufficient: the ALSA trigger path can rearm the work after disable()<br /> returns. Cancelling at the refcount-zero free site is the boundary<br /> after which neither arming source can survive, because by then both<br /> references that keep the midi object alive have been dropped: the USB<br /> endpoints are already disabled and the rawmidi device has been released.<br /> <br /> Fix this by calling cancel_work_sync(&amp;midi-&gt;work) in the refcount-zero<br /> block of f_midi_free(), before the embedded work_struct is freed along<br /> with the rest of the structure. opts-&gt;lock is a sleeping mutex, so<br /> calling cancel_work_sync() under it is permitted, and the handler takes<br /> midi-&gt;transmit_lock rather than opts-&gt;lock, so no self-deadlock can<br /> occur while it waits for a running instance of the work to finish.<br /> <br /> This issue was found by an in-house static analysis tool.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> can: esd_usb: kill anchored URBs before freeing netdevs<br /> <br /> esd_usb_disconnect() frees each CAN netdev with free_candev() inside<br /> its per-netdev loop and only calls unlink_all_urbs(dev) afterwards.<br /> The per-netdev private data (struct esd_usb_net_priv) is embedded in<br /> the net_device allocation returned by alloc_candev(), so once<br /> free_candev() has run, dev-&gt;nets[i] points to freed memory.<br /> unlink_all_urbs() then dereferences the freed dev-&gt;nets[i] to kill the<br /> per-netdev TX anchor (usb_kill_anchored_urbs(&amp;priv-&gt;tx_submitted)),<br /> clear active_tx_jobs, and reset priv-&gt;tx_contexts[].<br /> <br /> Reorder the teardown so the anchored URBs are killed before the netdevs<br /> are freed, matching other CAN/USB drivers in the same directory such as<br /> ems_usb, usb_8dev and mcba_usb, which unregister, then unlink, then<br /> free: unregister the netdevs first (which stops their TX queues), call<br /> unlink_all_urbs(dev) once, then free the netdevs.<br /> <br /> This issue was found by an in-house static analysis tool.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: ethernet: arc: emac: quiesce interrupts before requesting IRQ<br /> <br /> Normal RX/TX interrupts are enabled later, in arc_emac_open(), so probe<br /> should not see interrupt delivery in the usual case. However, hardware may<br /> still present stale or latched interrupt status left by firmware or the<br /> bootloader.<br /> <br /> If probe later unwinds after devm_request_irq() has installed the handler,<br /> such a stale interrupt can still reach arc_emac_intr() during teardown and<br /> race with release of the associated net_device.<br /> <br /> Avoid that window by putting the device into a known quiescent state before<br /> requesting the IRQ: disable all EMAC interrupt sources and clear any<br /> pending EMAC interrupt status bits. This keeps the change hardware-focused<br /> and minimal, while preventing spurious IRQ delivery from leftover state.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: brcmfmac: drain bus_reset work on device removal<br /> <br /> brcmf_fw_crashed() and the debugfs "reset" entry both schedule<br /> drvr-&gt;bus_reset, whose callback recovers drvr through container_of()<br /> and dereferences it. The removal path frees drvr (brcmf_free -&gt;<br /> wiphy_free) without draining the work, so a bus_reset callback pending<br /> or running during removal can outlive drvr.<br /> <br /> Cancellation cannot live in brcmf_detach() or brcmf_free(): the work<br /> callback reaches teardown through the bus .reset op (PCIe<br /> brcmf_pcie_reset -&gt; brcmf_detach; SDIO brcmf_sdio_bus_reset -&gt;<br /> brcmf_sdiod_remove -&gt; brcmf_free), so cancelling there would wait for<br /> the running work and deadlock.<br /> <br /> Add a per-bus mutex (bus_reset_lock) and route all arming through<br /> brcmf_bus_schedule_reset(), which under the lock skips when the bus is<br /> marked removing. Each bus remove entry calls<br /> brcmf_bus_cancel_reset_work(), which under the same lock sets removing<br /> and cancels the work. Holding the mutex across cancel_work_sync() makes<br /> the set-removing + drain step atomic. Every producer reaches the arming<br /> path from process context -- the PCIe firmware-halt notification runs in<br /> the threaded IRQ handler (brcmf_pcie_isr_thread) and the SDIO hostmail<br /> path runs from the data workqueue -- so the mutex is taken only in<br /> sleepable contexts. Where applicable the remove entry first stops the<br /> firmware-crash producer: on PCIe mask the mailbox and synchronize_irq;<br /> on SDIO unregister the bus interrupt and cancel the data worker, which<br /> also reports firmware halts through brcmf_fw_crashed(). The mutex is<br /> initialized at bus allocation. The SDIO suspend power-off path frees<br /> drvr through the same brcmf_sdiod_remove() and takes the same lock;<br /> resume re-allows the work only on a successful re-probe.<br /> <br /> Also guard brcmf_fw_crashed() against a NULL bus_if/drvr: it can fire<br /> before brcmf_attach() wires up drvr, and it dereferences drvr<br /> (bphy_err/brcmf_dev_coredump) before reaching the arming gate.<br /> <br /> The bus_reset work is shared across buses, so the drain is applied to<br /> every remove path: PCIe (the .reset op introduced by the Fixes commit),<br /> SDIO (arms the same work through brcmf_fw_crashed()), and USB (via the<br /> debugfs "reset" entry). cancel_work_sync() drains a running or pending<br /> bus_reset work item before removal frees drvr, and patch 1/2 makes the<br /> scratch-buffer release safe when reset teardown has already released<br /> those DMA buffers.<br /> <br /> This patch fixes the lifetime of the bus_reset work item itself. It does<br /> not attempt to address the separate, pre-existing lifetime of the<br /> asynchronous firmware completion started by the PCIe reset path. That<br /> callback needs its own lifetime/ownership protocol and is being tracked<br /> separately.<br /> <br /> This issue was found by an in-house static analysis tool.

The JWT authentication mechanism accepts tokens signed with algorithms other than those explicitly configured or supported. This allows an attacker to craft a JWT with an unsupported algorithm, which is then incorrectly validated, leading to unauthorized access.<br /> <br /> Successful exploitation of this vulnerability may result in unauthorized access to the system, including the potential compromise of administrative accounts and full account takeover. The CVSS score is adjusted to 9.8 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H) in single-tenant deployments, reflecting that the impact is contained within a single security authority boundary.

Tokens issued to a low-privileged user are not sufficiently restricted, allowing them to be used to access product-level Admin REST APIs.<br /> <br /> Exploitation of this vulnerability allows a low-privileged user to invoke the Admin REST APIs of WSO2 products, potentially leading to full administrative account takeover. This requires the attacker to already possess a low-privileged user account and be able to obtain a valid token for it.

A weakness has been identified in itsourcecode Hospital Management System 1.0. Affected by this vulnerability is an unknown functionality of the file /servicetype.php. This manipulation of the argument editid causes sql injection. It is possible to initiate the attack remotely. The exploit has been made available to the public and could be used for attacks.

A security vulnerability has been detected in SourceCodester Computer Repair Shop Management System 1.0. Affected by this issue is some unknown functionality of the file /classes/Master.php?f=delete_product. Such manipulation of the argument ID leads to sql injection. It is possible to launch the attack remotely. The exploit has been disclosed publicly and may be used.

A vulnerability was identified in mf-yang openclaw-cn up to 0.2.1. This issue affects the function assertNoSymlinkEscape of the file src/agents/sandbox-paths.ts of the component apply_patch Tool. Such manipulation leads to link following. It is possible to launch the attack remotely. The exploit is publicly available and might be used. The project was informed of the problem early through an issue report but has not responded yet.

A weakness has been identified in TinyAGI 0.0.20. This issue affects the function collectFiles of the file packages/core/src/response.ts of the component Message API Endpoint. This manipulation causes file inclusion. The attack can be initiated remotely. The exploit has been made available to the public and could be used for attacks. The project was informed of the problem early through an issue report but has not responded yet.