Vulnerabilidades

*** Pendiente de traducción *** A security flaw has been discovered in itsourcecode Hospital Management System 1.0. Affected is an unknown function of the file /viewmedicine.php. Performing a manipulation of the argument delid results in sql injection. The attack can be initiated remotely. The exploit has been released to the public and may be used for attacks.

*** Pendiente de traducción *** DBI versions before 1.652 for Perl allow a heap out-of-bounds write on 32-bit perl via an integer wraparound in the output buffer size computed by preparse.<br /> <br /> preparse reserves its output buffer with `newSV(strlen(statement) * 7 + 16)`, budgeting seven output bytes per input byte for the longest &amp;#39;:p99999&amp;#39; expansion. The product is computed in STRLEN, which is 32 bits wide on a 32-bit perl build, so a statement of 613,566,757 bytes multiplies to 4,294,967,299, wraps modulo 2^32 to 3, and reserves 19 bytes. The parser then copies the statement out through a raw pointer with no capacity check, writing the whole 585 MB input past the end of the allocation. The 99,999 placeholder limit does not bound this path, which is reached by ordinary non-placeholder content.<br /> <br /> Any caller that passes an untrusted statement of that length to preparse on a 32-bit perl gets a heap out-of-bounds write of attacker controlled bytes. Builds with a 64-bit STRLEN are not affected, since the wrap there needs a statement of about 2.3 exabytes.

*** Pendiente de traducción *** DBI versions before 1.652 for Perl allow a heap out-of-bounds write via an unvalidated numeric placeholder that sets the binder counter in preparse.<br /> <br /> preparse reserves seven output bytes per input byte, the width of the longest &amp;#39;:p99999&amp;#39; expansion. The &amp;#39;:N&amp;#39; branch parses the number with `atoi(src)` and assigns it to the binder counter with no range check, so a statement containing &amp;#39;:2147483648&amp;#39; leaves the counter negative (-2147483648 with glibc, where atoi wraps). Each following &amp;#39;?&amp;#39; then expands through `sprintf(start, ":p%d", idx++)` to &amp;#39;:p-2147483648&amp;#39;, 14 bytes with the terminating NUL where the buffer budgets 7. The placeholder limit added in 1.650 tests the counter against 99,999, which a negative counter passes.<br /> <br /> Any caller that preparses an untrusted statement into &amp;#39;:pN&amp;#39; style placeholders gets a heap out-of-bounds write that grows with the number of &amp;#39;?&amp;#39; marks following the poisoned placeholder. The &amp;#39;?&amp;#39; and &amp;#39;%s&amp;#39; return styles compare the parsed number against the expected sequence and error out, and are unaffected.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/xe: Wait on external BO kernel fences in exec IOCTL<br /> <br /> Before arming a user job, xe_exec_ioctl() only added the VM&amp;#39;s<br /> dma-resv KERNEL slot as a dependency. That slot covers rebinds and<br /> the kernel operations of the VM&amp;#39;s private BOs, but not external BOs<br /> (bo-&gt;vm == NULL), which carry their kernel operations (evictions,<br /> moves, ...) in their own dma-resv KERNEL slot.<br /> <br /> The DMA_RESV_USAGE_KERNEL slot is the cross-driver contract for<br /> memory management operations that must complete before the BO or its<br /> backing store may be used: any accessor is required to wait on the<br /> KERNEL fences before touching the resv. By skipping the external BOs&amp;#39;<br /> KERNEL slots, the exec path violated that contract and could schedule<br /> a user job while a kernel operation on an external BO mapped by the VM<br /> was still in flight, racing against it and potentially reading or<br /> writing memory that was being moved.<br /> <br /> Replace the VM-only dependency with an iteration over every object<br /> locked by the exec, adding each object&amp;#39;s KERNEL slot as a job<br /> dependency. This covers the VM resv (rebinds and private BOs) as well<br /> as every external BO, mirroring the drm_gpuvm_resv_add_fence() call<br /> that later publishes the job fence to the same set of objects.<br /> Long-running mode continues to skip this, as before.<br /> <br /> (cherry picked from commit a6b842acf3ddd1efc53a56de9260cfa718fb35e7)

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: typec: ucsi: Fix race condition and ordering in port unregistration<br /> <br /> A synchronization issue exists during port unregistration where pending<br /> partner work items can race against workqueue destruction, leading to<br /> use-after-free conditions:<br /> <br /> cros_ec_ucsi cros_ec_ucsi.3.auto: error -ETIMEDOUT: PPM init failed<br /> BUG: kernel NULL pointer dereference, address: 0000000000000000<br /> RIP: 0010:__queue_work+0x83/0x4a0<br /> Call Trace:<br /> <br /> __cfi_delayed_work_timer_fn+0x10/0x10<br /> run_timer_softirq+0x3b6/0xbd0<br /> sched_clock_cpu+0xc/0x110<br /> irq_exit_rcu+0x18d/0x330<br /> fred_sysvec_apic_timer_interrupt+0x5e/0x80<br /> <br /> Fix this by ensuring strict ordering and proper serialization during<br /> teardown:<br /> <br /> 1. Move ucsi_unregister_partner() to the beginning of the teardown<br /> sequence and protect it under the connector mutex lock.<br /> 2. Ensure all pending partner tasks are explicitly flushed and finished<br /> before the workqueue is destroyed.<br /> 3. Switch from mod_delayed_work() to a cancel_delayed_work() and<br /> queue_delayed_work() sequence. This guarantees that items currently marked<br /> as pending won&amp;#39;t be scheduled an additional time, preventing a double<br /> release of resources which leads to the following crash:<br /> <br /> Oops: general protection fault, probably for non-canonical address<br /> 0xdead000000000122: 0000 [#1] SMP NOPTI<br /> Workqueue: cros_ec_ucsi.3.auto-con2 ucsi_poll_worker<br /> RIP: 0010:ucsi_poll_worker+0x65/0x1e0<br /> Call Trace:<br /> <br /> process_scheduled_works+0x218/0x6d0<br /> worker_thread+0x188/0x3f0<br /> __cfi_worker_thread+0x10/0x10<br /> kthread+0x226/0x2a0<br /> <br /> To ensure these rules are applied identically across both the normal<br /> teardown and the ucsi_init() error paths, consolidate the cleanup logic<br /> into a new helper, ucsi_unregister_port().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/vmwgfx: avoid destroy_workqueue(NULL) on vkms init failure<br /> <br /> Two paths through vmw_vkms_init() can leave vmw-&gt;crc_workq NULL while<br /> still leaving the rest of the driver in a state that calls<br /> vmw_vkms_cleanup() at module unload:<br /> <br /> 1. vmw_host_get_guestinfo(GUESTINFO_VBLANK, ...) failing or<br /> returning an oversized buffer -- the common case on hosts<br /> without a VBLANK guestinfo entry -- early-returned before the<br /> workqueue allocation.<br /> 2. alloc_ordered_workqueue() returning NULL on memory pressure.<br /> <br /> vmw_vkms_cleanup() then calls destroy_workqueue(NULL), which<br /> dereferences wq-&gt;name and panics.<br /> <br /> Fix the first case by removing the early return: vmw-&gt;vkms_enabled<br /> is already false on the rpci-failure path so no work will ever be<br /> queued, and allocating the workqueue unconditionally keeps the<br /> control flow simple. Fix the second case by guarding the cleanup<br /> with a NULL check, since alloc_ordered_workqueue() can still fail<br /> under low memory.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/vmwgfx: bound DMA command body size against suffix pointer<br /> <br /> vmw_cmd_dma() locates the DMA suffix at<br /> <br /> (unsigned long) &amp;cmd-&gt;body + header-&gt;size - sizeof(*suffix)<br /> <br /> without checking that header-&gt;size is large enough to contain both<br /> cmd-&gt;body and the suffix. An undersized header makes the suffix<br /> pointer underflow back into the previous command in the bounce<br /> buffer. The verifier later writes suffix-&gt;maximumOffset, clobbering<br /> verified fields of an already-relocated earlier command -- a TOCTOU<br /> on the device-visible command stream that lets one command rewrite<br /> another&amp;#39;s GMR id, surface id, or other authenticated fields.<br /> <br /> Reject the command if the body is too small for the suffix to fit.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/vmwgfx: validate DRAW_PRIMITIVES header size before division<br /> <br /> vmw_cmd_draw() computes<br /> <br /> maxnum = (header-&gt;size - sizeof(cmd-&gt;body)) / sizeof(*decl);<br /> <br /> where header-&gt;size is u32 and is taken straight from the user-supplied<br /> command stream. When header-&gt;size is less than sizeof(cmd-&gt;body) the<br /> unsigned subtraction wraps to nearly 4 GiB, producing a huge maxnum.<br /> Any user-controlled cmd-&gt;body.numVertexDecls then passes the bound and<br /> the loop dereferences decl[i] far past the end of the kernel command<br /> bounce buffer, producing an out-of-bounds read of kernel memory.<br /> <br /> Reject undersized headers up front.

