Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cpufreq: amd-pstate: add check for cpufreq_cpu_get&amp;#39;s return value<br /> <br /> cpufreq_cpu_get may return NULL. To avoid NULL-dereference check it<br /> and return in case of error.<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with SVACE.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: Intel: soc-acpi-intel-rpl-match: add missing empty item<br /> <br /> There is no links_num in struct snd_soc_acpi_mach {}, and we test<br /> !link-&gt;num_adr as a condition to end the loop in hda_sdw_machine_select().<br /> So an empty item in struct snd_soc_acpi_link_adr array is required.

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 /> ext4: fix access to uninitialised lock in fc replay path<br /> <br /> The following kernel trace can be triggered with fstest generic/629 when<br /> executed against a filesystem with fast-commit feature enabled:<br /> <br /> INFO: trying to register non-static key.<br /> The code is fine but needs lockdep annotation, or maybe<br /> you didn&amp;#39;t initialize this object before use?<br /> turning off the locking correctness validator.<br /> CPU: 0 PID: 866 Comm: mount Not tainted 6.10.0+ #11<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-3-gd478f380-prebuilt.qemu.org 04/01/2014<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x66/0x90<br /> register_lock_class+0x759/0x7d0<br /> __lock_acquire+0x85/0x2630<br /> ? __find_get_block+0xb4/0x380<br /> lock_acquire+0xd1/0x2d0<br /> ? __ext4_journal_get_write_access+0xd5/0x160<br /> _raw_spin_lock+0x33/0x40<br /> ? __ext4_journal_get_write_access+0xd5/0x160<br /> __ext4_journal_get_write_access+0xd5/0x160<br /> ext4_reserve_inode_write+0x61/0xb0<br /> __ext4_mark_inode_dirty+0x79/0x270<br /> ? ext4_ext_replay_set_iblocks+0x2f8/0x450<br /> ext4_ext_replay_set_iblocks+0x330/0x450<br /> ext4_fc_replay+0x14c8/0x1540<br /> ? jread+0x88/0x2e0<br /> ? rcu_is_watching+0x11/0x40<br /> do_one_pass+0x447/0xd00<br /> jbd2_journal_recover+0x139/0x1b0<br /> jbd2_journal_load+0x96/0x390<br /> ext4_load_and_init_journal+0x253/0xd40<br /> ext4_fill_super+0x2cc6/0x3180<br /> ...<br /> <br /> In the replay path there&amp;#39;s an attempt to lock sbi-&gt;s_bdev_wb_lock in<br /> function ext4_check_bdev_write_error(). Unfortunately, at this point this<br /> spinlock has not been initialized yet. Moving it&amp;#39;s initialization to an<br /> earlier point in __ext4_fill_super() fixes this splat.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Fix system hang while resume with TBT monitor<br /> <br /> [Why]<br /> Connected with a Thunderbolt monitor and do the suspend and the system<br /> may hang while resume.<br /> <br /> The TBT monitor HPD will be triggered during the resume procedure<br /> and call the drm_client_modeset_probe() while<br /> struct drm_connector connector-&gt;dev-&gt;master is NULL.<br /> <br /> It will mess up the pipe topology after resume.<br /> <br /> [How]<br /> Skip the TBT monitor HPD during the resume procedure because we<br /> currently will probe the connectors after resume by default.<br /> <br /> (cherry picked from commit 453f86a26945207a16b8f66aaed5962dc2b95b85)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: fix i_data_sem unlock order in ext4_ind_migrate()<br /> <br /> Fuzzing reports a possible deadlock in jbd2_log_wait_commit.<br /> <br /> This issue is triggered when an EXT4_IOC_MIGRATE ioctl is set to require<br /> synchronous updates because the file descriptor is opened with O_SYNC.<br /> This can lead to the jbd2_journal_stop() function calling<br /> jbd2_might_wait_for_commit(), potentially causing a deadlock if the<br /> EXT4_IOC_MIGRATE call races with a write(2) system call.<br /> <br /> This problem only arises when CONFIG_PROVE_LOCKING is enabled. In this<br /> case, the jbd2_might_wait_for_commit macro locks jbd2_handle in the<br /> jbd2_journal_stop function while i_data_sem is locked. This triggers<br /> lockdep because the jbd2_journal_start function might also lock the same<br /> jbd2_handle simultaneously.<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with syzkaller.<br /> <br /> Rule: add

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: asihpi: Fix potential OOB array access<br /> <br /> ASIHPI driver stores some values in the static array upon a response<br /> from the driver, and its index depends on the firmware. We shouldn&amp;#39;t<br /> trust it blindly.<br /> <br /> This patch adds a sanity check of the array index to fit in the array<br /> size.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mwifiex: Fix memcpy() field-spanning write warning in mwifiex_cmd_802_11_scan_ext()<br /> <br /> Replace one-element array with a flexible-array member in<br /> `struct host_cmd_ds_802_11_scan_ext`.<br /> <br /> With this, fix the following warning:<br /> <br /> elo 16 17:51:58 surfacebook kernel: ------------[ cut here ]------------<br /> elo 16 17:51:58 surfacebook kernel: memcpy: detected field-spanning write (size 243) of single field "ext_scan-&gt;tlv_buffer" at drivers/net/wireless/marvell/mwifiex/scan.c:2239 (size 1)<br /> elo 16 17:51:58 surfacebook kernel: WARNING: CPU: 0 PID: 498 at drivers/net/wireless/marvell/mwifiex/scan.c:2239 mwifiex_cmd_802_11_scan_ext+0x83/0x90 [mwifiex]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> exec: don&amp;#39;t WARN for racy path_noexec check<br /> <br /> Both i_mode and noexec checks wrapped in WARN_ON stem from an artifact<br /> of the previous implementation. They used to legitimately check for the<br /> condition, but that got moved up in two commits:<br /> 633fb6ac3980 ("exec: move S_ISREG() check earlier")<br /> 0fd338b2d2cd ("exec: move path_noexec() check earlier")<br /> <br /> Instead of being removed said checks are WARN_ON&amp;#39;ed instead, which<br /> has some debug value.<br /> <br /> However, the spurious path_noexec check is racy, resulting in<br /> unwarranted warnings should someone race with setting the noexec flag.<br /> <br /> One can note there is more to perm-checking whether execve is allowed<br /> and none of the conditions are guaranteed to still hold after they were<br /> tested for.<br /> <br /> Additionally this does not validate whether the code path did any perm<br /> checking to begin with -- it will pass if the inode happens to be<br /> regular.<br /> <br /> Keep the redundant path_noexec() check even though it&amp;#39;s mindless<br /> nonsense checking for guarantee that isn&amp;#39;t given so drop the WARN.<br /> <br /> Reword the commentary and do small tidy ups while here.<br /> <br /> [brauner: keep redundant path_noexec() check]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cpufreq: Avoid a bad reference count on CPU node<br /> <br /> In the parse_perf_domain function, if the call to<br /> of_parse_phandle_with_args returns an error, then the reference to the<br /> CPU device node that was acquired at the start of the function would not<br /> be properly decremented.<br /> <br /> Address this by declaring the variable with the __free(device_node)<br /> cleanup attribute.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> exfat: fix memory leak in exfat_load_bitmap()<br /> <br /> If the first directory entry in the root directory is not a bitmap<br /> directory entry, &amp;#39;bh&amp;#39; will not be released and reassigned, which<br /> will cause a memory leak.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: dax: fix overflowing extents beyond inode size when partially writing<br /> <br /> The dax_iomap_rw() does two things in each iteration: map written blocks<br /> and copy user data to blocks. If the process is killed by user(See signal<br /> handling in dax_iomap_iter()), the copied data will be returned and added<br /> on inode size, which means that the length of written extents may exceed<br /> the inode size, then fsck will fail. An example is given as:<br /> <br /> dd if=/dev/urandom of=file bs=4M count=1<br /> dax_iomap_rw<br /> iomap_iter // round 1<br /> ext4_iomap_begin<br /> ext4_iomap_alloc // allocate 0~2M extents(written flag)<br /> dax_iomap_iter // copy 2M data<br /> iomap_iter // round 2<br /> iomap_iter_advance<br /> iter-&gt;pos += iter-&gt;processed // iter-&gt;pos = 2M<br /> ext4_iomap_begin<br /> ext4_iomap_alloc // allocate 2~4M extents(written flag)<br /> dax_iomap_iter<br /> fatal_signal_pending<br /> done = iter-&gt;pos - iocb-&gt;ki_pos // done = 2M<br /> ext4_handle_inode_extension<br /> ext4_update_inode_size // inode size = 2M<br /> <br /> fsck reports: Inode 13, i_size is 2097152, should be 4194304. Fix?<br /> <br /> Fix the problem by truncating extents if the written length is smaller<br /> than expected.