Vulnerabilities

The default configuration in ETSI Open-Source MANO (OSM) v.14.x, v.15.x, v.16.x, v.17.x does not impose any restrictions on the authentication attempts performed by the default admin user, allowing a remote attacker to escalate privileges.

CNCF Harbor 2.13.x before 2.13.1 and 2.12.x before 2.12.4 allows information disclosure by administrators who can exploit an ORM Leak present in the /api/v2.0/users endpoint to leak users' password hash and salt values. The q URL parameter allows a user to filter users by any column, and filter password=~ could be abused to leak out a user's password hash character by character. An attacker with administrator access could exploit this to leak highly sensitive information stored in the Harbor database. All endpoints that support the q URL parameter are vulnerable to this ORM leak attack.

An issue in ETSI Open-Source MANO (OSM) 14.0.x before 14.0.3, 15.0.x before 15.0.2, 16.0.0, and 17.0.0 allows a remote authenticated attacker to escalate privileges via the /osm/admin/v1/users component.

A vulnerability was found in PHPGurukul Login and User Management System 3.3. It has been declared as critical. This vulnerability affects unknown code of the file /admin/yesterday-reg-users.php. The manipulation of the argument ID leads to sql injection. The attack can be initiated remotely. The exploit has been disclosed to the public and may be used.

An issue in the OTP mechanism of Chavara Family Welfare Centre Chavara Matrimony Site v2.0 allows attackers to bypass authentication via supplying a crafted request.