*** Pendiente de traducción *** A vulnerability was identified in D-Link DIR-842 2.01.B04. This impacts an unknown function of the file /etc/vsftpd.conf of the component vsftpd. Such manipulation leads to incorrect default permissions. It is possible to launch the attack remotely. A high complexity level is associated with this attack. The exploitability is said to be difficult.

*** Pendiente de traducción *** The WPML Multilingual CMS plugin for WordPress is vulnerable to SQL Injection via the &amp;#39;sorting&amp;#39; parameter in all versions up to, and including, 4.9.5 due to insufficient escaping on the user supplied parameter and lack of sufficient preparation on the existing SQL query. This makes it possible for authenticated attackers, with translator-level access and above, to append additional SQL queries into already existing queries that can be used to extract sensitive information from the database.

*** Pendiente de traducción *** Exposure of data element to wrong session vulnerability in the JSON plugin of Apache Struts. Per-request parsing state could be shared across concurrent requests, allowing data associated with one request to become observable in another, and configured parsing limits not to be enforced as intended. Populating actions from a JSON request body is not enabled by default; applications that do not use the JSON plugin are not affected.<br /> <br /> This issue affects Apache Struts: 7.2.1.<br /> <br /> Users are recommended to upgrade to version 7.3.0, which fixes the issue.

*** Pendiente de traducción *** Exposure of data element to wrong session vulnerability in the JSON plugin of Apache Struts. Per-response serialization state could be shared across concurrent requests, allowing response content associated with one request to become observable in another. Only the SMD / JSON-RPC handling of the JSON interceptor is affected, which is not enabled by default; applications using the json result type are not affected.<br /> <br /> This issue affects Apache Struts: 7.2.1.<br /> <br /> Users are recommended to upgrade to version 7.3.0, which fixes the issue.