Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nfsd: nfsd4_spo_must_allow() must check this is a v4 compound request<br /> <br /> If the request being processed is not a v4 compound request, then<br /> examining the cstate can have undefined results.<br /> <br /> This patch adds a check that the rpc procedure being executed<br /> (rq_procinfo) is the NFSPROC4_COMPOUND procedure.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: carl9170: do not ping device which has failed to load firmware<br /> <br /> Syzkaller reports [1, 2] crashes caused by an attempts to ping<br /> the device which has failed to load firmware. Since such a device<br /> doesn&amp;#39;t pass &amp;#39;ieee80211_register_hw()&amp;#39;, an internal workqueue<br /> managed by &amp;#39;ieee80211_queue_work()&amp;#39; is not yet created and an<br /> attempt to queue work on it causes null-ptr-deref.<br /> <br /> [1] https://syzkaller.appspot.com/bug?extid=9a4aec827829942045ff<br /> [2] https://syzkaller.appspot.com/bug?extid=0d8afba53e8fb2633217

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> platform/x86/amd: pmf: Use device managed allocations<br /> <br /> If setting up smart PC fails for any reason then this can lead to<br /> a double free when unloading amd-pmf. This is because dev-&gt;buf was<br /> freed but never set to NULL and is again freed in amd_pmf_remove().<br /> <br /> To avoid subtle allocation bugs in failures leading to a double free<br /> change all allocations into device managed allocations.

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&amp;#39; 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&amp;#39;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().