Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> io-wq: check that the predecessor is hashed in io_wq_remove_pending()<br /> <br /> io_wq_remove_pending() needs to fix up wq-&gt;hash_tail[] if the cancelled<br /> work was the tail of its hash bucket. When doing this, it checks whether<br /> the preceding entry in acct-&gt;work_list has the same hash value, but<br /> never checks that the predecessor is hashed at all. io_get_work_hash()<br /> is simply atomic_read(&amp;work-&gt;flags) &gt;&gt; IO_WQ_HASH_SHIFT, and the hash<br /> bits are never set for non-hashed work, so it returns 0. Thus, when a<br /> hashed bucket-0 work is cancelled while a non-hashed work is its list<br /> predecessor, the check spuriously passes and a pointer to the non-hashed<br /> io_kiocb is stored in wq-&gt;hash_tail[0].<br /> <br /> Because non-hashed work is dequeued via the fast path in<br /> io_get_next_work(), which never touches hash_tail[], the stale pointer<br /> is never cleared. Therefore, after the non-hashed io_kiocb completes and<br /> is freed back to req_cachep, wq-&gt;hash_tail[0] is a dangling pointer. The<br /> io_wq is per-task (tctx-&gt;io_wq) and survives ring open/close, so the<br /> dangling pointer persists for the lifetime of the task; the next hashed<br /> bucket-0 enqueue dereferences it in io_wq_insert_work() and<br /> wq_list_add_after() writes through freed memory.<br /> <br /> Add the missing io_wq_is_hashed() check so a non-hashed predecessor<br /> never inherits a hash_tail[] slot.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: hci_uart: fix UAFs and race conditions in close and init paths<br /> <br /> Vulnerabilities leading to Use-After-Free (UAF) and Null Pointer<br /> Dereference (NPD) conditions were observed in the lifecycle management<br /> of hci_uart.<br /> <br /> The primary issue arises because the workqueues (init_ready and<br /> write_work) are only flushed/cancelled if the HCI_UART_PROTO_READY<br /> flag is set during TTY close. If a hangup occurs before setup completes,<br /> hci_uart_tty_close() skips the teardown of these workqueues and<br /> proceeds to free the `hu` struct. When the scheduled work executes<br /> later, it blindly dereferences the freed `hu` struct.<br /> <br /> Furthermore, several data races and UAFs were identified in the teardown<br /> sequence:<br /> 1. Calling hci_uart_flush() from hci_uart_close() without effectively<br /> disabling write_work causes a race condition where both can concurrently<br /> double-free hu-&gt;tx_skb. This happens because protocol timers can<br /> concurrently invoke hci_uart_tx_wakeup() and requeue write_work.<br /> 2. Calling hci_free_dev(hdev) before hu-&gt;proto-&gt;close(hu) causes a UAF<br /> when vendor specific protocol close callbacks dereference hu-&gt;hdev.<br /> 3. In the initialization error paths, failing to take the proto_lock<br /> write lock before clearing PROTO_READY leads to races with active<br /> readers. Additionally, hci_uart_tty_receive() accesses hu-&gt;hdev<br /> outside the read lock, leading to UAFs if the initialization error<br /> path frees hdev concurrently.<br /> <br /> Fix these synchronization and lifecycle issues by:<br /> 1. Re-ordering hci_uart_tty_close() to clear HCI_UART_PROTO_READY first,<br /> followed immediately by a cancel_work_sync(&amp;hu-&gt;write_work). Clearing<br /> the flag locks out concurrent protocol timers from successfully invoking<br /> hci_uart_tx_wakeup(), effectively rendering the cancellation permanent<br /> and preventing the tx_skb double-free.<br /> 2. Note: Clearing PROTO_READY early causes hci_uart_close() to skip<br /> hu-&gt;proto-&gt;flush(). This is perfectly safe in the tty_close path<br /> because hu-&gt;proto-&gt;close() executes shortly after, which intrinsically<br /> purges all protocol SKB queues and tears down the state.<br /> 3. Relocating hu-&gt;proto-&gt;close(hu) strictly prior to hci_free_dev(hdev)<br /> across all close and error paths to prevent vendor-level UAFs.<br /> 4. Moving the hdev-&gt;stat.byte_rx increment in hci_uart_tty_receive()<br /> inside the proto_lock read-side critical section to safely synchronize<br /> with device unregistration.<br /> 5. Adding cancel_work_sync(&amp;hu-&gt;write_work) to hci_uart_close() to safely<br /> flush the workqueue before hci_uart_flush() is invoked via the HCI core.<br /> 6. Utilizing cancel_work_sync() instead of disable_work_sync() across<br /> all paths to prevent permanently breaking user-space retry capabilities.

