Vulnerabilities

Cross-Site Request Forgery (CSRF) vulnerability in Simplehelp.This issue affects Simplehelp: before 5.5.11.

Rejected reason: DO NOT USE THIS CANDIDATE NUMBER. ConsultIDs: none. Reason: This candidate was withdrawn by its CNA. Further investigation showed that it was not a security issue; there is no indication that an applicable SSH private key has ever been compromised. Notes: none.

A Gardyn Azure IoT Hub connection string is downloaded over an insecure HTTP connection in Gardyn Home Kit firmware before master.619, Home Kit Mobile Application before 2.11.0, and Home Kit Cloud API before 2.12.2026 leaving the string vulnerable to interception and modification through a Man-in-the-Middle attack. This may result in the attacker capturing device credentials or taking control of vulnerable home kits.

Gardyn Home Kit firmware before master.619, Home Kit Mobile Application before 2.11.0, and Home Kit Cloud API before 2.12.2026 use weak default credentials for secure shell access. This may result in attackers gaining access to exposed Gardyn Home Kits.

Gardyn Home Kit firmware before master.619, Home Kit Mobile Application before 2.11.0, and Home Kit Cloud API before 2.12.2026 allow command injection through vulnerable methods that do not sanitize input before passing content to the operating system for execution. The vulnerability may allow an attacker to execute arbitrary operating system commands on a target Home Kit.

goform/formTest in EmbedThis GoAhead 2.5 allows HTML injection via the name parameter.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/exynos: exynos7_drm_decon: add vblank check in IRQ handling<br /> <br /> If there&amp;#39;s support for another console device (such as a TTY serial),<br /> the kernel occasionally panics during boot. The panic message and a<br /> relevant snippet of the call stack is as follows:<br /> <br /> Unable to handle kernel NULL pointer dereference at virtual address 000000000000000<br /> Call trace:<br /> drm_crtc_handle_vblank+0x10/0x30 (P)<br /> decon_irq_handler+0x88/0xb4<br /> [...]<br /> <br /> Otherwise, the panics don&amp;#39;t happen. This indicates that it&amp;#39;s some sort<br /> of race condition.<br /> <br /> Add a check to validate if the drm device can handle vblanks before<br /> calling drm_crtc_handle_vblank() to avoid this.

Unitree Go1

Certain HP DesignJet products may be vulnerable to information disclosure though printer&amp;#39;s web interface allowing unauthenticated users to view sensitive print job information.

