Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf, sockmap: fix race in sock_map_free()<br /> <br /> sock_map_free() calls release_sock(sk) without owning a reference<br /> on the socket. This can cause use-after-free as syzbot found [1]<br /> <br /> Jakub Sitnicki already took care of a similar issue<br /> in sock_hash_free() in commit 75e68e5bf2c7 ("bpf, sockhash:<br /> Synchronize delete from bucket list on map free")<br /> <br /> [1]<br /> refcount_t: decrement hit 0; leaking memory.<br /> WARNING: CPU: 0 PID: 3785 at lib/refcount.c:31 refcount_warn_saturate+0x17c/0x1a0 lib/refcount.c:31<br /> Modules linked in:<br /> CPU: 0 PID: 3785 Comm: kworker/u4:6 Not tainted 6.1.0-rc7-syzkaller-00103-gef4d3ea40565 #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022<br /> Workqueue: events_unbound bpf_map_free_deferred<br /> RIP: 0010:refcount_warn_saturate+0x17c/0x1a0 lib/refcount.c:31<br /> Code: 68 8b 31 c0 e8 75 71 15 fd 0f 0b e9 64 ff ff ff e8 d9 6e 4e fd c6 05 62 9c 3d 0a 01 48 c7 c7 80 bb 68 8b 31 c0 e8 54 71 15 fd 0b e9 43 ff ff ff 89 d9 80 e1 07 80 c1 03 38 c1 0f 8c a2 fe ff<br /> RSP: 0018:ffffc9000456fb60 EFLAGS: 00010246<br /> RAX: eae59bab72dcd700 RBX: 0000000000000004 RCX: ffff8880207057c0<br /> RDX: 0000000000000000 RSI: 0000000000000201 RDI: 0000000000000000<br /> RBP: 0000000000000004 R08: ffffffff816fdabd R09: fffff520008adee5<br /> R10: fffff520008adee5 R11: 1ffff920008adee4 R12: 0000000000000004<br /> R13: dffffc0000000000 R14: ffff88807b1c6c00 R15: 1ffff1100f638dcf<br /> FS: 0000000000000000(0000) GS:ffff8880b9800000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000001b30c30000 CR3: 000000000d08e000 CR4: 00000000003506f0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> __refcount_dec include/linux/refcount.h:344 [inline]<br /> refcount_dec include/linux/refcount.h:359 [inline]<br /> __sock_put include/net/sock.h:779 [inline]<br /> tcp_release_cb+0x2d0/0x360 net/ipv4/tcp_output.c:1092<br /> release_sock+0xaf/0x1c0 net/core/sock.c:3468<br /> sock_map_free+0x219/0x2c0 net/core/sock_map.c:356<br /> process_one_work+0x81c/0xd10 kernel/workqueue.c:2289<br /> worker_thread+0xb14/0x1330 kernel/workqueue.c:2436<br /> kthread+0x266/0x300 kernel/kthread.c:376<br /> ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306<br />

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/msm: Make .remove and .shutdown HW shutdown consistent<br /> <br /> Drivers&amp;#39; .remove and .shutdown callbacks are executed on different code<br /> paths. The former is called when a device is removed from the bus, while<br /> the latter is called at system shutdown time to quiesce the device.<br /> <br /> This means that some overlap exists between the two, because both have to<br /> take care of properly shutting down the hardware. But currently the logic<br /> used in these two callbacks isn&amp;#39;t consistent in msm drivers, which could<br /> lead to kernel panic.<br /> <br /> For example, on .remove the component is deleted and its .unbind callback<br /> leads to the hardware being shutdown but only if the DRM device has been<br /> marked as registered.<br /> <br /> That check doesn&amp;#39;t exist in the .shutdown logic and this can lead to the<br /> driver calling drm_atomic_helper_shutdown() for a DRM device that hasn&amp;#39;t<br /> been properly initialized.<br /> <br /> A situation like this can happen if drivers for expected sub-devices fail<br /> to probe, since the .bind callback will never be executed. If that is the<br /> case, drm_atomic_helper_shutdown() will attempt to take mutexes that are<br /> only initialized if drm_mode_config_init() is called during a device bind.<br /> <br /> This bug was attempted to be fixed in commit 623f279c7781 ("drm/msm: fix<br /> shutdown hook in case GPU components failed to bind"), but unfortunately<br /> it still happens in some cases as the one mentioned above, i.e:<br /> <br /> systemd-shutdown[1]: Powering off.<br /> kvm: exiting hardware virtualization<br /> platform wifi-firmware.0: Removing from iommu group 12<br /> platform video-firmware.0: Removing from iommu group 10<br /> ------------[ cut here ]------------<br /> WARNING: CPU: 6 PID: 1 at drivers/gpu/drm/drm_modeset_lock.c:317 drm_modeset_lock_all_ctx+0x3c4/0x3d0<br /> ...<br /> Hardware name: Google CoachZ (rev3+) (DT)<br /> pstate: a0400009 (NzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> pc : drm_modeset_lock_all_ctx+0x3c4/0x3d0<br /> lr : drm_modeset_lock_all_ctx+0x48/0x3d0<br /> sp : ffff80000805bb80<br /> x29: ffff80000805bb80 x28: ffff327c00128000 x27: 0000000000000000<br /> x26: 0000000000000000 x25: 0000000000000001 x24: ffffc95d820ec030<br /> x23: ffff327c00bbd090 x22: ffffc95d8215eca0 x21: ffff327c039c5800<br /> x20: ffff327c039c5988 x19: ffff80000805bbe8 x18: 0000000000000034<br /> x17: 000000040044ffff x16: ffffc95d80cac920 x15: 0000000000000000<br /> x14: 0000000000000315 x13: 0000000000000315 x12: 0000000000000000<br /> x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000<br /> x8 : ffff80000805bc28 x7 : 0000000000000000 x6 : 0000000000000000<br /> x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000<br /> x2 : ffff327c00128000 x1 : 0000000000000000 x0 : ffff327c039c59b0<br /> Call trace:<br /> drm_modeset_lock_all_ctx+0x3c4/0x3d0<br /> drm_atomic_helper_shutdown+0x70/0x134<br /> msm_drv_shutdown+0x30/0x40<br /> platform_shutdown+0x28/0x40<br /> device_shutdown+0x148/0x350<br /> kernel_power_off+0x38/0x80<br /> __do_sys_reboot+0x288/0x2c0<br /> __arm64_sys_reboot+0x28/0x34<br /> invoke_syscall+0x48/0x114<br /> el0_svc_common.constprop.0+0x44/0xec<br /> do_el0_svc+0x2c/0xc0<br /> el0_svc+0x2c/0x84<br /> el0t_64_sync_handler+0x11c/0x150<br /> el0t_64_sync+0x18c/0x190<br /> ---[ end trace 0000000000000000 ]---<br /> Unable to handle kernel NULL pointer dereference at virtual address 0000000000000018<br /> Mem abort info:<br /> ESR = 0x0000000096000004<br /> EC = 0x25: DABT (current EL), IL = 32 bits<br /> SET = 0, FnV = 0<br /> EA = 0, S1PTW = 0<br /> FSC = 0x04: level 0 translation fault<br /> Data abort info:<br /> ISV = 0, ISS = 0x00000004<br /> CM = 0, WnR = 0<br /> user pgtable: 4k pages, 48-bit VAs, pgdp=000000010eab1000<br /> [0000000000000018] pgd=0000000000000000, p4d=0000000000000000<br /> Internal error: Oops: 96000004 [#1] PREEMPT SMP<br /> ...<br /> Hardware name: Google CoachZ (rev3+) (DT)<br /> pstate: a0400009 (NzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> pc : ww_mutex_lock+0x28/0x32c<br /> lr : drm_modeset_lock_all_ctx+0x1b0/0x3d0<br /> sp : ffff80000805bb50<br /> x29: ffff80000805bb50 x28: ffff327c00128000 x27: 0000000000000000<br /> x26: 00000<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/sti: Fix return type of sti_{dvo,hda,hdmi}_connector_mode_valid()<br /> <br /> With clang&amp;#39;s kernel control flow integrity (kCFI, CONFIG_CFI_CLANG),<br /> indirect call targets are validated against the expected function<br /> pointer prototype to make sure the call target is valid to help mitigate<br /> ROP attacks. If they are not identical, there is a failure at run time,<br /> which manifests as either a kernel panic or thread getting killed. A<br /> proposed warning in clang aims to catch these at compile time, which<br /> reveals:<br /> <br /> drivers/gpu/drm/sti/sti_hda.c:637:16: error: incompatible function pointer types initializing &amp;#39;enum drm_mode_status (*)(struct drm_connector *, struct drm_display_mode *)&amp;#39; with an expression of type &amp;#39;int (struct drm_connector *, struct drm_display_mode *)&amp;#39; [-Werror,-Wincompatible-function-pointer-types-strict]<br /> .mode_valid = sti_hda_connector_mode_valid,<br /> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~<br /> drivers/gpu/drm/sti/sti_dvo.c:376:16: error: incompatible function pointer types initializing &amp;#39;enum drm_mode_status (*)(struct drm_connector *, struct drm_display_mode *)&amp;#39; with an expression of type &amp;#39;int (struct drm_connector *, struct drm_display_mode *)&amp;#39; [-Werror,-Wincompatible-function-pointer-types-strict]<br /> .mode_valid = sti_dvo_connector_mode_valid,<br /> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~<br /> drivers/gpu/drm/sti/sti_hdmi.c:1035:16: error: incompatible function pointer types initializing &amp;#39;enum drm_mode_status (*)(struct drm_connector *, struct drm_display_mode *)&amp;#39; with an expression of type &amp;#39;int (struct drm_connector *, struct drm_display_mode *)&amp;#39; [-Werror,-Wincompatible-function-pointer-types-strict]<br /> .mode_valid = sti_hdmi_connector_mode_valid,<br /> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~<br /> <br /> -&gt;mode_valid() in &amp;#39;struct drm_connector_helper_funcs&amp;#39; expects a return<br /> type of &amp;#39;enum drm_mode_status&amp;#39;, not &amp;#39;int&amp;#39;. Adjust the return type of<br /> sti_{dvo,hda,hdmi}_connector_mode_valid() to match the prototype&amp;#39;s to<br /> resolve the warning and CFI failure.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: typec: tcpci: fix of node refcount leak in tcpci_register_port()<br /> <br /> I got the following report while doing device(mt6370-tcpc) load<br /> test with CONFIG_OF_UNITTEST and CONFIG_OF_DYNAMIC enabled:<br /> <br /> OF: ERROR: memory leak, expected refcount 1 instead of 2,<br /> of_node_get()/of_node_put() unbalanced - destroy cset entry:<br /> attach overlay node /i2c/pmic@34/tcpc/connector<br /> <br /> The &amp;#39;fwnode&amp;#39; set in tcpci_parse_config() which is called<br /> in tcpci_register_port(), its node refcount is increased<br /> in device_get_named_child_node(). It needs be put while<br /> exiting, so call fwnode_handle_put() in the error path of<br /> tcpci_register_port() and in tcpci_unregister_port() to<br /> avoid leak.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: xhci-mtk: fix leakage of shared hcd when fail to set wakeup irq<br /> <br /> Can not set the @shared_hcd to NULL before decrease the usage count<br /> by usb_put_hcd(), this will cause the shared hcd not released.

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 /> 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 /> 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 /> 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 /> 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 /> 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.