Vulnerabilidades

*** Pendiente de traducción *** An origin validation error vulnerability in Trend Micro Apex One could allow a local attacker to escalate privileges on affected installations.<br /> <br /> Please note: an attacker must first obtain the ability to execute low-privileged code on the target system in order to exploit this vulnerability.

*** Pendiente de traducción *** Exposure of private personal information to an unauthorized actor, Insufficiently Protected Credentials vulnerability in Digital Operations Services Inc. WifiBurada allows Authentication Bypass.<br /> <br /> This issue affects WifiBurada: through 21052026. NOTE: The vendor was contacted early about this disclosure but did not respond in any way.

*** Pendiente de traducción *** Authorization bypass through User-Controlled key vulnerability in PosCube Hardware Software and Consulting Ltd. QR Menu allows Exploitation of Trusted Identifiers.<br /> <br /> This issue affects QR Menu: through 21052026. NOTE: The vendor was contacted early about this disclosure but did not respond in any way.

*** Pendiente de traducción *** The Divi Form Builder plugin for WordPress is vulnerable to privilege escalation in versions up to, and including, 5.1.2. This is due to the plugin accepting a user-controlled &amp;#39;role&amp;#39; parameter from POST data during user registration without validating it against the form&amp;#39;s configured default_user_role setting. This makes it possible for unauthenticated attackers to create administrator accounts by tampering with the role parameter during registration.

*** Pendiente de traducción *** Request Tracker is vulnerable to a reflected cross-site scripting (XSS) vulnerability via the "Page" parameter in GET requests. An attacker can craft a URL that, when opened, results in arbitrary JavaScript execution in the victim’s browser.<br /> <br /> This vulnerability affects versions from 5.0.4 up to 5.0.9 and from 6.0.0 up to 6.0.2.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fbdev: udlfb: add vm_ops to dlfb_ops_mmap to prevent use-after-free<br /> <br /> dlfb_ops_mmap() uses remap_pfn_range() to map vmalloc framebuffer pages<br /> to userspace but sets no vm_ops on the VMA. This means the kernel cannot<br /> track active mmaps. When dlfb_realloc_framebuffer() replaces the backing<br /> buffer via FBIOPUT_VSCREENINFO, existing mmap PTEs are not invalidated.<br /> On USB disconnect, dlfb_ops_destroy() calls vfree() on the old pages<br /> while userspace PTEs still reference them, resulting in a use-after-free:<br /> the process retains read/write access to freed kernel pages.<br /> <br /> Add vm_operations_struct with open/close callbacks that maintain an<br /> atomic mmap_count on struct dlfb_data. In dlfb_realloc_framebuffer(),<br /> check mmap_count and return -EBUSY if the buffer is currently mapped,<br /> preventing buffer replacement while userspace holds stale PTEs.<br /> <br /> Tested with PoC using dummy_hcd + raw_gadget USB device emulation.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> accel/ivpu: Disallow re-exporting imported GEM objects<br /> <br /> Prevent re-exporting of imported GEM buffers by adding a custom<br /> prime_handle_to_fd callback that checks if the object is imported<br /> and returns -EOPNOTSUPP if so.<br /> <br /> Re-exporting imported GEM buffers causes loss of buffer flags settings,<br /> leading to incorrect device access and data corruption.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rtmutex: Use waiter::task instead of current in remove_waiter()<br /> <br /> remove_waiter() is used by the slowlock paths, but it is also used for<br /> proxy-lock rollback in rt_mutex_start_proxy_lock() when invoked from<br /> futex_requeue().<br /> <br /> In the latter case waiter::task is not current, but remove_waiter()<br /> operates on current for the dequeue operation. That results in several<br /> problems:<br /> <br /> 1) the rbtree dequeue happens without waiter::task::pi_lock being held<br /> <br /> 2) the waiter task&amp;#39;s pi_blocked_on state is not cleared, which leaves a<br /> dangling pointer primed for UAF around.<br /> <br /> 3) rt_mutex_adjust_prio_chain() operates on the wrong top priority waiter<br /> task<br /> <br /> Use waiter::task instead of current in all related operations in<br /> remove_waiter() to cure those problems.<br /> <br /> [ tglx: Fixup rt_mutex_adjust_prio_chain(), add a comment and amend the<br /> changelog ]

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipv6: rpl: reserve mac_len headroom when recompressed SRH grows<br /> <br /> ipv6_rpl_srh_rcv() decompresses an RFC 6554 Source Routing Header, swaps<br /> the next segment into ipv6_hdr-&gt;daddr, recompresses, then pulls the old<br /> header and pushes the new one plus the IPv6 header back. The<br /> recompressed header can be larger than the received one when the swap<br /> reduces the common-prefix length the segments share with daddr (CmprI=0,<br /> CmprE&gt;0, seg[0][0] != daddr[0] gives the maximum +8 bytes).<br /> <br /> pskb_expand_head() was gated on segments_left == 0, so on earlier<br /> segments the push consumed unchecked headroom. Once skb_push() leaves<br /> fewer than skb-&gt;mac_len bytes in front of data,<br /> skb_mac_header_rebuild()&amp;#39;s call to:<br /> <br /> skb_set_mac_header(skb, -skb-&gt;mac_len);<br /> <br /> will store (data - head) - mac_len into the u16 mac_header field, which<br /> wraps to ~65530, and the following memmove() writes mac_len bytes ~64KiB<br /> past skb-&gt;head.<br /> <br /> A single AF_INET6/SOCK_RAW/IPV6_HDRINCL packet over lo with a two<br /> segment type-3 SRH (CmprI=0, CmprE=15) reaches headroom 8 after one<br /> pass; KASAN reports a 14-byte OOB write in ipv6_rthdr_rcv.<br /> <br /> Fix this by expanding the head whenever the remaining room is less than<br /> the push size plus mac_len, and request that much extra so the rebuilt<br /> MAC header fits afterwards.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/rds: handle zerocopy send cleanup before the message is queued<br /> <br /> A zerocopy send can fail after user pages have been pinned but before<br /> the message is attached to the sending socket.<br /> <br /> The purge path currently infers zerocopy state from rm-&gt;m_rs, so an<br /> unqueued message can be cleaned up as if it owned normal payload pages.<br /> However, zerocopy ownership is really determined by the presence of<br /> op_mmp_znotifier, regardless of whether the message has reached the<br /> socket queue.<br /> <br /> Capture op_mmp_znotifier up front in rds_message_purge() and use it as<br /> the cleanup discriminator. If the message is already associated with a<br /> socket, keep the existing completion path. Otherwise, drop the pinned<br /> page accounting directly and release the notifier before putting the<br /> payload pages.<br /> <br /> This keeps early send failure cleanup consistent with the zerocopy<br /> lifetime rules without changing the normal queued completion path.

