Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: handle chunk tree lookup error in btrfs_relocate_sys_chunks()<br /> <br /> The unhandled case in btrfs_relocate_sys_chunks() loop is a corruption,<br /> as it could be caused only by two impossible conditions:<br /> <br /> - at first the search key is set up to look for a chunk tree item, with<br /> offset -1, this is an inexact search and the key-&gt;offset will contain<br /> the correct offset upon a successful search, a valid chunk tree item<br /> cannot have an offset -1<br /> <br /> - after first successful search, the found_key corresponds to a chunk<br /> item, the offset is decremented by 1 before the next loop, it&amp;#39;s<br /> impossible to find a chunk item there due to alignment and size<br /> constraints

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.

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.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: skbuff: add overflow debug check to pull/push helpers<br /> <br /> syzbot managed to trigger following splat:<br /> BUG: KASAN: use-after-free in __skb_flow_dissect+0x4a3b/0x5e50<br /> Read of size 1 at addr ffff888208a4000e by task a.out/2313<br /> [..]<br /> __skb_flow_dissect+0x4a3b/0x5e50<br /> __skb_get_hash+0xb4/0x400<br /> ip_tunnel_xmit+0x77e/0x26f0<br /> ipip_tunnel_xmit+0x298/0x410<br /> ..<br /> <br /> Analysis shows that the skb has a valid -&gt;head, but bogus -&gt;data<br /> pointer.<br /> <br /> skb-&gt;data gets its bogus value via the neigh layer, which does:<br /> <br /> 1556 __skb_pull(skb, skb_network_offset(skb));<br /> <br /> ... and the skb was already dodgy at this point:<br /> <br /> skb_network_offset(skb) returns a negative value due to an<br /> earlier overflow of skb-&gt;network_header (u16). __skb_pull thus<br /> "adjusts" skb-&gt;data by a huge offset, pointing outside skb-&gt;head<br /> area.<br /> <br /> Allow debug builds to splat when we try to pull/push more than<br /> INT_MAX bytes.<br /> <br /> After this, the syzkaller reproducer yields a more precise splat<br /> before the flow dissector attempts to read off skb-&gt;data memory:<br /> <br /> WARNING: CPU: 5 PID: 2313 at include/linux/skbuff.h:2653 neigh_connected_output+0x28e/0x400<br /> ip_finish_output2+0xb25/0xed0<br /> iptunnel_xmit+0x4ff/0x870<br /> ipgre_xmit+0x78e/0xbb0

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 /> pmdomain: ti: Add a null pointer check to the omap_prm_domain_init<br /> <br /> devm_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.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> randomize_kstack: Improve entropy diffusion<br /> <br /> The kstack_offset variable was really only ever using the low bits for<br /> kernel stack offset entropy. Add a ror32() to increase bit diffusion.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: mediatek: vcodec: adding lock to protect encoder context list<br /> <br /> Add a lock for the ctx_list, to avoid accessing a NULL pointer<br /> within the &amp;#39;vpu_enc_ipi_handler&amp;#39; function when the ctx_list has<br /> been deleted due to an unexpected behavior on the SCP IP block.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: mediatek: vcodec: adding lock to protect decoder context list<br /> <br /> Add a lock for the ctx_list, to avoid accessing a NULL pointer<br /> within the &amp;#39;vpu_dec_ipi_handler&amp;#39; function when the ctx_list has<br /> been deleted due to an unexpected behavior on the SCP IP block.<br /> <br /> Hardware name: Google juniper sku16 board (DT)<br /> pstate: 20400005 (nzCv daif +PAN -UAO -TCO BTYPE=--)<br /> pc : vpu_dec_ipi_handler+0x58/0x1f8 [mtk_vcodec_dec]<br /> lr : scp_ipi_handler+0xd0/0x194 [mtk_scp]<br /> sp : ffffffc0131dbbd0<br /> x29: ffffffc0131dbbd0 x28: 0000000000000000<br /> x27: ffffff9bb277f348 x26: ffffff9bb242ad00<br /> x25: ffffffd2d440d3b8 x24: ffffffd2a13ff1d4<br /> x23: ffffff9bb7fe85a0 x22: ffffffc0133fbdb0<br /> x21: 0000000000000010 x20: ffffff9b050ea328<br /> x19: ffffffc0131dbc08 x18: 0000000000001000<br /> x17: 0000000000000000 x16: ffffffd2d461c6e0<br /> x15: 0000000000000242 x14: 000000000000018f<br /> x13: 000000000000004d x12: 0000000000000000<br /> x11: 0000000000000001 x10: fffffffffffffff0<br /> x9 : ffffff9bb6e793a8 x8 : 0000000000000000<br /> x7 : 0000000000000000 x6 : 000000000000003f<br /> x5 : 0000000000000040 x4 : fffffffffffffff0<br /> x3 : 0000000000000020 x2 : ffffff9bb6e79080<br /> x1 : 0000000000000010 x0 : ffffffc0131dbc08<br /> Call trace:<br /> vpu_dec_ipi_handler+0x58/0x1f8 [mtk_vcodec_dec (HASH:6c3f 2)]<br /> scp_ipi_handler+0xd0/0x194 [mtk_scp (HASH:7046 3)]<br /> mt8183_scp_irq_handler+0x44/0x88 [mtk_scp (HASH:7046 3)]<br /> scp_irq_handler+0x48/0x90 [mtk_scp (HASH:7046 3)]<br /> irq_thread_fn+0x38/0x94<br /> irq_thread+0x100/0x1c0<br /> kthread+0x140/0x1fc<br /> ret_from_fork+0x10/0x30<br /> Code: 54000088 f94ca50a eb14015f 54000060 (f9400108)<br /> ---[ end trace ace43ce36cbd5c93 ]---<br /> Kernel panic - not syncing: Oops: Fatal exception<br /> SMP: stopping secondary CPUs<br /> Kernel Offset: 0x12c4000000 from 0xffffffc010000000<br /> PHYS_OFFSET: 0xffffffe580000000<br /> CPU features: 0x08240002,2188200c<br /> Memory Limit: none

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: mediatek: vcodec: Fix oops when HEVC init fails<br /> <br /> The stateless HEVC decoder saves the instance pointer in the context<br /> regardless if the initialization worked or not. This caused a use after<br /> free, when the pointer is freed in case of a failure in the deinit<br /> function.<br /> Only store the instance pointer when the initialization was successful,<br /> to solve this issue.<br /> <br /> Hardware name: Acer Tomato (rev3 - 4) board (DT)<br /> pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> pc : vcodec_vpu_send_msg+0x4c/0x190 [mtk_vcodec_dec]<br /> lr : vcodec_send_ap_ipi+0x78/0x170 [mtk_vcodec_dec]<br /> sp : ffff80008750bc20<br /> x29: ffff80008750bc20 x28: ffff1299f6d70000 x27: 0000000000000000<br /> x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000<br /> x23: ffff80008750bc98 x22: 000000000000a003 x21: ffffd45c4cfae000<br /> x20: 0000000000000010 x19: ffff1299fd668310 x18: 000000000000001a<br /> x17: 000000040044ffff x16: ffffd45cb15dc648 x15: 0000000000000000<br /> x14: ffff1299c08da1c0 x13: ffffd45cb1f87a10 x12: ffffd45cb2f5fe80<br /> x11: 0000000000000001 x10: 0000000000001b30 x9 : ffffd45c4d12b488<br /> x8 : 1fffe25339380d81 x7 : 0000000000000001 x6 : ffff1299c9c06c00<br /> x5 : 0000000000000132 x4 : 0000000000000000 x3 : 0000000000000000<br /> x2 : 0000000000000010 x1 : ffff80008750bc98 x0 : 0000000000000000<br /> Call trace:<br /> vcodec_vpu_send_msg+0x4c/0x190 [mtk_vcodec_dec]<br /> vcodec_send_ap_ipi+0x78/0x170 [mtk_vcodec_dec]<br /> vpu_dec_deinit+0x1c/0x30 [mtk_vcodec_dec]<br /> vdec_hevc_slice_deinit+0x30/0x98 [mtk_vcodec_dec]<br /> vdec_if_deinit+0x38/0x68 [mtk_vcodec_dec]<br /> mtk_vcodec_dec_release+0x20/0x40 [mtk_vcodec_dec]<br /> fops_vcodec_release+0x64/0x118 [mtk_vcodec_dec]<br /> v4l2_release+0x7c/0x100<br /> __fput+0x80/0x2d8<br /> __fput_sync+0x58/0x70<br /> __arm64_sys_close+0x40/0x90<br /> invoke_syscall+0x50/0x128<br /> el0_svc_common.constprop.0+0x48/0xf0<br /> do_el0_svc+0x24/0x38<br /> el0_svc+0x38/0xd8<br /> el0t_64_sync_handler+0xc0/0xc8<br /> el0t_64_sync+0x1a8/0x1b0<br /> Code: d503201f f9401660 b900127f b900227f (f9400400)