Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xfs: remove xfs_attr_leaf_hasname<br /> <br /> The calling convention of xfs_attr_leaf_hasname() is problematic, because<br /> it returns a NULL buffer when xfs_attr3_leaf_read fails, a valid buffer<br /> when xfs_attr3_leaf_lookup_int returns -ENOATTR or -EEXIST, and a<br /> non-NULL buffer pointer for an already released buffer when<br /> xfs_attr3_leaf_lookup_int fails with other error values.<br /> <br /> Fix this by simply open coding xfs_attr_leaf_hasname in the callers, so<br /> that the buffer release code is done by each caller of<br /> xfs_attr3_leaf_read.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> octeontx2-af: CGX: fix bitmap leaks<br /> <br /> The RX/TX flow-control bitmaps (rx_fc_pfvf_bmap and tx_fc_pfvf_bmap)<br /> are allocated by cgx_lmac_init() but never freed in cgx_lmac_exit().<br /> Unbinding and rebinding the driver therefore triggers kmemleak:<br /> <br /> unreferenced object (size 16):<br /> backtrace:<br /> rvu_alloc_bitmap<br /> cgx_probe<br /> <br /> Free both bitmaps during teardown.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: usb: pegasus: enable basic endpoint checking<br /> <br /> pegasus_probe() fills URBs with hardcoded endpoint pipes without<br /> verifying the endpoint descriptors:<br /> <br /> - usb_rcvbulkpipe(dev, 1) for RX data<br /> - usb_sndbulkpipe(dev, 2) for TX data<br /> - usb_rcvintpipe(dev, 3) for status interrupts<br /> <br /> A malformed USB device can present these endpoints with transfer types<br /> that differ from what the driver assumes.<br /> <br /> Add a pegasus_usb_ep enum for endpoint numbers, replacing magic<br /> constants throughout. Add usb_check_bulk_endpoints() and<br /> usb_check_int_endpoints() calls before any resource allocation to<br /> verify endpoint types before use, rejecting devices with mismatched<br /> descriptors at probe time, and avoid triggering assertion.<br /> <br /> Similar fix to<br /> - commit 90b7f2961798 ("net: usb: rtl8150: enable basic endpoint checking")<br /> - commit 9e7021d2aeae ("net: usb: catc: enable basic endpoint checking")

*** 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().