*** Pendiente de traducción *** A path handling issue in mod_dav_fs in Apache 2.4.67 and earlier allows a WebDAV content author to directly manipulate trusted DAV property databases, potentially causing child process crashes.<br /> <br /> Users are recommended to upgrade to version 2.4.68, which fixes this issue.

*** Pendiente de traducción *** Flowise is a drag &amp; drop user interface to build a customized large language model flow. Prior to version 3.1.2, a mass assignment vulnerability exists in the variable update endpoint of FlowiseAI. The endpoint allows authenticated users to modify server-controlled properties such as workspaceId, createdDate, and updatedDate when updating a variable resource. Due to missing server-side validation and authorization checks, an attacker can manipulate the workspaceId field and reassign variables to arbitrary workspaces. This behavior may break tenant isolation in multi-workspace environments. This issue has been patched in version 3.1.2.

*** Pendiente de traducción *** Flowise is a drag &amp; drop user interface to build a customized large language model flow. Prior to version 3.1.2, a mass assignment vulnerability exists in the tool update endpoint of FlowiseAI. The endpoint allows authenticated users to modify server-controlled properties such as workspaceId, createdDate, and updatedDate when updating a tool resource. Due to missing server-side validation and authorization checks, an attacker can manipulate the workspaceId field and reassign tools to arbitrary workspaces. This breaks tenant isolation in multi-workspace environments. This issue has been patched in version 3.1.2.

*** Pendiente de traducción *** Flowise is a drag &amp; drop user interface to build a customized large language model flow. Prior to version 3.1.2, a mass assignment vulnerability exists in the chatflow update endpoint of FlowiseAI. The endpoint allows clients to modify server-controlled properties such as deployed, isPublic, workspaceId, createdDate, and updatedDate when updating a chatflow object. Due to missing server-side validation and authorization checks, an authenticated user can manipulate internal attributes of a chatflow and reassign it to another workspace. This allows cross-workspace resource reassignment and unauthorized modification of deployment and visibility settings. This issue has been patched in version 3.1.2.

*** Pendiente de traducción *** Heap-based Buffer Overflow vulnerability in Apache HTTP Server with mod_xml2enc, xml2StartParse, and untrusted content<br /> <br /> This issue affects Apache HTTP Server: from 2.4.0 through 2.4.67.<br /> <br /> Users are recommended to upgrade to version 2.4.68, which fixes the issue.

*** Pendiente de traducción *** Software installed and run as a non-privileged user may conduct improper GPU system calls to cause mismanagement of a mapping state maintained for a sparse memory allocation.<br /> <br /> <br /> <br /> The product accidentally refers to the wrong memory due to the semantics of how math operations are implicitly scaled across buffers of different sizes.

*** Pendiente de traducción *** Shenzhen Tenda Technology Co., Ltd Tenda FH451 V1.0.0.9 was discovered to contain a stack overflow in the list1 parameter of the fromDhcpListClient function. This vulnerability allows attackers to cause a Denial of Service (DoS) via a crafted HTTP request.

*** Pendiente de traducción *** Heap-based Buffer Overflow vulnerability in Apache HTTP Server with malicious backend servers and ProxyPassReverseCookie*<br /> <br /> This issue affects Apache HTTP Server: from 2.4.0 through 2.4.67.<br /> <br /> Users are recommended to upgrade to version 2.4.68, which fixes the issue.

*** Pendiente de traducción *** A cross-site scripting vulnerability exists in mod_proxy_ftp&amp;#39;s HTML directory list generation in Apache HTTP Server 2.4.67 and earlier when listing FTP directory contents either via forward or reverse proxy configuration.<br /> <br /> Users are recommended to upgrade to version 2.4.68, which fixes this issue.

*** Pendiente de traducción *** A buffer overflow in mod_proxy_html in Apache HTTP Server 2.4.67 and earlier allows an attack by an untrusted backend.<br /> Users are recommended to upgrade to version 2.4.68, which fixes this issue.