Vulnerabilities

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.

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.

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

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 /> 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.

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 /> netlink: Fix wraparounds of sk-&gt;sk_rmem_alloc.<br /> <br /> Netlink has this pattern in some places<br /> <br /> if (atomic_read(&amp;sk-&gt;sk_rmem_alloc) &gt; sk-&gt;sk_rcvbuf)<br /> atomic_add(skb-&gt;truesize, &amp;sk-&gt;sk_rmem_alloc);<br /> <br /> , which has the same problem fixed by commit 5a465a0da13e ("udp:<br /> Fix multiple wraparounds of sk-&gt;sk_rmem_alloc.").<br /> <br /> For example, if we set INT_MAX to SO_RCVBUFFORCE, the condition<br /> is always false as the two operands are of int.<br /> <br /> Then, a single socket can eat as many skb as possible until OOM<br /> happens, and we can see multiple wraparounds of sk-&gt;sk_rmem_alloc.<br /> <br /> Let&amp;#39;s fix it by using atomic_add_return() and comparing the two<br /> variables as unsigned int.<br /> <br /> Before:<br /> [root@fedora ~]# ss -f netlink<br /> Recv-Q Send-Q Local Address:Port Peer Address:Port<br /> -1668710080 0 rtnl:nl_wraparound/293 *<br /> <br /> After:<br /> [root@fedora ~]# ss -f netlink<br /> Recv-Q Send-Q Local Address:Port Peer Address:Port<br /> 2147483072 0 rtnl:nl_wraparound/290 *<br /> ^<br /> `--- INT_MAX - 576

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> perf: Revert to requiring CAP_SYS_ADMIN for uprobes<br /> <br /> Jann reports that uprobes can be used destructively when used in the<br /> middle of an instruction. The kernel only verifies there is a valid<br /> instruction at the requested offset, but due to variable instruction<br /> length cannot determine if this is an instruction as seen by the<br /> intended execution stream.<br /> <br /> Additionally, Mark Rutland notes that on architectures that mix data<br /> in the text segment (like arm64), a similar things can be done if the<br /> data word is &amp;#39;mistaken&amp;#39; for an instruction.<br /> <br /> As such, require CAP_SYS_ADMIN for uprobes.

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