Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: iwlwifi: mvm: fix potential out-of-bounds read in iwl_mvm_nd_match_info_handler()<br /> <br /> The memcpy function assumes the dynamic array notif-&gt;matches is at least<br /> as large as the number of bytes to copy. Otherwise, results-&gt;matches may<br /> contain unwanted data. To guarantee safety, extend the validation in one<br /> of the checks to ensure sufficient packet length.<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with SVACE.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: caiaq: fix stack out-of-bounds read in init_card<br /> <br /> The loop creates a whitespace-stripped copy of the card shortname<br /> where `len id)` is used for the bounds check. Since<br /> sizeof(card-&gt;id) is 16 and the local id buffer is also 16 bytes,<br /> writing 16 non-space characters fills the entire buffer,<br /> overwriting the terminating nullbyte.<br /> <br /> When this non-null-terminated string is later passed to<br /> snd_card_set_id() -&gt; copy_valid_id_string(), the function scans<br /> forward with `while (*nid &amp;&amp; ...)` and reads past the end of the<br /> stack buffer, reading the contents of the stack.<br /> <br /> A USB device with a product name containing many non-ASCII, non-space<br /> characters (e.g. multibyte UTF-8) will reliably trigger this as follows:<br /> <br /> BUG: KASAN: stack-out-of-bounds in copy_valid_id_string<br /> sound/core/init.c:696 [inline]<br /> BUG: KASAN: stack-out-of-bounds in snd_card_set_id_no_lock+0x698/0x74c<br /> sound/core/init.c:718<br /> <br /> The off-by-one has been present since commit bafeee5b1f8d ("ALSA:<br /> snd_usb_caiaq: give better shortname") from June 2009 (v2.6.31-rc1),<br /> which first introduced this whitespace-stripping loop. The original<br /> code never accounted for the null terminator when bounding the copy.<br /> <br /> Fix this by changing the loop bound to `sizeof(card-&gt;id) - 1`,<br /> ensuring at least one byte remains as the null terminator.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> spi: amlogic: spifc-a4: unregister ECC engine on probe failure and remove() callback<br /> <br /> aml_sfc_probe() registers the on-host NAND ECC engine, but teardown was<br /> missing from both probe unwind and remove-time cleanup. Add a devm cleanup<br /> action after successful registration so<br /> nand_ecc_unregister_on_host_hw_engine() runs automatically on probe<br /> failures and during device removal.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> perf/x86: Fix potential bad container_of in intel_pmu_hw_config<br /> <br /> Auto counter reload may have a group of events with software events<br /> present within it. The software event PMU isn&amp;#39;t the x86_hybrid_pmu and<br /> a container_of operation in intel_pmu_set_acr_caused_constr (via the<br /> hybrid helper) could cause out of bound memory reads. Avoid this by<br /> guarding the call to intel_pmu_set_acr_caused_constr with an<br /> is_x86_event check.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/ioc32: stop speculation on the drm_compat_ioctl path<br /> <br /> The drm compat ioctl path takes a user controlled pointer, and then<br /> dereferences it into a table of function pointers, the signature method<br /> of spectre problems. Fix this up by calling array_index_nospec() on the<br /> index to the function pointer list.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: wilc1000: fix u8 overflow in SSID scan buffer size calculation<br /> <br /> The variable valuesize is declared as u8 but accumulates the total<br /> length of all SSIDs to scan. Each SSID contributes up to 33 bytes<br /> (IEEE80211_MAX_SSID_LEN + 1), and with WILC_MAX_NUM_PROBED_SSID (10)<br /> SSIDs the total can reach 330, which wraps around to 74 when stored<br /> in a u8.<br /> <br /> This causes kmalloc to allocate only 75 bytes while the subsequent<br /> memcpy writes up to 331 bytes into the buffer, resulting in a 256-byte<br /> heap buffer overflow.<br /> <br /> Widen valuesize from u8 to u32 to accommodate the full range.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/xe/pxp: Clear restart flag in pxp_start after jumping back<br /> <br /> If we don&amp;#39;t clear the flag we&amp;#39;ll keep jumping back at the beginning of<br /> the function once we reach the end.<br /> <br /> (cherry picked from commit 0850ec7bb2459602351639dccf7a68a03c9d1ee0)

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: ctxfi: Fix missing SPDIFI1 index handling<br /> <br /> SPDIF1 DAIO type isn&amp;#39;t properly handled in daio_device_index() for<br /> hw20k2, and it returned -EINVAL, which ended up with the out-of-bounds<br /> array access. Follow the hw20k1 pattern and return the proper index<br /> for this type, too.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: ctxfi: Don&amp;#39;t enumerate SPDIF1 at DAIO initialization<br /> <br /> The recent refactoring of xfi driver changed the assignment of<br /> atc-&gt;daios[] at atc_get_resources(); now it loops over all enum<br /> DAIOTYP entries while it looped formerly only a part of them.<br /> The problem is that the last entry, SPDIF1, is a special type that<br /> is used only for hw20k1 CTSB073X model (as a replacement of SPDIFIO),<br /> and there is no corresponding definition for hw20k2. Due to the lack<br /> of the info, it caused a kernel crash on hw20k2, which was already<br /> worked around by the commit b045ab3dff97 ("ALSA: ctxfi: Fix missing<br /> SPDIFI1 index handling").<br /> <br /> This patch addresses the root cause of the regression above properly,<br /> simply by skipping the incorrect SPDIF1 type in the parser loop.<br /> <br /> For making the change clearer, the code is slightly arranged, too.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> io_uring/net: fix slab-out-of-bounds read in io_bundle_nbufs()<br /> <br /> sqe-&gt;len is __u32 but gets stored into sr-&gt;len which is int. When<br /> userspace passes sqe-&gt;len values exceeding INT_MAX (e.g. 0xFFFFFFFF),<br /> sr-&gt;len overflows to a negative value. This negative value propagates<br /> through the bundle recv/send path:<br /> <br /> 1. io_recv(): sel.val = sr-&gt;len (ssize_t gets -1)<br /> 2. io_recv_buf_select(): arg.max_len = sel-&gt;val (size_t gets<br /> 0xFFFFFFFFFFFFFFFF)<br /> 3. io_ring_buffers_peek(): buf-&gt;len is not clamped because max_len<br /> is astronomically large<br /> 4. iov[].iov_len = 0xFFFFFFFF flows into io_bundle_nbufs()<br /> 5. io_bundle_nbufs(): min_t(int, 0xFFFFFFFF, ret) yields -1,<br /> causing ret to increase instead of decrease, creating an<br /> infinite loop that reads past the allocated iov[] array<br /> <br /> This results in a slab-out-of-bounds read in io_bundle_nbufs() from<br /> the kmalloc-64 slab, as nbufs increments past the allocated iovec<br /> entries.<br /> <br /> BUG: KASAN: slab-out-of-bounds in io_bundle_nbufs+0x128/0x160<br /> Read of size 8 at addr ffff888100ae05c8 by task exp/145<br /> Call Trace:<br /> io_bundle_nbufs+0x128/0x160<br /> io_recv_finish+0x117/0xe20<br /> io_recv+0x2db/0x1160<br /> <br /> Fix this by rejecting negative sr-&gt;len values early in both<br /> io_sendmsg_prep() and io_recvmsg_prep(). Since sqe-&gt;len is __u32,<br /> any value &gt; INT_MAX indicates overflow and is not a valid length.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> gpib: fix use-after-free in IO ioctl handlers<br /> <br /> The IBRD, IBWRT, IBCMD, and IBWAIT ioctl handlers use a gpib_descriptor<br /> pointer after board-&gt;big_gpib_mutex has been released. A concurrent<br /> IBCLOSEDEV ioctl can free the descriptor via close_dev_ioctl() during<br /> this window, causing a use-after-free.<br /> <br /> The IO handlers (read_ioctl, write_ioctl, command_ioctl) explicitly<br /> release big_gpib_mutex before calling their handler. wait_ioctl() is<br /> called with big_gpib_mutex held, but ibwait() releases it internally<br /> when wait_mask is non-zero. In all four cases, the descriptor pointer<br /> obtained from handle_to_descriptor() becomes unprotected.<br /> <br /> Fix this by introducing a kernel-only descriptor_busy reference count<br /> in struct gpib_descriptor. Each handler atomically increments<br /> descriptor_busy under file_priv-&gt;descriptors_mutex before releasing the<br /> lock, and decrements it when done. close_dev_ioctl() checks<br /> descriptor_busy under the same lock and rejects the close with -EBUSY<br /> if the count is non-zero.<br /> <br /> A reference count rather than a simple flag is necessary because<br /> multiple handlers can operate on the same descriptor concurrently<br /> (e.g. IBRD and IBWAIT on the same handle from different threads).<br /> <br /> A separate counter is needed because io_in_progress can be cleared from<br /> unprivileged userspace via the IBWAIT ioctl (through general_ibstatus()<br /> with set_mask containing CMPL), which would allow an attacker to bypass<br /> a check based solely on io_in_progress. The new descriptor_busy<br /> counter is only modified by the kernel IO paths.<br /> <br /> The lock ordering is consistent (big_gpib_mutex -&gt; descriptors_mutex)<br /> and the handlers only hold descriptors_mutex briefly during the lookup,<br /> so there is no deadlock risk and no impact on IO throughput.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> hwmon: (occ) Fix division by zero in occ_show_power_1()<br /> <br /> In occ_show_power_1() case 1, the accumulator is divided by<br /> update_tag without checking for zero. If no samples have been<br /> collected yet (e.g. during early boot when the sensor block is<br /> included but hasn&amp;#39;t been updated), update_tag is zero, causing<br /> a kernel divide-by-zero crash.<br /> <br /> The 2019 fix in commit 211186cae14d ("hwmon: (occ) Fix division by<br /> zero issue") only addressed occ_get_powr_avg() used by<br /> occ_show_power_2() and occ_show_power_a0(). This separate code<br /> path in occ_show_power_1() was missed.<br /> <br /> Fix this by reusing the existing occ_get_powr_avg() helper, which<br /> already handles the zero-sample case and uses mul_u64_u32_div()<br /> to multiply before dividing for better precision. Move the helper<br /> above occ_show_power_1() so it is visible at the call site.<br /> <br /> [groeck: Fix alignment problems reported by checkpatch]