Vulnerabilidades

*** Pendiente de traducción *** Tenda AX-1806 v1.0.0.1 was discovered to contain a stack overflow in the time parameter of the sub_60CFC function. This vulnerability allows attackers to cause a Denial of Service (DoS) via a crafted request.

*** Pendiente de traducción *** Tenda AX1803 v1.0.0.1 was discovered to contain a stack overflow in the security parameter of the sub_72290 function. This vulnerability allows attackers to cause a Denial of Service (DoS) via a crafted request.

*** Pendiente de traducción *** The WorklogPRO - Timesheets for Jira plugin in Jira Data Center before version 4.23.6-jira10 and before version 4.23.5-jira9 allows users and attackers to inject arbitrary HTML or JavaScript via a Cross-Site Scripting (XSS) vulnerability. The vulnerability is exploited via a specially crafted payload placed in an issue's summary field

*** Pendiente de traducción *** Authentication Bypass by Primary Weakness vulnerability in Jamf Jamf Pro allows unspecified impact.This issue affects Jamf Pro: from 11.20 through 11.24.

*** Pendiente de traducción *** Tenda AX-1806 v1.0.0.1 was discovered to contain a stack overflow in the deviceList parameter of the formSetMacFilterCfg function. This vulnerability allows attackers to cause a Denial of Service (DoS) via a crafted request.

*** Pendiente de traducción *** Tenda AX-1806 v1.0.0.1 was discovered to contain a stack overflow in the deviceList parameter of the formSetWifiMacFilterCfg function. This vulnerability allows attackers to cause a Denial of Service (DoS) via a crafted request.

*** Pendiente de traducción *** Tenda AX-1803 v1.0.0.1 was discovered to contain a stack overflow in the ssid parameter of the form_fast_setting_wifi_set function. This vulnerability allows attackers to cause a Denial of Service (DoS) via a crafted request.

*** Pendiente de traducción *** Malformed BRID/HHIT records can cause `named` to terminate unexpectedly.<br /> This issue affects BIND 9 versions 9.18.40 through 9.18.43, 9.20.13 through 9.20.17, 9.21.12 through 9.21.16, 9.18.40-S1 through 9.18.43-S1, and 9.20.13-S1 through 9.20.17-S1.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: sock: fix hardened usercopy panic in sock_recv_errqueue<br /> <br /> skbuff_fclone_cache was created without defining a usercopy region,<br /> [1] unlike skbuff_head_cache which properly whitelists the cb[] field.<br /> [2] This causes a usercopy BUG() when CONFIG_HARDENED_USERCOPY is<br /> enabled and the kernel attempts to copy sk_buff.cb data to userspace<br /> via sock_recv_errqueue() -&gt; put_cmsg().<br /> <br /> The crash occurs when: 1. TCP allocates an skb using alloc_skb_fclone()<br /> (from skbuff_fclone_cache) [1]<br /> 2. The skb is cloned via skb_clone() using the pre-allocated fclone<br /> [3] 3. The cloned skb is queued to sk_error_queue for timestamp<br /> reporting 4. Userspace reads the error queue via recvmsg(MSG_ERRQUEUE)<br /> 5. sock_recv_errqueue() calls put_cmsg() to copy serr-&gt;ee from skb-&gt;cb<br /> [4] 6. __check_heap_object() fails because skbuff_fclone_cache has no<br /> usercopy whitelist [5]<br /> <br /> When cloned skbs allocated from skbuff_fclone_cache are used in the<br /> socket error queue, accessing the sock_exterr_skb structure in skb-&gt;cb<br /> via put_cmsg() triggers a usercopy hardening violation:<br /> <br /> [ 5.379589] usercopy: Kernel memory exposure attempt detected from SLUB object &amp;#39;skbuff_fclone_cache&amp;#39; (offset 296, size 16)!<br /> [ 5.382796] kernel BUG at mm/usercopy.c:102!<br /> [ 5.383923] Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI<br /> [ 5.384903] CPU: 1 UID: 0 PID: 138 Comm: poc_put_cmsg Not tainted 6.12.57 #7<br /> [ 5.384903] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014<br /> [ 5.384903] RIP: 0010:usercopy_abort+0x6c/0x80<br /> [ 5.384903] Code: 1a 86 51 48 c7 c2 40 15 1a 86 41 52 48 c7 c7 c0 15 1a 86 48 0f 45 d6 48 c7 c6 80 15 1a 86 48 89 c1 49 0f 45 f3 e8 84 27 88 ff 0b 490<br /> [ 5.384903] RSP: 0018:ffffc900006f77a8 EFLAGS: 00010246<br /> [ 5.384903] RAX: 000000000000006f RBX: ffff88800f0ad2a8 RCX: 1ffffffff0f72e74<br /> [ 5.384903] RDX: 0000000000000000 RSI: 0000000000000004 RDI: ffffffff87b973a0<br /> [ 5.384903] RBP: 0000000000000010 R08: 0000000000000000 R09: fffffbfff0f72e74<br /> [ 5.384903] R10: 0000000000000003 R11: 79706f6372657375 R12: 0000000000000001<br /> [ 5.384903] R13: ffff88800f0ad2b8 R14: ffffea00003c2b40 R15: ffffea00003c2b00<br /> [ 5.384903] FS: 0000000011bc4380(0000) GS:ffff8880bf100000(0000) knlGS:0000000000000000<br /> [ 5.384903] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 5.384903] CR2: 000056aa3b8e5fe4 CR3: 000000000ea26004 CR4: 0000000000770ef0<br /> [ 5.384903] PKRU: 55555554<br /> [ 5.384903] Call Trace:<br /> [ 5.384903] <br /> [ 5.384903] __check_heap_object+0x9a/0xd0<br /> [ 5.384903] __check_object_size+0x46c/0x690<br /> [ 5.384903] put_cmsg+0x129/0x5e0<br /> [ 5.384903] sock_recv_errqueue+0x22f/0x380<br /> [ 5.384903] tls_sw_recvmsg+0x7ed/0x1960<br /> [ 5.384903] ? srso_alias_return_thunk+0x5/0xfbef5<br /> [ 5.384903] ? schedule+0x6d/0x270<br /> [ 5.384903] ? srso_alias_return_thunk+0x5/0xfbef5<br /> [ 5.384903] ? mutex_unlock+0x81/0xd0<br /> [ 5.384903] ? __pfx_mutex_unlock+0x10/0x10<br /> [ 5.384903] ? __pfx_tls_sw_recvmsg+0x10/0x10<br /> [ 5.384903] ? _raw_spin_lock_irqsave+0x8f/0xf0<br /> [ 5.384903] ? _raw_read_unlock_irqrestore+0x20/0x40<br /> [ 5.384903] ? srso_alias_return_thunk+0x5/0xfbef5<br /> <br /> The crash offset 296 corresponds to skb2-&gt;cb within skbuff_fclones:<br /> - sizeof(struct sk_buff) = 232 - offsetof(struct sk_buff, cb) = 40 -<br /> offset of skb2.cb in fclones = 232 + 40 = 272 - crash offset 296 =<br /> 272 + 24 (inside sock_exterr_skb.ee)<br /> <br /> This patch uses a local stack variable as a bounce buffer to avoid the hardened usercopy check failure.<br /> <br /> [1] https://elixir.bootlin.com/linux/v6.12.62/source/net/ipv4/tcp.c#L885<br /> [2] https://elixir.bootlin.com/linux/v6.12.62/source/net/core/skbuff.c#L5104<br /> [3] https://elixir.bootlin.com/linux/v6.12.62/source/net/core/skbuff.c#L5566<br /> [4] https://elixir.bootlin.com/linux/v6.12.62/source/net/core/skbuff.c#L5491<br /> [5] https://elixir.bootlin.com/linux/v6.12.62/source/mm/slub.c#L5719

