Vulnerabilities

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 /> 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 /> 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 /> 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 /> 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 /> 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 /> 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 /> iommu/vt-d: Flush dev-IOTLB only when PCIe device is accessible in scalable mode<br /> <br /> Commit 4fc82cd907ac ("iommu/vt-d: Don&amp;#39;t issue ATS Invalidation<br /> request when device is disconnected") relies on<br /> pci_dev_is_disconnected() to skip ATS invalidation for<br /> safely-removed devices, but it does not cover link-down caused<br /> by faults, which can still hard-lock the system.<br /> <br /> For example, if a VM fails to connect to the PCIe device,<br /> "virsh destroy" is executed to release resources and isolate<br /> the fault, but a hard-lockup occurs while releasing the group fd.<br /> <br /> Call Trace:<br /> qi_submit_sync<br /> qi_flush_dev_iotlb<br /> intel_pasid_tear_down_entry<br /> device_block_translation<br /> blocking_domain_attach_dev<br /> __iommu_attach_device<br /> __iommu_device_set_domain<br /> __iommu_group_set_domain_internal<br /> iommu_detach_group<br /> vfio_iommu_type1_detach_group<br /> vfio_group_detach_container<br /> vfio_group_fops_release<br /> __fput<br /> <br /> Although pci_device_is_present() is slower than<br /> pci_dev_is_disconnected(), it still takes only ~70 µs on a<br /> ConnectX-5 (8 GT/s, x2) and becomes even faster as PCIe speed<br /> and width increase.<br /> <br /> Besides, devtlb_invalidation_with_pasid() is called only in the<br /> paths below, which are far less frequent than memory map/unmap.<br /> <br /> 1. mm-struct release<br /> 2. {attach,release}_dev<br /> 3. set/remove PASID<br /> 4. dirty-tracking setup<br /> <br /> The gain in system stability far outweighs the negligible cost<br /> of using pci_device_is_present() instead of pci_dev_is_disconnected()<br /> to decide when to skip ATS invalidation, especially under GDR<br /> high-load conditions.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/pm: Fix null pointer dereference issue<br /> <br /> If SMU is disabled, during RAS initialization,<br /> there will be null pointer dereference issue here.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dm-verity: correctly handle dm_bufio_client_create() failure<br /> <br /> If either of the calls to dm_bufio_client_create() in verity_fec_ctr()<br /> fails, then dm_bufio_client_destroy() is later called with an ERR_PTR()<br /> argument. That causes a crash. Fix this.

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.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: L2CAP: Fix missing key size check for L2CAP_LE_CONN_REQ<br /> <br /> This adds a check for encryption key size upon receiving<br /> L2CAP_LE_CONN_REQ which is required by L2CAP/LE/CFC/BV-15-C which<br /> expects L2CAP_CR_LE_BAD_KEY_SIZE.