Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mmc: vub300: fix return value check of mmc_add_host()<br /> <br /> mmc_add_host() may return error, if we ignore its return value, the memory<br /> that allocated in mmc_alloc_host() will be leaked and it will lead a kernel<br /> crash because of deleting not added device in the remove path.<br /> <br /> So fix this by checking the return value and goto error path which will call<br /> mmc_free_host(), besides, the timer added before mmc_add_host() needs be del.<br /> <br /> And this patch fixes another missing call mmc_free_host() if usb_control_msg()<br /> fails.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> igb: Do not free q_vector unless new one was allocated<br /> <br /> Avoid potential use-after-free condition under memory pressure. If the<br /> kzalloc() fails, q_vector will be freed but left in the original<br /> adapter-&gt;q_vector[v_idx] array position.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> regulator: core: fix use_count leakage when handling boot-on<br /> <br /> I found a use_count leakage towards supply regulator of rdev with<br /> boot-on option.<br /> <br /> ┌───────────────────┐ ┌───────────────────┐<br /> │ regulator_dev A │ │ regulator_dev B │<br /> │ (boot-on) │ │ (boot-on) │<br /> │ use_count=0 │◀──supply──│ use_count=1 │<br /> │ │ │ │<br /> └───────────────────┘ └───────────────────┘<br /> <br /> In case of rdev(A) configured with `regulator-boot-on&amp;#39;, the use_count<br /> of supplying regulator(B) will increment inside<br /> regulator_enable(rdev-&gt;supply).<br /> <br /> Thus, B will acts like always-on, and further balanced<br /> regulator_enable/disable cannot actually disable it anymore.<br /> <br /> However, B was also configured with `regulator-boot-on&amp;#39;, we wish it<br /> could be disabled afterwards.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> memory: of: Fix refcount leak bug in of_get_ddr_timings()<br /> <br /> We should add the of_node_put() when breaking out of<br /> for_each_child_of_node() as it will automatically increase<br /> and decrease the refcount.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: iwlwifi: mvm: fix double free on tx path.<br /> <br /> We see kernel crashes and lockups and KASAN errors related to ax210<br /> firmware crashes. One of the KASAN dumps pointed at the tx path,<br /> and it appears there is indeed a way to double-free an skb.<br /> <br /> If iwl_mvm_tx_skb_sta returns non-zero, then the &amp;#39;skb&amp;#39; sent into the<br /> method will be freed. But, in case where we build TSO skb buffer,<br /> the skb may also be freed in error case. So, return 0 in that particular<br /> error case and do cleanup manually.<br /> <br /> BUG: KASAN: use-after-free in __list_del_entry_valid+0x12/0x90<br /> iwlwifi 0000:06:00.0: 0x00000000 | tsf hi<br /> Read of size 8 at addr ffff88813cfa4ba0 by task btserver/9650<br /> <br /> CPU: 4 PID: 9650 Comm: btserver Tainted: G W 5.19.8+ #5<br /> iwlwifi 0000:06:00.0: 0x00000000 | time gp1<br /> Hardware name: Default string Default string/SKYBAY, BIOS 5.12 02/19/2019<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x55/0x6d<br /> print_report.cold.12+0xf2/0x684<br /> iwlwifi 0000:06:00.0: 0x1D0915A8 | time gp2<br /> ? __list_del_entry_valid+0x12/0x90<br /> kasan_report+0x8b/0x180<br /> iwlwifi 0000:06:00.0: 0x00000001 | uCode revision type<br /> ? __list_del_entry_valid+0x12/0x90<br /> __list_del_entry_valid+0x12/0x90<br /> iwlwifi 0000:06:00.0: 0x00000048 | uCode version major<br /> tcp_update_skb_after_send+0x5d/0x170<br /> __tcp_transmit_skb+0xb61/0x15c0<br /> iwlwifi 0000:06:00.0: 0xDAA05125 | uCode version minor<br /> ? __tcp_select_window+0x490/0x490<br /> iwlwifi 0000:06:00.0: 0x00000420 | hw version<br /> ? trace_kmalloc_node+0x29/0xd0<br /> ? __kmalloc_node_track_caller+0x12a/0x260<br /> ? memset+0x1f/0x40<br /> ? __build_skb_around+0x125/0x150<br /> ? __alloc_skb+0x1d4/0x220<br /> ? skb_zerocopy_clone+0x55/0x230<br /> iwlwifi 0000:06:00.0: 0x00489002 | board version<br /> ? kmalloc_reserve+0x80/0x80<br /> ? rcu_read_lock_bh_held+0x60/0xb0<br /> tcp_write_xmit+0x3f1/0x24d0<br /> iwlwifi 0000:06:00.0: 0x034E001C | hcmd<br /> ? __check_object_size+0x180/0x350<br /> iwlwifi 0000:06:00.0: 0x24020000 | isr0<br /> tcp_sendmsg_locked+0x8a9/0x1520<br /> iwlwifi 0000:06:00.0: 0x01400000 | isr1<br /> ? tcp_sendpage+0x50/0x50<br /> iwlwifi 0000:06:00.0: 0x48F0000A | isr2<br /> ? lock_release+0xb9/0x400<br /> ? tcp_sendmsg+0x14/0x40<br /> iwlwifi 0000:06:00.0: 0x00C3080C | isr3<br /> ? lock_downgrade+0x390/0x390<br /> ? do_raw_spin_lock+0x114/0x1d0<br /> iwlwifi 0000:06:00.0: 0x00200000 | isr4<br /> ? rwlock_bug.part.2+0x50/0x50<br /> iwlwifi 0000:06:00.0: 0x034A001C | last cmd Id<br /> ? rwlock_bug.part.2+0x50/0x50<br /> ? lockdep_hardirqs_on_prepare+0xe/0x200<br /> iwlwifi 0000:06:00.0: 0x0000C2F0 | wait_event<br /> ? __local_bh_enable_ip+0x87/0xe0<br /> ? inet_send_prepare+0x220/0x220<br /> iwlwifi 0000:06:00.0: 0x000000C4 | l2p_control<br /> tcp_sendmsg+0x22/0x40<br /> sock_sendmsg+0x5f/0x70<br /> iwlwifi 0000:06:00.0: 0x00010034 | l2p_duration<br /> __sys_sendto+0x19d/0x250<br /> iwlwifi 0000:06:00.0: 0x00000007 | l2p_mhvalid<br /> ? __ia32_sys_getpeername+0x40/0x40<br /> iwlwifi 0000:06:00.0: 0x00000000 | l2p_addr_match<br /> ? rcu_read_lock_held_common+0x12/0x50<br /> ? rcu_read_lock_sched_held+0x5a/0xd0<br /> ? rcu_read_lock_bh_held+0xb0/0xb0<br /> ? rcu_read_lock_sched_held+0x5a/0xd0<br /> ? rcu_read_lock_sched_held+0x5a/0xd0<br /> ? lock_release+0xb9/0x400<br /> ? lock_downgrade+0x390/0x390<br /> ? ktime_get+0x64/0x130<br /> ? ktime_get+0x8d/0x130<br /> ? rcu_read_lock_held_common+0x12/0x50<br /> ? rcu_read_lock_sched_held+0x5a/0xd0<br /> ? rcu_read_lock_held_common+0x12/0x50<br /> ? rcu_read_lock_sched_held+0x5a/0xd0<br /> ? rcu_read_lock_bh_held+0xb0/0xb0<br /> ? rcu_read_lock_bh_held+0xb0/0xb0<br /> __x64_sys_sendto+0x6f/0x80<br /> do_syscall_64+0x34/0xb0<br /> entry_SYSCALL_64_after_hwframe+0x46/0xb0<br /> RIP: 0033:0x7f1d126e4531<br /> Code: 00 00 00 00 0f 1f 44 00 00 f3 0f 1e fa 48 8d 05 35 80 0c 00 41 89 ca 8b 00 85 c0 75 1c 45 31 c9 45 31 c0 b8 2c 00 00 00 0f 05 3d 00 f0 ff ff 77 67 c3 66 0f 1f 44 00 00 55 48 83 ec 20 48 89<br /> RSP: 002b:00007ffe21a679d8 EFLAGS: 00000246 ORIG_RAX: 000000000000002c<br /> RAX: ffffffffffffffda RBX: 000000000000ffdc RCX: 00007f1d126e4531<br /> RDX: 0000000000010000 RSI: 000000000374acf0 RDI: 0000000000000014<br /> RBP: 00007ffe21a67ac0 R08: 0000000000000000 R09: 0000000000000000<br /> R10: 0000000000000000 R11: 0000000000000246 R<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> android: binder: stop saving a pointer to the VMA<br /> <br /> Do not record a pointer to a VMA outside of the mmap_lock for later use. <br /> This is unsafe and there are a number of failure paths *after* the<br /> recorded VMA pointer may be freed during setup. There is no callback to<br /> the driver to clear the saved pointer from generic mm code. Furthermore,<br /> the VMA pointer may become stale if any number of VMA operations end up<br /> freeing the VMA so saving it was fragile to being with.<br /> <br /> Instead, change the binder_alloc struct to record the start address of the<br /> VMA and use vma_lookup() to get the vma when needed. Add lockdep<br /> mmap_lock checks on updates to the vma pointer to ensure the lock is held<br /> and depend on that lock for synchronization of readers and writers - which<br /> was already the case anyways, so the smp_wmb()/smp_rmb() was not<br /> necessary.<br /> <br /> [akpm@linux-foundation.org: fix drivers/android/binder_alloc_selftest.c]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cpufreq: qcom: fix writes in read-only memory region<br /> <br /> This commit fixes a kernel oops because of a write in some read-only memory:<br /> <br /> [ 9.068287] Unable to handle kernel write to read-only memory at virtual address ffff800009240ad8<br /> ..snip..<br /> [ 9.138790] Internal error: Oops: 9600004f [#1] PREEMPT SMP<br /> ..snip..<br /> [ 9.269161] Call trace:<br /> [ 9.276271] __memcpy+0x5c/0x230<br /> [ 9.278531] snprintf+0x58/0x80<br /> [ 9.282002] qcom_cpufreq_msm8939_name_version+0xb4/0x190<br /> [ 9.284869] qcom_cpufreq_probe+0xc8/0x39c<br /> ..snip..<br /> <br /> The following line defines a pointer that point to a char buffer stored<br /> in read-only memory:<br /> <br /> char *pvs_name = "speedXX-pvsXX-vXX";<br /> <br /> This pointer is meant to hold a template "speedXX-pvsXX-vXX" where the<br /> XX values get overridden by the qcom_cpufreq_krait_name_version function. Since<br /> the template is actually stored in read-only memory, when the function<br /> executes the following call we get an oops:<br /> <br /> snprintf(*pvs_name, sizeof("speedXX-pvsXX-vXX"), "speed%d-pvs%d-v%d",<br /> speed, pvs, pvs_ver);<br /> <br /> To fix this issue, we instead store the template name onto the stack by<br /> using the following syntax:<br /> <br /> char pvs_name_buffer[] = "speedXX-pvsXX-vXX";<br /> <br /> Because the `pvs_name` needs to be able to be assigned to NULL, the<br /> template buffer is stored in the pvs_name_buffer and not under the<br /> pvs_name variable.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommu/mediatek: Fix crash on isr after kexec()<br /> <br /> If the system is rebooted via isr(), the IRQ handler might<br /> be triggered before the domain is initialized. Resulting on<br /> an invalid memory access error.<br /> <br /> Fix:<br /> [ 0.500930] Unable to handle kernel read from unreadable memory at virtual address 0000000000000070<br /> [ 0.501166] Call trace:<br /> [ 0.501174] report_iommu_fault+0x28/0xfc<br /> [ 0.501180] mtk_iommu_isr+0x10c/0x1c0<br /> <br /> [ joro: Fixed spelling in commit message ]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rapidio: fix possible UAF when kfifo_alloc() fails<br /> <br /> If kfifo_alloc() fails in mport_cdev_open(), goto err_fifo and just free<br /> priv. But priv is still in the chdev-&gt;file_list, then list traversal<br /> may cause UAF. This fixes the following smatch warning:<br /> <br /> drivers/rapidio/devices/rio_mport_cdev.c:1930 mport_cdev_open() warn: &amp;#39;&amp;priv-&gt;list&amp;#39; not removed from list

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cxl: fix possible null-ptr-deref in cxl_pci_init_afu|adapter()<br /> <br /> If device_register() fails in cxl_pci_afu|adapter(), the device<br /> is not added, device_unregister() can not be called in the error<br /> path, otherwise it will cause a null-ptr-deref because of removing<br /> not added device.<br /> <br /> As comment of device_register() says, it should use put_device() to give<br /> up the reference in the error path. So split device_unregister() into<br /> device_del() and put_device(), then goes to put dev when register fails.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sctp: handle the error returned from sctp_auth_asoc_init_active_key<br /> <br /> When it returns an error from sctp_auth_asoc_init_active_key(), the<br /> active_key is actually not updated. The old sh_key will be freeed<br /> while it&amp;#39;s still used as active key in asoc. Then an use-after-free<br /> will be triggered when sending patckets, as found by syzbot:<br /> <br /> sctp_auth_shkey_hold+0x22/0xa0 net/sctp/auth.c:112<br /> sctp_set_owner_w net/sctp/socket.c:132 [inline]<br /> sctp_sendmsg_to_asoc+0xbd5/0x1a20 net/sctp/socket.c:1863<br /> sctp_sendmsg+0x1053/0x1d50 net/sctp/socket.c:2025<br /> inet_sendmsg+0x99/0xe0 net/ipv4/af_inet.c:819<br /> sock_sendmsg_nosec net/socket.c:714 [inline]<br /> sock_sendmsg+0xcf/0x120 net/socket.c:734<br /> <br /> This patch is to fix it by not replacing the sh_key when it returns<br /> errors from sctp_auth_asoc_init_active_key() in sctp_auth_set_key().<br /> For sctp_auth_set_active_key(), old active_key_id will be set back<br /> to asoc-&gt;active_key_id when the same thing happens.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drivers: net: qlcnic: Fix potential memory leak in qlcnic_sriov_init()<br /> <br /> If vp alloc failed in qlcnic_sriov_init(), all previously allocated vp<br /> needs to be freed.