Vulnerabilities

TOTOLINK CPE CP900 V6.3c.1144_B20190715 was discovered to contain a command injection vulnerability in the setUploadUserData function via the FileName parameter. This vulnerability allows attackers to execute arbitrary commands via a crafted request.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> IB/hfi1: Correctly move list in sc_disable()<br /> <br /> Commit 13bac861952a ("IB/hfi1: Fix abba locking issue with sc_disable()")<br /> incorrectly tries to move a list from one list head to another. The<br /> result is a kernel crash.<br /> <br /> The crash is triggered when a link goes down and there are waiters for a<br /> send to complete. The following signature is seen:<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000030<br /> [...]<br /> Call Trace:<br /> sc_disable+0x1ba/0x240 [hfi1]<br /> pio_freeze+0x3d/0x60 [hfi1]<br /> handle_freeze+0x27/0x1b0 [hfi1]<br /> process_one_work+0x1b0/0x380<br /> ? process_one_work+0x380/0x380<br /> worker_thread+0x30/0x360<br /> ? process_one_work+0x380/0x380<br /> kthread+0xd7/0x100<br /> ? kthread_complete_and_exit+0x20/0x20<br /> ret_from_fork+0x1f/0x30<br /> <br /> The fix is to use the correct call to move the list.

NVIDIA vGPU software for Windows and Linux contains a vulnerability in the Virtual GPU Manager (vGPU plugin), where it allows a guest to consume uncontrolled resources. A successful exploit of this vulnerability might lead to denial of service.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nfc: fdp: Fix potential memory leak in fdp_nci_send()<br /> <br /> fdp_nci_send() will call fdp_nci_i2c_write that will not free skb in<br /> the function. As a result, when fdp_nci_i2c_write() finished, the skb<br /> will memleak. fdp_nci_send() should free skb after fdp_nci_i2c_write()<br /> finished.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/core: Fix null-ptr-deref in ib_core_cleanup()<br /> <br /> KASAN reported a null-ptr-deref error:<br /> <br /> KASAN: null-ptr-deref in range [0x0000000000000118-0x000000000000011f]<br /> CPU: 1 PID: 379<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)<br /> RIP: 0010:destroy_workqueue+0x2f/0x740<br /> RSP: 0018:ffff888016137df8 EFLAGS: 00000202<br /> ...<br /> Call Trace:<br /> ib_core_cleanup+0xa/0xa1 [ib_core]<br /> __do_sys_delete_module.constprop.0+0x34f/0x5b0<br /> do_syscall_64+0x3a/0x90<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> RIP: 0033:0x7fa1a0d221b7<br /> ...<br /> <br /> It is because the fail of roce_gid_mgmt_init() is ignored:<br /> <br /> ib_core_init()<br /> roce_gid_mgmt_init()<br /> gid_cache_wq = alloc_ordered_workqueue # fail<br /> ...<br /> ib_core_cleanup()<br /> roce_gid_mgmt_cleanup()<br /> destroy_workqueue(gid_cache_wq)<br /> # destroy an unallocated wq<br /> <br /> Fix this by catching the fail of roce_gid_mgmt_init() in ib_core_init().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: dsa: Fix possible memory leaks in dsa_loop_init()<br /> <br /> kmemleak reported memory leaks in dsa_loop_init():<br /> <br /> kmemleak: 12 new suspected memory leaks<br /> <br /> unreferenced object 0xffff8880138ce000 (size 2048):<br /> comm "modprobe", pid 390, jiffies 4295040478 (age 238.976s)<br /> backtrace:<br /> [] kmalloc_trace+0x26/0x60<br /> [] phy_device_create+0x5d/0x970<br /> [] get_phy_device+0xf3/0x2b0<br /> [] __fixed_phy_register.part.0+0x92/0x4e0<br /> [] fixed_phy_register+0x84/0xb0<br /> [] dsa_loop_init+0xa9/0x116 [dsa_loop]<br /> ...<br /> <br /> There are two reasons for memleak in dsa_loop_init().<br /> <br /> First, fixed_phy_register() create and register phy_device:<br /> <br /> fixed_phy_register()<br /> get_phy_device()<br /> phy_device_create() # freed by phy_device_free()<br /> phy_device_register() # freed by phy_device_remove()<br /> <br /> But fixed_phy_unregister() only calls phy_device_remove().<br /> So the memory allocated in phy_device_create() is leaked.<br /> <br /> Second, when mdio_driver_register() fail in dsa_loop_init(),<br /> it just returns and there is no cleanup for phydevs.<br /> <br /> Fix the problems by catching the error of mdio_driver_register()<br /> in dsa_loop_init(), then calling both fixed_phy_unregister() and<br /> phy_device_free() to release phydevs.<br /> Also add a function for phydevs cleanup to avoid duplacate.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nfs4: Fix kmemleak when allocate slot failed<br /> <br /> If one of the slot allocate failed, should cleanup all the other<br /> allocated slots, otherwise, the allocated slots will leak:<br /> <br /> unreferenced object 0xffff8881115aa100 (size 64):<br /> comm ""mount.nfs"", pid 679, jiffies 4294744957 (age 115.037s)<br /> hex dump (first 32 bytes):<br /> 00 cc 19 73 81 88 ff ff 00 a0 5a 11 81 88 ff ff ...s......Z.....<br /> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br /> backtrace:<br /> [] nfs4_find_or_create_slot+0x8e/0x130<br /> [] nfs4_realloc_slot_table+0x23f/0x270<br /> [] nfs40_init_client+0x4a/0x90<br /> [] nfs4_init_client+0xce/0x270<br /> [] nfs4_set_client+0x1a2/0x2b0<br /> [] nfs4_create_server+0x300/0x5f0<br /> [] nfs4_try_get_tree+0x65/0x110<br /> [] vfs_get_tree+0x41/0xf0<br /> [] path_mount+0x9b3/0xdd0<br /> [] __x64_sys_mount+0x190/0x1d0<br /> [] do_syscall_64+0x35/0x80<br /> [] entry_SYSCALL_64_after_hwframe+0x46/0xb0

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> SUNRPC: Fix null-ptr-deref when xps sysfs alloc failed<br /> <br /> There is a null-ptr-deref when xps sysfs alloc failed:<br /> BUG: KASAN: null-ptr-deref in sysfs_do_create_link_sd+0x40/0xd0<br /> Read of size 8 at addr 0000000000000030 by task gssproxy/457<br /> <br /> CPU: 5 PID: 457 Comm: gssproxy Not tainted 6.0.0-09040-g02357b27ee03 #9<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x34/0x44<br /> kasan_report+0xa3/0x120<br /> sysfs_do_create_link_sd+0x40/0xd0<br /> rpc_sysfs_client_setup+0x161/0x1b0<br /> rpc_new_client+0x3fc/0x6e0<br /> rpc_create_xprt+0x71/0x220<br /> rpc_create+0x1d4/0x350<br /> gssp_rpc_create+0xc3/0x160<br /> set_gssp_clnt+0xbc/0x140<br /> write_gssp+0x116/0x1a0<br /> proc_reg_write+0xd6/0x130<br /> vfs_write+0x177/0x690<br /> ksys_write+0xb9/0x150<br /> do_syscall_64+0x35/0x80<br /> entry_SYSCALL_64_after_hwframe+0x46/0xb0<br /> <br /> When the xprt_switch sysfs alloc failed, should not add xprt and<br /> switch sysfs to it, otherwise, maybe null-ptr-deref; also initialize<br /> the &amp;#39;xps_sysfs&amp;#39; to NULL to avoid oops when destroy it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/hns: Fix NULL pointer problem in free_mr_init()<br /> <br /> Lock grab occurs in a concurrent scenario, resulting in stepping on a NULL<br /> pointer. It should be init mutex_init() first before use the lock.<br /> <br /> Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000<br /> Call trace:<br /> __mutex_lock.constprop.0+0xd0/0x5c0<br /> __mutex_lock_slowpath+0x1c/0x2c<br /> mutex_lock+0x44/0x50<br /> free_mr_send_cmd_to_hw+0x7c/0x1c0 [hns_roce_hw_v2]<br /> hns_roce_v2_dereg_mr+0x30/0x40 [hns_roce_hw_v2]<br /> hns_roce_dereg_mr+0x4c/0x130 [hns_roce_hw_v2]<br /> ib_dereg_mr_user+0x54/0x124<br /> uverbs_free_mr+0x24/0x30<br /> destroy_hw_idr_uobject+0x38/0x74<br /> uverbs_destroy_uobject+0x48/0x1c4<br /> uobj_destroy+0x74/0xcc<br /> ib_uverbs_cmd_verbs+0x368/0xbb0<br /> ib_uverbs_ioctl+0xec/0x1a4<br /> __arm64_sys_ioctl+0xb4/0x100<br /> invoke_syscall+0x50/0x120<br /> el0_svc_common.constprop.0+0x58/0x190<br /> do_el0_svc+0x30/0x90<br /> el0_svc+0x2c/0xb4<br /> el0t_64_sync_handler+0x1a4/0x1b0<br /> el0t_64_sync+0x19c/0x1a0

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/rxe: Fix mr leak in RESPST_ERR_RNR<br /> <br /> rxe_recheck_mr() will increase mr&amp;#39;s ref_cnt, so we should call rxe_put(mr)<br /> to drop mr&amp;#39;s ref_cnt in RESPST_ERR_RNR to avoid below warning:<br /> <br /> WARNING: CPU: 0 PID: 4156 at drivers/infiniband/sw/rxe/rxe_pool.c:259 __rxe_cleanup+0x1df/0x240 [rdma_rxe]<br /> ...<br /> Call Trace:<br /> rxe_dereg_mr+0x4c/0x60 [rdma_rxe]<br /> ib_dereg_mr_user+0xa8/0x200 [ib_core]<br /> ib_mr_pool_destroy+0x77/0xb0 [ib_core]<br /> nvme_rdma_destroy_queue_ib+0x89/0x240 [nvme_rdma]<br /> nvme_rdma_free_queue+0x40/0x50 [nvme_rdma]<br /> nvme_rdma_teardown_io_queues.part.0+0xc3/0x120 [nvme_rdma]<br /> nvme_rdma_error_recovery_work+0x4d/0xf0 [nvme_rdma]<br /> process_one_work+0x582/0xa40<br /> ? pwq_dec_nr_in_flight+0x100/0x100<br /> ? rwlock_bug.part.0+0x60/0x60<br /> worker_thread+0x2a9/0x700<br /> ? process_one_work+0xa40/0xa40<br /> kthread+0x168/0x1a0<br /> ? kthread_complete_and_exit+0x20/0x20<br /> ret_from_fork+0x22/0x30

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nf_tables: release flow rule object from commit path<br /> <br /> No need to postpone this to the commit release path, since no packets<br /> are walking over this object, this is accessed from control plane only.<br /> This helped uncovered UAF triggered by races with the netlink notifier.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nf_tables: netlink notifier might race to release objects<br /> <br /> commit release path is invoked via call_rcu and it runs lockless to<br /> release the objects after rcu grace period. The netlink notifier handler<br /> might win race to remove objects that the transaction context is still<br /> referencing from the commit release path.<br /> <br /> Call rcu_barrier() to ensure pending rcu callbacks run to completion<br /> if the list of transactions to be destroyed is not empty.