Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Revert "PCI/IOV: Add PCI rescan-remove locking when enabling/disabling SR-IOV"<br /> <br /> This reverts commit 05703271c3cd ("PCI/IOV: Add PCI rescan-remove locking<br /> when enabling/disabling SR-IOV"), which causes a deadlock by recursively<br /> taking pci_rescan_remove_lock when sriov_del_vfs() is called as part of<br /> pci_stop_and_remove_bus_device(). For example with the following sequence<br /> of commands:<br /> <br /> $ echo &gt; /sys/bus/pci/devices//sriov_numvfs<br /> $ echo 1 &gt; /sys/bus/pci/devices//remove<br /> <br /> A trimmed trace of the deadlock on a mlx5 device is as below:<br /> <br /> zsh/5715 is trying to acquire lock:<br /> 000002597926ef50 (pci_rescan_remove_lock){+.+.}-{3:3}, at: sriov_disable+0x34/0x140<br /> <br /> but task is already holding lock:<br /> 000002597926ef50 (pci_rescan_remove_lock){+.+.}-{3:3}, at: pci_stop_and_remove_bus_device_locked+0x24/0x80<br /> ...<br /> Call Trace:<br /> [] dump_stack_lvl+0xc0/0x110<br /> [] print_deadlock_bug+0x31e/0x330<br /> [] __lock_acquire+0x16c8/0x32f0<br /> [] lock_acquire+0x14c/0x350<br /> [] __mutex_lock_common+0xe6/0x1520<br /> [] mutex_lock_nested+0x3c/0x50<br /> [] sriov_disable+0x34/0x140<br /> [] mlx5_sriov_disable+0x50/0x80 [mlx5_core]<br /> [] remove_one+0x5e/0xf0 [mlx5_core]<br /> [] pci_device_remove+0x3c/0xa0<br /> [] device_release_driver_internal+0x18e/0x280<br /> [] pci_stop_bus_device+0x82/0xa0<br /> [] pci_stop_and_remove_bus_device_locked+0x5e/0x80<br /> [] remove_store+0x72/0x90<br /> [] kernfs_fop_write_iter+0x15a/0x200<br /> [] vfs_write+0x24c/0x300<br /> [] ksys_write+0x86/0x110<br /> [] __do_syscall+0x14c/0x400<br /> [] system_call+0x6e/0x90<br /> <br /> This alone is not a complete fix as it restores the issue the cited commit<br /> tried to solve. A new fix will be provided as a follow on.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: iris: Add buffer to list only after successful allocation<br /> <br /> Move `list_add_tail()` to after `dma_alloc_attrs()` succeeds when creating<br /> internal buffers. Previously, the buffer was enqueued in `buffers-&gt;list`<br /> before the DMA allocation. If the allocation failed, the function returned<br /> `-ENOMEM` while leaving a partially initialized buffer in the list, which<br /> could lead to inconsistent state and potential leaks.<br /> <br /> By adding the buffer to the list only after `dma_alloc_attrs()` succeeds,<br /> we ensure the list contains only valid, fully initialized buffers.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> reset: gpio: suppress bind attributes in sysfs<br /> <br /> This is a special device that&amp;#39;s created dynamically and is supposed to<br /> stay in memory forever. We also currently don&amp;#39;t have a devlink between<br /> it and the actual reset consumer. Suppress sysfs bind attributes so that<br /> user-space can&amp;#39;t unbind the device because - as of now - it will cause a<br /> use-after-free splat from any user that puts the reset control handle.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: SOF: Intel: hda: Fix NULL pointer dereference<br /> <br /> If there&amp;#39;s a mismatch between the DAI links in the machine driver and<br /> the topology, it is possible that the playback/capture widget is not<br /> set, especially in the case of loopback capture for echo reference<br /> where we use the dummy DAI link. Return the error when the widget is not<br /> set to avoid a null pointer dereference like below when the topology is<br /> broken.<br /> <br /> RIP: 0010:hda_dai_get_ops.isra.0+0x14/0xa0 [snd_sof_intel_hda_common]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mfd: core: Add locking around &amp;#39;mfd_of_node_list&amp;#39;<br /> <br /> Manipulating a list in the kernel isn&amp;#39;t safe without some sort of<br /> mutual exclusion. Add a mutex any time we access / modify<br /> &amp;#39;mfd_of_node_list&amp;#39; to prevent possible crashes.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: iris: gen1: Destroy internal buffers after FW releases<br /> <br /> After the firmware releases internal buffers, the driver was not<br /> destroying them. This left stale allocations that were no longer used,<br /> especially across resolution changes where new buffers are allocated per<br /> the updated requirements. As a result, memory was wasted until session<br /> close.<br /> <br /> Destroy internal buffers once the release response is received from the<br /> firmware.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xfrm6: fix uninitialized saddr in xfrm6_get_saddr()<br /> <br /> xfrm6_get_saddr() does not check the return value of<br /> ipv6_dev_get_saddr(). When ipv6_dev_get_saddr() fails to find a suitable<br /> source address (returns -EADDRNOTAVAIL), saddr-&gt;in6 is left<br /> uninitialized, but xfrm6_get_saddr() still returns 0 (success).<br /> <br /> This causes the caller xfrm_tmpl_resolve_one() to use the uninitialized<br /> address in xfrm_state_find(), triggering KMSAN warning:<br /> <br /> =====================================================<br /> BUG: KMSAN: uninit-value in xfrm_state_find+0x2424/0xa940<br /> xfrm_state_find+0x2424/0xa940<br /> xfrm_resolve_and_create_bundle+0x906/0x5a20<br /> xfrm_lookup_with_ifid+0xcc0/0x3770<br /> xfrm_lookup_route+0x63/0x2b0<br /> ip_route_output_flow+0x1ce/0x270<br /> udp_sendmsg+0x2ce1/0x3400<br /> inet_sendmsg+0x1ef/0x2a0<br /> __sock_sendmsg+0x278/0x3d0<br /> __sys_sendto+0x593/0x720<br /> __x64_sys_sendto+0x130/0x200<br /> x64_sys_call+0x332b/0x3e70<br /> do_syscall_64+0xd3/0xf80<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> Local variable tmp.i.i created at:<br /> xfrm_resolve_and_create_bundle+0x3e3/0x5a20<br /> xfrm_lookup_with_ifid+0xcc0/0x3770<br /> =====================================================<br /> <br /> Fix by checking the return value of ipv6_dev_get_saddr() and propagating<br /> the error.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ntb: ntb_hw_switchtec: Fix shift-out-of-bounds for 0 mw lut<br /> <br /> Number of MW LUTs depends on NTB configuration and can be set to zero,<br /> in such scenario rounddown_pow_of_two will cause undefined behaviour and<br /> should not be performed.<br /> This patch ensures that rounddown_pow_of_two is called on valid value.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> HID: magicmouse: Do not crash on missing msc-&gt;input<br /> <br /> Fake USB devices can send their own report descriptors for which the<br /> input_mapping() hook does not get called. In this case, msc-&gt;input stays NULL,<br /> leading to a crash at a later time.<br /> <br /> Detect this condition in the input_configured() hook and reject the device.<br /> <br /> This is not supposed to happen with actual magic mouse devices, but can be<br /> provoked by imposing as a magic mouse USB device.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> remoteproc: imx_rproc: Fix invalid loaded resource table detection<br /> <br /> imx_rproc_elf_find_loaded_rsc_table() may incorrectly report a loaded<br /> resource table even when the current firmware does not provide one.<br /> <br /> When the device tree contains a "rsc-table" entry, priv-&gt;rsc_table is<br /> non-NULL and denotes where a resource table would be located if one is<br /> present in memory. However, when the current firmware has no resource<br /> table, rproc-&gt;table_ptr is NULL. The function still returns<br /> priv-&gt;rsc_table, and the remoteproc core interprets this as a valid loaded<br /> resource table.<br /> <br /> Fix this by returning NULL from imx_rproc_elf_find_loaded_rsc_table() when<br /> there is no resource table for the current firmware (i.e. when<br /> rproc-&gt;table_ptr is NULL). This aligns the function&amp;#39;s semantics with the<br /> remoteproc core: a loaded resource table is only reported when a valid<br /> table_ptr exists.<br /> <br /> With this change, starting firmware without a resource table no longer<br /> triggers a crash.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: brcmfmac: Fix potential kernel oops when probe fails<br /> <br /> When probe of the sdio brcmfmac device fails for some reasons (i.e.<br /> missing firmware), the sdiodev-&gt;bus is set to error instead of NULL, thus<br /> the cleanup later in brcmf_sdio_remove() tries to free resources via<br /> invalid bus pointer. This happens because sdiodev-&gt;bus is set 2 times:<br /> first in brcmf_sdio_probe() and second time in brcmf_sdiod_probe(). Fix<br /> this by chaning the brcmf_sdio_probe() function to return the error code<br /> and set sdio-&gt;bus only there.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: nSVM: Always use vmcb01 in VMLOAD/VMSAVE emulation<br /> <br /> Commit cc3ed80ae69f ("KVM: nSVM: always use vmcb01 to for vmsave/vmload<br /> of guest state") made KVM always use vmcb01 for the fields controlled by<br /> VMSAVE/VMLOAD, but it missed updating the VMLOAD/VMSAVE emulation code<br /> to always use vmcb01.<br /> <br /> As a result, if VMSAVE/VMLOAD is executed by an L2 guest and is not<br /> intercepted by L1, KVM will mistakenly use vmcb02. Always use vmcb01<br /> instead of the current VMCB.