Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ocfs2: fix reflink preserve cleanup issue<br /> <br /> commit c06c303832ec ("ocfs2: fix xattr array entry __counted_by error")<br /> doesn&amp;#39;t handle all cases and the cleanup job for preserved xattr entries<br /> still has bug:<br /> - the &amp;#39;last&amp;#39; pointer should be shifted by one unit after cleanup<br /> an array entry.<br /> - current code logic doesn&amp;#39;t cleanup the first entry when xh_count is 1.<br /> <br /> Note, commit c06c303832ec is also a bug fix for 0fe9b66c65f3.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/buddy: Prevent BUG_ON by validating rounded allocation<br /> <br /> When DRM_BUDDY_CONTIGUOUS_ALLOCATION is set, the requested size is<br /> rounded up to the next power-of-two via roundup_pow_of_two().<br /> Similarly, for non-contiguous allocations with large min_block_size,<br /> the size is aligned up via round_up(). Both operations can produce a<br /> rounded size that exceeds mm-&gt;size, which later triggers<br /> BUG_ON(order &gt; mm-&gt;max_order).<br /> <br /> Example scenarios:<br /> - 9G CONTIGUOUS allocation on 10G VRAM memory:<br /> roundup_pow_of_two(9G) = 16G &gt; 10G<br /> - 9G allocation with 8G min_block_size on 10G VRAM memory:<br /> round_up(9G, 8G) = 16G &gt; 10G<br /> <br /> Fix this by checking the rounded size against mm-&gt;size. For<br /> non-contiguous or range allocations where size &gt; mm-&gt;size is invalid,<br /> return -EINVAL immediately. For contiguous allocations without range<br /> restrictions, allow the request to fall through to the existing<br /> __alloc_contig_try_harder() fallback.<br /> <br /> This ensures invalid user input returns an error or uses the fallback<br /> path instead of hitting BUG_ON.<br /> <br /> v2: (Matt A)<br /> - Add Fixes, Cc stable, and Closes tags for context

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: dwc3: gadget: Move vbus draw to workqueue context<br /> <br /> Currently dwc3_gadget_vbus_draw() can be called from atomic<br /> context, which in turn invokes power-supply-core APIs. And<br /> some these PMIC APIs have operations that may sleep, leading<br /> to kernel panic.<br /> <br /> Fix this by moving the vbus_draw into a workqueue context.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> EFI/CPER: don&amp;#39;t dump the entire memory region<br /> <br /> The current logic at cper_print_fw_err() doesn&amp;#39;t check if the<br /> error record length is big enough to handle offset. On a bad firmware,<br /> if the ofset is above the actual record, length -= offset will<br /> underflow, making it dump the entire memory.<br /> <br /> The end result can be:<br /> <br /> - the logic taking a lot of time dumping large regions of memory;<br /> - data disclosure due to the memory dumps;<br /> - an OOPS, if it tries to dump an unmapped memory region.<br /> <br /> Fix it by checking if the section length is too small before doing<br /> a hex dump.<br /> <br /> [ rjw: Subject tweaks ]

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: ethernet: xscale: Check for PTP support properly<br /> <br /> In ixp4xx_get_ts_info() ixp46x_ptp_find() is called<br /> unconditionally despite this feature only existing on<br /> ixp46x, leading to the following splat from tcpdump:<br /> <br /> root@OpenWrt:~# tcpdump -vv -X -i eth0<br /> (...)<br /> Unable to handle kernel NULL pointer dereference at virtual address<br /> 00000238 when read<br /> (...)<br /> Call trace:<br /> ptp_clock_index from ixp46x_ptp_find+0x1c/0x38<br /> ixp46x_ptp_find from ixp4xx_get_ts_info+0x4c/0x64<br /> ixp4xx_get_ts_info from __ethtool_get_ts_info+0x90/0x108<br /> __ethtool_get_ts_info from __dev_ethtool+0xa00/0x2648<br /> __dev_ethtool from dev_ethtool+0x160/0x234<br /> dev_ethtool from dev_ioctl+0x2cc/0x460<br /> dev_ioctl from sock_ioctl+0x1ec/0x524<br /> sock_ioctl from sys_ioctl+0x51c/0xa94<br /> sys_ioctl from ret_fast_syscall+0x0/0x44<br /> (...)<br /> Segmentation fault<br /> <br /> Check for ixp46x in ixp46x_ptp_find() before trying to set up<br /> PTP to avoid this.<br /> <br /> To avoid altering the returned error code from ixp4xx_hwtstamp_set()<br /> which before this patch was -EOPNOTSUPP, we return -EOPNOTSUPP<br /> from ixp4xx_hwtstamp_set() if ixp46x_ptp_find() fails no matter<br /> the error code. The helper function ixp46x_ptp_find() helper<br /> returns -ENODEV.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> io_uring/zcrx: fix post open error handling<br /> <br /> Closing a queue doesn&amp;#39;t guarantee that all associated page pools are<br /> terminated right away, let the refcounting do the work instead of<br /> releasing the zcrx ctx directly.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> clk: rs9: Reserve 8 struct clk_hw slots for for 9FGV0841<br /> <br /> The 9FGV0841 has 8 outputs and registers 8 struct clk_hw, make sure<br /> there are 8 slots for those newly registered clk_hw pointers, else<br /> there is going to be out of bounds write when pointers 4..7 are set<br /> into struct rs9_driver_data .clk_dif[4..7] field.<br /> <br /> Since there are other structure members past this struct clk_hw<br /> pointer array, writing to .clk_dif[4..7] fields corrupts both<br /> the struct rs9_driver_data content and data around it, sometimes<br /> without crashing the kernel. However, the kernel does surely<br /> crash when the driver is unbound or during suspend.<br /> <br /> Fix this, increase the struct clk_hw pointer array size to the<br /> maximum output count of 9FGV0841, which is the biggest chip that<br /> is supported by this driver.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: iwlwifi: fix 22000 series SMEM parsing<br /> <br /> If the firmware were to report three LMACs (which doesn&amp;#39;t<br /> exist in hardware) then using "fwrt-&gt;smem_cfg.lmac[2]" is<br /> an overrun of the array. Reject such and use IWL_FW_CHECK<br /> instead of WARN_ON in this function.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommu/vt-d: Skip dev-iotlb flush for inaccessible PCIe device without scalable mode<br /> <br /> PCIe endpoints with ATS enabled and passed through to userspace<br /> (e.g., QEMU, DPDK) can hard-lock the host when their link drops,<br /> either by surprise removal or by a link fault.<br /> <br /> Commit 4fc82cd907ac ("iommu/vt-d: Don&amp;#39;t issue ATS Invalidation<br /> request when device is disconnected") adds pci_dev_is_disconnected()<br /> to devtlb_invalidation_with_pasid() so ATS invalidation is skipped<br /> only when the device is being safely removed, but it applies only<br /> when Intel IOMMU scalable mode is enabled.<br /> <br /> With scalable mode disabled or unsupported, a system hard-lock<br /> occurs when a PCIe endpoint&amp;#39;s link drops because the Intel IOMMU<br /> waits indefinitely for an ATS invalidation that cannot complete.<br /> <br /> Call Trace:<br /> qi_submit_sync<br /> qi_flush_dev_iotlb<br /> __context_flush_dev_iotlb.part.0<br /> domain_context_clear_one_cb<br /> pci_for_each_dma_alias<br /> device_block_translation<br /> blocking_domain_attach_dev<br /> iommu_deinit_device<br /> __iommu_group_remove_device<br /> iommu_release_device<br /> iommu_bus_notifier<br /> blocking_notifier_call_chain<br /> bus_notify<br /> device_del<br /> pci_remove_bus_device<br /> pci_stop_and_remove_bus_device<br /> pciehp_unconfigure_device<br /> pciehp_disable_slot<br /> pciehp_handle_presence_or_link_change<br /> pciehp_ist<br /> <br /> Commit 81e921fd3216 ("iommu/vt-d: Fix NULL domain on device release")<br /> adds intel_pasid_teardown_sm_context() to intel_iommu_release_device(),<br /> which calls qi_flush_dev_iotlb() and can also hard-lock the system<br /> when a PCIe endpoint&amp;#39;s link drops.<br /> <br /> Call Trace:<br /> qi_submit_sync<br /> qi_flush_dev_iotlb<br /> __context_flush_dev_iotlb.part.0<br /> intel_context_flush_no_pasid<br /> device_pasid_table_teardown<br /> pci_pasid_table_teardown<br /> pci_for_each_dma_alias<br /> intel_pasid_teardown_sm_context<br /> intel_iommu_release_device<br /> iommu_deinit_device<br /> __iommu_group_remove_device<br /> iommu_release_device<br /> iommu_bus_notifier<br /> blocking_notifier_call_chain<br /> bus_notify<br /> device_del<br /> pci_remove_bus_device<br /> pci_stop_and_remove_bus_device<br /> pciehp_unconfigure_device<br /> pciehp_disable_slot<br /> pciehp_handle_presence_or_link_change<br /> pciehp_ist<br /> <br /> Sometimes the endpoint loses connection without a link-down event<br /> (e.g., due to a link fault); killing the process (virsh destroy)<br /> then hard-locks the host.<br /> <br /> Call Trace:<br /> qi_submit_sync<br /> qi_flush_dev_iotlb<br /> __context_flush_dev_iotlb.part.0<br /> domain_context_clear_one_cb<br /> pci_for_each_dma_alias<br /> device_block_translation<br /> blocking_domain_attach_dev<br /> __iommu_attach_device<br /> __iommu_device_set_domain<br /> __iommu_group_set_domain_internal<br /> iommu_detach_group<br /> vfio_iommu_type1_detach_group<br /> vfio_group_detach_container<br /> vfio_group_fops_release<br /> __fput<br /> <br /> pci_dev_is_disconnected() only covers safe-removal paths;<br /> pci_device_is_present() tests accessibility by reading<br /> vendor/device IDs and internally calls pci_dev_is_disconnected().<br /> On a ConnectX-5 (8 GT/s, x2) this costs ~70 µs.<br /> <br /> Since __context_flush_dev_iotlb() is only called on<br /> {attach,release}_dev paths (not hot), add pci_device_is_present()<br /> there to skip inaccessible devices and avoid the hard-lock.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: tegra-video: Fix memory leak in __tegra_channel_try_format()<br /> <br /> The state object allocated by __v4l2_subdev_state_alloc() must be freed<br /> with __v4l2_subdev_state_free() when it is no longer needed.<br /> <br /> In __tegra_channel_try_format(), two error paths return directly after<br /> v4l2_subdev_call() fails, without freeing the allocated &amp;#39;sd_state&amp;#39;<br /> object. This violates the requirement and causes a memory leak.<br /> <br /> Fix this by introducing a cleanup label and using goto statements in the<br /> error paths to ensure that __v4l2_subdev_state_free() is always called<br /> before the function returns.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> md/bitmap: fix GPF in write_page caused by resize race<br /> <br /> A General Protection Fault occurs in write_page() during array resize:<br /> RIP: 0010:write_page+0x22b/0x3c0 [md_mod]<br /> <br /> This is a use-after-free race between bitmap_daemon_work() and<br /> __bitmap_resize(). The daemon iterates over `bitmap-&gt;storage.filemap`<br /> without locking, while the resize path frees that storage via<br /> md_bitmap_file_unmap(). `quiesce()` does not stop the md thread,<br /> allowing concurrent access to freed pages.<br /> <br /> Fix by holding `mddev-&gt;bitmap_info.mutex` during the bitmap update.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> hwmon: (nct7363) Fix a resource leak in nct7363_present_pwm_fanin<br /> <br /> When calling of_parse_phandle_with_args(), the caller is responsible<br /> to call of_node_put() to release the reference of device node.<br /> In nct7363_present_pwm_fanin, it does not release the reference,<br /> causing a resource leak.