Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Do not set DRR on pipe Commit<br /> <br /> [WHY]<br /> Writing to DRR registers such as OTG_V_TOTAL_MIN on the same frame as a<br /> pipe commit can cause underflow.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> arm64: dts: qcom: sc7280: Mark PCIe controller as cache coherent<br /> <br /> If the controller is not marked as cache coherent, then kernel will<br /> try to ensure coherency during dma-ops and that may cause data corruption.<br /> So, mark the PCIe node as dma-coherent as the devices on PCIe bus are<br /> cache coherent.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dm stats: check for and propagate alloc_percpu failure<br /> <br /> Check alloc_precpu()&amp;#39;s return value and return an error from<br /> dm_stats_init() if it fails. Update alloc_dev() to fail if<br /> dm_stats_init() does.<br /> <br /> Otherwise, a NULL pointer dereference will occur in dm_stats_cleanup()<br /> even if dm-stats isn&amp;#39;t being actively used.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: gadget: u_audio: don&amp;#39;t let userspace block driver unbind<br /> <br /> In the unbind callback for f_uac1 and f_uac2, a call to snd_card_free()<br /> via g_audio_cleanup() will disconnect the card and then wait for all<br /> resources to be released, which happens when the refcount falls to zero.<br /> Since userspace can keep the refcount incremented by not closing the<br /> relevant file descriptor, the call to unbind may block indefinitely.<br /> This can cause a deadlock during reboot, as evidenced by the following<br /> blocked task observed on my machine:<br /> <br /> task:reboot state:D stack:0 pid:2827 ppid:569 flags:0x0000000c<br /> Call trace:<br /> __switch_to+0xc8/0x140<br /> __schedule+0x2f0/0x7c0<br /> schedule+0x60/0xd0<br /> schedule_timeout+0x180/0x1d4<br /> wait_for_completion+0x78/0x180<br /> snd_card_free+0x90/0xa0<br /> g_audio_cleanup+0x2c/0x64<br /> afunc_unbind+0x28/0x60<br /> ...<br /> kernel_restart+0x4c/0xac<br /> __do_sys_reboot+0xcc/0x1ec<br /> __arm64_sys_reboot+0x28/0x30<br /> invoke_syscall+0x4c/0x110<br /> ...<br /> <br /> The issue can also be observed by opening the card with arecord and<br /> then stopping the process through the shell before unbinding:<br /> <br /> # arecord -D hw:UAC2Gadget -f S32_LE -c 2 -r 48000 /dev/null<br /> Recording WAVE &amp;#39;/dev/null&amp;#39; : Signed 32 bit Little Endian, Rate 48000 Hz, Stereo<br /> ^Z[1]+ Stopped arecord -D hw:UAC2Gadget -f S32_LE -c 2 -r 48000 /dev/null<br /> # echo gadget.0 &gt; /sys/bus/gadget/drivers/configfs-gadget/unbind<br /> (observe that the unbind command never finishes)<br /> <br /> Fix the problem by using snd_card_free_when_closed() instead, which will<br /> still disconnect the card as desired, but defer the task of freeing the<br /> resources to the core once userspace closes its file descriptor.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: Fix race condition in hci_cmd_sync_clear<br /> <br /> There is a potential race condition in hci_cmd_sync_work and<br /> hci_cmd_sync_clear, and could lead to use-after-free. For instance,<br /> hci_cmd_sync_work is added to the &amp;#39;req_workqueue&amp;#39; after cancel_work_sync<br /> The entry of &amp;#39;cmd_sync_work_list&amp;#39; may be freed in hci_cmd_sync_clear, and<br /> causing kernel panic when it is used in &amp;#39;hci_cmd_sync_work&amp;#39;.<br /> <br /> Here&amp;#39;s the call trace:<br /> <br /> dump_stack_lvl+0x49/0x63<br /> print_report.cold+0x5e/0x5d3<br /> ? hci_cmd_sync_work+0x282/0x320<br /> kasan_report+0xaa/0x120<br /> ? hci_cmd_sync_work+0x282/0x320<br /> __asan_report_load8_noabort+0x14/0x20<br /> hci_cmd_sync_work+0x282/0x320<br /> process_one_work+0x77b/0x11c0<br /> ? _raw_spin_lock_irq+0x8e/0xf0<br /> worker_thread+0x544/0x1180<br /> ? poll_idle+0x1e0/0x1e0<br /> kthread+0x285/0x320<br /> ? process_one_work+0x11c0/0x11c0<br /> ? kthread_complete_and_exit+0x30/0x30<br /> ret_from_fork+0x22/0x30<br /> <br /> <br /> Allocated by task 266:<br /> kasan_save_stack+0x26/0x50<br /> __kasan_kmalloc+0xae/0xe0<br /> kmem_cache_alloc_trace+0x191/0x350<br /> hci_cmd_sync_queue+0x97/0x2b0<br /> hci_update_passive_scan+0x176/0x1d0<br /> le_conn_complete_evt+0x1b5/0x1a00<br /> hci_le_conn_complete_evt+0x234/0x340<br /> hci_le_meta_evt+0x231/0x4e0<br /> hci_event_packet+0x4c5/0xf00<br /> hci_rx_work+0x37d/0x880<br /> process_one_work+0x77b/0x11c0<br /> worker_thread+0x544/0x1180<br /> kthread+0x285/0x320<br /> ret_from_fork+0x22/0x30<br /> <br /> Freed by task 269:<br /> kasan_save_stack+0x26/0x50<br /> kasan_set_track+0x25/0x40<br /> kasan_set_free_info+0x24/0x40<br /> ____kasan_slab_free+0x176/0x1c0<br /> __kasan_slab_free+0x12/0x20<br /> slab_free_freelist_hook+0x95/0x1a0<br /> kfree+0xba/0x2f0<br /> hci_cmd_sync_clear+0x14c/0x210<br /> hci_unregister_dev+0xff/0x440<br /> vhci_release+0x7b/0xf0<br /> __fput+0x1f3/0x970<br /> ____fput+0xe/0x20<br /> task_work_run+0xd4/0x160<br /> do_exit+0x8b0/0x22a0<br /> do_group_exit+0xba/0x2a0<br /> get_signal+0x1e4a/0x25b0<br /> arch_do_signal_or_restart+0x93/0x1f80<br /> exit_to_user_mode_prepare+0xf5/0x1a0<br /> syscall_exit_to_user_mode+0x26/0x50<br /> ret_from_fork+0x15/0x30

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tee: amdtee: fix race condition in amdtee_open_session<br /> <br /> There is a potential race condition in amdtee_open_session that may<br /> lead to use-after-free. For instance, in amdtee_open_session() after<br /> sess-&gt;sess_mask is set, and before setting:<br /> <br /> sess-&gt;session_info[i] = session_info;<br /> <br /> if amdtee_close_session() closes this same session, then &amp;#39;sess&amp;#39; data<br /> structure will be released, causing kernel panic when &amp;#39;sess&amp;#39; is<br /> accessed within amdtee_open_session().<br /> <br /> The solution is to set the bit sess-&gt;sess_mask as the last step in<br /> amdtee_open_session().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: typec: tcpm: fix warning when handle discover_identity message<br /> <br /> Since both source and sink device can send discover_identity message in<br /> PD3, kernel may dump below warning:<br /> <br /> ------------[ cut here ]------------<br /> WARNING: CPU: 0 PID: 169 at drivers/usb/typec/tcpm/tcpm.c:1446 tcpm_queue_vdm+0xe0/0xf0<br /> Modules linked in:<br /> CPU: 0 PID: 169 Comm: 1-0050 Not tainted 6.1.1-00038-g6a3c36cf1da2-dirty #567<br /> Hardware name: NXP i.MX8MPlus EVK board (DT)<br /> pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> pc : tcpm_queue_vdm+0xe0/0xf0<br /> lr : tcpm_queue_vdm+0x2c/0xf0<br /> sp : ffff80000c19bcd0<br /> x29: ffff80000c19bcd0 x28: 0000000000000001 x27: ffff0000d11c8ab8<br /> x26: ffff0000d11cc000 x25: 0000000000000000 x24: 00000000ff008081<br /> x23: 0000000000000001 x22: 00000000ff00a081 x21: ffff80000c19bdbc<br /> x20: 0000000000000000 x19: ffff0000d11c8080 x18: ffffffffffffffff<br /> x17: 0000000000000000 x16: 0000000000000000 x15: ffff0000d716f580<br /> x14: 0000000000000001 x13: ffff0000d716f507 x12: 0000000000000001<br /> x11: 0000000000000000 x10: 0000000000000020 x9 : 00000000000ee098<br /> x8 : 00000000ffffffff x7 : 000000000000001c x6 : ffff0000d716f580<br /> x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000<br /> x2 : ffff80000c19bdbc x1 : 00000000ff00a081 x0 : 0000000000000004<br /> Call trace:<br /> tcpm_queue_vdm+0xe0/0xf0<br /> tcpm_pd_rx_handler+0x340/0x1ab0<br /> kthread_worker_fn+0xcc/0x18c<br /> kthread+0x10c/0x110<br /> ret_from_fork+0x10/0x20<br /> ---[ end trace 0000000000000000 ]---<br /> <br /> Below sequences may trigger this warning:<br /> <br /> tcpm_send_discover_work(work)<br /> tcpm_send_vdm(port, USB_SID_PD, CMD_DISCOVER_IDENT, NULL, 0);<br /> tcpm_queue_vdm(port, header, data, count);<br /> port-&gt;vdm_state = VDM_STATE_READY;<br /> <br /> vdm_state_machine_work(work);<br /> vdm_state = VDM_STATE_SEND_MESSAGE;<br /> mod_vdm_delayed_work(port, x);<br /> <br /> tcpm_pd_rx_handler(work);<br /> tcpm_pd_data_request(port, msg);<br /> tcpm_handle_vdm_request(port, msg-&gt;payload, cnt);<br /> tcpm_queue_vdm(port, response[0], &amp;response[1], rlen - 1);<br /> --&gt; WARN_ON(port-&gt;vdm_state &gt; VDM_STATE_DONE);<br /> <br /> For this case, the state machine could still send out discover<br /> identity message later if we skip current discover_identity message.<br /> So we should handle the received message firstly and override the pending<br /> discover_identity message without warning in this case. Then, a delayed<br /> send_discover work will send discover_identity message again.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: ucsi: Fix NULL pointer deref in ucsi_connector_change()<br /> <br /> When ucsi_init() fails, ucsi-&gt;connector is NULL, yet in case of<br /> ucsi_acpi we may still get events which cause the ucs_acpi code to call<br /> ucsi_connector_change(), which then derefs the NULL ucsi-&gt;connector<br /> pointer.<br /> <br /> Fix this by not setting ucsi-&gt;ntfy inside ucsi_init() until ucsi_init()<br /> has succeeded, so that ucsi_connector_change() ignores the events<br /> because UCSI_ENABLE_NTFY_CONNECTOR_CHANGE is not set in the ntfy mask.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: VMX: Do _all_ initialization before exposing /dev/kvm to userspace<br /> <br /> Call kvm_init() only after _all_ setup is complete, as kvm_init() exposes<br /> /dev/kvm to userspace and thus allows userspace to create VMs (and call<br /> other ioctls). E.g. KVM will encounter a NULL pointer when attempting to<br /> add a vCPU to the per-CPU loaded_vmcss_on_cpu list if userspace is able to<br /> create a VM before vmx_init() configures said list.<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000008<br /> #PF: supervisor write access in kernel mode<br /> #PF: error_code(0x0002) - not-present page<br /> PGD 0 P4D 0<br /> Oops: 0002 [#1] SMP<br /> CPU: 6 PID: 1143 Comm: stable Not tainted 6.0.0-rc7+ #988<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015<br /> RIP: 0010:vmx_vcpu_load_vmcs+0x68/0x230 [kvm_intel]<br /> <br /> vmx_vcpu_load+0x16/0x60 [kvm_intel]<br /> kvm_arch_vcpu_load+0x32/0x1f0 [kvm]<br /> vcpu_load+0x2f/0x40 [kvm]<br /> kvm_arch_vcpu_create+0x231/0x310 [kvm]<br /> kvm_vm_ioctl+0x79f/0xe10 [kvm]<br /> ? handle_mm_fault+0xb1/0x220<br /> __x64_sys_ioctl+0x80/0xb0<br /> do_syscall_64+0x2b/0x50<br /> entry_SYSCALL_64_after_hwframe+0x46/0xb0<br /> RIP: 0033:0x7f5a6b05743b<br /> <br /> Modules linked in: vhost_net vhost vhost_iotlb tap kvm_intel(+) kvm irqbypass

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nilfs2: fix kernel-infoleak in nilfs_ioctl_wrap_copy()<br /> <br /> The ioctl helper function nilfs_ioctl_wrap_copy(), which exchanges a<br /> metadata array to/from user space, may copy uninitialized buffer regions<br /> to user space memory for read-only ioctl commands NILFS_IOCTL_GET_SUINFO<br /> and NILFS_IOCTL_GET_CPINFO.<br /> <br /> This can occur when the element size of the user space metadata given by<br /> the v_size member of the argument nilfs_argv structure is larger than the<br /> size of the metadata element (nilfs_suinfo structure or nilfs_cpinfo<br /> structure) on the file system side.<br /> <br /> KMSAN-enabled kernels detect this issue as follows:<br /> <br /> BUG: KMSAN: kernel-infoleak in instrument_copy_to_user<br /> include/linux/instrumented.h:121 [inline]<br /> BUG: KMSAN: kernel-infoleak in _copy_to_user+0xc0/0x100 lib/usercopy.c:33<br /> instrument_copy_to_user include/linux/instrumented.h:121 [inline]<br /> _copy_to_user+0xc0/0x100 lib/usercopy.c:33<br /> copy_to_user include/linux/uaccess.h:169 [inline]<br /> nilfs_ioctl_wrap_copy+0x6fa/0xc10 fs/nilfs2/ioctl.c:99<br /> nilfs_ioctl_get_info fs/nilfs2/ioctl.c:1173 [inline]<br /> nilfs_ioctl+0x2402/0x4450 fs/nilfs2/ioctl.c:1290<br /> nilfs_compat_ioctl+0x1b8/0x200 fs/nilfs2/ioctl.c:1343<br /> __do_compat_sys_ioctl fs/ioctl.c:968 [inline]<br /> __se_compat_sys_ioctl+0x7dd/0x1000 fs/ioctl.c:910<br /> __ia32_compat_sys_ioctl+0x93/0xd0 fs/ioctl.c:910<br /> do_syscall_32_irqs_on arch/x86/entry/common.c:112 [inline]<br /> __do_fast_syscall_32+0xa2/0x100 arch/x86/entry/common.c:178<br /> do_fast_syscall_32+0x37/0x80 arch/x86/entry/common.c:203<br /> do_SYSENTER_32+0x1f/0x30 arch/x86/entry/common.c:246<br /> entry_SYSENTER_compat_after_hwframe+0x70/0x82<br /> <br /> Uninit was created at:<br /> __alloc_pages+0x9f6/0xe90 mm/page_alloc.c:5572<br /> alloc_pages+0xab0/0xd80 mm/mempolicy.c:2287<br /> __get_free_pages+0x34/0xc0 mm/page_alloc.c:5599<br /> nilfs_ioctl_wrap_copy+0x223/0xc10 fs/nilfs2/ioctl.c:74<br /> nilfs_ioctl_get_info fs/nilfs2/ioctl.c:1173 [inline]<br /> nilfs_ioctl+0x2402/0x4450 fs/nilfs2/ioctl.c:1290<br /> nilfs_compat_ioctl+0x1b8/0x200 fs/nilfs2/ioctl.c:1343<br /> __do_compat_sys_ioctl fs/ioctl.c:968 [inline]<br /> __se_compat_sys_ioctl+0x7dd/0x1000 fs/ioctl.c:910<br /> __ia32_compat_sys_ioctl+0x93/0xd0 fs/ioctl.c:910<br /> do_syscall_32_irqs_on arch/x86/entry/common.c:112 [inline]<br /> __do_fast_syscall_32+0xa2/0x100 arch/x86/entry/common.c:178<br /> do_fast_syscall_32+0x37/0x80 arch/x86/entry/common.c:203<br /> do_SYSENTER_32+0x1f/0x30 arch/x86/entry/common.c:246<br /> entry_SYSENTER_compat_after_hwframe+0x70/0x82<br /> <br /> Bytes 16-127 of 3968 are uninitialized<br /> ...<br /> <br /> This eliminates the leak issue by initializing the page allocated as<br /> buffer using get_zeroed_page().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu: Fix call trace warning and hang when removing amdgpu device<br /> <br /> On GPUs with RAS enabled, below call trace and hang are observed when<br /> shutting down device.<br /> <br /> v2: use DRM device unplugged flag instead of shutdown flag as the check to<br /> prevent memory wipe in shutdown stage.<br /> <br /> [ +0.000000] RIP: 0010:amdgpu_vram_mgr_fini+0x18d/0x1c0 [amdgpu]<br /> [ +0.000001] PKRU: 55555554<br /> [ +0.000001] Call Trace:<br /> [ +0.000001] <br /> [ +0.000002] amdgpu_ttm_fini+0x140/0x1c0 [amdgpu]<br /> [ +0.000183] amdgpu_bo_fini+0x27/0xa0 [amdgpu]<br /> [ +0.000184] gmc_v11_0_sw_fini+0x2b/0x40 [amdgpu]<br /> [ +0.000163] amdgpu_device_fini_sw+0xb6/0x510 [amdgpu]<br /> [ +0.000152] amdgpu_driver_release_kms+0x16/0x30 [amdgpu]<br /> [ +0.000090] drm_dev_release+0x28/0x50 [drm]<br /> [ +0.000016] devm_drm_dev_init_release+0x38/0x60 [drm]<br /> [ +0.000011] devm_action_release+0x15/0x20<br /> [ +0.000003] release_nodes+0x40/0xc0<br /> [ +0.000001] devres_release_all+0x9e/0xe0<br /> [ +0.000001] device_unbind_cleanup+0x12/0x80<br /> [ +0.000003] device_release_driver_internal+0xff/0x160<br /> [ +0.000001] driver_detach+0x4a/0x90<br /> [ +0.000001] bus_remove_driver+0x6c/0xf0<br /> [ +0.000001] driver_unregister+0x31/0x50<br /> [ +0.000001] pci_unregister_driver+0x40/0x90<br /> [ +0.000003] amdgpu_exit+0x15/0x120 [amdgpu]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: mpi3mr: Bad drive in topology results kernel crash<br /> <br /> When the SAS Transport Layer support is enabled and a device exposed to<br /> the OS by the driver fails INQUIRY commands, the driver frees up the memory<br /> allocated for an internal HBA port data structure. However, in some places,<br /> the reference to the freed memory is not cleared. When the firmware sends<br /> the Device Info change event for the same device again, the freed memory is<br /> accessed and that leads to memory corruption and OS crash.