Vulnerabilities

<br /> Delta Electronics CNCSoft-B versions 1.0.0.4 and prior are vulnerable to a stack-based buffer overflow, which may allow an attacker to execute arbitrary code.<br /> <br />

<br /> <br /> <br /> <br /> <br /> MicroDicom DICOM Viewer versions 2023.3 (Build 9342) and prior are affected by a heap-based buffer overflow vulnerability, which could allow an attacker to execute arbitrary code on affected installations of DICOM Viewer. A user must open a malicious DCM file in order to exploit the vulnerability.<br /> <br /> <br /> <br /> <br /> <br />

<br /> <br /> <br /> MicroDicom DICOM Viewer versions 2023.3 (Build 9342) and prior contain a lack of proper validation of user-supplied data, which could result in memory corruption within the application.<br /> <br /> <br /> <br />

A vulnerability was found in Netentsec NS-ASG Application Security Gateway 6.3. It has been classified as critical. Affected is an unknown function of the file /admin/list_localuser.php. The manipulation of the argument ResId leads to sql injection. It is possible to launch the attack remotely. The exploit has been disclosed to the public and may be used. The identifier of this vulnerability is VDB-255300. NOTE: The vendor was contacted early about this disclosure but did not respond in any way.

A vulnerability was found in Netentsec NS-ASG Application Security Gateway 6.3. It has been declared as critical. Affected by this vulnerability is an unknown functionality of the file /admin/list_ipAddressPolicy.php. The manipulation of the argument GroupId leads to sql injection. The attack can be launched remotely. The exploit has been disclosed to the public and may be used. The identifier VDB-255301 was assigned to this vulnerability. NOTE: The vendor was contacted early about this disclosure but did not respond in any way.

Session version 1.17.5 allows obtaining internal application files and public<br /> <br /> files from the user&amp;#39;s device without the user&amp;#39;s consent. This is possible<br /> <br /> because the application is vulnerable to Local File Read via chat attachments.