*** Pendiente de traducción *** (Externally Controlled Reference to a Resource in Another Sphere), (Authorization Bypass Through User-Controlled Key) vulnerability in Apache Camel K. Authorized users in a Kubernetes namespace can create a Build resource, controlling the Pod generation in a namespace of their choice, including the operator namespace.<br /> <br /> This issue affects Apache Camel K: from 2.0.0 before 2.8.1, from 2.9.0 before 2.9.2, from 2.10.0 before 2.10.1.<br /> <br /> Users are recommended to upgrade to version 2.10.1 (or 2.8.1 or 2.9.2), which fixes the issue.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: wwan: t7xx: validate port_count against message length in t7xx_port_enum_msg_handler<br /> <br /> t7xx_port_enum_msg_handler() uses the modem-supplied port_count field as<br /> a loop bound over port_msg-&gt;data[] without checking that the message buffer<br /> contains sufficient data. A modem sending port_count=65535 in a 12-byte<br /> buffer triggers a slab-out-of-bounds read of up to 262140 bytes.<br /> <br /> Add a sizeof(*port_msg) check before accessing the port message header<br /> fields to guard against undersized messages.<br /> <br /> Add a struct_size() check after extracting port_count and before the loop.<br /> <br /> In t7xx_parse_host_rt_data(), guard the rt_feature header read with a<br /> remaining-buffer check before accessing data_len, validate feat_data_len<br /> against the actual remaining buffer to prevent OOB reads and signed<br /> integer overflow on offset.<br /> <br /> Pass msg_len from both call sites: skb-&gt;len at the DPMAIF path after<br /> skb_pull(), and the validated feat_data_len at the handshake path.