Vulnerabilities

SQL Injection vulnerability in RuoYi v.4.7.9 and before allows a remote attacker to execute arbitrary code via the createTable function in SqlUtil.java.

An integer overflow in the RTPS protocol implementation of OpenDDS DDS before v3.33.0 allows attackers to cause a Denial of Service (DoS) via a crafted message.

Improper verification of the time certificate in Eclipse Cyclone DDS before v0.10.5 allows attackers to bypass certificate checks and execute commands with System privileges.

Rejected reason: This CVE id was assigned but later discarded.

Rejected reason: This CVE id was assigned but later discarded.

eProsima Fast-DDS v3.3 was discovered to contain improper validation for ticket revocation, resulting in insecure communications and connections.

Netgear EX8000 V1.0.0.126 was discovered to contain a command injection vulnerability via the switch_status function.

Netgear EX8000 V1.0.0.126 is vulnerable to Command Injection via the iface parameter in the action_bandwidth function.

An integer overflow in eProsima Fast-DDS v3.3 allows attackers to cause a Denial of Service (DoS) via a crafted input.

Rejected reason: This CVE id was assigned but later discarded.

FreyrSCADA/IEC-60870-5-104 server v21.06.008 allows remote attackers to cause a denial of service by sending specific message sequences.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> veth: reduce XDP no_direct return section to fix race<br /> <br /> As explain in commit fa349e396e48 ("veth: Fix race with AF_XDP exposing<br /> old or uninitialized descriptors") for veth there is a chance after<br /> napi_complete_done() that another CPU can manage start another NAPI<br /> instance running veth_pool(). For NAPI this is correctly handled as the<br /> napi_schedule_prep() check will prevent multiple instances from getting<br /> scheduled, but for the remaining code in veth_pool() this can run<br /> concurrent with the newly started NAPI instance.<br /> <br /> The problem/race is that xdp_clear_return_frame_no_direct() isn&amp;#39;t<br /> designed to be nested.<br /> <br /> Prior to commit 401cb7dae813 ("net: Reference bpf_redirect_info via<br /> task_struct on PREEMPT_RT.") the temporary BPF net context<br /> bpf_redirect_info was stored per CPU, where this wasn&amp;#39;t an issue. Since<br /> this commit the BPF context is stored in &amp;#39;current&amp;#39; task_struct. When<br /> running veth in threaded-NAPI mode, then the kthread becomes the storage<br /> area. Now a race exists between two concurrent veth_pool() function calls<br /> one exiting NAPI and one running new NAPI, both using the same BPF net<br /> context.<br /> <br /> Race is when another CPU gets within the xdp_set_return_frame_no_direct()<br /> section before exiting veth_pool() calls the clear-function<br /> xdp_clear_return_frame_no_direct().