The following APIs for the Silcon Labs SiWx91x prior to vesion 3.4.0 failed to check the size of the output buffer of the caller which could lead to data corruption on the host (Cortex-M4) application.<br /> <br /> <br /> sl_si91x_aes<br /> sl_si91x_gcm<br /> sl_si91x_ccm <br /> sl_si91x_sha

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tipc: Fix use-after-free in tipc_conn_close().<br /> <br /> syzbot reported a null-ptr-deref in tipc_conn_close() during netns<br /> dismantle. [0]<br /> <br /> tipc_topsrv_stop() iterates tipc_net(net)-&gt;topsrv-&gt;conn_idr and calls<br /> tipc_conn_close() for each tipc_conn.<br /> <br /> The problem is that tipc_conn_close() is called after releasing the<br /> IDR lock.<br /> <br /> At the same time, there might be tipc_conn_recv_work() running and it<br /> could call tipc_conn_close() for the same tipc_conn and release its<br /> last -&gt;kref.<br /> <br /> Once we release the IDR lock in tipc_topsrv_stop(), there is no<br /> guarantee that the tipc_conn is alive.<br /> <br /> Let&amp;#39;s hold the ref before releasing the lock and put the ref after<br /> tipc_conn_close() in tipc_topsrv_stop().<br /> <br /> [0]:<br /> BUG: KASAN: use-after-free in tipc_conn_close+0x122/0x140 net/tipc/topsrv.c:165<br /> Read of size 8 at addr ffff888099305a08 by task kworker/u4:3/435<br /> <br /> CPU: 0 PID: 435 Comm: kworker/u4:3 Not tainted 4.19.204-syzkaller #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011<br /> Workqueue: netns cleanup_net<br /> Call Trace:<br /> __dump_stack lib/dump_stack.c:77 [inline]<br /> dump_stack+0x1fc/0x2ef lib/dump_stack.c:118<br /> print_address_description.cold+0x54/0x219 mm/kasan/report.c:256<br /> kasan_report_error.cold+0x8a/0x1b9 mm/kasan/report.c:354<br /> kasan_report mm/kasan/report.c:412 [inline]<br /> __asan_report_load8_noabort+0x88/0x90 mm/kasan/report.c:433<br /> tipc_conn_close+0x122/0x140 net/tipc/topsrv.c:165<br /> tipc_topsrv_stop net/tipc/topsrv.c:701 [inline]<br /> tipc_topsrv_exit_net+0x27b/0x5c0 net/tipc/topsrv.c:722<br /> ops_exit_list+0xa5/0x150 net/core/net_namespace.c:153<br /> cleanup_net+0x3b4/0x8b0 net/core/net_namespace.c:553<br /> process_one_work+0x864/0x1570 kernel/workqueue.c:2153<br /> worker_thread+0x64c/0x1130 kernel/workqueue.c:2296<br /> kthread+0x33f/0x460 kernel/kthread.c:259<br /> ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:415<br /> <br /> Allocated by task 23:<br /> kmem_cache_alloc_trace+0x12f/0x380 mm/slab.c:3625<br /> kmalloc include/linux/slab.h:515 [inline]<br /> kzalloc include/linux/slab.h:709 [inline]<br /> tipc_conn_alloc+0x43/0x4f0 net/tipc/topsrv.c:192<br /> tipc_topsrv_accept+0x1b5/0x280 net/tipc/topsrv.c:470<br /> process_one_work+0x864/0x1570 kernel/workqueue.c:2153<br /> worker_thread+0x64c/0x1130 kernel/workqueue.c:2296<br /> kthread+0x33f/0x460 kernel/kthread.c:259<br /> ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:415<br /> <br /> Freed by task 23:<br /> __cache_free mm/slab.c:3503 [inline]<br /> kfree+0xcc/0x210 mm/slab.c:3822<br /> tipc_conn_kref_release net/tipc/topsrv.c:150 [inline]<br /> kref_put include/linux/kref.h:70 [inline]<br /> conn_put+0x2cd/0x3a0 net/tipc/topsrv.c:155<br /> process_one_work+0x864/0x1570 kernel/workqueue.c:2153<br /> worker_thread+0x64c/0x1130 kernel/workqueue.c:2296<br /> kthread+0x33f/0x460 kernel/kthread.c:259<br /> ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:415<br /> <br /> The buggy address belongs to the object at ffff888099305a00<br /> which belongs to the cache kmalloc-512 of size 512<br /> The buggy address is located 8 bytes inside of<br /> 512-byte region [ffff888099305a00, ffff888099305c00)<br /> The buggy address belongs to the page:<br /> page:ffffea000264c140 count:1 mapcount:0 mapping:ffff88813bff0940 index:0x0<br /> flags: 0xfff00000000100(slab)<br /> raw: 00fff00000000100 ffffea00028b6b88 ffffea0002cd2b08 ffff88813bff0940<br /> raw: 0000000000000000 ffff888099305000 0000000100000006 0000000000000000<br /> page dumped because: kasan: bad access detected<br /> <br /> Memory state around the buggy address:<br /> ffff888099305900: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb<br /> ffff888099305980: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc<br /> &gt;ffff888099305a00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb<br /> ^<br /> ffff888099305a80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb<br /> ffff888099305b00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vsock: Fix transport_{g2h,h2g} TOCTOU<br /> <br /> vsock_find_cid() and vsock_dev_do_ioctl() may race with module unload.<br /> transport_{g2h,h2g} may become NULL after the NULL check.<br /> <br /> Introduce vsock_transport_local_cid() to protect from a potential<br /> null-ptr-deref.<br /> <br /> KASAN: null-ptr-deref in range [0x0000000000000118-0x000000000000011f]<br /> RIP: 0010:vsock_find_cid+0x47/0x90<br /> Call Trace:<br /> __vsock_bind+0x4b2/0x720<br /> vsock_bind+0x90/0xe0<br /> __sys_bind+0x14d/0x1e0<br /> __x64_sys_bind+0x6e/0xc0<br /> do_syscall_64+0x92/0x1c0<br /> entry_SYSCALL_64_after_hwframe+0x4b/0x53<br /> <br /> KASAN: null-ptr-deref in range [0x0000000000000118-0x000000000000011f]<br /> RIP: 0010:vsock_dev_do_ioctl.isra.0+0x58/0xf0<br /> Call Trace:<br /> __x64_sys_ioctl+0x12d/0x190<br /> do_syscall_64+0x92/0x1c0<br /> entry_SYSCALL_64_after_hwframe+0x4b/0x53