Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vdpa/mlx5: add validation for VIRTIO_NET_CTRL_MQ_VQ_PAIRS_SET command<br /> <br /> When control vq receives a VIRTIO_NET_CTRL_MQ_VQ_PAIRS_SET command<br /> request from the driver, presently there is no validation against the<br /> number of queue pairs to configure, or even if multiqueue had been<br /> negotiated or not is unverified. This may lead to kernel panic due to<br /> uninitialized resource for the queues were there any bogus request<br /> sent down by untrusted driver. Tie up the loose ends there.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tipc: fix kernel panic when enabling bearer<br /> <br /> When enabling a bearer on a node, a kernel panic is observed:<br /> <br /> [ 4.498085] RIP: 0010:tipc_mon_prep+0x4e/0x130 [tipc]<br /> ...<br /> [ 4.520030] Call Trace:<br /> [ 4.520689] <br /> [ 4.521236] tipc_link_build_proto_msg+0x375/0x750 [tipc]<br /> [ 4.522654] tipc_link_build_state_msg+0x48/0xc0 [tipc]<br /> [ 4.524034] __tipc_node_link_up+0xd7/0x290 [tipc]<br /> [ 4.525292] tipc_rcv+0x5da/0x730 [tipc]<br /> [ 4.526346] ? __netif_receive_skb_core+0xb7/0xfc0<br /> [ 4.527601] tipc_l2_rcv_msg+0x5e/0x90 [tipc]<br /> [ 4.528737] __netif_receive_skb_list_core+0x20b/0x260<br /> [ 4.530068] netif_receive_skb_list_internal+0x1bf/0x2e0<br /> [ 4.531450] ? dev_gro_receive+0x4c2/0x680<br /> [ 4.532512] napi_complete_done+0x6f/0x180<br /> [ 4.533570] virtnet_poll+0x29c/0x42e [virtio_net]<br /> ...<br /> <br /> The node in question is receiving activate messages in another<br /> thread after changing bearer status to allow message sending/<br /> receiving in current thread:<br /> <br /> thread 1 | thread 2<br /> -------- | --------<br /> |<br /> tipc_enable_bearer() |<br /> test_and_set_bit_lock() |<br /> tipc_bearer_xmit_skb() |<br /> | tipc_l2_rcv_msg()<br /> | tipc_rcv()<br /> | __tipc_node_link_up()<br /> | tipc_link_build_state_msg()<br /> | tipc_link_build_proto_msg()<br /> | tipc_mon_prep()<br /> | {<br /> | ...<br /> | // null-pointer dereference<br /> | u16 gen = mon-&gt;dom_gen;<br /> | ...<br /> | }<br /> // Not being executed yet |<br /> tipc_mon_create() |<br /> { |<br /> ... |<br /> // allocate |<br /> mon = kzalloc(); |<br /> ... |<br /> } |<br /> <br /> Monitoring pointer in thread 2 is dereferenced before monitoring data<br /> is allocated in thread 1. This causes kernel panic.<br /> <br /> This commit fixes it by allocating the monitoring data before enabling<br /> the bearer to receive messages.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> HID: hid-thrustmaster: fix OOB read in thrustmaster_interrupts<br /> <br /> Syzbot reported an slab-out-of-bounds Read in thrustmaster_probe() bug.<br /> The root case is in missing validation check of actual number of endpoints.<br /> <br /> Code should not blindly access usb_host_interface::endpoint array, since<br /> it may contain less endpoints than code expects.<br /> <br /> Fix it by adding missing validaion check and print an error if<br /> number of endpoints do not match expected number

A privilege escalation vulnerability exists in the affected products which could allow a malicious user with basic privileges to access functions which should only be available to users with administrative level privileges. If exploited, an attacker could read sensitive data, and create users. For example, a malicious user with basic privileges could perform critical functions such as creating a user with elevated privileges and reading sensitive information in the “views” section.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tracing/osnoise: Do not unregister events twice<br /> <br /> Nicolas reported that using:<br /> <br /> # trace-cmd record -e all -M 10 -p osnoise --poll<br /> <br /> Resulted in the following kernel warning:<br /> <br /> ------------[ cut here ]------------<br /> WARNING: CPU: 0 PID: 1217 at kernel/tracepoint.c:404 tracepoint_probe_unregister+0x280/0x370<br /> [...]<br /> CPU: 0 PID: 1217 Comm: trace-cmd Not tainted 5.17.0-rc6-next-20220307-nico+ #19<br /> RIP: 0010:tracepoint_probe_unregister+0x280/0x370<br /> [...]<br /> CR2: 00007ff919b29497 CR3: 0000000109da4005 CR4: 0000000000170ef0<br /> Call Trace:<br /> <br /> osnoise_workload_stop+0x36/0x90<br /> tracing_set_tracer+0x108/0x260<br /> tracing_set_trace_write+0x94/0xd0<br /> ? __check_object_size.part.0+0x10a/0x150<br /> ? selinux_file_permission+0x104/0x150<br /> vfs_write+0xb5/0x290<br /> ksys_write+0x5f/0xe0<br /> do_syscall_64+0x3b/0x90<br /> entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> RIP: 0033:0x7ff919a18127<br /> [...]<br /> ---[ end trace 0000000000000000 ]---<br /> <br /> The warning complains about an attempt to unregister an<br /> unregistered tracepoint.<br /> <br /> This happens on trace-cmd because it first stops tracing, and<br /> then switches the tracer to nop. Which is equivalent to:<br /> <br /> # cd /sys/kernel/tracing/<br /> # echo osnoise &gt; current_tracer<br /> # echo 0 &gt; tracing_on<br /> # echo nop &gt; current_tracer<br /> <br /> The osnoise tracer stops the workload when no trace instance<br /> is actually collecting data. This can be caused both by<br /> disabling tracing or disabling the tracer itself.<br /> <br /> To avoid unregistering events twice, use the existing<br /> trace_osnoise_callback_enabled variable to check if the events<br /> (and the workload) are actually active before trying to<br /> deactivate them.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu: bypass tiling flag check in virtual display case (v2)<br /> <br /> vkms leverages common amdgpu framebuffer creation, and<br /> also as it does not support FB modifier, there is no need<br /> to check tiling flags when initing framebuffer when virtual<br /> display is enabled.<br /> <br /> This can fix below calltrace:<br /> <br /> amdgpu 0000:00:08.0: GFX9+ requires FB check based on format modifier<br /> WARNING: CPU: 0 PID: 1023 at drivers/gpu/drm/amd/amdgpu/amdgpu_display.c:1150 amdgpu_display_framebuffer_init+0x8e7/0xb40 [amdgpu]<br /> <br /> v2: check adev-&gt;enable_virtual_display instead as vkms can be<br /> enabled in bare metal as well.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net-sysfs: add check for netdevice being present to speed_show<br /> <br /> When bringing down the netdevice or system shutdown, a panic can be<br /> triggered while accessing the sysfs path because the device is already<br /> removed.<br /> <br /> [ 755.549084] mlx5_core 0000:12:00.1: Shutdown was called<br /> [ 756.404455] mlx5_core 0000:12:00.0: Shutdown was called<br /> ...<br /> [ 757.937260] BUG: unable to handle kernel NULL pointer dereference at (null)<br /> [ 758.031397] IP: [] dma_pool_alloc+0x1ab/0x280<br /> <br /> crash&gt; bt<br /> ...<br /> PID: 12649 TASK: ffff8924108f2100 CPU: 1 COMMAND: "amsd"<br /> ...<br /> #9 [ffff89240e1a38b0] page_fault at ffffffff8f38c778<br /> [exception RIP: dma_pool_alloc+0x1ab]<br /> RIP: ffffffff8ee11acb RSP: ffff89240e1a3968 RFLAGS: 00010046<br /> RAX: 0000000000000246 RBX: ffff89243d874100 RCX: 0000000000001000<br /> RDX: 0000000000000000 RSI: 0000000000000246 RDI: ffff89243d874090<br /> RBP: ffff89240e1a39c0 R8: 000000000001f080 R9: ffff8905ffc03c00<br /> R10: ffffffffc04680d4 R11: ffffffff8edde9fd R12: 00000000000080d0<br /> R13: ffff89243d874090 R14: ffff89243d874080 R15: 0000000000000000<br /> ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018<br /> #10 [ffff89240e1a39c8] mlx5_alloc_cmd_msg at ffffffffc04680f3 [mlx5_core]<br /> #11 [ffff89240e1a3a18] cmd_exec at ffffffffc046ad62 [mlx5_core]<br /> #12 [ffff89240e1a3ab8] mlx5_cmd_exec at ffffffffc046b4fb [mlx5_core]<br /> #13 [ffff89240e1a3ae8] mlx5_core_access_reg at ffffffffc0475434 [mlx5_core]<br /> #14 [ffff89240e1a3b40] mlx5e_get_fec_caps at ffffffffc04a7348 [mlx5_core]<br /> #15 [ffff89240e1a3bb0] get_fec_supported_advertised at ffffffffc04992bf [mlx5_core]<br /> #16 [ffff89240e1a3c08] mlx5e_get_link_ksettings at ffffffffc049ab36 [mlx5_core]<br /> #17 [ffff89240e1a3ce8] __ethtool_get_link_ksettings at ffffffff8f25db46<br /> #18 [ffff89240e1a3d48] speed_show at ffffffff8f277208<br /> #19 [ffff89240e1a3dd8] dev_attr_show at ffffffff8f0b70e3<br /> #20 [ffff89240e1a3df8] sysfs_kf_seq_show at ffffffff8eedbedf<br /> #21 [ffff89240e1a3e18] kernfs_seq_show at ffffffff8eeda596<br /> #22 [ffff89240e1a3e28] seq_read at ffffffff8ee76d10<br /> #23 [ffff89240e1a3e98] kernfs_fop_read at ffffffff8eedaef5<br /> #24 [ffff89240e1a3ed8] vfs_read at ffffffff8ee4e3ff<br /> #25 [ffff89240e1a3f08] sys_read at ffffffff8ee4f27f<br /> #26 [ffff89240e1a3f50] system_call_fastpath at ffffffff8f395f92<br /> <br /> crash&gt; net_device.state ffff89443b0c0000<br /> state = 0x5 (__LINK_STATE_START| __LINK_STATE_NOCARRIER)<br /> <br /> To prevent this scenario, we also make sure that the netdevice is present.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> staging: gdm724x: fix use after free in gdm_lte_rx()<br /> <br /> The netif_rx_ni() function frees the skb so we can&amp;#39;t dereference it to<br /> save the skb-&gt;len.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/vc4: hdmi: Unregister codec device on unbind<br /> <br /> On bind we will register the HDMI codec device but we don&amp;#39;t unregister<br /> it on unbind, leading to a device leakage. Unregister our device at<br /> unbind.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: arc_emac: Fix use after free in arc_mdio_probe()<br /> <br /> If bus-&gt;state is equal to MDIOBUS_ALLOCATED, mdiobus_free(bus) will free<br /> the "bus". But bus-&gt;name is still used in the next line, which will lead<br /> to a use after free.<br /> <br /> We can fix it by putting the name in a local variable and make the<br /> bus-&gt;name point to the rodata section "name",then use the name in the<br /> error message without referring to bus to avoid the uaf.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sctp: fix kernel-infoleak for SCTP sockets<br /> <br /> syzbot reported a kernel infoleak [1] of 4 bytes.<br /> <br /> After analysis, it turned out r-&gt;idiag_expires is not initialized<br /> if inet_sctp_diag_fill() calls inet_diag_msg_common_fill()<br /> <br /> Make sure to clear idiag_timer/idiag_retrans/idiag_expires<br /> and let inet_diag_msg_sctpasoc_fill() fill them again if needed.<br /> <br /> [1]<br /> <br /> BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:121 [inline]<br /> BUG: KMSAN: kernel-infoleak in copyout lib/iov_iter.c:154 [inline]<br /> BUG: KMSAN: kernel-infoleak in _copy_to_iter+0x6ef/0x25a0 lib/iov_iter.c:668<br /> instrument_copy_to_user include/linux/instrumented.h:121 [inline]<br /> copyout lib/iov_iter.c:154 [inline]<br /> _copy_to_iter+0x6ef/0x25a0 lib/iov_iter.c:668<br /> copy_to_iter include/linux/uio.h:162 [inline]<br /> simple_copy_to_iter+0xf3/0x140 net/core/datagram.c:519<br /> __skb_datagram_iter+0x2d5/0x11b0 net/core/datagram.c:425<br /> skb_copy_datagram_iter+0xdc/0x270 net/core/datagram.c:533<br /> skb_copy_datagram_msg include/linux/skbuff.h:3696 [inline]<br /> netlink_recvmsg+0x669/0x1c80 net/netlink/af_netlink.c:1977<br /> sock_recvmsg_nosec net/socket.c:948 [inline]<br /> sock_recvmsg net/socket.c:966 [inline]<br /> __sys_recvfrom+0x795/0xa10 net/socket.c:2097<br /> __do_sys_recvfrom net/socket.c:2115 [inline]<br /> __se_sys_recvfrom net/socket.c:2111 [inline]<br /> __x64_sys_recvfrom+0x19d/0x210 net/socket.c:2111<br /> do_syscall_x64 arch/x86/entry/common.c:51 [inline]<br /> do_syscall_64+0x54/0xd0 arch/x86/entry/common.c:82<br /> entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> <br /> Uninit was created at:<br /> slab_post_alloc_hook mm/slab.h:737 [inline]<br /> slab_alloc_node mm/slub.c:3247 [inline]<br /> __kmalloc_node_track_caller+0xe0c/0x1510 mm/slub.c:4975<br /> kmalloc_reserve net/core/skbuff.c:354 [inline]<br /> __alloc_skb+0x545/0xf90 net/core/skbuff.c:426<br /> alloc_skb include/linux/skbuff.h:1158 [inline]<br /> netlink_dump+0x3e5/0x16c0 net/netlink/af_netlink.c:2248<br /> __netlink_dump_start+0xcf8/0xe90 net/netlink/af_netlink.c:2373<br /> netlink_dump_start include/linux/netlink.h:254 [inline]<br /> inet_diag_handler_cmd+0x2e7/0x400 net/ipv4/inet_diag.c:1341<br /> sock_diag_rcv_msg+0x24a/0x620<br /> netlink_rcv_skb+0x40c/0x7e0 net/netlink/af_netlink.c:2494<br /> sock_diag_rcv+0x63/0x80 net/core/sock_diag.c:277<br /> netlink_unicast_kernel net/netlink/af_netlink.c:1317 [inline]<br /> netlink_unicast+0x1093/0x1360 net/netlink/af_netlink.c:1343<br /> netlink_sendmsg+0x14d9/0x1720 net/netlink/af_netlink.c:1919<br /> sock_sendmsg_nosec net/socket.c:705 [inline]<br /> sock_sendmsg net/socket.c:725 [inline]<br /> sock_write_iter+0x594/0x690 net/socket.c:1061<br /> do_iter_readv_writev+0xa7f/0xc70<br /> do_iter_write+0x52c/0x1500 fs/read_write.c:851<br /> vfs_writev fs/read_write.c:924 [inline]<br /> do_writev+0x645/0xe00 fs/read_write.c:967<br /> __do_sys_writev fs/read_write.c:1040 [inline]<br /> __se_sys_writev fs/read_write.c:1037 [inline]<br /> __x64_sys_writev+0xe5/0x120 fs/read_write.c:1037<br /> do_syscall_x64 arch/x86/entry/common.c:51 [inline]<br /> do_syscall_64+0x54/0xd0 arch/x86/entry/common.c:82<br /> entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> <br /> Bytes 68-71 of 2508 are uninitialized<br /> Memory access of size 2508 starts at ffff888114f9b000<br /> Data copied to user address 00007f7fe09ff2e0<br /> <br /> CPU: 1 PID: 3478 Comm: syz-executor306 Not tainted 5.17.0-rc4-syzkaller #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> gianfar: ethtool: Fix refcount leak in gfar_get_ts_info<br /> <br /> The of_find_compatible_node() function returns a node pointer with<br /> refcount incremented, We should use of_node_put() on it when done<br /> Add the missing of_node_put() to release the refcount.