Recipes version 1.5.10 allows arbitrary HTTP requests to be made<br /> <br /> through the server. This is possible because the application is<br /> <br /> vulnerable to SSRF.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rtw88: Fix array overrun in rtw_get_tx_power_params()<br /> <br /> Using a kernel with the Undefined Behaviour Sanity Checker (UBSAN) enabled, the<br /> following array overrun is logged:<br /> <br /> ================================================================================<br /> UBSAN: array-index-out-of-bounds in /home/finger/wireless-drivers-next/drivers/net/wireless/realtek/rtw88/phy.c:1789:34<br /> index 5 is out of range for type &amp;#39;u8 [5]&amp;#39;<br /> CPU: 2 PID: 84 Comm: kworker/u16:3 Tainted: G O 5.12.0-rc5-00086-gd88bba47038e-dirty #651<br /> Hardware name: TOSHIBA TECRA A50-A/TECRA A50-A, BIOS Version 4.50 09/29/2014<br /> Workqueue: phy0 ieee80211_scan_work [mac80211]<br /> Call Trace:<br /> dump_stack+0x64/0x7c<br /> ubsan_epilogue+0x5/0x40<br /> __ubsan_handle_out_of_bounds.cold+0x43/0x48<br /> rtw_get_tx_power_params+0x83a/drivers/net/wireless/realtek/rtw88/0xad0 [rtw_core]<br /> ? rtw_pci_read16+0x20/0x20 [rtw_pci]<br /> ? check_hw_ready+0x50/0x90 [rtw_core]<br /> rtw_phy_get_tx_power_index+0x4d/0xd0 [rtw_core]<br /> rtw_phy_set_tx_power_level+0xee/0x1b0 [rtw_core]<br /> rtw_set_channel+0xab/0x110 [rtw_core]<br /> rtw_ops_config+0x87/0xc0 [rtw_core]<br /> ieee80211_hw_config+0x9d/0x130 [mac80211]<br /> ieee80211_scan_state_set_channel+0x81/0x170 [mac80211]<br /> ieee80211_scan_work+0x19f/0x2a0 [mac80211]<br /> process_one_work+0x1dd/0x3a0<br /> worker_thread+0x49/0x330<br /> ? rescuer_thread+0x3a0/0x3a0<br /> kthread+0x134/0x150<br /> ? kthread_create_worker_on_cpu+0x70/0x70<br /> ret_from_fork+0x22/0x30<br /> ================================================================================<br /> <br /> The statement where an array is being overrun is shown in the following snippet:<br /> <br /> if (rate cck_base[group];<br /> else<br /> ====&gt; tx_power = pwr_idx_2g-&gt;bw40_base[group];<br /> <br /> The associated arrays are defined in main.h as follows:<br /> <br /> struct rtw_2g_txpwr_idx {<br /> u8 cck_base[6];<br /> u8 bw40_base[5];<br /> struct rtw_2g_1s_pwr_idx_diff ht_1s_diff;<br /> struct rtw_2g_ns_pwr_idx_diff ht_2s_diff;<br /> struct rtw_2g_ns_pwr_idx_diff ht_3s_diff;<br /> struct rtw_2g_ns_pwr_idx_diff ht_4s_diff;<br /> };<br /> <br /> The problem arises because the value of group is 5 for channel 14. The trivial<br /> increase in the dimension of bw40_base fails as this struct must match the layout of<br /> efuse. The fix is to add the rate as an argument to rtw_get_channel_group() and set<br /> the group for channel 14 to 4 if rate

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> async_xor: increase src_offs when dropping destination page<br /> <br /> Now we support sharing one page if PAGE_SIZE is not equal stripe size. To<br /> support this, it needs to support calculating xor value with different<br /> offsets for each r5dev. One offset array is used to record those offsets.<br /> <br /> In RMW mode, parity page is used as a source page. It sets<br /> ASYNC_TX_XOR_DROP_DST before calculating xor value in ops_run_prexor5.<br /> So it needs to add src_list and src_offs at the same time. Now it only<br /> needs src_list. So the xor value which is calculated is wrong. It can<br /> cause data corruption problem.<br /> <br /> I can reproduce this problem 100% on a POWER8 machine. The steps are:<br /> <br /> mdadm -CR /dev/md0 -l5 -n3 /dev/sdb1 /dev/sdc1 /dev/sdd1 --size=3G<br /> mkfs.xfs /dev/md0<br /> mount /dev/md0 /mnt/test<br /> mount: /mnt/test: mount(2) system call failed: Structure needs cleaning.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> soc/tegra: regulators: Fix locking up when voltage-spread is out of range<br /> <br /> Fix voltage coupler lockup which happens when voltage-spread is out<br /> of range due to a bug in the code. The max-spread requirement shall be<br /> accounted when CPU regulator doesn&amp;#39;t have consumers. This problem is<br /> observed on Tegra30 Ouya game console once system-wide DVFS is enabled<br /> in a device-tree.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/nfc: fix use-after-free llcp_sock_bind/connect<br /> <br /> Commits 8a4cd82d ("nfc: fix refcount leak in llcp_sock_connect()")<br /> and c33b1cc62 ("nfc: fix refcount leak in llcp_sock_bind()")<br /> fixed a refcount leak bug in bind/connect but introduced a<br /> use-after-free if the same local is assigned to 2 different sockets.<br /> <br /> This can be triggered by the following simple program:<br /> int sock1 = socket( AF_NFC, SOCK_STREAM, NFC_SOCKPROTO_LLCP );<br /> int sock2 = socket( AF_NFC, SOCK_STREAM, NFC_SOCKPROTO_LLCP );<br /> memset( &amp;addr, 0, sizeof(struct sockaddr_nfc_llcp) );<br /> addr.sa_family = AF_NFC;<br /> addr.nfc_protocol = NFC_PROTO_NFC_DEP;<br /> bind( sock1, (struct sockaddr*) &amp;addr, sizeof(struct sockaddr_nfc_llcp) )<br /> bind( sock2, (struct sockaddr*) &amp;addr, sizeof(struct sockaddr_nfc_llcp) )<br /> close(sock1);<br /> close(sock2);<br /> <br /> Fix this by assigning NULL to llcp_sock-&gt;local after calling<br /> nfc_llcp_local_put.<br /> <br /> This addresses CVE-2021-23134.

dp-golang is a Puppet module for Go installations. Prior to 1.2.7, dp-golang could install files — including the compiler binary — with the wrong ownership when Puppet was run as root and the installed package was On macOS: Go version 1.4.3 through 1.21rc3, inclusive, go1.4-bootstrap-20170518.tar.gz, or go1.4-bootstrap-20170531.tar.gz. The user and group specified in Puppet code were ignored for files within the archive. dp-puppet version 1.2.7 will recreate installations if the owner or group of any file or directory within that installation does not match the requested owner or group