Vulnerabilities

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

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.

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.

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.

A flaw was found in glib. Missing validation of offset and count parameters in the g_buffered_input_stream_peek() function can lead to an integer overflow during length calculation. When specially crafted values are provided, this overflow results in an incorrect size being passed to memcpy(), triggering a buffer overflow. This can cause application crashes, leading to a Denial of Service (DoS).

Denial-of-service vulnerability in M-Files Server versions before 26.1.15632.3 allows an authenticated attacker with vault administrator privileges to crash the M-Files Server process by calling a vulnerable API endpoint.

The installer of ServerView Agents for Windows provided by Fsas Technologies Inc. may insecurely load Dynamic Link Libraries. Arbitrary code may be executed with the administrator privilege when the installer is executed.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/sched: sch_qfq: Fix NULL deref when deactivating inactive aggregate in qfq_reset<br /> <br /> `qfq_class-&gt;leaf_qdisc-&gt;q.qlen &gt; 0` does not imply that the class<br /> itself is active.<br /> <br /> Two qfq_class objects may point to the same leaf_qdisc. This happens<br /> when:<br /> <br /> 1. one QFQ qdisc is attached to the dev as the root qdisc, and<br /> <br /> 2. another QFQ qdisc is temporarily referenced (e.g., via qdisc_get()<br /> / qdisc_put()) and is pending to be destroyed, as in function<br /> tc_new_tfilter.<br /> <br /> When packets are enqueued through the root QFQ qdisc, the shared<br /> leaf_qdisc-&gt;q.qlen increases. At the same time, the second QFQ<br /> qdisc triggers qdisc_put and qdisc_destroy: the qdisc enters<br /> qfq_reset() with its own q-&gt;q.qlen == 0, but its class&amp;#39;s leaf<br /> qdisc-&gt;q.qlen &gt; 0. Therefore, the qfq_reset would wrongly deactivate<br /> an inactive aggregate and trigger a null-deref in qfq_deactivate_agg:<br /> <br /> [ 0.903172] BUG: kernel NULL pointer dereference, address: 0000000000000000<br /> [ 0.903571] #PF: supervisor write access in kernel mode<br /> [ 0.903860] #PF: error_code(0x0002) - not-present page<br /> [ 0.904177] PGD 10299b067 P4D 10299b067 PUD 10299c067 PMD 0<br /> [ 0.904502] Oops: Oops: 0002 [#1] SMP NOPTI<br /> [ 0.904737] CPU: 0 UID: 0 PID: 135 Comm: exploit Not tainted 6.19.0-rc3+ #2 NONE<br /> [ 0.905157] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.17.0-0-gb52ca86e094d-prebuilt.qemu.org 04/01/2014<br /> [ 0.905754] RIP: 0010:qfq_deactivate_agg (include/linux/list.h:992 (discriminator 2) include/linux/list.h:1006 (discriminator 2) net/sched/sch_qfq.c:1367 (discriminator 2) net/sched/sch_qfq.c:1393 (discriminator 2))<br /> [ 0.906046] Code: 0f 84 4d 01 00 00 48 89 70 18 8b 4b 10 48 c7 c2 ff ff ff ff 48 8b 78 08 48 d3 e2 48 21 f2 48 2b 13 48 8b 30 48 d3 ea 8b 4b 18 0<br /> <br /> Code starting with the faulting instruction<br /> ===========================================<br /> 0: 0f 84 4d 01 00 00 je 0x153<br /> 6: 48 89 70 18 mov %rsi,0x18(%rax)<br /> a: 8b 4b 10 mov 0x10(%rbx),%ecx<br /> d: 48 c7 c2 ff ff ff ff mov $0xffffffffffffffff,%rdx<br /> 14: 48 8b 78 08 mov 0x8(%rax),%rdi<br /> 18: 48 d3 e2 shl %cl,%rdx<br /> 1b: 48 21 f2 and %rsi,%rdx<br /> 1e: 48 2b 13 sub (%rbx),%rdx<br /> 21: 48 8b 30 mov (%rax),%rsi<br /> 24: 48 d3 ea shr %cl,%rdx<br /> 27: 8b 4b 18 mov 0x18(%rbx),%ecx<br /> ...<br /> [ 0.907095] RSP: 0018:ffffc900004a39a0 EFLAGS: 00010246<br /> [ 0.907368] RAX: ffff8881043a0880 RBX: ffff888102953340 RCX: 0000000000000000<br /> [ 0.907723] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000<br /> [ 0.908100] RBP: ffff888102952180 R08: 0000000000000000 R09: 0000000000000000<br /> [ 0.908451] R10: ffff8881043a0000 R11: 0000000000000000 R12: ffff888102952000<br /> [ 0.908804] R13: ffff888102952180 R14: ffff8881043a0ad8 R15: ffff8881043a0880<br /> [ 0.909179] FS: 000000002a1a0380(0000) GS:ffff888196d8d000(0000) knlGS:0000000000000000<br /> [ 0.909572] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 0.909857] CR2: 0000000000000000 CR3: 0000000102993002 CR4: 0000000000772ef0<br /> [ 0.910247] PKRU: 55555554<br /> [ 0.910391] Call Trace:<br /> [ 0.910527] <br /> [ 0.910638] qfq_reset_qdisc (net/sched/sch_qfq.c:357 net/sched/sch_qfq.c:1485)<br /> [ 0.910826] qdisc_reset (include/linux/skbuff.h:2195 include/linux/skbuff.h:2501 include/linux/skbuff.h:3424 include/linux/skbuff.h:3430 net/sched/sch_generic.c:1036)<br /> [ 0.911040] __qdisc_destroy (net/sched/sch_generic.c:1076)<br /> [ 0.911236] tc_new_tfilter (net/sched/cls_api.c:2447)<br /> [ 0.911447] rtnetlink_rcv_msg (net/core/rtnetlink.c:6958)<br /> [ 0.911663] ? __pfx_rtnetlink_rcv_msg (net/core/rtnetlink.c:6861)<br /> [ 0.911894] netlink_rcv_skb (net/netlink/af_netlink.c:2550)<br /> [ 0.912100] netlink_unicast (net/netlink/af_netlink.c:1319 net/netlink/af_netlink.c:1344)<br /> [ 0.912296] ? __alloc_skb (net/core/skbuff.c:706)<br /> [ 0.912484] netlink_sendmsg (net/netlink/af<br /> ---truncated---

telnetd in GNU Inetutils through 2.7 allows remote authentication bypass via a "-f root" value for the USER environment variable.

A flaw was found in the keycloak-services component of Keycloak. This vulnerability allows the issuance of access and refresh tokens for disabled users, leading to unauthorized use of previously revoked privileges, via a business logic vulnerability in the Token Exchange implementation when a privileged client invokes the token exchange flow.

A flaw was found in the Keycloak server during refresh token processing, specifically in the TokenManager class responsible for enforcing refresh token reuse policies. When strict refresh token rotation is enabled, the validation and update of refresh token usage are not performed atomically. This allows concurrent refresh requests to bypass single-use enforcement and issue multiple access tokens from the same refresh token. As a result, Keycloak’s refresh token rotation hardening can be undermined.

Rejected reason: Not used