Apwide Golive 10.2.0 Jira plugin allows Server-Side Request Forgery (SSRF) via the test webhook function.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> remoteproc: core: Cleanup acquired resources when rproc_handle_resources() fails in rproc_attach()<br /> <br /> When rproc-&gt;state = RPROC_DETACHED and rproc_attach() is used<br /> to attach to the remote processor, if rproc_handle_resources()<br /> returns a failure, the resources allocated by imx_rproc_prepare()<br /> should be released, otherwise the following memory leak will occur.<br /> <br /> Since almost the same thing is done in imx_rproc_prepare() and<br /> rproc_resource_cleanup(), Function rproc_resource_cleanup() is able<br /> to deal with empty lists so it is better to fix the "goto" statements<br /> in rproc_attach(). replace the "unprepare_device" goto statement with<br /> "clean_up_resources" and get rid of the "unprepare_device" label.<br /> <br /> unreferenced object 0xffff0000861c5d00 (size 128):<br /> comm "kworker/u12:3", pid 59, jiffies 4294893509 (age 149.220s)<br /> hex dump (first 32 bytes):<br /> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br /> 00 00 02 88 00 00 00 00 00 00 10 00 00 00 00 00 ............<br /> backtrace:<br /> [] slab_post_alloc_hook+0x98/0x37c<br /> [] __kmem_cache_alloc_node+0x138/0x2e0<br /> [] kmalloc_trace+0x40/0x158<br /> [] rproc_mem_entry_init+0x60/0xf8<br /> [] imx_rproc_prepare+0xe0/0x180<br /> [] rproc_boot+0x2ec/0x528<br /> [] rproc_add+0x124/0x17c<br /> [] imx_rproc_probe+0x4ec/0x5d4<br /> [] platform_probe+0x68/0xd8<br /> [] really_probe+0x110/0x27c<br /> [] __driver_probe_device+0x78/0x12c<br /> [] driver_probe_device+0x3c/0x118<br /> [] __device_attach_driver+0xb8/0xf8<br /> [] bus_for_each_drv+0x84/0xe4<br /> [] __device_attach+0xfc/0x18c<br /> [] device_initial_probe+0x14/0x20

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> remoteproc: core: Release rproc-&gt;clean_table after rproc_attach() fails<br /> <br /> When rproc-&gt;state = RPROC_DETACHED is attached to remote processor<br /> through rproc_attach(), if rproc_handle_resources() returns failure,<br /> then the clean table should be released, otherwise the following<br /> memory leak will occur.<br /> <br /> unreferenced object 0xffff000086a99800 (size 1024):<br /> comm "kworker/u12:3", pid 59, jiffies 4294893670 (age 121.140s)<br /> hex dump (first 32 bytes):<br /> 00 00 00 00 00 80 00 00 00 00 00 00 00 00 10 00 ............<br /> 00 00 00 00 00 00 08 00 00 00 00 00 00 00 00 00 ............<br /> backtrace:<br /> [] slab_post_alloc_hook+0x98/0x3fc<br /> [] __kmem_cache_alloc_node+0x13c/0x230<br /> [] __kmalloc_node_track_caller+0x5c/0x260<br /> [] kmemdup+0x34/0x60<br /> [] rproc_boot+0x35c/0x56c<br /> [] rproc_add+0x124/0x17c<br /> [] imx_rproc_probe+0x4ec/0x5d4<br /> [] platform_probe+0x68/0xd8<br /> [] really_probe+0x110/0x27c<br /> [] __driver_probe_device+0x78/0x12c<br /> [] driver_probe_device+0x3c/0x118<br /> [] __device_attach_driver+0xb8/0xf8<br /> [] bus_for_each_drv+0x84/0xe4<br /> [] __device_attach+0xfc/0x18c<br /> [] device_initial_probe+0x14/0x20<br /> [] bus_probe_device+0xb0/0xb4<br /> unreferenced object 0xffff0000864c9690 (size 16):

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> NFC: nci: uart: Set tty-&gt;disc_data only in success path<br /> <br /> Setting tty-&gt;disc_data before opening the NCI device means we need to<br /> clean it up on error paths. This also opens some short window if device<br /> starts sending data, even before NCIUARTSETDRIVER IOCTL succeeded<br /> (broken hardware?). Close the window by exposing tty-&gt;disc_data only on<br /> the success path, when opening of the NCI device and try_module_get()<br /> succeeds.<br /> <br /> The code differs in error path in one aspect: tty-&gt;disc_data won&amp;#39;t be<br /> ever assigned thus NULL-ified. This however should not be relevant<br /> difference, because of "tty-&gt;disc_data=NULL" in nci_uart_tty_open().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Squashfs: check return result of sb_min_blocksize<br /> <br /> Syzkaller reports an "UBSAN: shift-out-of-bounds in squashfs_bio_read" bug.<br /> <br /> Syzkaller forks multiple processes which after mounting the Squashfs<br /> filesystem, issues an ioctl("/dev/loop0", LOOP_SET_BLOCK_SIZE, 0x8000). <br /> Now if this ioctl occurs at the same time another process is in the<br /> process of mounting a Squashfs filesystem on /dev/loop0, the failure<br /> occurs. When this happens the following code in squashfs_fill_super()<br /> fails.<br /> <br /> ----<br /> msblk-&gt;devblksize = sb_min_blocksize(sb, SQUASHFS_DEVBLK_SIZE);<br /> msblk-&gt;devblksize_log2 = ffz(~msblk-&gt;devblksize);<br /> ----<br /> <br /> sb_min_blocksize() returns 0, which means msblk-&gt;devblksize is set to 0.<br /> <br /> As a result, ffz(~msblk-&gt;devblksize) returns 64, and msblk-&gt;devblksize_log2<br /> is set to 64.<br /> <br /> This subsequently causes the<br /> <br /> UBSAN: shift-out-of-bounds in fs/squashfs/block.c:195:36<br /> shift exponent 64 is too large for 64-bit type &amp;#39;u64&amp;#39; (aka<br /> &amp;#39;unsigned long long&amp;#39;)<br /> <br /> This commit adds a check for a 0 return by sb_min_blocksize().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> virtio-net: xsk: rx: fix the frame&amp;#39;s length check<br /> <br /> When calling buf_to_xdp, the len argument is the frame data&amp;#39;s length<br /> without virtio header&amp;#39;s length (vi-&gt;hdr_len). We check that len with<br /> <br /> xsk_pool_get_rx_frame_size() + vi-&gt;hdr_len<br /> <br /> to ensure the provided len does not larger than the allocated chunk<br /> size. The additional vi-&gt;hdr_len is because in virtnet_add_recvbuf_xsk,<br /> we use part of XDP_PACKET_HEADROOM for virtio header and ask the vhost<br /> to start placing data from<br /> <br /> hard_start + XDP_PACKET_HEADROOM - vi-&gt;hdr_len<br /> not<br /> hard_start + XDP_PACKET_HEADROOM<br /> <br /> But the first buffer has virtio_header, so the maximum frame&amp;#39;s length in<br /> the first buffer can only be<br /> <br /> xsk_pool_get_rx_frame_size()<br /> not<br /> xsk_pool_get_rx_frame_size() + vi-&gt;hdr_len<br /> <br /> like in the current check.<br /> <br /> This commit adds an additional argument to buf_to_xdp differentiate<br /> between the first buffer and other ones to correctly calculate the maximum<br /> frame&amp;#39;s length.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: ath12k: fix GCC_GCC_PCIE_HOT_RST definition for WCN7850<br /> <br /> GCC_GCC_PCIE_HOT_RST is wrongly defined for WCN7850, causing kernel crash<br /> on some specific platforms.<br /> <br /> Since this register is divergent for WCN7850 and QCN9274, move it to<br /> register table to allow different definitions. Then correct the register<br /> address for WCN7850 to fix this issue.<br /> <br /> Note IPQ5332 is not affected as it is not PCIe based device.<br /> <br /> Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3