Vulnerabilities

TOTOLINK CA600-PoE V5.3c.6665_B20180820 was found to contain a command injection vulnerability in the setUpgradeFW function via the FileName parameter. This vulnerability allows attackers to execute arbitrary commands via a crafted request.

TOTOLINK CA600-PoE V5.3c.6665_B20180820 was found to contain a command injection vulnerability in the NTPSyncWithHost function via the hostTime parameter. This vulnerability allows attackers to execute arbitrary commands via a crafted request.

TOTOLINK CA600-PoE V5.3c.6665_B20180820 was found to contain a command injection vulnerability in the recvUpgradeNewFw function via the fwUrl parameter. This vulnerability allows attackers to execute arbitrary commands via a crafted request.

TOTOLINK CPE CP900 V6.3c.1144_B20190715 was discovered to contain a command injection vulnerability in the setApRebootScheCfg function via the hour or minute parameters. This vulnerability allows attackers to execute arbitrary commands via a crafted request.

TOTOLINK CPE CP900 V6.3c.1144_B20190715 was discovered to contain a command injection vulnerability in the CloudSrvUserdataVersionCheck function via the url or magicid parameters. This vulnerability allows attackers to execute arbitrary commands via a crafted request.

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