Vulnerabilities

Vigor165/166 4.2.7 and earlier; Vigor2620/LTE200 3.9.8.9 and earlier; Vigor2860/2925 3.9.8 and earlier; Vigor2862/2926 3.9.9.5 and earlier; Vigor2133/2762/2832 3.9.9 and earlier; Vigor2135/2765/2766 4.4.5. and earlier; Vigor2865/2866/2927 4.4.5.3 and earlier; Vigor2962 4.3.2.8 and earlier; Vigor3912 4.3.6.1 and earlier; Vigor3910 4.4.3.1 and earlier a stack-based buffer overflow vulnerability has been identified in the URL parsing functionality of the TR069 STUN server. This flaw occurs due to insufficient bounds checking on the amount of URL parameters, allowing an attacker to exploit the overflow by sending a maliciously crafted request. Consequently, a remote attacker can execute arbitrary code with elevated privileges.

GFast between v2 to v3.2 was discovered to contain a SQL injection vulnerability via the OrderBy parameter at /system/operLog/list.

Draytek devices Vigor 165/166 prior to v4.2.6 , Vigor 2620/LTE200 prior to v3.9.8.8, Vigor 2860/2925 prior to v3.9.7, Vigor 2862/2926 prior to v3.9.9.4, Vigor 2133/2762/2832 prior to v3.9.8, Vigor 2135/2765/2766 prior to v4.4.5.1, Vigor 2865/2866/2927 prior to v4.4.5.3, Vigor 2962/3910 prior to v4.3.2.7, Vigor 3912 prior to v4.3.5.2, and Vigor 2925 up to v3.9.6 were discovered to store passwords in plaintext.

Draytek devices Vigor 165/166 prior to v4.2.6 , Vigor 2620/LTE200 prior to v3.9.8.8, Vigor 2860/2925 prior to v3.9.7, Vigor 2862/2926 prior to v3.9.9.4, Vigor 2133/2762/2832 prior to v3.9.8, Vigor 2135/2765/2766 prior to v4.4.5.1, Vigor 2865/2866/2927 prior to v4.4.5.3, Vigor 2962/3910 prior to v4.3.2.7, Vigor 3912 prior to v4.3.5.2, and Vigor 2925 up to v3.9.6 were discovered to utilize insecure versions of the functions strcmp and memcmp, allowing attackers to possibly obtain sensitive information via timing attacks.

A NULL pointer dereference in Draytek devices Vigor 165/166 prior to v4.2.6 , Vigor 2620/LTE200 prior to v3.9.8.8, Vigor 2860/2925 prior to v3.9.7, Vigor 2862/2926 prior to v3.9.9.4, Vigor 2133/2762/2832 prior to v3.9.8, Vigor 2135/2765/2766 prior to v4.4.5.1, Vigor 2865/2866/2927 prior to v4.4.5.3, Vigor 2962/3910 prior to v4.3.2.7, Vigor 3912 prior to v4.3.5.2, and Vigor 2925 up to v3.9.6 allows attackers to cause a Denial of Service (DoS) via a crafted DHCP request.

Draytek devices Vigor 165/166 prior to v4.2.6 , Vigor 2620/LTE200 prior to v3.9.8.8, Vigor 2860/2925 prior to v3.9.7, Vigor 2862/2926 prior to v3.9.9.4, Vigor 2133/2762/2832 prior to v3.9.8, Vigor 2135/2765/2766 prior to v4.4.5.1, Vigor 2865/2866/2927 prior to v4.4.5.3, Vigor 2962/3910 prior to v4.3.2.7, Vigor 3912 prior to v4.3.5.2, and Vigor 2925 up to v3.9.6 were discovered to not utilize certificate verification, allowing attackers to upload crafted APPE modules from non-official servers, leading to arbitrary code execution.

An issue in Draytek devices Vigor 165/166 prior to v4.2.6 , Vigor 2620/LTE200 prior to v3.9.8.8, Vigor 2860/2925 prior to v3.9.7, Vigor 2862/2926 prior to v3.9.9.4, Vigor 2133/2762/2832 prior to v3.9.8, Vigor 2135/2765/2766 prior to v4.4.5.1, Vigor 2865/2866/2927 prior to v4.4.5.3, Vigor 2962/3910 prior to v4.3.2.7, Vigor 3912 prior to v4.3.5.2, and Vigor 2925 up to v3.9.6 allows attackers to upload crafted APP Enforcement modules, leading to arbitrary code execution.

