Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xfs: fix freemap adjustments when adding xattrs to leaf blocks<br /> <br /> xfs/592 and xfs/794 both trip this assertion in the leaf block freemap<br /> adjustment code after ~20 minutes of running on my test VMs:<br /> <br /> ASSERT(ichdr-&gt;firstused &gt;= ichdr-&gt;count * sizeof(xfs_attr_leaf_entry_t)<br /> + xfs_attr3_leaf_hdr_size(leaf));<br /> <br /> Upon enabling quite a lot more debugging code, I narrowed this down to<br /> fsstress trying to set a local extended attribute with namelen=3 and<br /> valuelen=71. This results in an entry size of 80 bytes.<br /> <br /> At the start of xfs_attr3_leaf_add_work, the freemap looks like this:<br /> <br /> i 0 base 448 size 0 rhs 448 count 46<br /> i 1 base 388 size 132 rhs 448 count 46<br /> i 2 base 2120 size 4 rhs 448 count 46<br /> firstused = 520<br /> <br /> where "rhs" is the first byte past the end of the leaf entry array.<br /> This is inconsistent -- the entries array ends at byte 448, but<br /> freemap[1] says there&amp;#39;s free space starting at byte 388!<br /> <br /> By the end of the function, the freemap is in worse shape:<br /> <br /> i 0 base 456 size 0 rhs 456 count 47<br /> i 1 base 388 size 52 rhs 456 count 47<br /> i 2 base 2120 size 4 rhs 456 count 47<br /> firstused = 440<br /> <br /> Important note: 388 is not aligned with the entries array element size<br /> of 8 bytes.<br /> <br /> Based on the incorrect freemap, the name area starts at byte 440, which<br /> is below the end of the entries array! That&amp;#39;s why the assertion<br /> triggers and the filesystem shuts down.<br /> <br /> How did we end up here? First, recall from the previous patch that the<br /> freemap array in an xattr leaf block is not intended to be a<br /> comprehensive map of all free space in the leaf block. In other words,<br /> it&amp;#39;s perfectly legal to have a leaf block with:<br /> <br /> * 376 bytes in use by the entries array<br /> * freemap[0] has [base = 376, size = 8]<br /> * freemap[1] has [base = 388, size = 1500]<br /> * the space between 376 and 388 is free, but the freemap stopped<br /> tracking that some time ago<br /> <br /> If we add one xattr, the entries array grows to 384 bytes, and<br /> freemap[0] becomes [base = 384, size = 0]. So far, so good. But if we<br /> add a second xattr, the entries array grows to 392 bytes, and freemap[0]<br /> gets pushed up to [base = 392, size = 0]. This is bad, because<br /> freemap[1] hasn&amp;#39;t been updated, and now the entries array and the free<br /> space claim the same space.<br /> <br /> The fix here is to adjust all freemap entries so that none of them<br /> collide with the entries array. Note that this fix relies on commit<br /> 2a2b5932db6758 ("xfs: fix attr leaf header freemap.size underflow") and<br /> the previous patch that resets zero length freemap entries to have<br /> base = 0.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> HID: hid-pl: handle probe errors<br /> <br /> Errors in init must be reported back or we&amp;#39;ll<br /> follow a NULL pointer the first time FF is used.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Revert "media: iris: Add sanity check for stop streaming"<br /> <br /> This reverts commit ad699fa78b59241c9d71a8cafb51525f3dab04d4.<br /> <br /> Revert the check that skipped stop_streaming when the instance was in<br /> IRIS_INST_ERROR, as it caused multiple regressions:<br /> <br /> 1. Buffers were not returned to vb2 when the instance was already in<br /> error state, triggering warnings in the vb2 core because buffer<br /> completion was skipped.<br /> <br /> 2. If a session failed early (e.g. unsupported configuration), the<br /> instance transitioned to IRIS_INST_ERROR. When userspace attempted<br /> to stop streaming for cleanup, stop_streaming was skipped due to the<br /> added check, preventing proper teardown and leaving the firmware<br /> in an inconsistent state.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> perf/arm-cmn: Reject unsupported hardware configurations<br /> <br /> So far we&amp;#39;ve been fairly lax about accepting both unknown CMN models<br /> (at least with a warning), and unknown revisions of those which we<br /> do know, as although things do frequently change between releases,<br /> typically enough remains the same to be somewhat useful for at least<br /> some basic bringup checks. However, we also make assumptions of the<br /> maximum supported sizes and numbers of things in various places, and<br /> there&amp;#39;s no guarantee that something new might not be bigger and lead<br /> to nasty array overflows. Make sure we only try to run on things that<br /> actually match our assumptions and so will not risk memory corruption.<br /> <br /> We have at least always failed on completely unknown node types, so<br /> update that error message for clarity and consistency too.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: wan/fsl_ucc_hdlc: Fix dma_free_coherent() in uhdlc_memclean()<br /> <br /> The priv-&gt;rx_buffer and priv-&gt;tx_buffer are alloc&amp;#39;d together as<br /> contiguous buffers in uhdlc_init() but freed as two buffers in<br /> uhdlc_memclean().<br /> <br /> Change the cleanup to only call dma_free_coherent() once on the whole<br /> buffer.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> powerpc/smp: Add check for kcalloc() failure in parse_thread_groups()<br /> <br /> As kcalloc() may fail, check its return value to avoid a NULL pointer<br /> dereference when passing it to of_property_read_u32_array().

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 /> 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.