Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bus: fsl-mc: fix double-free on mc_dev<br /> <br /> The blamed commit tried to simplify how the deallocations are done but,<br /> in the process, introduced a double-free on the mc_dev variable.<br /> <br /> In case the MC device is a DPRC, a new mc_bus is allocated and the<br /> mc_dev variable is just a reference to one of its fields. In this<br /> circumstance, on the error path only the mc_bus should be freed.<br /> <br /> This commit introduces back the following checkpatch warning which is a<br /> false-positive.<br /> <br /> WARNING: kfree(NULL) is safe and this check is probably not required<br /> + if (mc_bus)<br /> + kfree(mc_bus);

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> virtio-pci: Fix result size returned for the admin command completion<br /> <br /> The result size returned by virtio_pci_admin_dev_parts_get() is 8 bytes<br /> larger than the actual result data size. This occurs because the<br /> result_sg_size field of the command is filled with the result length<br /> from virtqueue_get_buf(), which includes both the data size and an<br /> additional 8 bytes of status.<br /> <br /> This oversized result size causes two issues:<br /> 1. The state transferred to the destination includes 8 bytes of extra<br /> data at the end.<br /> 2. The allocated buffer in the kernel may be smaller than the returned<br /> size, leading to failures when reading beyond the allocated size.<br /> <br /> The commit fixes this by subtracting the status size from the result of<br /> virtqueue_get_buf().<br /> <br /> This fix has been tested through live migrations with virtio-net,<br /> virtio-net-transitional, and virtio-blk devices.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: btintel: Check dsbr size from EFI variable<br /> <br /> Since the size of struct btintel_dsbr is already known, we can just<br /> start there instead of querying the EFI variable size. If the final<br /> result doesn&amp;#39;t match what we expect also fail. This fixes a stack buffer<br /> overflow when the EFI variable is larger than struct btintel_dsbr.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mt76: mt7996: avoid NULL pointer dereference in mt7996_set_monitor()<br /> <br /> The function mt7996_set_monitor() dereferences phy before<br /> the NULL sanity check.<br /> <br /> Fix this to avoid NULL pointer dereference by moving the<br /> dereference after the check.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: ath12k: Fix buffer overflow in debugfs<br /> <br /> If the user tries to write more than 32 bytes then it results in memory<br /> corruption. Fortunately, this is debugfs so it&amp;#39;s limited to root users.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> perf: arm-ni: Fix missing platform_set_drvdata()<br /> <br /> Add missing platform_set_drvdata in arm_ni_probe(), otherwise<br /> calling platform_get_drvdata() in remove returns NULL.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/pp: Fix potential NULL pointer dereference in atomctrl_initialize_mc_reg_table<br /> <br /> The function atomctrl_initialize_mc_reg_table() and<br /> atomctrl_initialize_mc_reg_table_v2_2() does not check the return<br /> value of smu_atom_get_data_table(). If smu_atom_get_data_table()<br /> fails to retrieve vram_info, it returns NULL which is later<br /> dereferenced.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: eir: Fix possible crashes on eir_create_adv_data<br /> <br /> eir_create_adv_data may attempt to add EIR_FLAGS and EIR_TX_POWER<br /> without checking if that would fit.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: Fix NULL pointer deference on eir_get_service_data<br /> <br /> The len parameter is considered optional so it can be NULL so it cannot<br /> be used for skipping to next entry of EIR_SERVICE_DATA.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ptp: remove ptp-&gt;n_vclocks check logic in ptp_vclock_in_use()<br /> <br /> There is no disagreement that we should check both ptp-&gt;is_virtual_clock<br /> and ptp-&gt;n_vclocks to check if the ptp virtual clock is in use.<br /> <br /> However, when we acquire ptp-&gt;n_vclocks_mux to read ptp-&gt;n_vclocks in<br /> ptp_vclock_in_use(), we observe a recursive lock in the call trace<br /> starting from n_vclocks_store().<br /> <br /> ============================================<br /> WARNING: possible recursive locking detected<br /> 6.15.0-rc6 #1 Not tainted<br /> --------------------------------------------<br /> syz.0.1540/13807 is trying to acquire lock:<br /> ffff888035a24868 (&amp;ptp-&gt;n_vclocks_mux){+.+.}-{4:4}, at:<br /> ptp_vclock_in_use drivers/ptp/ptp_private.h:103 [inline]<br /> ffff888035a24868 (&amp;ptp-&gt;n_vclocks_mux){+.+.}-{4:4}, at:<br /> ptp_clock_unregister+0x21/0x250 drivers/ptp/ptp_clock.c:415<br /> <br /> but task is already holding lock:<br /> ffff888030704868 (&amp;ptp-&gt;n_vclocks_mux){+.+.}-{4:4}, at:<br /> n_vclocks_store+0xf1/0x6d0 drivers/ptp/ptp_sysfs.c:215<br /> <br /> other info that might help us debug this:<br /> Possible unsafe locking scenario:<br /> <br /> CPU0<br /> ----<br /> lock(&amp;ptp-&gt;n_vclocks_mux);<br /> lock(&amp;ptp-&gt;n_vclocks_mux);<br /> <br /> *** DEADLOCK ***<br /> ....<br /> ============================================<br /> <br /> The best way to solve this is to remove the logic that checks<br /> ptp-&gt;n_vclocks in ptp_vclock_in_use().<br /> <br /> The reason why this is appropriate is that any path that uses<br /> ptp-&gt;n_vclocks must unconditionally check if ptp-&gt;n_vclocks is greater<br /> than 0 before unregistering vclocks, and all functions are already<br /> written this way. And in the function that uses ptp-&gt;n_vclocks, we<br /> already get ptp-&gt;n_vclocks_mux before unregistering vclocks.<br /> <br /> Therefore, we need to remove the redundant check for ptp-&gt;n_vclocks in<br /> ptp_vclock_in_use() to prevent recursive locking.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs/fhandle.c: fix a race in call of has_locked_children()<br /> <br /> may_decode_fh() is calling has_locked_children() while holding no locks.<br /> That&amp;#39;s an oopsable race...<br /> <br /> The rest of the callers are safe since they are holding namespace_sem and<br /> are guaranteed a positive refcount on the mount in question.<br /> <br /> Rename the current has_locked_children() to __has_locked_children(), make<br /> it static and switch the fs/namespace.c users to it.<br /> <br /> Make has_locked_children() a wrapper for __has_locked_children(), calling<br /> the latter under read_seqlock_excl(&amp;mount_lock).

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: Intel: avs: Verify content returned by parse_int_array()<br /> <br /> The first element of the returned array stores its length. If it is 0,<br /> any manipulation beyond the element at index 0 ends with null-ptr-deref.