An issue in the CGI endpoint used to upload configurations in Draytek devices Vigor 165/166 prior to v4.2.6 , Vigor 2620/LTE200 prior to v3.9.8.8, Vigor 2860/2925 prior to v3.9.7, Vigor 2862/2926 prior to v3.9.9.4, Vigor 2133/2762/2832 prior to v3.9.8, Vigor 2135/2765/2766 prior to v4.4.5.1, Vigor 2865/2866/2927 prior to v4.4.5.3, Vigor 2962/3910 prior to v4.3.2.7, Vigor 3912 prior to v4.3.5.2, and Vigor 2925 up to v3.9.6 allows attackers to upload a crafted kernel module, allowing for arbitrary code execution.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tty: xilinx_uartps: split sysrq handling<br /> <br /> lockdep detects the following circular locking dependency:<br /> <br /> CPU 0 CPU 1<br /> ========================== ============================<br /> cdns_uart_isr() printk()<br /> uart_port_lock(port) console_lock()<br /> cdns_uart_console_write()<br /> if (!port-&gt;sysrq)<br /> uart_port_lock(port)<br /> uart_handle_break()<br /> port-&gt;sysrq = ...<br /> uart_handle_sysrq_char()<br /> printk()<br /> console_lock()<br /> <br /> The fixed commit attempts to avoid this situation by only taking the<br /> port lock in cdns_uart_console_write if port-&gt;sysrq unset. However, if<br /> (as shown above) cdns_uart_console_write runs before port-&gt;sysrq is set,<br /> then it will try to take the port lock anyway. This may result in a<br /> deadlock.<br /> <br /> Fix this by splitting sysrq handling into two parts. We use the prepare<br /> helper under the port lock and defer handling until we release the lock.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> batman-adv: Drop unmanaged ELP metric worker<br /> <br /> The ELP worker needs to calculate new metric values for all neighbors<br /> "reachable" over an interface. Some of the used metric sources require<br /> locks which might need to sleep. This sleep is incompatible with the RCU<br /> list iterator used for the recorded neighbors. The initial approach to work<br /> around of this problem was to queue another work item per neighbor and then<br /> run this in a new context.<br /> <br /> Even when this solved the RCU vs might_sleep() conflict, it has a major<br /> problems: Nothing was stopping the work item in case it is not needed<br /> anymore - for example because one of the related interfaces was removed or<br /> the batman-adv module was unloaded - resulting in potential invalid memory<br /> accesses.<br /> <br /> Directly canceling the metric worker also has various problems:<br /> <br /> * cancel_work_sync for a to-be-deactivated interface is called with<br /> rtnl_lock held. But the code in the ELP metric worker also tries to use<br /> rtnl_lock() - which will never return in this case. This also means that<br /> cancel_work_sync would never return because it is waiting for the worker<br /> to finish.<br /> * iterating over the neighbor list for the to-be-deactivated interface is<br /> currently done using the RCU specific methods. Which means that it is<br /> possible to miss items when iterating over it without the associated<br /> spinlock - a behaviour which is acceptable for a periodic metric check<br /> but not for a cleanup routine (which must "stop" all still running<br /> workers)<br /> <br /> The better approch is to get rid of the per interface neighbor metric<br /> worker and handle everything in the interface worker. The original problems<br /> are solved by:<br /> <br /> * creating a list of neighbors which require new metric information inside<br /> the RCU protected context, gathering the metric according to the new list<br /> outside the RCU protected context<br /> * only use rcu_trylock inside metric gathering code to avoid a deadlock<br /> when the cancel_delayed_work_sync is called in the interface removal code<br /> (which is called with the rtnl_lock held)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/compaction: fix UBSAN shift-out-of-bounds warning<br /> <br /> syzkaller reported a UBSAN shift-out-of-bounds warning of (1UL

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> block: mark GFP_NOIO around sysfs -&gt;store()<br /> <br /> sysfs -&gt;store is called with queue freezed, meantime we have several<br /> -&gt;store() callbacks(update_nr_requests, wbt, scheduler) to allocate<br /> memory with GFP_KERNEL which may run into direct reclaim code path,<br /> then potential deadlock can be caused.<br /> <br /> Fix the issue by marking NOIO around sysfs -&gt;store()