Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> VMCI: Fix memcpy() run-time warning in dg_dispatch_as_host()<br /> <br /> Syzkaller hit &amp;#39;WARNING in dg_dispatch_as_host&amp;#39; bug.<br /> <br /> memcpy: detected field-spanning write (size 56) of single field "&amp;dg_info-&gt;msg"<br /> at drivers/misc/vmw_vmci/vmci_datagram.c:237 (size 24)<br /> <br /> WARNING: CPU: 0 PID: 1555 at drivers/misc/vmw_vmci/vmci_datagram.c:237<br /> dg_dispatch_as_host+0x88e/0xa60 drivers/misc/vmw_vmci/vmci_datagram.c:237<br /> <br /> Some code commentry, based on my understanding:<br /> <br /> 544 #define VMCI_DG_SIZE(_dg) (VMCI_DG_HEADERSIZE + (size_t)(_dg)-&gt;payload_size)<br /> /// This is 24 + payload_size<br /> <br /> memcpy(&amp;dg_info-&gt;msg, dg, dg_size);<br /> Destination = dg_info-&gt;msg ---&gt; this is a 24 byte<br /> structure(struct vmci_datagram)<br /> Source = dg --&gt; this is a 24 byte structure (struct vmci_datagram)<br /> Size = dg_size = 24 + payload_size<br /> <br /> {payload_size = 56-24 =32} -- Syzkaller managed to set payload_size to 32.<br /> <br /> 35 struct delayed_datagram_info {<br /> 36 struct datagram_entry *entry;<br /> 37 struct work_struct work;<br /> 38 bool in_dg_host_queue;<br /> 39 /* msg and msg_payload must be together. */<br /> 40 struct vmci_datagram msg;<br /> 41 u8 msg_payload[];<br /> 42 };<br /> <br /> So those extra bytes of payload are copied into msg_payload[], a run time<br /> warning is seen while fuzzing with Syzkaller.<br /> <br /> One possible way to fix the warning is to split the memcpy() into<br /> two parts -- one -- direct assignment of msg and second taking care of payload.<br /> <br /> Gustavo quoted:<br /> "Under FORTIFY_SOURCE we should not copy data across multiple members<br /> in a structure."

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: lpfc: Fix possible memory leak in lpfc_rcv_padisc()<br /> <br /> The call to lpfc_sli4_resume_rpi() in lpfc_rcv_padisc() may return an<br /> unsuccessful status. In such cases, the elsiocb is not issued, the<br /> completion is not called, and thus the elsiocb resource is leaked.<br /> <br /> Check return value after calling lpfc_sli4_resume_rpi() and conditionally<br /> release the elsiocb resource.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu: Skip do PCI error slot reset during RAS recovery<br /> <br /> Why:<br /> The PCI error slot reset maybe triggered after inject ue to UMC multi times, this<br /> caused system hang.<br /> [ 557.371857] amdgpu 0000:af:00.0: amdgpu: GPU reset succeeded, trying to resume<br /> [ 557.373718] [drm] PCIE GART of 512M enabled.<br /> [ 557.373722] [drm] PTB located at 0x0000031FED700000<br /> [ 557.373788] [drm] VRAM is lost due to GPU reset!<br /> [ 557.373789] [drm] PSP is resuming...<br /> [ 557.547012] mlx5_core 0000:55:00.0: mlx5_pci_err_detected Device state = 1 pci_status: 0. Exit, result = 3, need reset<br /> [ 557.547067] [drm] PCI error: detected callback, state(1)!!<br /> [ 557.547069] [drm] No support for XGMI hive yet...<br /> [ 557.548125] mlx5_core 0000:55:00.0: mlx5_pci_slot_reset Device state = 1 pci_status: 0. Enter<br /> [ 557.607763] mlx5_core 0000:55:00.0: wait vital counter value 0x16b5b after 1 iterations<br /> [ 557.607777] mlx5_core 0000:55:00.0: mlx5_pci_slot_reset Device state = 1 pci_status: 1. Exit, err = 0, result = 5, recovered<br /> [ 557.610492] [drm] PCI error: slot reset callback!!<br /> ...<br /> [ 560.689382] amdgpu 0000:3f:00.0: amdgpu: GPU reset(2) succeeded!<br /> [ 560.689546] amdgpu 0000:5a:00.0: amdgpu: GPU reset(2) succeeded!<br /> [ 560.689562] general protection fault, probably for non-canonical address 0x5f080b54534f611f: 0000 [#1] SMP NOPTI<br /> [ 560.701008] CPU: 16 PID: 2361 Comm: kworker/u448:9 Tainted: G OE 5.15.0-91-generic #101-Ubuntu<br /> [ 560.712057] Hardware name: Microsoft C278A/C278A, BIOS C2789.5.BS.1C11.AG.1 11/08/2023<br /> [ 560.720959] Workqueue: amdgpu-reset-hive amdgpu_ras_do_recovery [amdgpu]<br /> [ 560.728887] RIP: 0010:amdgpu_device_gpu_recover.cold+0xbf1/0xcf5 [amdgpu]<br /> [ 560.736891] Code: ff 41 89 c6 e9 1b ff ff ff 44 0f b6 45 b0 e9 4f ff ff ff be 01 00 00 00 4c 89 e7 e8 76 c9 8b ff 44 0f b6 45 b0 e9 3c fd ff ff 83 ba 18 02 00 00 00 0f 84 6a f8 ff ff 48 8d 7a 78 be 01 00 00<br /> [ 560.757967] RSP: 0018:ffa0000032e53d80 EFLAGS: 00010202<br /> [ 560.763848] RAX: ffa00000001dfd10 RBX: ffa0000000197090 RCX: ffa0000032e53db0<br /> [ 560.771856] RDX: 5f080b54534f5f07 RSI: 0000000000000000 RDI: ff11000128100010<br /> [ 560.779867] RBP: ffa0000032e53df0 R08: 0000000000000000 R09: ffffffffffe77f08<br /> [ 560.787879] R10: 0000000000ffff0a R11: 0000000000000001 R12: 0000000000000000<br /> [ 560.795889] R13: ffa0000032e53e00 R14: 0000000000000000 R15: 0000000000000000<br /> [ 560.803889] FS: 0000000000000000(0000) GS:ff11007e7e800000(0000) knlGS:0000000000000000<br /> [ 560.812973] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 560.819422] CR2: 000055a04c118e68 CR3: 0000000007410005 CR4: 0000000000771ee0<br /> [ 560.827433] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> [ 560.835433] DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400<br /> [ 560.843444] PKRU: 55555554<br /> [ 560.846480] Call Trace:<br /> [ 560.849225] <br /> [ 560.851580] ? show_trace_log_lvl+0x1d6/0x2ea<br /> [ 560.856488] ? show_trace_log_lvl+0x1d6/0x2ea<br /> [ 560.861379] ? amdgpu_ras_do_recovery+0x1b2/0x210 [amdgpu]<br /> [ 560.867778] ? show_regs.part.0+0x23/0x29<br /> [ 560.872293] ? __die_body.cold+0x8/0xd<br /> [ 560.876502] ? die_addr+0x3e/0x60<br /> [ 560.880238] ? exc_general_protection+0x1c5/0x410<br /> [ 560.885532] ? asm_exc_general_protection+0x27/0x30<br /> [ 560.891025] ? amdgpu_device_gpu_recover.cold+0xbf1/0xcf5 [amdgpu]<br /> [ 560.898323] amdgpu_ras_do_recovery+0x1b2/0x210 [amdgpu]<br /> [ 560.904520] process_one_work+0x228/0x3d0<br /> How:<br /> In RAS recovery, mode-1 reset is issued from RAS fatal error handling and expected<br /> all the nodes in a hive to be reset. no need to issue another mode-1 during this procedure.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/vc4: don&amp;#39;t check if plane-&gt;state-&gt;fb == state-&gt;fb<br /> <br /> Currently, when using non-blocking commits, we can see the following<br /> kernel warning:<br /> <br /> [ 110.908514] ------------[ cut here ]------------<br /> [ 110.908529] refcount_t: underflow; use-after-free.<br /> [ 110.908620] WARNING: CPU: 0 PID: 1866 at lib/refcount.c:87 refcount_dec_not_one+0xb8/0xc0<br /> [ 110.908664] Modules linked in: rfcomm snd_seq_dummy snd_hrtimer snd_seq snd_seq_device cmac algif_hash aes_arm64 aes_generic algif_skcipher af_alg bnep hid_logitech_hidpp vc4 brcmfmac hci_uart btbcm brcmutil bluetooth snd_soc_hdmi_codec cfg80211 cec drm_display_helper drm_dma_helper drm_kms_helper snd_soc_core snd_compress snd_pcm_dmaengine fb_sys_fops sysimgblt syscopyarea sysfillrect raspberrypi_hwmon ecdh_generic ecc rfkill libaes i2c_bcm2835 binfmt_misc joydev snd_bcm2835(C) bcm2835_codec(C) bcm2835_isp(C) v4l2_mem2mem videobuf2_dma_contig snd_pcm bcm2835_v4l2(C) raspberrypi_gpiomem bcm2835_mmal_vchiq(C) videobuf2_v4l2 snd_timer videobuf2_vmalloc videobuf2_memops videobuf2_common snd videodev vc_sm_cma(C) mc hid_logitech_dj uio_pdrv_genirq uio i2c_dev drm fuse dm_mod drm_panel_orientation_quirks backlight ip_tables x_tables ipv6<br /> [ 110.909086] CPU: 0 PID: 1866 Comm: kodi.bin Tainted: G C 6.1.66-v8+ #32<br /> [ 110.909104] Hardware name: Raspberry Pi 3 Model B Rev 1.2 (DT)<br /> [ 110.909114] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> [ 110.909132] pc : refcount_dec_not_one+0xb8/0xc0<br /> [ 110.909152] lr : refcount_dec_not_one+0xb4/0xc0<br /> [ 110.909170] sp : ffffffc00913b9c0<br /> [ 110.909177] x29: ffffffc00913b9c0 x28: 000000556969bbb0 x27: 000000556990df60<br /> [ 110.909205] x26: 0000000000000002 x25: 0000000000000004 x24: ffffff8004448480<br /> [ 110.909230] x23: ffffff800570b500 x22: ffffff802e03a7bc x21: ffffffecfca68c78<br /> [ 110.909257] x20: ffffff8002b42000 x19: ffffff802e03a600 x18: 0000000000000000<br /> [ 110.909283] x17: 0000000000000011 x16: ffffffffffffffff x15: 0000000000000004<br /> [ 110.909308] x14: 0000000000000fff x13: ffffffed577e47e0 x12: 0000000000000003<br /> [ 110.909333] x11: 0000000000000000 x10: 0000000000000027 x9 : c912d0d083728c00<br /> [ 110.909359] x8 : c912d0d083728c00 x7 : 65646e75203a745f x6 : 746e756f63666572<br /> [ 110.909384] x5 : ffffffed579f62ee x4 : ffffffed579eb01e x3 : 0000000000000000<br /> [ 110.909409] x2 : 0000000000000000 x1 : ffffffc00913b750 x0 : 0000000000000001<br /> [ 110.909434] Call trace:<br /> [ 110.909441] refcount_dec_not_one+0xb8/0xc0<br /> [ 110.909461] vc4_bo_dec_usecnt+0x4c/0x1b0 [vc4]<br /> [ 110.909903] vc4_cleanup_fb+0x44/0x50 [vc4]<br /> [ 110.910315] drm_atomic_helper_cleanup_planes+0x88/0xa4 [drm_kms_helper]<br /> [ 110.910669] vc4_atomic_commit_tail+0x390/0x9dc [vc4]<br /> [ 110.911079] commit_tail+0xb0/0x164 [drm_kms_helper]<br /> [ 110.911397] drm_atomic_helper_commit+0x1d0/0x1f0 [drm_kms_helper]<br /> [ 110.911716] drm_atomic_commit+0xb0/0xdc [drm]<br /> [ 110.912569] drm_mode_atomic_ioctl+0x348/0x4b8 [drm]<br /> [ 110.913330] drm_ioctl_kernel+0xec/0x15c [drm]<br /> [ 110.914091] drm_ioctl+0x24c/0x3b0 [drm]<br /> [ 110.914850] __arm64_sys_ioctl+0x9c/0xd4<br /> [ 110.914873] invoke_syscall+0x4c/0x114<br /> [ 110.914897] el0_svc_common+0xd0/0x118<br /> [ 110.914917] do_el0_svc+0x38/0xd0<br /> [ 110.914936] el0_svc+0x30/0x8c<br /> [ 110.914958] el0t_64_sync_handler+0x84/0xf0<br /> [ 110.914979] el0t_64_sync+0x18c/0x190<br /> [ 110.914996] ---[ end trace 0000000000000000 ]---<br /> <br /> This happens because, although `prepare_fb` and `cleanup_fb` are<br /> perfectly balanced, we cannot guarantee consistency in the check<br /> plane-&gt;state-&gt;fb == state-&gt;fb. This means that sometimes we can increase<br /> the refcount in `prepare_fb` and don&amp;#39;t decrease it in `cleanup_fb`. The<br /> opposite can also be true.<br /> <br /> In fact, the struct drm_plane .state shouldn&amp;#39;t be accessed directly<br /> but instead, the `drm_atomic_get_new_plane_state()` helper function should<br /> be used. So, we could stick to this check, but using<br /> `drm_atomic_get_new_plane_state()`. But actually, this check is not re<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: ath11k: decrease MHI channel buffer length to 8KB<br /> <br /> Currently buf_len field of ath11k_mhi_config_qca6390 is assigned<br /> with 0, making MHI use a default size, 64KB, to allocate channel<br /> buffers. This is likely to fail in some scenarios where system<br /> memory is highly fragmented and memory compaction or reclaim is<br /> not allowed.<br /> <br /> There is a fail report which is caused by it:<br /> kworker/u32:45: page allocation failure: order:4, mode:0x40c00(GFP_NOIO|__GFP_COMP), nodemask=(null),cpuset=/,mems_allowed=0<br /> CPU: 0 PID: 19318 Comm: kworker/u32:45 Not tainted 6.8.0-rc3-1.gae4495f-default #1 openSUSE Tumbleweed (unreleased) 493b6d5b382c603654d7a81fc3c144d59a1dfceb<br /> Workqueue: events_unbound async_run_entry_fn<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x47/0x60<br /> warn_alloc+0x13a/0x1b0<br /> ? srso_alias_return_thunk+0x5/0xfbef5<br /> ? __alloc_pages_direct_compact+0xab/0x210<br /> __alloc_pages_slowpath.constprop.0+0xd3e/0xda0<br /> __alloc_pages+0x32d/0x350<br /> ? mhi_prepare_channel+0x127/0x2d0 [mhi 40df44e07c05479f7a6e7b90fba9f0e0031a7814]<br /> __kmalloc_large_node+0x72/0x110<br /> __kmalloc+0x37c/0x480<br /> ? mhi_map_single_no_bb+0x77/0xf0 [mhi 40df44e07c05479f7a6e7b90fba9f0e0031a7814]<br /> ? mhi_prepare_channel+0x127/0x2d0 [mhi 40df44e07c05479f7a6e7b90fba9f0e0031a7814]<br /> mhi_prepare_channel+0x127/0x2d0 [mhi 40df44e07c05479f7a6e7b90fba9f0e0031a7814]<br /> __mhi_prepare_for_transfer+0x44/0x80 [mhi 40df44e07c05479f7a6e7b90fba9f0e0031a7814]<br /> ? __pfx_____mhi_prepare_for_transfer+0x10/0x10 [mhi 40df44e07c05479f7a6e7b90fba9f0e0031a7814]<br /> device_for_each_child+0x5c/0xa0<br /> ? __pfx_pci_pm_resume+0x10/0x10<br /> ath11k_core_resume+0x65/0x100 [ath11k a5094e22d7223135c40d93c8f5321cf09fd85e4e]<br /> ? srso_alias_return_thunk+0x5/0xfbef5<br /> ath11k_pci_pm_resume+0x32/0x60 [ath11k_pci 830b7bfc3ea80ebef32e563cafe2cb55e9cc73ec]<br /> ? srso_alias_return_thunk+0x5/0xfbef5<br /> dpm_run_callback+0x8c/0x1e0<br /> device_resume+0x104/0x340<br /> ? __pfx_dpm_watchdog_handler+0x10/0x10<br /> async_resume+0x1d/0x30<br /> async_run_entry_fn+0x32/0x120<br /> process_one_work+0x168/0x330<br /> worker_thread+0x2f5/0x410<br /> ? __pfx_worker_thread+0x10/0x10<br /> kthread+0xe8/0x120<br /> ? __pfx_kthread+0x10/0x10<br /> ret_from_fork+0x34/0x50<br /> ? __pfx_kthread+0x10/0x10<br /> ret_from_fork_asm+0x1b/0x30<br /> <br /> <br /> Actually those buffers are used only by QMI target -&gt; host communication.<br /> And for WCN6855 and QCA6390, the largest packet size for that is less<br /> than 6KB. So change buf_len field to 8KB, which results in order 1<br /> allocation if page size is 4KB. In this way, we can at least save some<br /> memory, and as well as decrease the possibility of allocation failure<br /> in those scenarios.<br /> <br /> Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.30

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dma-direct: Leak pages on dma_set_decrypted() failure<br /> <br /> On TDX it is possible for the untrusted host to cause<br /> set_memory_encrypted() or set_memory_decrypted() to fail such that an<br /> error is returned and the resulting memory is shared. Callers need to<br /> take care to handle these errors to avoid returning decrypted (shared)<br /> memory to the page allocator, which could lead to functional or security<br /> issues.<br /> <br /> DMA could free decrypted/shared pages if dma_set_decrypted() fails. This<br /> should be a rare case. Just leak the pages in this case instead of<br /> freeing them.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> pstore/zone: Add a null pointer check to the psz_kmsg_read<br /> <br /> kasprintf() returns a pointer to dynamically allocated memory<br /> which can be NULL upon failure. Ensure the allocation was successful<br /> by checking the pointer validity.

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 /> pmdomain: imx8mp-blk-ctrl: imx8mp_blk: Add fdcc clock to hdmimix domain<br /> <br /> According to i.MX8MP RM and HDMI ADD, the fdcc clock is part of<br /> hdmi rx verification IP that should not enable for HDMI TX.<br /> But actually if the clock is disabled before HDMI/LCDIF probe,<br /> LCDIF will not get pixel clock from HDMI PHY and print the error<br /> logs:<br /> <br /> [CRTC:39:crtc-2] vblank wait timed out<br /> WARNING: CPU: 2 PID: 9 at drivers/gpu/drm/drm_atomic_helper.c:1634 drm_atomic_helper_wait_for_vblanks.part.0+0x23c/0x260<br /> <br /> Add fdcc clock to LCDIF and HDMI TX power domains to fix the issue.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: send: handle path ref underflow in header iterate_inode_ref()<br /> <br /> Change BUG_ON to proper error handling if building the path buffer<br /> fails. The pointers are not printed so we don&amp;#39;t accidentally leak kernel<br /> addresses.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: btintel: Fix null ptr deref in btintel_read_version<br /> <br /> If hci_cmd_sync_complete() is triggered and skb is NULL, then<br /> hdev-&gt;req_skb is NULL, which will cause this issue.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: cfg80211: check A-MSDU format more carefully<br /> <br /> If it looks like there&amp;#39;s another subframe in the A-MSDU<br /> but the header isn&amp;#39;t fully there, we can end up reading<br /> data out of bounds, only to discard later. Make this a<br /> bit more careful and check if the subframe header can<br /> even be present.