Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mux: mmio: fix regmap leak on probe failure<br /> <br /> The mmio regmap that may be allocated during probe is never freed.<br /> <br /> Switch to using the device managed allocator so that the regmap is<br /> released on probe failures (e.g. probe deferral) and on driver unbind.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mfd: macsmc: Initialize mutex<br /> <br /> Initialize struct apple_smc&amp;#39;s mutex in apple_smc_probe(). Using the<br /> mutex uninitialized surprisingly resulted only in occasional NULL<br /> pointer dereferences in apple_smc_read() calls from the probe()<br /> functions of sub devices.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> staging: rtl8723bs: fix null dereference in find_network<br /> <br /> The variable pwlan has the possibility of being NULL when passed into<br /> rtw_free_network_nolock() which would later dereference the variable.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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().

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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.