Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fbdev: core: fbcvt: avoid division by 0 in fb_cvt_hperiod()<br /> <br /> In fb_find_mode_cvt(), iff mode-&gt;refresh somehow happens to be 0x80000000,<br /> cvt.f_refresh will become 0 when multiplying it by 2 due to overflow. It&amp;#39;s<br /> then passed to fb_cvt_hperiod(), where it&amp;#39;s used as a divider -- division<br /> by 0 will result in kernel oops. Add a sanity check for cvt.f_refresh to<br /> avoid such overflow...<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with the Svace static<br /> analysis tool.

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 /> 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 /> 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 /> 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 /> 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 /> iavf: get rid of the crit lock<br /> <br /> Get rid of the crit lock.<br /> That frees us from the error prone logic of try_locks.<br /> <br /> Thanks to netdev_lock() by Jakub it is now easy, and in most cases we were<br /> protected by it already - replace crit lock by netdev lock when it was not<br /> the case.<br /> <br /> Lockdep reports that we should cancel the work under crit_lock [splat1],<br /> and that was the scheme we have mostly followed since [1] by Slawomir.<br /> But when that is done we still got into deadlocks [splat2]. So instead<br /> we should look at the bigger problem, namely "weird locking/scheduling"<br /> of the iavf. The first step to fix that is to remove the crit lock.<br /> I will followup with a -next series that simplifies scheduling/tasks.<br /> <br /> Cancel the work without netdev lock (weird unlock+lock scheme),<br /> to fix the [splat2] (which would be totally ugly if we would kept<br /> the crit lock).<br /> <br /> Extend protected part of iavf_watchdog_task() to include scheduling<br /> more work.<br /> <br /> Note that the removed comment in iavf_reset_task() was misplaced,<br /> it belonged to inside of the removed if condition, so it&amp;#39;s gone now.<br /> <br /> [splat1] - w/o this patch - The deadlock during VF removal:<br /> WARNING: possible circular locking dependency detected<br /> sh/3825 is trying to acquire lock:<br /> ((work_completion)(&amp;(&amp;adapter-&gt;watchdog_task)-&gt;work)){+.+.}-{0:0}, at: start_flush_work+0x1a1/0x470<br /> but task is already holding lock:<br /> (&amp;adapter-&gt;crit_lock){+.+.}-{4:4}, at: iavf_remove+0xd1/0x690 [iavf]<br /> which lock already depends on the new lock.<br /> <br /> [splat2] - when cancelling work under crit lock, w/o this series,<br /> see [2] for the band aid attempt<br /> WARNING: possible circular locking dependency detected<br /> sh/3550 is trying to acquire lock:<br /> ((wq_completion)iavf){+.+.}-{0:0}, at: touch_wq_lockdep_map+0x26/0x90<br /> but task is already holding lock:<br /> (&amp;dev-&gt;lock){+.+.}-{4:4}, at: iavf_remove+0xa6/0x6e0 [iavf]<br /> which lock already depends on the new lock.<br /> <br /> [1] fc2e6b3b132a ("iavf: Rework mutexes for better synchronisation")<br /> [2] https://github.com/pkitszel/linux/commit/52dddbfc2bb60294083f5711a158a

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 /> seg6: Fix validation of nexthop addresses<br /> <br /> The kernel currently validates that the length of the provided nexthop<br /> address does not exceed the specified length. This can lead to the<br /> kernel reading uninitialized memory if user space provided a shorter<br /> length than the specified one.<br /> <br /> Fix by validating that the provided length exactly matches the specified<br /> one.

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 /> drm/xe/vm: move xe_svm_init() earlier<br /> <br /> In xe_vm_close_and_put() we need to be able to call xe_svm_fini(),<br /> however during vm creation we can call this on the error path, before<br /> having actually initialised the svm state, leading to various splats<br /> followed by a fatal NPD.<br /> <br /> (cherry picked from commit 4f296d77cf49fcb5f90b4674123ad7f3a0676165)