Vulnerabilities

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

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.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/sched: Abort __tc_modify_qdisc if parent class does not exist<br /> <br /> Lion&amp;#39;s patch [1] revealed an ancient bug in the qdisc API.<br /> Whenever a user creates/modifies a qdisc specifying as a parent another<br /> qdisc, the qdisc API will, during grafting, detect that the user is<br /> not trying to attach to a class and reject. However grafting is<br /> performed after qdisc_create (and thus the qdiscs&amp;#39; init callback) is<br /> executed. In qdiscs that eventually call qdisc_tree_reduce_backlog<br /> during init or change (such as fq, hhf, choke, etc), an issue<br /> arises. For example, executing the following commands:<br /> <br /> sudo tc qdisc add dev lo root handle a: htb default 2<br /> sudo tc qdisc add dev lo parent a: handle beef fq<br /> <br /> Qdiscs such as fq, hhf, choke, etc unconditionally invoke<br /> qdisc_tree_reduce_backlog() in their control path init() or change() which<br /> then causes a failure to find the child class; however, that does not stop<br /> the unconditional invocation of the assumed child qdisc&amp;#39;s qlen_notify with<br /> a null class. All these qdiscs make the assumption that class is non-null.<br /> <br /> The solution is ensure that qdisc_leaf() which looks up the parent<br /> class, and is invoked prior to qdisc_create(), should return failure on<br /> not finding the class.<br /> In this patch, we leverage qdisc_leaf to return ERR_PTRs whenever the<br /> parentid doesn&amp;#39;t correspond to a class, so that we can detect it<br /> earlier on and abort before qdisc_create is called.<br /> <br /> [1] https://lore.kernel.org/netdev/d912cbd7-193b-4269-9857-525bee8bbb6a@gmail.com/

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> atm: clip: Fix NULL pointer dereference in vcc_sendmsg()<br /> <br /> atmarpd_dev_ops does not implement the send method, which may cause crash<br /> as bellow.<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000000<br /> PGD 0 P4D 0<br /> Oops: Oops: 0010 [#1] SMP KASAN NOPTI<br /> CPU: 0 UID: 0 PID: 5324 Comm: syz.0.0 Not tainted 6.15.0-rc6-syzkaller-00346-g5723cc3450bc #0 PREEMPT(full)<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014<br /> RIP: 0010:0x0<br /> Code: Unable to access opcode bytes at 0xffffffffffffffd6.<br /> RSP: 0018:ffffc9000d3cf778 EFLAGS: 00010246<br /> RAX: 1ffffffff1910dd1 RBX: 00000000000000c0 RCX: dffffc0000000000<br /> RDX: ffffc9000dc82000 RSI: ffff88803e4c4640 RDI: ffff888052cd0000<br /> RBP: ffffc9000d3cf8d0 R08: ffff888052c9143f R09: 1ffff1100a592287<br /> R10: dffffc0000000000 R11: 0000000000000000 R12: 1ffff92001a79f00<br /> R13: ffff888052cd0000 R14: ffff88803e4c4640 R15: ffffffff8c886e88<br /> FS: 00007fbc762566c0(0000) GS:ffff88808d6c2000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: ffffffffffffffd6 CR3: 0000000041f1b000 CR4: 0000000000352ef0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> vcc_sendmsg+0xa10/0xc50 net/atm/common.c:644<br /> sock_sendmsg_nosec net/socket.c:712 [inline]<br /> __sock_sendmsg+0x219/0x270 net/socket.c:727<br /> ____sys_sendmsg+0x52d/0x830 net/socket.c:2566<br /> ___sys_sendmsg+0x21f/0x2a0 net/socket.c:2620<br /> __sys_sendmmsg+0x227/0x430 net/socket.c:2709<br /> __do_sys_sendmmsg net/socket.c:2736 [inline]<br /> __se_sys_sendmmsg net/socket.c:2733 [inline]<br /> __x64_sys_sendmmsg+0xa0/0xc0 net/socket.c:2733<br /> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]<br /> do_syscall_64+0xf6/0x210 arch/x86/entry/syscall_64.c:94<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> atm: clip: Fix infinite recursive call of clip_push().<br /> <br /> syzbot reported the splat below. [0]<br /> <br /> This happens if we call ioctl(ATMARP_MKIP) more than once.<br /> <br /> During the first call, clip_mkip() sets clip_push() to vcc-&gt;push(),<br /> and the second call copies it to clip_vcc-&gt;old_push().<br /> <br /> Later, when the socket is close()d, vcc_destroy_socket() passes<br /> NULL skb to clip_push(), which calls clip_vcc-&gt;old_push(),<br /> triggering the infinite recursion.<br /> <br /> Let&amp;#39;s prevent the second ioctl(ATMARP_MKIP) by checking<br /> vcc-&gt;user_back, which is allocated by the first call as clip_vcc.<br /> <br /> Note also that we use lock_sock() to prevent racy calls.<br /> <br /> [0]:<br /> BUG: TASK stack guard page was hit at ffffc9000d66fff8 (stack is ffffc9000d670000..ffffc9000d678000)<br /> Oops: stack guard page: 0000 [#1] SMP KASAN NOPTI<br /> CPU: 0 UID: 0 PID: 5322 Comm: syz.0.0 Not tainted 6.16.0-rc4-syzkaller #0 PREEMPT(full)<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014<br /> RIP: 0010:clip_push+0x5/0x720 net/atm/clip.c:191<br /> Code: e0 8f aa 8c e8 1c ad 5b fa eb ae 66 2e 0f 1f 84 00 00 00 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 55 57 41 56 41 55 41 54 53 48 83 ec 20 48 89 f3 49 89 fd 48 bd 00<br /> RSP: 0018:ffffc9000d670000 EFLAGS: 00010246<br /> RAX: 1ffff1100235a4a5 RBX: ffff888011ad2508 RCX: ffff8880003c0000<br /> RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff888037f01000<br /> RBP: dffffc0000000000 R08: ffffffff8fa104f7 R09: 1ffffffff1f4209e<br /> R10: dffffc0000000000 R11: ffffffff8a99b300 R12: ffffffff8a99b300<br /> R13: ffff888037f01000 R14: ffff888011ad2500 R15: ffff888037f01578<br /> FS: 000055557ab6d500(0000) GS:ffff88808d250000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: ffffc9000d66fff8 CR3: 0000000043172000 CR4: 0000000000352ef0<br /> Call Trace:<br /> <br /> clip_push+0x6dc/0x720 net/atm/clip.c:200<br /> clip_push+0x6dc/0x720 net/atm/clip.c:200<br /> clip_push+0x6dc/0x720 net/atm/clip.c:200<br /> ...<br /> clip_push+0x6dc/0x720 net/atm/clip.c:200<br /> clip_push+0x6dc/0x720 net/atm/clip.c:200<br /> clip_push+0x6dc/0x720 net/atm/clip.c:200<br /> vcc_destroy_socket net/atm/common.c:183 [inline]<br /> vcc_release+0x157/0x460 net/atm/common.c:205<br /> __sock_release net/socket.c:647 [inline]<br /> sock_close+0xc0/0x240 net/socket.c:1391<br /> __fput+0x449/0xa70 fs/file_table.c:465<br /> task_work_run+0x1d1/0x260 kernel/task_work.c:227<br /> resume_user_mode_work include/linux/resume_user_mode.h:50 [inline]<br /> exit_to_user_mode_loop+0xec/0x110 kernel/entry/common.c:114<br /> exit_to_user_mode_prepare include/linux/entry-common.h:330 [inline]<br /> syscall_exit_to_user_mode_work include/linux/entry-common.h:414 [inline]<br /> syscall_exit_to_user_mode include/linux/entry-common.h:449 [inline]<br /> do_syscall_64+0x2bd/0x3b0 arch/x86/entry/syscall_64.c:100<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> RIP: 0033:0x7ff31c98e929<br /> Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48<br /> RSP: 002b:00007fffb5aa1f78 EFLAGS: 00000246 ORIG_RAX: 00000000000001b4<br /> RAX: 0000000000000000 RBX: 0000000000012747 RCX: 00007ff31c98e929<br /> RDX: 0000000000000000 RSI: 000000000000001e RDI: 0000000000000003<br /> RBP: 00007ff31cbb7ba0 R08: 0000000000000001 R09: 0000000db5aa226f<br /> R10: 00007ff31c7ff030 R11: 0000000000000246 R12: 00007ff31cbb608c<br /> R13: 00007ff31cbb6080 R14: ffffffffffffffff R15: 00007fffb5aa2090<br /> <br /> Modules linked in:

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> atm: clip: Fix potential null-ptr-deref in to_atmarpd().<br /> <br /> atmarpd is protected by RTNL since commit f3a0592b37b8 ("[ATM]: clip<br /> causes unregister hang").<br /> <br /> However, it is not enough because to_atmarpd() is called without RTNL,<br /> especially clip_neigh_solicit() / neigh_ops-&gt;solicit() is unsleepable.<br /> <br /> Also, there is no RTNL dependency around atmarpd.<br /> <br /> Let&amp;#39;s use a private mutex and RCU to protect access to atmarpd in<br /> to_atmarpd().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vsock: Fix transport_* TOCTOU<br /> <br /> Transport assignment may race with module unload. Protect new_transport<br /> from becoming a stale pointer.<br /> <br /> This also takes care of an insecure call in vsock_use_local_transport();<br /> add a lockdep assert.<br /> <br /> BUG: unable to handle page fault for address: fffffbfff8056000<br /> Oops: Oops: 0000 [#1] SMP KASAN<br /> RIP: 0010:vsock_assign_transport+0x366/0x600<br /> Call Trace:<br /> vsock_connect+0x59c/0xc40<br /> __sys_connect+0xe8/0x100<br /> __x64_sys_connect+0x6e/0xc0<br /> do_syscall_64+0x92/0x1c0<br /> entry_SYSCALL_64_after_hwframe+0x4b/0x53