Vulnerabilities

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

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ice: fix eswitch code memory leak in reset scenario<br /> <br /> Add simple eswitch mode checker in attaching VF procedure and allocate<br /> required port representor memory structures only in switchdev mode.<br /> The reset flows triggers VF (if present) detach/attach procedure.<br /> It might involve VF port representor(s) re-creation if the device is<br /> configured is switchdev mode (not legacy one).<br /> The memory was blindly allocated in current implementation,<br /> regardless of the mode and not freed if in legacy mode.<br /> <br /> Kmemeleak trace:<br /> unreferenced object (percpu) 0x7e3bce5b888458 (size 40):<br /> comm "bash", pid 1784, jiffies 4295743894<br /> hex dump (first 32 bytes on cpu 45):<br /> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br /> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br /> backtrace (crc 0):<br /> pcpu_alloc_noprof+0x4c4/0x7c0<br /> ice_repr_create+0x66/0x130 [ice]<br /> ice_repr_create_vf+0x22/0x70 [ice]<br /> ice_eswitch_attach_vf+0x1b/0xa0 [ice]<br /> ice_reset_all_vfs+0x1dd/0x2f0 [ice]<br /> ice_pci_err_resume+0x3b/0xb0 [ice]<br /> pci_reset_function+0x8f/0x120<br /> reset_store+0x56/0xa0<br /> kernfs_fop_write_iter+0x120/0x1b0<br /> vfs_write+0x31c/0x430<br /> ksys_write+0x61/0xd0<br /> do_syscall_64+0x5b/0x180<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> <br /> Testing hints (ethX is PF netdev):<br /> - create at least one VF<br /> echo 1 &gt; /sys/class/net/ethX/device/sriov_numvfs<br /> - trigger the reset<br /> echo 1 &gt; /sys/class/net/ethX/device/reset

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> platform/x86: dell-wmi-sysman: Fix WMI data block retrieval in sysfs callbacks<br /> <br /> After retrieving WMI data blocks in sysfs callbacks, check for the<br /> validity of them before dereferencing their content.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: ath6kl: remove WARN on bad firmware input<br /> <br /> If the firmware gives bad input, that&amp;#39;s nothing to do with<br /> the driver&amp;#39;s stack at this point etc., so the WARN_ON()<br /> doesn&amp;#39;t add any value. Additionally, this is one of the<br /> top syzbot reports now. Just print a message, and as an<br /> added bonus, print the sizes too.