*** Pendiente de traducción *** The "create core" API of Apache Solr 8.6 through 9.10.0 lacks sufficient input validation on some API parameters, which can cause Solr to check the existence of and attempt to read file-system paths that should be disallowed by Solr&amp;#39;s "allowPaths" security setting https://https://solr.apache.org/guide/solr/latest/configuration-guide/configuring-solr-xml.html#the-solr-element .  These read-only accesses can allow users to create cores using unexpected configsets if any are accessible via the filesystem.  On Windows systems configured to allow UNC paths this can additionally cause disclosure of NTLM "user" hashes. <br /> <br /> Solr deployments are subject to this vulnerability if they meet the following criteria:<br /> * Solr is running in its "standalone" mode.<br /> * Solr&amp;#39;s "allowPath" setting is being used to restrict file access to certain directories.<br /> * Solr&amp;#39;s "create core" API is exposed and accessible to untrusted users.  This can happen if Solr&amp;#39;s RuleBasedAuthorizationPlugin https://solr.apache.org/guide/solr/latest/deployment-guide/rule-based-authorization-plugin.html is disabled, or if it is enabled but the "core-admin-edit" predefined permission (or an equivalent custom permission) is given to low-trust (i.e. non-admin) user roles.<br /> <br /> Users can mitigate this by enabling Solr&amp;#39;s RuleBasedAuthorizationPlugin (if disabled) and configuring a permission-list that prevents untrusted users from creating new Solr cores.  Users should also upgrade to Apache Solr 9.10.1 or greater, which contain fixes for this issue.

*** Pendiente de traducción *** Deployments of Apache Solr 5.3.0 through 9.10.0 that rely on Solr&amp;#39;s "Rule Based Authorization Plugin" are vulnerable to allowing unauthorized access to certain Solr APIs, due to insufficiently strict input validation in those components.  Only deployments that meet all of the following criteria are impacted by this vulnerability:<br /> <br /> * Use of Solr&amp;#39;s "RuleBasedAuthorizationPlugin"<br /> * A RuleBasedAuthorizationPlugin config (see security.json) that specifies multiple "roles"<br /> * A RuleBasedAuthorizationPlugin permission list (see security.json) that uses one or more of the following pre-defined permission rules: "config-read", "config-edit", "schema-read", "metrics-read", or "security-read".<br /> * A RuleBasedAuthorizationPlugin permission list that doesn&amp;#39;t define the "all" pre-defined permission<br /> * A networking setup that allows clients to make unfiltered network requests to Solr. (i.e. user-submitted HTTP/HTTPS requests reach Solr as-is, unmodified or restricted by any intervening proxy or gateway)<br /> <br /> Users can mitigate this vulnerability by ensuring that their RuleBasedAuthorizationPlugin configuration specifies the "all" pre-defined permission and associates the permission with an "admin" or other privileged role.  Users can also upgrade to a Solr version outside of the impacted range, such as the recently released Solr 9.10.1.

*** Pendiente de traducción *** A flaw was found in the Keycloak Admin REST API. This vulnerability allows the exposure of backend schema and rules, potentially leading to targeted attacks or privilege escalation via improper access control.