Vulnerabilities

An issue in Gardyn 4 allows a remote attacker with the corresponding ssh private key can gain remote root access to affected devices

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

Certain HP DesignJet products may be vulnerable to information disclosure though printer'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 /> 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

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

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tcp: Correct signedness in skb remaining space calculation<br /> <br /> Syzkaller reported a bug [1] where sk-&gt;sk_forward_alloc can overflow.<br /> <br /> When we send data, if an skb exists at the tail of the write queue, the<br /> kernel will attempt to append the new data to that skb. However, the code<br /> that checks for available space in the skb is flawed:<br /> &amp;#39;&amp;#39;&amp;#39;<br /> copy = size_goal - skb-&gt;len<br /> &amp;#39;&amp;#39;&amp;#39;<br /> <br /> The types of the variables involved are:<br /> &amp;#39;&amp;#39;&amp;#39;<br /> copy: ssize_t (s64 on 64-bit systems)<br /> size_goal: int<br /> skb-&gt;len: unsigned int<br /> &amp;#39;&amp;#39;&amp;#39;<br /> <br /> Due to C&amp;#39;s type promotion rules, the signed size_goal is converted to an<br /> unsigned int to match skb-&gt;len before the subtraction. The result is an<br /> unsigned int.<br /> <br /> When this unsigned int result is then assigned to the s64 copy variable,<br /> it is zero-extended, preserving its non-negative value. Consequently, copy<br /> is always &gt;= 0.<br /> <br /> Assume we are sending 2GB of data and size_goal has been adjusted to a<br /> value smaller than skb-&gt;len. The subtraction will result in copy holding a<br /> very large positive integer. In the subsequent logic, this large value is<br /> used to update sk-&gt;sk_forward_alloc, which can easily cause it to overflow.<br /> <br /> The syzkaller reproducer uses TCP_REPAIR to reliably create this<br /> condition. However, this can also occur in real-world scenarios. The<br /> tcp_bound_to_half_wnd() function can also reduce size_goal to a small<br /> value. This would cause the subsequent tcp_wmem_schedule() to set<br /> sk-&gt;sk_forward_alloc to a value close to INT_MAX. Further memory<br /> allocation requests would then cause sk_forward_alloc to wrap around and<br /> become negative.<br /> <br /> [1]: https://syzkaller.appspot.com/bug?extid=de6565462ab540f50e47

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipmi:msghandler: Fix potential memory corruption in ipmi_create_user()<br /> <br /> The "intf" list iterator is an invalid pointer if the correct<br /> "intf-&gt;intf_num" is not found. Calling atomic_dec(&amp;intf-&gt;nr_users) on<br /> and invalid pointer will lead to memory corruption.<br /> <br /> We don&amp;#39;t really need to call atomic_dec() if we haven&amp;#39;t called<br /> atomic_add_return() so update the if (intf-&gt;in_shutdown) path as well.