Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: update DML2 policy EnhancedPrefetchScheduleAccelerationFinal DCN35<br /> <br /> [WHY &amp; HOW]<br /> Mismatch in DCN35 DML2 cause bw validation failed to acquire unexpected DPP pipe to cause<br /> grey screen and system hang. Remove EnhancedPrefetchScheduleAccelerationFinal value override<br /> to match HW spec.<br /> <br /> (cherry picked from commit 9dad21f910fcea2bdcff4af46159101d7f9cd8ba)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mac802154: Fix potential RCU dereference issue in mac802154_scan_worker<br /> <br /> In the `mac802154_scan_worker` function, the `scan_req-&gt;type` field was<br /> accessed after the RCU read-side critical section was unlocked. According<br /> to RCU usage rules, this is illegal and can lead to unpredictable<br /> behavior, such as accessing memory that has been updated or causing<br /> use-after-free issues.<br /> <br /> This possible bug was identified using a static analysis tool developed<br /> by myself, specifically designed to detect RCU-related issues.<br /> <br /> To address this, the `scan_req-&gt;type` value is now stored in a local<br /> variable `scan_req_type` while still within the RCU read-side critical<br /> section. The `scan_req_type` is then used after the RCU lock is released,<br /> ensuring that the type value is safely accessed without violating RCU<br /> rules.

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 /> 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 /> 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: 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 /> 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]