Vulnerabilities

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().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> can: gs_usb: gs_usb_receive_bulk_callback(): check actual_length before accessing data<br /> <br /> The URB received in gs_usb_receive_bulk_callback() contains a struct<br /> gs_host_frame. The length of the data after the header depends on the<br /> gs_host_frame hf::flags and the active device features (e.g. time<br /> stamping).<br /> <br /> Introduce a new function gs_usb_get_minimum_length() and check that we have<br /> at least received the required amount of data before accessing it. Only<br /> copy the data to that skb that has actually been received.<br /> <br /> [mkl: rename gs_usb_get_minimum_length() -&gt; +gs_usb_get_minimum_rx_length()]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> can: gs_usb: gs_usb_receive_bulk_callback(): check actual_length before accessing header<br /> <br /> The driver expects to receive a struct gs_host_frame in<br /> gs_usb_receive_bulk_callback().<br /> <br /> Use struct_group to describe the header of the struct gs_host_frame and<br /> check that we have at least received the header before accessing any<br /> members of it.<br /> <br /> To resubmit the URB, do not dereference the pointer chain<br /> "dev-&gt;parent-&gt;hf_size_rx" but use "parent-&gt;hf_size_rx" instead. Since<br /> "urb-&gt;context" contains "parent", it is always defined, while "dev" is not<br /> defined if the URB it too short.

Rejected reason: This CVE id was assigned to an issue which was later deemed not security relevant.

Rejected reason: This CVE id was assigned to an issue which was later deemed not security relevant.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: dsa: microchip: Don&amp;#39;t free uninitialized ksz_irq<br /> <br /> If something goes wrong at setup, ksz_irq_free() can be called on<br /> uninitialized ksz_irq (for example when ksz_ptp_irq_setup() fails). It<br /> leads to freeing uninitialized IRQ numbers and/or domains.<br /> <br /> Use dsa_switch_for_each_user_port_continue_reverse() in the error path<br /> to iterate only over the fully initialized ports.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> atm/fore200e: Fix possible data race in fore200e_open()<br /> <br /> Protect access to fore200e-&gt;available_cell_rate with rate_mtx lock in the<br /> error handling path of fore200e_open() to prevent a data race.<br /> <br /> The field fore200e-&gt;available_cell_rate is a shared resource used to track<br /> available bandwidth. It is concurrently accessed by fore200e_open(),<br /> fore200e_close(), and fore200e_change_qos().<br /> <br /> In fore200e_open(), the lock rate_mtx is correctly held when subtracting<br /> vcc-&gt;qos.txtp.max_pcr from available_cell_rate to reserve bandwidth.<br /> However, if the subsequent call to fore200e_activate_vcin() fails, the<br /> function restores the reserved bandwidth by adding back to<br /> available_cell_rate without holding the lock.<br /> <br /> This introduces a race condition because available_cell_rate is a global<br /> device resource shared across all VCCs. If the error path in<br /> fore200e_open() executes concurrently with operations like<br /> fore200e_close() or fore200e_change_qos() on other VCCs, a<br /> read-modify-write race occurs.<br /> <br /> Specifically, the error path reads the rate without the lock. If another<br /> CPU acquires the lock and modifies the rate (e.g., releasing bandwidth in<br /> fore200e_close()) between this read and the subsequent write, the error<br /> path will overwrite the concurrent update with a stale value. This results<br /> in incorrect bandwidth accounting.