Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: mediatek: mt8365-dai-i2s: pass correct size to mt8365_dai_set_priv<br /> <br /> Given mt8365_dai_set_priv allocate priv_size space to copy priv_data which<br /> means we should pass mt8365_i2s_priv[i] or "struct mtk_afe_i2s_priv"<br /> instead of afe_priv which has the size of "struct mt8365_afe_private".<br /> <br /> Otherwise the KASAN complains about.<br /> <br /> [ 59.389765] BUG: KASAN: global-out-of-bounds in mt8365_dai_set_priv+0xc8/0x168 [snd_soc_mt8365_pcm]<br /> ...<br /> [ 59.394789] Call trace:<br /> [ 59.395167] dump_backtrace+0xa0/0x128<br /> [ 59.395733] show_stack+0x20/0x38<br /> [ 59.396238] dump_stack_lvl+0xe8/0x148<br /> [ 59.396806] print_report+0x37c/0x5e0<br /> [ 59.397358] kasan_report+0xac/0xf8<br /> [ 59.397885] kasan_check_range+0xe8/0x190<br /> [ 59.398485] asan_memcpy+0x3c/0x98<br /> [ 59.399022] mt8365_dai_set_priv+0xc8/0x168 [snd_soc_mt8365_pcm]<br /> [ 59.399928] mt8365_dai_i2s_register+0x1e8/0x2b0 [snd_soc_mt8365_pcm]<br /> [ 59.400893] mt8365_afe_pcm_dev_probe+0x4d0/0xdf0 [snd_soc_mt8365_pcm]<br /> [ 59.401873] platform_probe+0xcc/0x228<br /> [ 59.402442] really_probe+0x340/0x9e8<br /> [ 59.402992] driver_probe_device+0x16c/0x3f8<br /> [ 59.403638] driver_probe_device+0x64/0x1d8<br /> [ 59.404256] driver_attach+0x1dc/0x4c8<br /> [ 59.404840] bus_for_each_dev+0x100/0x190<br /> [ 59.405442] driver_attach+0x44/0x68<br /> [ 59.405980] bus_add_driver+0x23c/0x500<br /> [ 59.406550] driver_register+0xf8/0x3d0<br /> [ 59.407122] platform_driver_register+0x68/0x98<br /> [ 59.407810] mt8365_afe_pcm_driver_init+0x2c/0xff8 [snd_soc_mt8365_pcm]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> gfs2: No more self recovery<br /> <br /> When a node withdraws and it turns out that it is the only node that has<br /> the filesystem mounted, gfs2 currently tries to replay the local journal<br /> to bring the filesystem back into a consistent state. Not only is that<br /> a very bad idea, it has also never worked because gfs2_recover_func()<br /> will refuse to do anything during a withdraw.<br /> <br /> However, before even getting to this point, gfs2_recover_func()<br /> dereferences sdp-&gt;sd_jdesc-&gt;jd_inode. This was a use-after-free before<br /> commit 04133b607a78 ("gfs2: Prevent double iput for journal on error")<br /> and is a NULL pointer dereference since then.<br /> <br /> Simply get rid of self recovery to fix that.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> proc: use the same treatment to check proc_lseek as ones for proc_read_iter et.al<br /> <br /> Check pde-&gt;proc_ops-&gt;proc_lseek directly may cause UAF in rmmod scenario. <br /> It&amp;#39;s a gap in proc_reg_open() after commit 654b33ada4ab("proc: fix UAF in<br /> proc_get_inode()"). Followed by AI Viro&amp;#39;s suggestion, fix it in same<br /> manner.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: fix to avoid out-of-boundary access in devs.path<br /> <br /> - touch /mnt/f2fs/012345678901234567890123456789012345678901234567890123<br /> - truncate -s $((1024*1024*1024)) \<br /> /mnt/f2fs/012345678901234567890123456789012345678901234567890123<br /> - touch /mnt/f2fs/file<br /> - truncate -s $((1024*1024*1024)) /mnt/f2fs/file<br /> - mkfs.f2fs /mnt/f2fs/012345678901234567890123456789012345678901234567890123 \<br /> -c /mnt/f2fs/file<br /> - mount /mnt/f2fs/012345678901234567890123456789012345678901234567890123 \<br /> /mnt/f2fs/loop<br /> <br /> [16937.192225] F2FS-fs (loop0): Mount Device [ 0]: /mnt/f2fs/012345678901234567890123456789012345678901234567890123\xff\x01, 511, 0 - 3ffff<br /> [16937.192268] F2FS-fs (loop0): Failed to find devices<br /> <br /> If device path length equals to MAX_PATH_LEN, sbi-&gt;devs.path[] may<br /> not end up w/ null character due to path array is fully filled, So<br /> accidently, fields locate after path[] may be treated as part of<br /> device path, result in parsing wrong device path.<br /> <br /> struct f2fs_dev_info {<br /> ...<br /> char path[MAX_PATH_LEN];<br /> ...<br /> };<br /> <br /> Let&amp;#39;s add one byte space for sbi-&gt;devs.path[] to store null<br /> character of device path string.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> pinctrl: canaan: k230: Fix order of DT parse and pinctrl register<br /> <br /> Move DT parse before pinctrl register. This ensures that device tree<br /> parsing is done before calling devm_pinctrl_register() to prevent using<br /> uninitialized pin resources.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> pinctrl: canaan: k230: add NULL check in DT parse<br /> <br /> Add a NULL check for the return value of of_get_property() when<br /> retrieving the "pinmux" property in the group parser. This avoids<br /> a potential NULL pointer dereference if the property is missing<br /> from the device tree node.<br /> <br /> Also fix a typo ("sintenel") in the device ID match table comment,<br /> correcting it to "sentinel".

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: iwlwifi: Fix error code in iwl_op_mode_dvm_start()<br /> <br /> Preserve the error code if iwl_setup_deferred_work() fails. The current<br /> code returns ERR_PTR(0) (which is NULL) on this path. I believe the<br /> missing error code potentially leads to a use after free involving<br /> debugfs.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: rtw89: mcc: prevent shift wrapping in rtw89_core_mlsr_switch()<br /> <br /> The "link_id" value comes from the user via debugfs. If it&amp;#39;s larger<br /> than BITS_PER_LONG then that would result in shift wrapping and<br /> potentially an out of bounds access later. In fact, we can limit it<br /> to IEEE80211_MLD_MAX_NUM_LINKS (15).<br /> <br /> Fortunately, only root can write to debugfs files so the security<br /> impact is minimal.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nvmet: pci-epf: Do not complete commands twice if nvmet_req_init() fails<br /> <br /> Have nvmet_req_init() and req-&gt;execute() complete failed commands.<br /> <br /> Description of the problem:<br /> nvmet_req_init() calls __nvmet_req_complete() internally upon failure,<br /> e.g., unsupported opcode, which calls the "queue_response" callback,<br /> this results in nvmet_pci_epf_queue_response() being called, which will<br /> call nvmet_pci_epf_complete_iod() if data_len is 0 or if dma_dir is<br /> different from DMA_TO_DEVICE. This results in a double completion as<br /> nvmet_pci_epf_exec_iod_work() also calls nvmet_pci_epf_complete_iod()<br /> when nvmet_req_init() fails.<br /> <br /> Steps to reproduce:<br /> On the host send a command with an unsupported opcode with nvme-cli,<br /> For example the admin command "security receive"<br /> $ sudo nvme security-recv /dev/nvme0n1 -n1 -x4096<br /> <br /> This triggers a double completion as nvmet_req_init() fails and<br /> nvmet_pci_epf_queue_response() is called, here iod-&gt;dma_dir is still<br /> in the default state of "DMA_NONE" as set by default in<br /> nvmet_pci_epf_alloc_iod(), so nvmet_pci_epf_complete_iod() is called.<br /> Because nvmet_req_init() failed nvmet_pci_epf_complete_iod() is also<br /> called in nvmet_pci_epf_exec_iod_work() leading to a double completion.<br /> This not only sends two completions to the host but also corrupts the<br /> state of the PCI NVMe target leading to kernel oops.<br /> <br /> This patch lets nvmet_req_init() and req-&gt;execute() complete all failed<br /> commands, and removes the double completion case in<br /> nvmet_pci_epf_exec_iod_work() therefore fixing the edge cases where<br /> double completions occurred.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> hfsplus: remove mutex_lock check in hfsplus_free_extents<br /> <br /> Syzbot reported an issue in hfsplus filesystem:<br /> <br /> ------------[ cut here ]------------<br /> WARNING: CPU: 0 PID: 4400 at fs/hfsplus/extents.c:346<br /> hfsplus_free_extents+0x700/0xad0<br /> Call Trace:<br /> <br /> hfsplus_file_truncate+0x768/0xbb0 fs/hfsplus/extents.c:606<br /> hfsplus_write_begin+0xc2/0xd0 fs/hfsplus/inode.c:56<br /> cont_expand_zero fs/buffer.c:2383 [inline]<br /> cont_write_begin+0x2cf/0x860 fs/buffer.c:2446<br /> hfsplus_write_begin+0x86/0xd0 fs/hfsplus/inode.c:52<br /> generic_cont_expand_simple+0x151/0x250 fs/buffer.c:2347<br /> hfsplus_setattr+0x168/0x280 fs/hfsplus/inode.c:263<br /> notify_change+0xe38/0x10f0 fs/attr.c:420<br /> do_truncate+0x1fb/0x2e0 fs/open.c:65<br /> do_sys_ftruncate+0x2eb/0x380 fs/open.c:193<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> To avoid deadlock, Commit 31651c607151 ("hfsplus: avoid deadlock<br /> on file truncation") unlock extree before hfsplus_free_extents(),<br /> and add check wheather extree is locked in hfsplus_free_extents().<br /> <br /> However, when operations such as hfsplus_file_release,<br /> hfsplus_setattr, hfsplus_unlink, and hfsplus_get_block are executed<br /> concurrently in different files, it is very likely to trigger the<br /> WARN_ON, which will lead syzbot and xfstest to consider it as an<br /> abnormality.<br /> <br /> The comment above this warning also describes one of the easy<br /> triggering situations, which can easily trigger and cause<br /> xfstest&amp;syzbot to report errors.<br /> <br /> [task A] [task B]<br /> -&gt;hfsplus_file_release<br /> -&gt;hfsplus_file_truncate<br /> -&gt;hfs_find_init<br /> -&gt;mutex_lock<br /> -&gt;mutex_unlock<br /> -&gt;hfsplus_write_begin<br /> -&gt;hfsplus_get_block<br /> -&gt;hfsplus_file_extend<br /> -&gt;hfsplus_ext_read_extent<br /> -&gt;hfs_find_init<br /> -&gt;mutex_lock<br /> -&gt;hfsplus_free_extents<br /> WARN_ON(mutex_is_locked) !!!<br /> <br /> Several threads could try to lock the shared extents tree.<br /> And warning can be triggered in one thread when another thread<br /> has locked the tree. This is the wrong behavior of the code and<br /> we need to remove the warning.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> spi: stm32: Check for cfg availability in stm32_spi_probe<br /> <br /> The stm32_spi_probe function now includes a check to ensure that the<br /> pointer returned by of_device_get_match_data is not NULL before<br /> accessing its members. This resolves a warning where a potential NULL<br /> pointer dereference could occur when accessing cfg-&gt;has_device_mode.<br /> <br /> Before accessing the &amp;#39;has_device_mode&amp;#39; member, we verify that &amp;#39;cfg&amp;#39; is<br /> not NULL. If &amp;#39;cfg&amp;#39; is NULL, an error message is logged.<br /> <br /> This change ensures that the driver does not attempt to access<br /> configuration data if it is not available, thus preventing a potential<br /> system crash due to a NULL pointer dereference.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> arm64: dts: qcom: qcs615: fix a crash issue caused by infinite loop for Coresight<br /> <br /> An infinite loop has been created by the Coresight devices. When only a<br /> source device is enabled, the coresight_find_activated_sysfs_sink function<br /> is recursively invoked in an attempt to locate an active sink device,<br /> ultimately leading to a stack overflow and system crash. Therefore, disable<br /> the replicator1 to break the infinite loop and prevent a potential stack<br /> overflow.<br /> <br /> replicator1_out -&gt; funnel_swao_in6 -&gt; tmc_etf_swao_in -&gt; tmc_etf_swao_out<br /> | |<br /> replicator1_in replicator_swao_in<br /> | |<br /> replicator0_out1 replicator_swao_out0<br /> | |<br /> replicator0_in funnel_in1_in3<br /> | |<br /> tmc_etf_out