Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> riscv: mm: Unconditionally sfence.vma for spurious fault<br /> <br /> Svvptc does not guarantee that it&amp;#39;s safe to just return here. Since we<br /> have already cleared our bit, if, theoretically, the bounded timeframe<br /> for the accessed page to become valid still hasn&amp;#39;t happened after sret,<br /> we could fault again and actually crash.<br /> <br /> Hopefully, these spurious faults should be rare enough that this is an<br /> acceptable slowdown.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: do not trim a device which is not writeable<br /> <br /> [BUG]<br /> There is a bug report that btrfs/242 can randomly fail with the<br /> following NULL pointer dereference:<br /> <br /> run fstests btrfs/242 at 2026-06-01 10:25:08<br /> BTRFS: device fsid d4d7f234-487c-4787-88e4-47a8b68c9874 devid 1 transid 9 /dev/sdc (8:32) scanned by mount (122609)<br /> BTRFS info (device sdc): first mount of filesystem d4d7f234-487c-4787-88e4-47a8b68c9874<br /> BTRFS info (device sdc): using crc32c checksum algorithm<br /> BTRFS warning (device sdc): devid 2 uuid fbe72d72-3272-482d-80fb-ab88ed398192 is missing<br /> BTRFS warning (device sdc): devid 2 uuid fbe72d72-3272-482d-80fb-ab88ed398192 is missing<br /> BTRFS info (device sdc): allowing degraded mounts<br /> BTRFS info (device sdc): turning on async discard<br /> BTRFS info (device sdc): enabling free space tree<br /> Unable to handle kernel NULL pointer dereference at virtual address 0000000000000018<br /> user pgtable: 4k pages, 48-bit VAs, pgdp=000000013fd6b000<br /> CPU: 4 UID: 0 PID: 122625 Comm: fstrim Not tainted 7.0.10-2-default #1 PREEMPT(full) openSUSE Tumbleweed e9a5f6b24978fba3bf015a992f865837fdfff3dd<br /> Hardware name: QEMU KVM Virtual Machine, BIOS edk2-20250812-19.fc42 08/12/2025<br /> pstate: 01400005 (nzcv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)<br /> pc : btrfs_trim_fs+0x34c/0xa00 [btrfs]<br /> lr : btrfs_trim_fs+0x1f0/0xa00 [btrfs]<br /> Call trace:<br /> btrfs_trim_fs+0x34c/0xa00 [btrfs f02c1d570ceea621c69d302ba75dd61868083840] (P)<br /> btrfs_ioctl_fitrim+0xe8/0x178 [btrfs f02c1d570ceea621c69d302ba75dd61868083840]<br /> btrfs_ioctl+0xdd4/0x2bd8 [btrfs f02c1d570ceea621c69d302ba75dd61868083840]<br /> __arm64_sys_ioctl+0xac/0x108<br /> invoke_syscall.constprop.0+0x5c/0xd0<br /> el0_svc_common.constprop.0+0x40/0xf0<br /> do_el0_svc+0x24/0x40<br /> el0_svc+0x40/0x1d0<br /> el0t_64_sync_handler+0xa0/0xe8<br /> el0t_64_sync+0x1b0/0x1b8<br /> Code: 17ffff83 f94017e0 f9002be0 f9402ea0 (f9400c00)<br /> ---[ end trace 0000000000000000 ]---<br /> <br /> Also the reporter is very kind to test the following ASSERT() added to<br /> btrfs_trim_free_extents_throttle():<br /> <br /> ASSERT(device-&gt;bdev,<br /> "devid=%llu path=%s dev_state=0x%lx\n",<br /> device-&gt;devid, btrfs_dev_name(device), device-&gt;dev_state);<br /> <br /> And it shows the following output:<br /> <br /> assertion failed: device-&gt;bdev, in extent-tree.c:6630 (devid=2 path=/dev/sdd dev_state=0x82)<br /> <br /> Which means the device-&gt;bdev is NULL, and the dev_state is<br /> BTRFS_DEV_STATE_IN_FS_METADATA | BTRFS_DEV_STATE_ITEM_FOUND, without<br /> BTRFS_DEV_STATE_WRITEABLE flag set.<br /> <br /> [CAUSE]<br /> The pc points to the following call chain:<br /> <br /> btrfs_trim_fs()<br /> |- btrfs_trim_free_extents()<br /> |- btrfs_trim_free_extents_throttle()<br /> |- bdev_max_discard_sectors(device-&gt;bdev)<br /> <br /> So the NULL pointer dereference is caused by device-&gt;bdev being NULL.<br /> <br /> This looks impossible by a quick glance, as just before calling<br /> btrfs_trim_free_extents_throttle(), we have skipped any device that has<br /> BTRFS_DEV_STATE_MISSING flag set.<br /> <br /> However in this particular case, there is a window where the missing<br /> device is later re-scanned, causing btrfs to remove the<br /> BTRFS_DEV_STATE_MISSING flag:<br /> <br /> btrfs_control_ioctl()<br /> |- btrfs_scan_one_device()<br /> |- device_list_add()<br /> |- rcu_assign_pointer(device-&gt;name, name);<br /> | This updates the missing device&amp;#39;s path to the new good path.<br /> |<br /> |- clear_bit(BTRFS_DEV_STATE_MISSING, &amp;device-&gt;dev_state)<br /> This removes the BTRFS_DEV_STATE_MISSING flag.<br /> <br /> This allows the missing device to re-appear and clear the<br /> BTRFS_DEV_STATE_MISSING flag. However the device still does not have<br /> the BTRFS_DEV_STATE_WRITEABLE flag set, nor is its bdev pointer updated.<br /> <br /> The bdev pointer remains NULL, triggering the crash later.<br /> <br /> [FIX]<br /> This is a big de-synchronization between BTRFS_DEV_STATE_MISSING and<br /> device-&gt;bdev pointer, and shows a gap in btrfs&amp;#39;s re-appearing-device<br /> handling.<br /> <br /> The proper handling of re-appearing device will need quite some extra<br /> work, which is out of the context of this small<br /> ---truncated---

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: gadget: f_fs: initialize reset_work at allocation time<br /> <br /> ffs_fs_kill_sb() unconditionally calls cancel_work_sync() on<br /> ffs-&gt;reset_work when a functionfs instance is unmounted:<br /> <br /> ffs_data_reset(ffs);<br /> cancel_work_sync(&amp;ffs-&gt;reset_work);<br /> <br /> However ffs-&gt;reset_work is only ever initialized via INIT_WORK() in<br /> ffs_func_set_alt() and ffs_func_disable(), and only on the<br /> FFS_DEACTIVATED path. That state is reached solely by ffs_data_closed()<br /> when the instance is mounted with the "no_disconnect" option, so for the<br /> common case (no "no_disconnect", or mounted and unmounted without ever<br /> being deactivated) reset_work is never initialized.<br /> <br /> ffs_data_new() allocates the ffs_data with kzalloc_obj() and does not<br /> initialize reset_work, and ffs_data_reset()/ffs_data_clear() do not touch<br /> it either, so reset_work.func is left NULL. cancel_work_sync() on such a<br /> work then trips the WARN_ON(!work-&gt;func) guard in __flush_work():<br /> <br /> WARNING: kernel/workqueue.c:4301 at __flush_work+0x330/0x360, CPU#3: umount<br /> Call trace:<br /> __flush_work<br /> cancel_work_sync<br /> ffs_fs_kill_sb [usb_f_fs]<br /> deactivate_locked_super<br /> deactivate_super<br /> cleanup_mnt<br /> __cleanup_mnt<br /> task_work_run<br /> exit_to_user_mode_loop<br /> el0_svc<br /> <br /> On older kernels cancel_work_sync() on a zero-initialized work struct was<br /> a silent no-op, which hid the missing initialization.<br /> <br /> Initialize reset_work once in ffs_data_new() so it is always valid for<br /> the lifetime of the ffs_data, and drop the now-redundant INIT_WORK()<br /> calls from the two deactivation paths.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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.