Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> md/raid10: fix divide-by-zero in setup_geo() with zero far_copies<br /> <br /> setup_geo() extracts near_copies (nc) and far_copies (fc) from the<br /> user-provided layout parameter without checking for zero. When fc=0<br /> with the "improved" far set layout selected, &amp;#39;geo-&gt;far_set_size =<br /> disks / fc&amp;#39; triggers a divide-by-zero.<br /> <br /> Validate nc and fc immediately after extraction, returning -1 if<br /> either is zero.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ice: fix double free in ice_sf_eth_activate() error path<br /> <br /> When auxiliary_device_add() fails, ice_sf_eth_activate() jumps to<br /> aux_dev_uninit and calls auxiliary_device_uninit(&amp;sf_dev-&gt;adev).<br /> <br /> The device release callback ice_sf_dev_release() frees sf_dev, but<br /> the current error path falls through to sf_dev_free and calls<br /> kfree(sf_dev) again, causing a double free.<br /> <br /> Keep kfree(sf_dev) for the auxiliary_device_init() failure path, but<br /> avoid falling through to sf_dev_free after auxiliary_device_uninit().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: b43legacy: enforce bounds check on firmware key index in RX path<br /> <br /> Same fix as b43: the firmware-controlled key index in b43legacy_rx()<br /> can exceed dev-&gt;max_nr_keys. The existing B43legacy_WARN_ON is<br /> non-enforcing in production builds, allowing an out-of-bounds read of<br /> dev-&gt;key[].<br /> <br /> Make the check enforcing by dropping the frame for invalid indices.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/mana: Fix error unwind in mana_ib_create_qp_rss()<br /> <br /> Sashiko points out that mana_ib_cfg_vport_steering() is leaked, the normal<br /> destroy path cleans it up.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/mana: Validate rx_hash_key_len<br /> <br /> Sashiko points out that rx_hash_key_len comes from a uAPI structure and is<br /> blindly passed to memcpy, allowing the userspace to trash kernel<br /> memory. Bounds check it so the memcpy cannot overflow.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: usb-audio: Avoid potential endless loop in convert_chmap_v3()<br /> <br /> The convert_chmap_v3() has a loop with its increment size of<br /> cs_desc-&gt;wLength, but we forgot to validate cs_desc-&gt;wLength itself,<br /> which may lead to potential endless loop by a malformed descriptor.<br /> <br /> Add a proper size check to abort the loop for plugging the hole.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: arm64: Fix pin leak and publication ordering in __pkvm_init_vcpu()<br /> <br /> Two bugs exist in the vCPU initialisation path:<br /> <br /> 1. If a check fails after hyp_pin_shared_mem() succeeds, the cleanup<br /> path jumps to &amp;#39;unlock&amp;#39; without calling unpin_host_vcpu() or<br /> unpin_host_sve_state(), permanently leaking pin references on the<br /> host vCPU and SVE state pages.<br /> <br /> Extract a register_hyp_vcpu() helper that performs the checks and<br /> the store. When register_hyp_vcpu() returns an error, call<br /> unpin_host_vcpu() and unpin_host_sve_state() inline before falling<br /> through to the existing &amp;#39;unlock&amp;#39; label.<br /> <br /> 2. register_hyp_vcpu() publishes the new vCPU pointer into<br /> &amp;#39;hyp_vm-&gt;vcpus[]&amp;#39; with a bare store, allowing a concurrent caller<br /> of pkvm_load_hyp_vcpu() to observe a partially initialised vCPU<br /> object.<br /> <br /> Ensure the store uses smp_store_release() and the load uses<br /> smp_load_acquire(). While &amp;#39;vm_table_lock&amp;#39; currently serialises the<br /> store and the load, these barriers ensure the reader sees the fully<br /> initialised &amp;#39;hyp_vcpu&amp;#39; object even if there were a lockless path or<br /> if the lock&amp;#39;s own ordering guarantees were insufficient for nested<br /> object initialization.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> spi: microchip-core-qspi: control built-in cs manually<br /> <br /> The coreQSPI IP supports only a single chip select, which is<br /> automagically operated by the hardware - set low when the transmit<br /> buffer first gets written to and set high when the number of bytes<br /> written to the TOTALBYTES field of the FRAMES register have been sent on<br /> the bus. Additional devices must use GPIOs for their chip selects.<br /> It was reported to me that if there are two devices attached to this<br /> QSPI controller that the in-built chip select is set low while linux<br /> tries to access the device attached to the GPIO.<br /> <br /> This went undetected as the boards that connected multiple devices to<br /> the SPI controller all exclusively used GPIOs for chip selects, not<br /> relying on the built-in chip select at all. It turns out that this was<br /> because the built-in chip select, when controlled automagically, is set<br /> low when active and high when inactive, thereby ruling out its use for<br /> active-high devices or devices that need to transmit with the chip<br /> select disabled.<br /> <br /> Modify the driver so that it controls chip select directly, retaining<br /> the behaviour for mem_ops of setting the chip select active for the<br /> entire duration of the transfer in the exec_op callback. For regular<br /> transfers, implement the set_cs callback for the core to use.<br /> <br /> As part of this, the existing setup callback, mchp_coreqspi_setup_op(),<br /> is removed. Modifying the CLKIDLE field is not safe to do during<br /> operation when there are multiple devices, so this code is removed<br /> entirely. Setting the MASTER and ENABLE fields is something that can be<br /> done once at probe, it doesn&amp;#39;t need to be re-run for each device.<br /> Instead the new setup callback sets the built-in chip select to its<br /> inactive state for active-low devices, as the reset value of the chip<br /> select in software controlled mode is low.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: target: configfs: Bound snprintf() return in tg_pt_gp_members_show()<br /> <br /> target_tg_pt_gp_members_show() formats LUN paths with snprintf() into a<br /> 256-byte stack buffer, then will memcpy() cur_len bytes from that<br /> buffer. snprintf() returns the length the output would have had, which<br /> can exceed the buffer size when the fabric WWN is long because iSCSI IQN<br /> names can be up to 223 bytes. The check at the memcpy() site only<br /> guards the destination page write, not the source read, so memcpy() will<br /> read past the stack buffer and copy adjacent stack contents to the sysfs<br /> reader, which when CONFIG_FORTIFY_SOURCE is enabled, fortify_panic()<br /> will be triggered.<br /> <br /> Commit 27e06650a5ea ("scsi: target: target_core_configfs: Add length<br /> check to avoid buffer overflow") added the same bound to the<br /> target_lu_gp_members_show() but the tg_pt_gp variant was missed so<br /> resolve that here.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fanotify: fix false positive on permission events<br /> <br /> fsnotify_get_mark_safe() may return false for a mark on an unrelated group,<br /> which results in bypassing the permission check.<br /> <br /> Fix by skipping over detached marks that are not in the current group.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: usblp: fix heap leak in IEEE 1284 device ID via short response<br /> <br /> usblp_ctrl_msg() collapses the usb_control_msg() return value to<br /> 0/-errno, discarding the actual number of bytes transferred. A broken<br /> printer can complete the GET_DEVICE_ID control transfer short and the<br /> driver has no way to know.<br /> <br /> usblp_cache_device_id_string() reads the 2-byte big-endian length prefix<br /> from the response and trusts it (clamped only to the buffer bounds).<br /> The buffer is kmalloc(1024) at probe time. A device that sends exactly<br /> two bytes (e.g. 0x03 0xFF, claiming a 1023-byte ID) leaves<br /> device_id_string[2..1022] holding stale kmalloc heap.<br /> <br /> That stale data is then exposed:<br /> - via the ieee1284_id sysfs attribute (sprintf("%s", buf+2), truncated<br /> at the first NUL in the stale heap), and<br /> - via the IOCNR_GET_DEVICE_ID ioctl, which copy_to_user()s the full<br /> claimed length regardless of NULs, up to 1021 bytes of uninitialized<br /> heap, with the leak size chosen by the device.<br /> <br /> Fix this up by just zapping the buffer with zeros before each request<br /> sent to the device.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mac80211: drop stray &amp;#39;static&amp;#39; from fast-RX rx_result<br /> <br /> ieee80211_invoke_fast_rx() is documented as safe for parallel RX, but<br /> its per-invocation rx_result is declared static. Concurrent callers then<br /> share one instance and can overwrite each other&amp;#39;s result between<br /> ieee80211_rx_mesh_data() and the switch on res.<br /> <br /> That can make a packet that was queued or consumed by<br /> ieee80211_rx_mesh_data() fall through into ieee80211_rx_8023(), or make<br /> a packet that should continue return as queued.<br /> <br /> Make res an automatic variable so each invocation keeps its own result.