Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/xe/vf: Don&amp;#39;t try to trigger a full GT reset if VF<br /> <br /> VFs don&amp;#39;t have access to the GDRST(0x941c) register that driver<br /> uses to reset a GT. Attempt to trigger a reset using debugfs:<br /> <br /> $ cat /sys/kernel/debug/dri/0000:00:02.1/gt0/force_reset<br /> <br /> or due to a hang condition detected by the driver leads to:<br /> <br /> [ ] xe 0000:00:02.1: [drm] GT0: trying reset from force_reset [xe]<br /> [ ] xe 0000:00:02.1: [drm] GT0: reset queued<br /> [ ] xe 0000:00:02.1: [drm] GT0: reset started<br /> [ ] ------------[ cut here ]------------<br /> [ ] xe 0000:00:02.1: [drm] GT0: VF is trying to write 0x1 to an inaccessible register 0x941c+0x0<br /> [ ] WARNING: CPU: 3 PID: 3069 at drivers/gpu/drm/xe/xe_gt_sriov_vf.c:996 xe_gt_sriov_vf_write32+0xc6/0x580 [xe]<br /> [ ] RIP: 0010:xe_gt_sriov_vf_write32+0xc6/0x580 [xe]<br /> [ ] Call Trace:<br /> [ ] <br /> [ ] ? show_regs+0x6c/0x80<br /> [ ] ? __warn+0x93/0x1c0<br /> [ ] ? xe_gt_sriov_vf_write32+0xc6/0x580 [xe]<br /> [ ] ? report_bug+0x182/0x1b0<br /> [ ] ? handle_bug+0x6e/0xb0<br /> [ ] ? exc_invalid_op+0x18/0x80<br /> [ ] ? asm_exc_invalid_op+0x1b/0x20<br /> [ ] ? xe_gt_sriov_vf_write32+0xc6/0x580 [xe]<br /> [ ] ? xe_gt_sriov_vf_write32+0xc6/0x580 [xe]<br /> [ ] ? xe_gt_tlb_invalidation_reset+0xef/0x110 [xe]<br /> [ ] ? __mutex_unlock_slowpath+0x41/0x2e0<br /> [ ] xe_mmio_write32+0x64/0x150 [xe]<br /> [ ] do_gt_reset+0x2f/0xa0 [xe]<br /> [ ] gt_reset_worker+0x14e/0x1e0 [xe]<br /> [ ] process_one_work+0x21c/0x740<br /> [ ] worker_thread+0x1db/0x3c0<br /> <br /> Fix that by sending H2G VF_RESET(0x5507) action instead.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: venus: hfi: add a check to handle OOB in sfr region<br /> <br /> sfr-&gt;buf_size is in shared memory and can be modified by malicious user.<br /> OOB write is possible when the size is made higher than actual sfr data<br /> buffer. Cap the size to allocated size for such cases.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: venus: hfi: add check to handle incorrect queue size<br /> <br /> qsize represents size of shared queued between driver and video<br /> firmware. Firmware can modify this value to an invalid large value. In<br /> such situation, empty_space will be bigger than the space actually<br /> available. Since new_wr_idx is not checked, so the following code will<br /> result in an OOB write.<br /> ...<br /> qsize = qhdr-&gt;q_size<br /> <br /> if (wr_idx &gt;= rd_idx)<br /> empty_space = qsize - (wr_idx - rd_idx)<br /> ....<br /> if (new_wr_idx

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: venus: hfi_parser: add check to avoid out of bound access<br /> <br /> There is a possibility that init_codecs is invoked multiple times during<br /> manipulated payload from video firmware. In such case, if codecs_count<br /> can get incremented to value more than MAX_CODEC_NUM, there can be OOB<br /> access. Reset the count so that it always starts from beginning.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: venus: hfi_parser: refactor hfi packet parsing logic<br /> <br /> words_count denotes the number of words in total payload, while data<br /> points to payload of various property within it. When words_count<br /> reaches last word, data can access memory beyond the total payload. This<br /> can lead to OOB access. With this patch, the utility api for handling<br /> individual properties now returns the size of data consumed. Accordingly<br /> remaining bytes are calculated before parsing the payload, thereby<br /> eliminates the OOB access possibilities.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bus: mhi: host: Fix race between unprepare and queue_buf<br /> <br /> A client driver may use mhi_unprepare_from_transfer() to quiesce<br /> incoming data during the client driver&amp;#39;s tear down. The client driver<br /> might also be processing data at the same time, resulting in a call to<br /> mhi_queue_buf() which will invoke mhi_gen_tre(). If mhi_gen_tre() runs<br /> after mhi_unprepare_from_transfer() has torn down the channel, a panic<br /> will occur due to an invalid dereference leading to a page fault.<br /> <br /> This occurs because mhi_gen_tre() does not verify the channel state<br /> after locking it. Fix this by having mhi_gen_tre() confirm the channel<br /> state is valid, or return error to avoid accessing deinitialized data.<br /> <br /> [mani: added stable tag]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> arm/crc-t10dif: fix use of out-of-scope array in crc_t10dif_arch()<br /> <br /> Fix a silly bug where an array was used outside of its scope.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> io_uring/net: fix io_req_post_cqe abuse by send bundle<br /> <br /> [ 114.987980][ T5313] WARNING: CPU: 6 PID: 5313 at io_uring/io_uring.c:872 io_req_post_cqe+0x12e/0x4f0<br /> [ 114.991597][ T5313] RIP: 0010:io_req_post_cqe+0x12e/0x4f0<br /> [ 115.001880][ T5313] Call Trace:<br /> [ 115.002222][ T5313] <br /> [ 115.007813][ T5313] io_send+0x4fe/0x10f0<br /> [ 115.009317][ T5313] io_issue_sqe+0x1a6/0x1740<br /> [ 115.012094][ T5313] io_wq_submit_work+0x38b/0xed0<br /> [ 115.013223][ T5313] io_worker_handle_work+0x62a/0x1600<br /> [ 115.013876][ T5313] io_wq_worker+0x34f/0xdf0<br /> <br /> As the comment states, io_req_post_cqe() should only be used by<br /> multishot requests, i.e. REQ_F_APOLL_MULTISHOT, which bundled sends are<br /> not. Add a flag signifying whether a request wants to post multiple<br /> CQEs. Eventually REQ_F_APOLL_MULTISHOT should imply the new flag, but<br /> that&amp;#39;s left out for simplicity.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> arm64/crc-t10dif: fix use of out-of-scope array in crc_t10dif_arch()<br /> <br /> Fix a silly bug where an array was used outside of its scope.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: mediatek: vcodec: Fix a resource leak related to the scp device in FW initialization<br /> <br /> On Mediatek devices with a system companion processor (SCP) the mtk_scp<br /> structure has to be removed explicitly to avoid a resource leak.<br /> Free the structure in case the allocation of the firmware structure fails<br /> during the firmware initialization.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: stmmac: Fix accessing freed irq affinity_hint<br /> <br /> In stmmac_request_irq_multi_msi(), a pointer to the stack variable<br /> cpu_mask is passed to irq_set_affinity_hint(). This value is stored in<br /> irq_desc-&gt;affinity_hint, but once stmmac_request_irq_multi_msi()<br /> returns, the pointer becomes dangling.<br /> <br /> The affinity_hint is exposed via procfs with S_IRUGO permissions,<br /> allowing any unprivileged process to read it. Accessing this stale<br /> pointer can lead to:<br /> <br /> - a kernel oops or panic if the referenced memory has been released and<br /> unmapped, or<br /> - leakage of kernel data into userspace if the memory is re-used for<br /> other purposes.<br /> <br /> All platforms that use stmmac with PCI MSI (Intel, Loongson, etc) are<br /> affected.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: fix off-by-one error in do_split<br /> <br /> Syzkaller detected a use-after-free issue in ext4_insert_dentry that was<br /> caused by out-of-bounds access due to incorrect splitting in do_split.<br /> <br /> BUG: KASAN: use-after-free in ext4_insert_dentry+0x36a/0x6d0 fs/ext4/namei.c:2109<br /> Write of size 251 at addr ffff888074572f14 by task syz-executor335/5847<br /> <br /> CPU: 0 UID: 0 PID: 5847 Comm: syz-executor335 Not tainted 6.12.0-rc6-syzkaller-00318-ga9cda7c0ffed #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/30/2024<br /> Call Trace:<br /> <br /> __dump_stack lib/dump_stack.c:94 [inline]<br /> dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120<br /> print_address_description mm/kasan/report.c:377 [inline]<br /> print_report+0x169/0x550 mm/kasan/report.c:488<br /> kasan_report+0x143/0x180 mm/kasan/report.c:601<br /> kasan_check_range+0x282/0x290 mm/kasan/generic.c:189<br /> __asan_memcpy+0x40/0x70 mm/kasan/shadow.c:106<br /> ext4_insert_dentry+0x36a/0x6d0 fs/ext4/namei.c:2109<br /> add_dirent_to_buf+0x3d9/0x750 fs/ext4/namei.c:2154<br /> make_indexed_dir+0xf98/0x1600 fs/ext4/namei.c:2351<br /> ext4_add_entry+0x222a/0x25d0 fs/ext4/namei.c:2455<br /> ext4_add_nondir+0x8d/0x290 fs/ext4/namei.c:2796<br /> ext4_symlink+0x920/0xb50 fs/ext4/namei.c:3431<br /> vfs_symlink+0x137/0x2e0 fs/namei.c:4615<br /> do_symlinkat+0x222/0x3a0 fs/namei.c:4641<br /> __do_sys_symlink fs/namei.c:4662 [inline]<br /> __se_sys_symlink fs/namei.c:4660 [inline]<br /> __x64_sys_symlink+0x7a/0x90 fs/namei.c:4660<br /> do_syscall_x64 arch/x86/entry/common.c:52 [inline]<br /> do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> <br /> The following loop is located right above &amp;#39;if&amp;#39; statement.<br /> <br /> for (i = count-1; i &gt;= 0; i--) {<br /> /* is more than half of this entry in 2nd half of the block? */<br /> if (size + map[i].size/2 &gt; blocksize/2)<br /> break;<br /> size += map[i].size;<br /> move++;<br /> }<br /> <br /> &amp;#39;i&amp;#39; in this case could go down to -1, in which case sum of active entries<br /> wouldn&amp;#39;t exceed half the block size, but previous behaviour would also do<br /> split in half if sum would exceed at the very last block, which in case of<br /> having too many long name files in a single block could lead to<br /> out-of-bounds access and following use-after-free.<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with Syzkaller.