Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipack: ipoctal: fix stack information leak<br /> <br /> The tty driver name is used also after registering the driver and must<br /> specifically not be allocated on the stack to avoid leaking information<br /> to user space (or triggering an oops).<br /> <br /> Drivers should not try to encode topology information in the tty device<br /> name but this one snuck in through staging without anyone noticing and<br /> another driver has since copied this malpractice.<br /> <br /> Fixing the ABI is a separate issue, but this at least plugs the security<br /> hole.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: sched: flower: protect fl_walk() with rcu<br /> <br /> Patch that refactored fl_walk() to use idr_for_each_entry_continue_ul()<br /> also removed rcu protection of individual filters which causes following<br /> use-after-free when filter is deleted concurrently. Fix fl_walk() to obtain<br /> rcu read lock while iterating and taking the filter reference and temporary<br /> release the lock while calling arg-&gt;fn() callback that can sleep.<br /> <br /> KASAN trace:<br /> <br /> [ 352.773640] ==================================================================<br /> [ 352.775041] BUG: KASAN: use-after-free in fl_walk+0x159/0x240 [cls_flower]<br /> [ 352.776304] Read of size 4 at addr ffff8881c8251480 by task tc/2987<br /> <br /> [ 352.777862] CPU: 3 PID: 2987 Comm: tc Not tainted 5.15.0-rc2+ #2<br /> [ 352.778980] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014<br /> [ 352.781022] Call Trace:<br /> [ 352.781573] dump_stack_lvl+0x46/0x5a<br /> [ 352.782332] print_address_description.constprop.0+0x1f/0x140<br /> [ 352.783400] ? fl_walk+0x159/0x240 [cls_flower]<br /> [ 352.784292] ? fl_walk+0x159/0x240 [cls_flower]<br /> [ 352.785138] kasan_report.cold+0x83/0xdf<br /> [ 352.785851] ? fl_walk+0x159/0x240 [cls_flower]<br /> [ 352.786587] kasan_check_range+0x145/0x1a0<br /> [ 352.787337] fl_walk+0x159/0x240 [cls_flower]<br /> [ 352.788163] ? fl_put+0x10/0x10 [cls_flower]<br /> [ 352.789007] ? __mutex_unlock_slowpath.constprop.0+0x220/0x220<br /> [ 352.790102] tcf_chain_dump+0x231/0x450<br /> [ 352.790878] ? tcf_chain_tp_delete_empty+0x170/0x170<br /> [ 352.791833] ? __might_sleep+0x2e/0xc0<br /> [ 352.792594] ? tfilter_notify+0x170/0x170<br /> [ 352.793400] ? __mutex_unlock_slowpath.constprop.0+0x220/0x220<br /> [ 352.794477] tc_dump_tfilter+0x385/0x4b0<br /> [ 352.795262] ? tc_new_tfilter+0x1180/0x1180<br /> [ 352.796103] ? __mod_node_page_state+0x1f/0xc0<br /> [ 352.796974] ? __build_skb_around+0x10e/0x130<br /> [ 352.797826] netlink_dump+0x2c0/0x560<br /> [ 352.798563] ? netlink_getsockopt+0x430/0x430<br /> [ 352.799433] ? __mutex_unlock_slowpath.constprop.0+0x220/0x220<br /> [ 352.800542] __netlink_dump_start+0x356/0x440<br /> [ 352.801397] rtnetlink_rcv_msg+0x3ff/0x550<br /> [ 352.802190] ? tc_new_tfilter+0x1180/0x1180<br /> [ 352.802872] ? rtnl_calcit.isra.0+0x1f0/0x1f0<br /> [ 352.803668] ? tc_new_tfilter+0x1180/0x1180<br /> [ 352.804344] ? _copy_from_iter_nocache+0x800/0x800<br /> [ 352.805202] ? kasan_set_track+0x1c/0x30<br /> [ 352.805900] netlink_rcv_skb+0xc6/0x1f0<br /> [ 352.806587] ? rht_deferred_worker+0x6b0/0x6b0<br /> [ 352.807455] ? rtnl_calcit.isra.0+0x1f0/0x1f0<br /> [ 352.808324] ? netlink_ack+0x4d0/0x4d0<br /> [ 352.809086] ? netlink_deliver_tap+0x62/0x3d0<br /> [ 352.809951] netlink_unicast+0x353/0x480<br /> [ 352.810744] ? netlink_attachskb+0x430/0x430<br /> [ 352.811586] ? __alloc_skb+0xd7/0x200<br /> [ 352.812349] netlink_sendmsg+0x396/0x680<br /> [ 352.813132] ? netlink_unicast+0x480/0x480<br /> [ 352.813952] ? __import_iovec+0x192/0x210<br /> [ 352.814759] ? netlink_unicast+0x480/0x480<br /> [ 352.815580] sock_sendmsg+0x6c/0x80<br /> [ 352.816299] ____sys_sendmsg+0x3a5/0x3c0<br /> [ 352.817096] ? kernel_sendmsg+0x30/0x30<br /> [ 352.817873] ? __ia32_sys_recvmmsg+0x150/0x150<br /> [ 352.818753] ___sys_sendmsg+0xd8/0x140<br /> [ 352.819518] ? sendmsg_copy_msghdr+0x110/0x110<br /> [ 352.820402] ? ___sys_recvmsg+0xf4/0x1a0<br /> [ 352.821110] ? __copy_msghdr_from_user+0x260/0x260<br /> [ 352.821934] ? _raw_spin_lock+0x81/0xd0<br /> [ 352.822680] ? __handle_mm_fault+0xef3/0x1b20<br /> [ 352.823549] ? rb_insert_color+0x2a/0x270<br /> [ 352.824373] ? copy_page_range+0x16b0/0x16b0<br /> [ 352.825209] ? perf_event_update_userpage+0x2d0/0x2d0<br /> [ 352.826190] ? __fget_light+0xd9/0xf0<br /> [ 352.826941] __sys_sendmsg+0xb3/0x130<br /> [ 352.827613] ? __sys_sendmsg_sock+0x20/0x20<br /> [ 352.828377] ? do_user_addr_fault+0x2c5/0x8a0<br /> [ 352.829184] ? fpregs_assert_state_consistent+0x52/0x60<br /> [ 352.830001] ? exit_to_user_mode_prepare+0x32/0x160<br /> [ 352.830845] do_syscall_64+0x35/0x80<br /> [ 352.831445] entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> [ 352.832331] RIP: 0033:0x7f7bee973c17<br /> [ <br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipack: ipoctal: fix module reference leak<br /> <br /> A reference to the carrier module was taken on every open but was only<br /> released once when the final reference to the tty struct was dropped.<br /> <br /> Fix this by taking the module reference and initialising the tty driver<br /> data when installing the tty.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> HID: betop: fix slab-out-of-bounds Write in betop_probe<br /> <br /> Syzbot reported slab-out-of-bounds Write bug in hid-betopff driver.<br /> The problem is the driver assumes the device must have an input report but<br /> some malicious devices violate this assumption.<br /> <br /> So this patch checks hid_device&amp;#39;s input is non empty before it&amp;#39;s been used.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> hwmon: (w83792d) Fix NULL pointer dereference by removing unnecessary structure field<br /> <br /> If driver read val value sufficient for<br /> (val &amp; 0x08) &amp;&amp; (!(val &amp; 0x80)) &amp;&amp; ((val &amp; 0x7) == ((val &gt;&gt; 4) &amp; 0x7))<br /> from device then Null pointer dereference occurs.<br /> (It is possible if tmp = 0b0xyz1xyz, where same literals mean same numbers)<br /> Also lm75[] does not serve a purpose anymore after switching to<br /> devm_i2c_new_dummy_device() in w83791d_detect_subclients().<br /> <br /> The patch fixes possible NULL pointer dereference by removing lm75[].<br /> <br /> Found by Linux Driver Verification project (linuxtesting.org).<br /> <br /> [groeck: Dropped unnecessary continuation lines, fixed multipline alignment]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> hwmon: (w83791d) Fix NULL pointer dereference by removing unnecessary structure field<br /> <br /> If driver read val value sufficient for<br /> (val &amp; 0x08) &amp;&amp; (!(val &amp; 0x80)) &amp;&amp; ((val &amp; 0x7) == ((val &gt;&gt; 4) &amp; 0x7))<br /> from device then Null pointer dereference occurs.<br /> (It is possible if tmp = 0b0xyz1xyz, where same literals mean same numbers)<br /> Also lm75[] does not serve a purpose anymore after switching to<br /> devm_i2c_new_dummy_device() in w83791d_detect_subclients().<br /> <br /> The patch fixes possible NULL pointer dereference by removing lm75[].<br /> <br /> Found by Linux Driver Verification project (linuxtesting.org).<br /> <br /> [groeck: Dropped unnecessary continuation lines, fixed multi-line alignment]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cpufreq: schedutil: Use kobject release() method to free sugov_tunables<br /> <br /> The struct sugov_tunables is protected by the kobject, so we can&amp;#39;t free<br /> it directly. Otherwise we would get a call trace like this:<br /> ODEBUG: free active (active state 0) object type: timer_list hint: delayed_work_timer_fn+0x0/0x30<br /> WARNING: CPU: 3 PID: 720 at lib/debugobjects.c:505 debug_print_object+0xb8/0x100<br /> Modules linked in:<br /> CPU: 3 PID: 720 Comm: a.sh Tainted: G W 5.14.0-rc1-next-20210715-yocto-standard+ #507<br /> Hardware name: Marvell OcteonTX CN96XX board (DT)<br /> pstate: 40400009 (nZcv daif +PAN -UAO -TCO BTYPE=--)<br /> pc : debug_print_object+0xb8/0x100<br /> lr : debug_print_object+0xb8/0x100<br /> sp : ffff80001ecaf910<br /> x29: ffff80001ecaf910 x28: ffff00011b10b8d0 x27: ffff800011043d80<br /> x26: ffff00011a8f0000 x25: ffff800013cb3ff0 x24: 0000000000000000<br /> x23: ffff80001142aa68 x22: ffff800011043d80 x21: ffff00010de46f20<br /> x20: ffff800013c0c520 x19: ffff800011d8f5b0 x18: 0000000000000010<br /> x17: 6e6968207473696c x16: 5f72656d6974203a x15: 6570797420746365<br /> x14: 6a626f2029302065 x13: 303378302f307830 x12: 2b6e665f72656d69<br /> x11: ffff8000124b1560 x10: ffff800012331520 x9 : ffff8000100ca6b0<br /> x8 : 000000000017ffe8 x7 : c0000000fffeffff x6 : 0000000000000001<br /> x5 : ffff800011d8c000 x4 : ffff800011d8c740 x3 : 0000000000000000<br /> x2 : ffff0001108301c0 x1 : ab3c90eedf9c0f00 x0 : 0000000000000000<br /> Call trace:<br /> debug_print_object+0xb8/0x100<br /> __debug_check_no_obj_freed+0x1c0/0x230<br /> debug_check_no_obj_freed+0x20/0x88<br /> slab_free_freelist_hook+0x154/0x1c8<br /> kfree+0x114/0x5d0<br /> sugov_exit+0xbc/0xc0<br /> cpufreq_exit_governor+0x44/0x90<br /> cpufreq_set_policy+0x268/0x4a8<br /> store_scaling_governor+0xe0/0x128<br /> store+0xc0/0xf0<br /> sysfs_kf_write+0x54/0x80<br /> kernfs_fop_write_iter+0x128/0x1c0<br /> new_sync_write+0xf0/0x190<br /> vfs_write+0x2d4/0x478<br /> ksys_write+0x74/0x100<br /> __arm64_sys_write+0x24/0x30<br /> invoke_syscall.constprop.0+0x54/0xe0<br /> do_el0_svc+0x64/0x158<br /> el0_svc+0x2c/0xb0<br /> el0t_64_sync_handler+0xb0/0xb8<br /> el0t_64_sync+0x198/0x19c<br /> irq event stamp: 5518<br /> hardirqs last enabled at (5517): [] console_unlock+0x554/0x6c8<br /> hardirqs last disabled at (5518): [] el1_dbg+0x28/0xa0<br /> softirqs last enabled at (5504): [] __do_softirq+0x4d0/0x6c0<br /> softirqs last disabled at (5483): [] irq_exit+0x1b0/0x1b8<br /> <br /> So split the original sugov_tunables_free() into two functions,<br /> sugov_clear_global_tunables() is just used to clear the global_tunables<br /> and the new sugov_tunables_free() is used as kobj_type::release to<br /> release the sugov_tunables safely.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mac80211: fix use-after-free in CCMP/GCMP RX<br /> <br /> When PN checking is done in mac80211, for fragmentation we need<br /> to copy the PN to the RX struct so we can later use it to do a<br /> comparison, since commit bf30ca922a0c ("mac80211: check defrag<br /> PN against current frame").<br /> <br /> Unfortunately, in that commit I used the &amp;#39;hdr&amp;#39; variable without<br /> it being necessarily valid, so use-after-free could occur if it<br /> was necessary to reallocate (parts of) the frame.<br /> <br /> Fix this by reloading the variable after the code that results<br /> in the reallocations, if any.<br /> <br /> This fixes https://bugzilla.kernel.org/show_bug.cgi?id=214401.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: SVM: fix missing sev_decommission in sev_receive_start<br /> <br /> DECOMMISSION the current SEV context if binding an ASID fails after<br /> RECEIVE_START. Per AMD&amp;#39;s SEV API, RECEIVE_START generates a new guest<br /> context and thus needs to be paired with DECOMMISSION:<br /> <br /> The RECEIVE_START command is the only command other than the LAUNCH_START<br /> command that generates a new guest context and guest handle.<br /> <br /> The missing DECOMMISSION can result in subsequent SEV launch failures,<br /> as the firmware leaks memory and might not able to allocate more SEV<br /> guest contexts in the future.<br /> <br /> Note, LAUNCH_START suffered the same bug, but was previously fixed by<br /> commit 934002cd660b ("KVM: SVM: Call SEV Guest Decommission if ASID<br /> binding fails").

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: x86: Fix stack-out-of-bounds memory access from ioapic_write_indirect()<br /> <br /> KASAN reports the following issue:<br /> <br /> BUG: KASAN: stack-out-of-bounds in kvm_make_vcpus_request_mask+0x174/0x440 [kvm]<br /> Read of size 8 at addr ffffc9001364f638 by task qemu-kvm/4798<br /> <br /> CPU: 0 PID: 4798 Comm: qemu-kvm Tainted: G X --------- ---<br /> Hardware name: AMD Corporation DAYTONA_X/DAYTONA_X, BIOS RYM0081C 07/13/2020<br /> Call Trace:<br /> dump_stack+0xa5/0xe6<br /> print_address_description.constprop.0+0x18/0x130<br /> ? kvm_make_vcpus_request_mask+0x174/0x440 [kvm]<br /> __kasan_report.cold+0x7f/0x114<br /> ? kvm_make_vcpus_request_mask+0x174/0x440 [kvm]<br /> kasan_report+0x38/0x50<br /> kasan_check_range+0xf5/0x1d0<br /> kvm_make_vcpus_request_mask+0x174/0x440 [kvm]<br /> kvm_make_scan_ioapic_request_mask+0x84/0xc0 [kvm]<br /> ? kvm_arch_exit+0x110/0x110 [kvm]<br /> ? sched_clock+0x5/0x10<br /> ioapic_write_indirect+0x59f/0x9e0 [kvm]<br /> ? static_obj+0xc0/0xc0<br /> ? __lock_acquired+0x1d2/0x8c0<br /> ? kvm_ioapic_eoi_inject_work+0x120/0x120 [kvm]<br /> <br /> The problem appears to be that &amp;#39;vcpu_bitmap&amp;#39; is allocated as a single long<br /> on stack and it should really be KVM_MAX_VCPUS long. We also seem to clear<br /> the lower 16 bits of it with bitmap_zero() for no particular reason (my<br /> guess would be that &amp;#39;bitmap&amp;#39; and &amp;#39;vcpu_bitmap&amp;#39; variables in<br /> kvm_bitmap_or_dest_vcpus() caused the confusion: while the later is indeed<br /> 16-bit long, the later should accommodate all possible vCPUs).

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/cma: Ensure rdma_addr_cancel() happens before issuing more requests<br /> <br /> The FSM can run in a circle allowing rdma_resolve_ip() to be called twice<br /> on the same id_priv. While this cannot happen without going through the<br /> work, it violates the invariant that the same address resolution<br /> background request cannot be active twice.<br /> <br /> CPU 1 CPU 2<br /> <br /> rdma_resolve_addr():<br /> RDMA_CM_IDLE -&gt; RDMA_CM_ADDR_QUERY<br /> rdma_resolve_ip(addr_handler) #1<br /> <br /> process_one_req(): for #1<br /> addr_handler():<br /> RDMA_CM_ADDR_QUERY -&gt; RDMA_CM_ADDR_BOUND<br /> mutex_unlock(&amp;id_priv-&gt;handler_mutex);<br /> [.. handler still running ..]<br /> <br /> rdma_resolve_addr():<br /> RDMA_CM_ADDR_BOUND -&gt; RDMA_CM_ADDR_QUERY<br /> rdma_resolve_ip(addr_handler)<br /> !! two requests are now on the req_list<br /> <br /> rdma_destroy_id():<br /> destroy_id_handler_unlock():<br /> _destroy_id():<br /> cma_cancel_operation():<br /> rdma_addr_cancel()<br /> <br /> // process_one_req() self removes it<br /> spin_lock_bh(&amp;lock);<br /> cancel_delayed_work(&amp;req-&gt;work);<br /> if (!list_empty(&amp;req-&gt;list)) == true<br /> <br /> ! rdma_addr_cancel() returns after process_on_req #1 is done<br /> <br /> kfree(id_priv)<br /> <br /> process_one_req(): for #2<br /> addr_handler():<br /> mutex_lock(&amp;id_priv-&gt;handler_mutex);<br /> !! Use after free on id_priv<br /> <br /> rdma_addr_cancel() expects there to be one req on the list and only<br /> cancels the first one. The self-removal behavior of the work only happens<br /> after the handler has returned. This yields a situations where the<br /> req_list can have two reqs for the same "handle" but rdma_addr_cancel()<br /> only cancels the first one.<br /> <br /> The second req remains active beyond rdma_destroy_id() and will<br /> use-after-free id_priv once it inevitably triggers.<br /> <br /> Fix this by remembering if the id_priv has called rdma_resolve_ip() and<br /> always cancel before calling it again. This ensures the req_list never<br /> gets more than one item in it and doesn&amp;#39;t cost anything in the normal flow<br /> that never uses this strange error path.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/cma: Fix listener leak in rdma_cma_listen_on_all() failure<br /> <br /> If cma_listen_on_all() fails it leaves the per-device ID still on the<br /> listen_list but the state is not set to RDMA_CM_ADDR_BOUND.<br /> <br /> When the cmid is eventually destroyed cma_cancel_listens() is not called<br /> due to the wrong state, however the per-device IDs are still holding the<br /> refcount preventing the ID from being destroyed, thus deadlocking:<br /> <br /> task:rping state:D stack: 0 pid:19605 ppid: 47036 flags:0x00000084<br /> Call Trace:<br /> __schedule+0x29a/0x780<br /> ? free_unref_page_commit+0x9b/0x110<br /> schedule+0x3c/0xa0<br /> schedule_timeout+0x215/0x2b0<br /> ? __flush_work+0x19e/0x1e0<br /> wait_for_completion+0x8d/0xf0<br /> _destroy_id+0x144/0x210 [rdma_cm]<br /> ucma_close_id+0x2b/0x40 [rdma_ucm]<br /> __destroy_id+0x93/0x2c0 [rdma_ucm]<br /> ? __xa_erase+0x4a/0xa0<br /> ucma_destroy_id+0x9a/0x120 [rdma_ucm]<br /> ucma_write+0xb8/0x130 [rdma_ucm]<br /> vfs_write+0xb4/0x250<br /> ksys_write+0xb5/0xd0<br /> ? syscall_trace_enter.isra.19+0x123/0x190<br /> do_syscall_64+0x33/0x40<br /> entry_SYSCALL_64_after_hwframe+0x44/0xa9<br /> <br /> Ensure that cma_listen_on_all() atomically unwinds its action under the<br /> lock during error.