Vulnerabilities

Apache CXF allows to set a limit on the number of form parameters in a JAX-RS message via the "maxFormParameterCount" configuration option. However, no default limit is set which may lead to denial of service attacks when processing  requests with very large numbers of form parameters. Users are recommended to upgrade to versions 4.2.3 or 4.1.8 or 3.6.12, which fix this issue by using a default limit of 500 parameters.

Apache CXF reads a top-level WSDL through its hardened StaxUtils path, which disables XML DTDs and external entities. However, any  or  referenced from that top-level WSDL is handed off to WSDL4J, which does not disable DOCTYPE declarations or external entities. As a result, the protections applied to the top-level document do not extend to imported documents, leaving imported WSDL/XSD content vulnerable to XML External Entity (XXE) attacks. Users are recommended to upgrade to versions 4.2.3 or 4.1.8 or 3.6.12, which fix this issue.

Apache CXF's JMS transport deserializes the body of any inbound JMS ObjectMessage using native Java deserialization, with no type restrictions in place. Any attacker able to place a message on the service's JMS destination can submit a malicious serialized object, leading to denial of service or, if a suitable gadget class is on the classpath, remote code execution. The fix disables ObjectMessage deserialization by default, with a configuration switch to re-enable it if needed. Users are recommended to upgrade to versions 4.2.3 or 4.1.8 or 3.6.12, which fix this issue.

The OpenID Connect Core 1.0 specification mandates that the RP MUST validate the `c_hash` parameter when operating in the Hybrid Flow. If an Apache CXF RP is integrated with a non-compliant or misconfigured Identity Provider (IdP) that omits the `c_hash`, the RP becomes vulnerable to Authorization Code Substitution/Injection attacks. Users are recommended to upgrade to versions 4.2.3 or 4.1.8 or 3.6.12, which fix this issue.

A vulnerability was determined in Shibby Tomato 1.28.0000. Affected by this vulnerability is the function new_qoslimit_stop of the file /tmp/qoslimittc_stop.sh. Executing a manipulation of the argument wan_iface can lead to os command injection. The attack can be launched remotely. The exploit has been publicly disclosed and may be utilized. This project is superseded by FreshTomato.

An improper access control check in CatchPulse's named pipe communication interface could allow an attacker to invoke CatchPulse functions. This is limited to operations that enforce more restrictive security policies.

A denial-of-service vulnerability in CatchPulse could allow an attacker to conduct a stack buffer overrun attack, leading to a denial-of-service condition.

An improper access control vulnerability in CatchPulse could allow a non-administrative local attacker to connect to an unrestricted kernel filter communication port and bypass CatchPulse's security policy enforcement.

Apache Polaris did not consistently validate storage locations supplied during table and view registration.<br /> <br /> An authenticated principal with permission to register a table or view could, depending on the affected release and registration path, cause Polaris to use the catalog&amp;#39;s storage credentials to read a caller-selected Iceberg metadata file before verifying that the file was within the catalog&amp;#39;s allowed storage locations.<br /> <br /> If the catalog&amp;#39;s underlying credentials could read an object outside that boundary, this could disclose limited information from the object.<br /> <br /> <br /> Polaris could also accept registration metadata located within an allowed location that contained references to storage locations outside the allowed boundary.<br /> <br /> This second condition did not itself cause Polaris to read the referenced external locations during registration.<br /> <br /> <br /> The demonstrated impact is limited to confidentiality.<br /> <br /> No unauthorized data modification or availability impact has been demonstrated.<br /> <br /> <br /> The server-side read requires a deployment using S3 credential vending and an object outside the allowed locations that the catalog&amp;#39;s underlying storage credentials can read.<br /> <br /> Exploitation requires an authenticated principal with table- or view-registration privileges.

A vulnerability was determined in OpenHands up to 0.62.0. The affected element is the function initialize_repo of the file OpenHands/resolver/send_pull_request.py. This manipulation causes command injection. Remote exploitation of the attack is possible. The vendor deleted the original GitHub issue report. It appears that the affected path/file got removed in version 1.7.0.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> platform/x86: intel-hid: Protect ACPI notify handler against recursion<br /> <br /> Since commit e2ffcda16290 ("ACPI: OSL: Allow Notify () handlers to run on<br /> all CPUs") ACPI notify handlers like the intel-hid notify_handler() may<br /> run on multiple CPU cores racing with themselves.<br /> <br /> On convertibles and detachables (matched by DMI chassis-type 31 and 32 in<br /> dmi_auto_add_switch[]) the SW_TABLET_MODE input device is registered<br /> lazily from notify_handler() on the first tablet-mode event, via<br /> intel_hid_switches_setup(). When two such events race on different CPUs<br /> both can pass the !priv-&gt;switches check and register the priv-&gt;switches<br /> input device twice, resulting in a duplicate sysfs entry and a subsequent<br /> NULL pointer dereference.<br /> <br /> This is the same class of bug fixed by commit e075c3b13a0a ("platform/x86:<br /> intel-vbtn: Protect ACPI notify handler against recursion") for the<br /> sibling intel-vbtn driver.<br /> <br /> Protect intel-hid notify_handler() from racing with itself with a mutex<br /> to fix this.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: VMX: Grab vmcs12 on CR8 interception update iff vCPU is in guest mode<br /> <br /> When updating CR8 intercepts, get vmcs12 if and only if the vCPU is in<br /> guest mode so that a future change can have update CR8 intercepts during<br /> vCPU creation, without running afoul of get_vmcs12()&amp;#39;s lockdep assertion.<br /> <br /> ------------[ cut here ]------------<br /> debug_locks &amp;&amp; !(lock_is_held(&amp;(&amp;vcpu-&gt;mutex)-&gt;dep_map) || !refcount_read(&amp;vcpu-&gt;kvm-&gt;users_count))<br /> WARNING: arch/x86/kvm/vmx/nested.h:61 at get_vmcs12 arch/x86/kvm/vmx/nested.h:60 [inline], CPU#0: syz.2.19/5879<br /> WARNING: arch/x86/kvm/vmx/nested.h:61 at vmx_update_cr8_intercept+0x3de/0x4e0 arch/x86/kvm/vmx/vmx.c:6879, CPU#0: syz.2.19/5879<br /> Modules linked in:<br /> CPU: 0 UID: 0 PID: 5879 Comm: syz.2.19 Not tainted syzkaller #0 PREEMPT(full)<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 04/01/2014<br /> RIP: 0010:get_vmcs12 arch/x86/kvm/vmx/nested.h:60 [inline]<br /> RIP: 0010:vmx_update_cr8_intercept+0x3de/0x4e0 arch/x86/kvm/vmx/vmx.c:6879<br /> Call Trace:<br /> <br /> apic_update_ppr arch/x86/kvm/lapic.c:984 [inline]<br /> kvm_lapic_reset+0x1c24/0x2980 arch/x86/kvm/lapic.c:3023<br /> kvm_vcpu_reset+0x44c/0x1bf0 arch/x86/kvm/x86.c:12986<br /> kvm_arch_vcpu_create+0x746/0x8b0 arch/x86/kvm/x86.c:12847<br /> kvm_vm_ioctl_create_vcpu+0x428/0x930 virt/kvm/kvm_main.c:4201<br /> kvm_vm_ioctl+0x893/0xd50 virt/kvm/kvm_main.c:5159<br /> vfs_ioctl fs/ioctl.c:51 [inline]<br /> __do_sys_ioctl fs/ioctl.c:597 [inline]<br /> __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:583<br /> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]<br /> do_syscall_64+0x174/0x580 arch/x86/entry/syscall_64.c:94<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> <br /> No functional change intended.