Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Drivers: hv: vmbus: Fix potential crash on module unload<br /> <br /> The vmbus driver relies on the panic notifier infrastructure to perform<br /> some operations when a panic event is detected. Since vmbus can be built<br /> as module, it is required that the driver handles both registering and<br /> unregistering such panic notifier callback.<br /> <br /> After commit 74347a99e73a ("x86/Hyper-V: Unload vmbus channel in hv panic callback")<br /> though, the panic notifier registration is done unconditionally in the module<br /> initialization routine whereas the unregistering procedure is conditionally<br /> guarded and executes only if HV_FEATURE_GUEST_CRASH_MSR_AVAILABLE capability<br /> is set.<br /> <br /> This patch fixes that by unconditionally unregistering the panic notifier<br /> in the module&amp;#39;s exit routine as well.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Drivers: hv: vmbus: Fix initialization of device object in vmbus_device_register()<br /> <br /> Initialize the device&amp;#39;s dma_{mask,parms} pointers and the device&amp;#39;s<br /> dma_mask value before invoking device_register(). Address the<br /> following trace with 5.17-rc7:<br /> <br /> [ 49.646839] WARNING: CPU: 0 PID: 189 at include/linux/dma-mapping.h:543<br /> netvsc_probe+0x37a/0x3a0 [hv_netvsc]<br /> [ 49.646928] Call Trace:<br /> [ 49.646930] <br /> [ 49.646935] vmbus_probe+0x40/0x60 [hv_vmbus]<br /> [ 49.646942] really_probe+0x1ce/0x3b0<br /> [ 49.646948] __driver_probe_device+0x109/0x180<br /> [ 49.646952] driver_probe_device+0x23/0xa0<br /> [ 49.646955] __device_attach_driver+0x76/0xe0<br /> [ 49.646958] ? driver_allows_async_probing+0x50/0x50<br /> [ 49.646961] bus_for_each_drv+0x84/0xd0<br /> [ 49.646964] __device_attach+0xed/0x170<br /> [ 49.646967] device_initial_probe+0x13/0x20<br /> [ 49.646970] bus_probe_device+0x8f/0xa0<br /> [ 49.646973] device_add+0x41a/0x8e0<br /> [ 49.646975] ? hrtimer_init+0x28/0x80<br /> [ 49.646981] device_register+0x1b/0x20<br /> [ 49.646983] vmbus_device_register+0x5e/0xf0 [hv_vmbus]<br /> [ 49.646991] vmbus_add_channel_work+0x12d/0x190 [hv_vmbus]<br /> [ 49.646999] process_one_work+0x21d/0x3f0<br /> [ 49.647002] worker_thread+0x4a/0x3b0<br /> [ 49.647005] ? process_one_work+0x3f0/0x3f0<br /> [ 49.647007] kthread+0xff/0x130<br /> [ 49.647011] ? kthread_complete_and_exit+0x20/0x20<br /> [ 49.647015] ret_from_fork+0x22/0x30<br /> [ 49.647020] <br /> [ 49.647021] ---[ end trace 0000000000000000 ]---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> virtio_console: eliminate anonymous module_init &amp; module_exit<br /> <br /> Eliminate anonymous module_init() and module_exit(), which can lead to<br /> confusion or ambiguity when reading System.map, crashes/oops/bugs,<br /> or an initcall_debug log.<br /> <br /> Give each of these init and exit functions unique driver-specific<br /> names to eliminate the anonymous names.<br /> <br /> Example 1: (System.map)<br /> ffffffff832fc78c t init<br /> ffffffff832fc79e t init<br /> ffffffff832fc8f8 t init<br /> <br /> Example 2: (initcall_debug log)<br /> calling init+0x0/0x12 @ 1<br /> initcall init+0x0/0x12 returned 0 after 15 usecs<br /> calling init+0x0/0x60 @ 1<br /> initcall init+0x0/0x60 returned 0 after 2 usecs<br /> calling init+0x0/0x9a @ 1<br /> initcall init+0x0/0x9a returned 0 after 74 usecs

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> skbuff: fix coalescing for page_pool fragment recycling<br /> <br /> Fix a use-after-free when using page_pool with page fragments. We<br /> encountered this problem during normal RX in the hns3 driver:<br /> <br /> (1) Initially we have three descriptors in the RX queue. The first one<br /> allocates PAGE1 through page_pool, and the other two allocate one<br /> half of PAGE2 each. Page references look like this:<br /> <br /> RX_BD1 _______ PAGE1<br /> RX_BD2 _______ PAGE2<br /> RX_BD3 _________/<br /> <br /> (2) Handle RX on the first descriptor. Allocate SKB1, eventually added<br /> to the receive queue by tcp_queue_rcv().<br /> <br /> (3) Handle RX on the second descriptor. Allocate SKB2 and pass it to<br /> netif_receive_skb():<br /> <br /> netif_receive_skb(SKB2)<br /> ip_rcv(SKB2)<br /> SKB3 = skb_clone(SKB2)<br /> <br /> SKB2 and SKB3 share a reference to PAGE2 through<br /> skb_shinfo()-&gt;dataref. The other ref to PAGE2 is still held by<br /> RX_BD3:<br /> <br /> SKB2 ---+- PAGE2<br /> SKB3 __/ /<br /> RX_BD3 _________/<br /> <br /> (3b) Now while handling TCP, coalesce SKB3 with SKB1:<br /> <br /> tcp_v4_rcv(SKB3)<br /> tcp_try_coalesce(to=SKB1, from=SKB3) // succeeds<br /> kfree_skb_partial(SKB3)<br /> skb_release_data(SKB3) // drops one dataref<br /> <br /> SKB1 _____ PAGE1<br /> \____<br /> SKB2 _____ PAGE2<br /> /<br /> RX_BD3 _________/<br /> <br /> In skb_try_coalesce(), __skb_frag_ref() takes a page reference to<br /> PAGE2, where it should instead have increased the page_pool frag<br /> reference, pp_frag_count. Without coalescing, when releasing both<br /> SKB2 and SKB3, a single reference to PAGE2 would be dropped. Now<br /> when releasing SKB1 and SKB2, two references to PAGE2 will be<br /> dropped, resulting in underflow.<br /> <br /> (3c) Drop SKB2:<br /> <br /> af_packet_rcv(SKB2)<br /> consume_skb(SKB2)<br /> skb_release_data(SKB2) // drops second dataref<br /> page_pool_return_skb_page(PAGE2) // drops one pp_frag_count<br /> <br /> SKB1 _____ PAGE1<br /> \____<br /> PAGE2<br /> /<br /> RX_BD3 _________/<br /> <br /> (4) Userspace calls recvmsg()<br /> Copies SKB1 and releases it. Since SKB3 was coalesced with SKB1, we<br /> release the SKB3 page as well:<br /> <br /> tcp_eat_recv_skb(SKB1)<br /> skb_release_data(SKB1)<br /> page_pool_return_skb_page(PAGE1)<br /> page_pool_return_skb_page(PAGE2) // drops second pp_frag_count<br /> <br /> (5) PAGE2 is freed, but the third RX descriptor was still using it!<br /> In our case this causes IOMMU faults, but it would silently corrupt<br /> memory if the IOMMU was disabled.<br /> <br /> Change the logic that checks whether pp_recycle SKBs can be coalesced.<br /> We still reject differing pp_recycle between &amp;#39;from&amp;#39; and &amp;#39;to&amp;#39; SKBs, but<br /> in order to avoid the situation described above, we also reject<br /> coalescing when both &amp;#39;from&amp;#39; and &amp;#39;to&amp;#39; are pp_recycled and &amp;#39;from&amp;#39; is<br /> cloned.<br /> <br /> The new logic allows coalescing a cloned pp_recycle SKB into a page<br /> refcounted one, because in this case the release (4) will drop the right<br /> reference, the one taken by skb_try_coalesce().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rxrpc: fix a race in rxrpc_exit_net()<br /> <br /> Current code can lead to the following race:<br /> <br /> CPU0 CPU1<br /> <br /> rxrpc_exit_net()<br /> rxrpc_peer_keepalive_worker()<br /> if (rxnet-&gt;live)<br /> <br /> rxnet-&gt;live = false;<br /> del_timer_sync(&amp;rxnet-&gt;peer_keepalive_timer);<br /> <br /> timer_reduce(&amp;rxnet-&gt;peer_keepalive_timer, jiffies + delay);<br /> <br /> cancel_work_sync(&amp;rxnet-&gt;peer_keepalive_work);<br /> <br /> rxrpc_exit_net() exits while peer_keepalive_timer is still armed,<br /> leading to use-after-free.<br /> <br /> syzbot report was:<br /> <br /> ODEBUG: free active (active state 0) object type: timer_list hint: rxrpc_peer_keepalive_timeout+0x0/0xb0<br /> WARNING: CPU: 0 PID: 3660 at lib/debugobjects.c:505 debug_print_object+0x16e/0x250 lib/debugobjects.c:505<br /> Modules linked in:<br /> CPU: 0 PID: 3660 Comm: kworker/u4:6 Not tainted 5.17.0-syzkaller-13993-g88e6c0207623 #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011<br /> Workqueue: netns cleanup_net<br /> RIP: 0010:debug_print_object+0x16e/0x250 lib/debugobjects.c:505<br /> Code: ff df 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 af 00 00 00 48 8b 14 dd 00 1c 26 8a 4c 89 ee 48 c7 c7 00 10 26 8a e8 b1 e7 28 05 0b 83 05 15 eb c5 09 01 48 83 c4 18 5b 5d 41 5c 41 5d 41 5e c3<br /> RSP: 0018:ffffc9000353fb00 EFLAGS: 00010082<br /> RAX: 0000000000000000 RBX: 0000000000000003 RCX: 0000000000000000<br /> RDX: ffff888029196140 RSI: ffffffff815efad8 RDI: fffff520006a7f52<br /> RBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000000<br /> R10: ffffffff815ea4ae R11: 0000000000000000 R12: ffffffff89ce23e0<br /> R13: ffffffff8a2614e0 R14: ffffffff816628c0 R15: dffffc0000000000<br /> FS: 0000000000000000(0000) GS:ffff8880b9c00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007fe1f2908924 CR3: 0000000043720000 CR4: 00000000003506f0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> __debug_check_no_obj_freed lib/debugobjects.c:992 [inline]<br /> debug_check_no_obj_freed+0x301/0x420 lib/debugobjects.c:1023<br /> kfree+0xd6/0x310 mm/slab.c:3809<br /> ops_free_list.part.0+0x119/0x370 net/core/net_namespace.c:176<br /> ops_free_list net/core/net_namespace.c:174 [inline]<br /> cleanup_net+0x591/0xb00 net/core/net_namespace.c:598<br /> process_one_work+0x996/0x1610 kernel/workqueue.c:2289<br /> worker_thread+0x665/0x1080 kernel/workqueue.c:2436<br /> kthread+0x2e9/0x3a0 kernel/kthread.c:376<br /> ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:298<br />

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dpaa2-ptp: Fix refcount leak in dpaa2_ptp_probe<br /> <br /> This node pointer is returned by of_find_compatible_node() with<br /> refcount incremented. Calling of_node_put() to aovid the refcount leak.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> IB/rdmavt: add lock to call to rvt_error_qp to prevent a race condition<br /> <br /> The documentation of the function rvt_error_qp says both r_lock and s_lock<br /> need to be held when calling that function. It also asserts using lockdep<br /> that both of those locks are held. However, the commit I referenced in<br /> Fixes accidentally makes the call to rvt_error_qp in rvt_ruc_loopback no<br /> longer covered by r_lock. This results in the lockdep assertion failing<br /> and also possibly in a race condition.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> arch/arm64: Fix topology initialization for core scheduling<br /> <br /> Arm64 systems rely on store_cpu_topology() to call update_siblings_masks()<br /> to transfer the toplogy to the various cpu masks. This needs to be done<br /> before the call to notify_cpu_starting() which tells the scheduler about<br /> each cpu found, otherwise the core scheduling data structures are setup<br /> in a way that does not match the actual topology.<br /> <br /> With smt_mask not setup correctly we bail on `cpumask_weight(smt_mask) == 1`<br /> for !leaders in:<br /> <br /> notify_cpu_starting()<br /> cpuhp_invoke_callback_range()<br /> sched_cpu_starting()<br /> sched_core_cpu_starting()<br /> <br /> which leads to rq-&gt;core not being correctly set for !leader-rq&amp;#39;s.<br /> <br /> Without this change stress-ng (which enables core scheduling in its prctl<br /> tests in newer versions -- i.e. with PR_SCHED_CORE support) causes a warning<br /> and then a crash (trimmed for legibility):<br /> <br /> [ 1853.805168] ------------[ cut here ]------------<br /> [ 1853.809784] task_rq(b)-&gt;core != rq-&gt;core<br /> [ 1853.809792] WARNING: CPU: 117 PID: 0 at kernel/sched/fair.c:11102 cfs_prio_less+0x1b4/0x1c4<br /> ...<br /> [ 1854.015210] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010<br /> ...<br /> [ 1854.231256] Call trace:<br /> [ 1854.233689] pick_next_task+0x3dc/0x81c<br /> [ 1854.237512] __schedule+0x10c/0x4cc<br /> [ 1854.240988] schedule_idle+0x34/0x54

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/imx: Fix memory leak in imx_pd_connector_get_modes<br /> <br /> Avoid leaking the display mode variable if of_get_drm_display_mode<br /> fails.<br /> <br /> Addresses-Coverity-ID: 1443943 ("Resource leak")

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: ipv4: fix route with nexthop object delete warning<br /> <br /> FRR folks have hit a kernel warning[1] while deleting routes[2] which is<br /> caused by trying to delete a route pointing to a nexthop id without<br /> specifying nhid but matching on an interface. That is, a route is found<br /> but we hit a warning while matching it. The warning is from<br /> fib_info_nh() in include/net/nexthop.h because we run it on a fib_info<br /> with nexthop object. The call chain is:<br /> inet_rtm_delroute -&gt; fib_table_delete -&gt; fib_nh_match (called with a<br /> nexthop fib_info and also with fc_oif set thus calling fib_info_nh on<br /> the fib_info and triggering the warning). The fix is to not do any<br /> matching in that branch if the fi has a nexthop object because those are<br /> managed separately. I.e. we should match when deleting without nh spec and<br /> should fail when deleting a nexthop route with old-style nh spec because<br /> nexthop objects are managed separately, e.g.:<br /> $ ip r show 1.2.3.4/32<br /> 1.2.3.4 nhid 12 via 192.168.11.2 dev dummy0<br /> <br /> $ ip r del 1.2.3.4/32<br /> $ ip r del 1.2.3.4/32 nhid 12<br /> <br /> <br /> $ ip r del 1.2.3.4/32 dev dummy0<br /> <br /> <br /> [1]<br /> [ 523.462226] ------------[ cut here ]------------<br /> [ 523.462230] WARNING: CPU: 14 PID: 22893 at include/net/nexthop.h:468 fib_nh_match+0x210/0x460<br /> [ 523.462236] Modules linked in: dummy rpcsec_gss_krb5 xt_socket nf_socket_ipv4 nf_socket_ipv6 ip6table_raw iptable_raw bpf_preload xt_statistic ip_set ip_vs_sh ip_vs_wrr ip_vs_rr ip_vs xt_mark nf_tables xt_nat veth nf_conntrack_netlink nfnetlink xt_addrtype br_netfilter overlay dm_crypt nfsv3 nfs fscache netfs vhost_net vhost vhost_iotlb tap tun xt_CHECKSUM xt_MASQUERADE xt_conntrack 8021q garp mrp ipt_REJECT nf_reject_ipv4 ip6table_mangle ip6table_nat iptable_mangle iptable_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 iptable_filter bridge stp llc rfcomm snd_seq_dummy snd_hrtimer rpcrdma rdma_cm iw_cm ib_cm ib_core ip6table_filter xt_comment ip6_tables vboxnetadp(OE) vboxnetflt(OE) vboxdrv(OE) qrtr bnep binfmt_misc xfs vfat fat squashfs loop nvidia_drm(POE) nvidia_modeset(POE) nvidia_uvm(POE) nvidia(POE) intel_rapl_msr intel_rapl_common snd_hda_codec_realtek snd_hda_codec_generic ledtrig_audio snd_hda_codec_hdmi btusb btrtl iwlmvm uvcvideo btbcm snd_hda_intel edac_mce_amd<br /> [ 523.462274] videobuf2_vmalloc videobuf2_memops btintel snd_intel_dspcfg videobuf2_v4l2 snd_intel_sdw_acpi bluetooth snd_usb_audio snd_hda_codec mac80211 snd_usbmidi_lib joydev snd_hda_core videobuf2_common kvm_amd snd_rawmidi snd_hwdep snd_seq videodev ccp snd_seq_device libarc4 ecdh_generic mc snd_pcm kvm iwlwifi snd_timer drm_kms_helper snd cfg80211 cec soundcore irqbypass rapl wmi_bmof i2c_piix4 rfkill k10temp pcspkr acpi_cpufreq nfsd auth_rpcgss nfs_acl lockd grace sunrpc drm zram ip_tables crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel nvme sp5100_tco r8169 nvme_core wmi ipmi_devintf ipmi_msghandler fuse<br /> [ 523.462300] CPU: 14 PID: 22893 Comm: ip Tainted: P OE 5.16.18-200.fc35.x86_64 #1<br /> [ 523.462302] Hardware name: Micro-Star International Co., Ltd. MS-7C37/MPG X570 GAMING EDGE WIFI (MS-7C37), BIOS 1.C0 10/29/2020<br /> [ 523.462303] RIP: 0010:fib_nh_match+0x210/0x460<br /> [ 523.462304] Code: 7c 24 20 48 8b b5 90 00 00 00 e8 bb ee f4 ff 48 8b 7c 24 20 41 89 c4 e8 ee eb f4 ff 45 85 e4 0f 85 2e fe ff ff e9 4c ff ff ff 0b e9 17 ff ff ff 3c 0a 0f 85 61 fe ff ff 48 8b b5 98 00 00 00<br /> [ 523.462306] RSP: 0018:ffffaa53d4d87928 EFLAGS: 00010286<br /> [ 523.462307] RAX: 0000000000000000 RBX: ffffaa53d4d87a90 RCX: ffffaa53d4d87bb0<br /> [ 523.462308] RDX: ffff9e3d2ee6be80 RSI: ffffaa53d4d87a90 RDI: ffffffff920ed380<br /> [ 523.462309] RBP: ffff9e3d2ee6be80 R08: 0000000000000064 R09: 0000000000000000<br /> [ 523.462310] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000031<br /> [ 523.462310] R13: 0000000000000020 R14: 0000000000000000 R15: ffff9e3d331054e0<br /> [ 523.462311] FS: 00007f2455<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/tls: fix slab-out-of-bounds bug in decrypt_internal<br /> <br /> The memory size of tls_ctx-&gt;rx.iv for AES128-CCM is 12 setting in<br /> tls_set_sw_offload(). The return value of crypto_aead_ivsize()<br /> for "ccm(aes)" is 16. So memcpy() require 16 bytes from 12 bytes<br /> memory space will trigger slab-out-of-bounds bug as following:<br /> <br /> ==================================================================<br /> BUG: KASAN: slab-out-of-bounds in decrypt_internal+0x385/0xc40 [tls]<br /> Read of size 16 at addr ffff888114e84e60 by task tls/10911<br /> <br /> Call Trace:<br /> <br /> dump_stack_lvl+0x34/0x44<br /> print_report.cold+0x5e/0x5db<br /> ? decrypt_internal+0x385/0xc40 [tls]<br /> kasan_report+0xab/0x120<br /> ? decrypt_internal+0x385/0xc40 [tls]<br /> kasan_check_range+0xf9/0x1e0<br /> memcpy+0x20/0x60<br /> decrypt_internal+0x385/0xc40 [tls]<br /> ? tls_get_rec+0x2e0/0x2e0 [tls]<br /> ? process_rx_list+0x1a5/0x420 [tls]<br /> ? tls_setup_from_iter.constprop.0+0x2e0/0x2e0 [tls]<br /> decrypt_skb_update+0x9d/0x400 [tls]<br /> tls_sw_recvmsg+0x3c8/0xb50 [tls]<br /> <br /> Allocated by task 10911:<br /> kasan_save_stack+0x1e/0x40<br /> __kasan_kmalloc+0x81/0xa0<br /> tls_set_sw_offload+0x2eb/0xa20 [tls]<br /> tls_setsockopt+0x68c/0x700 [tls]<br /> __sys_setsockopt+0xfe/0x1b0<br /> <br /> Replace the crypto_aead_ivsize() with prot-&gt;iv_size + prot-&gt;salt_size<br /> when memcpy() iv value in TLS_1_3_VERSION scenario.