Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> accel/amdxdna: Stop job scheduling across aie2_release_resource()<br /> <br /> Running jobs on a hardware context while it is in the process of<br /> releasing resources can lead to use-after-free and crashes.<br /> <br /> Fix this by stopping job scheduling before calling<br /> aie2_release_resource() and restarting it after the release completes.<br /> Additionally, aie2_sched_job_run() now checks whether the hardware<br /> context is still active.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu: clean up the amdgpu_cs_parser_bos<br /> <br /> In low memory conditions, kmalloc can fail. In such conditions<br /> unlock the mutex for a clean exit.<br /> <br /> We do not need to amdgpu_bo_list_put as it&amp;#39;s been handled in the<br /> amdgpu_cs_parser_fini.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: ccree - fix a memory leak in cc_mac_digest()<br /> <br /> Add cc_unmap_result() if cc_map_hash_request_final()<br /> fails to prevent potential memory leak.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: don&amp;#39;t set EXT4_GET_BLOCKS_CONVERT when splitting before submitting I/O<br /> <br /> When allocating blocks during within-EOF DIO and writeback with<br /> dioread_nolock enabled, EXT4_GET_BLOCKS_PRE_IO was set to split an<br /> existing large unwritten extent. However, EXT4_GET_BLOCKS_CONVERT was<br /> set when calling ext4_split_convert_extents(), which may potentially<br /> result in stale data issues.<br /> <br /> Assume we have an unwritten extent, and then DIO writes the second half.<br /> <br /> [UUUUUUUUUUUUUUUU] on-disk extent U: unwritten extent<br /> [UUUUUUUUUUUUUUUU] extent status tree<br /> || ----&gt; dio write this range<br /> <br /> First, ext4_iomap_alloc() call ext4_map_blocks() with<br /> EXT4_GET_BLOCKS_PRE_IO, EXT4_GET_BLOCKS_UNWRIT_EXT and<br /> EXT4_GET_BLOCKS_CREATE flags set. ext4_map_blocks() find this extent and<br /> call ext4_split_convert_extents() with EXT4_GET_BLOCKS_CONVERT and the<br /> above flags set.<br /> <br /> Then, ext4_split_convert_extents() calls ext4_split_extent() with<br /> EXT4_EXT_MAY_ZEROOUT, EXT4_EXT_MARK_UNWRIT2 and EXT4_EXT_DATA_VALID2<br /> flags set, and it calls ext4_split_extent_at() to split the second half<br /> with EXT4_EXT_DATA_VALID2, EXT4_EXT_MARK_UNWRIT1, EXT4_EXT_MAY_ZEROOUT<br /> and EXT4_EXT_MARK_UNWRIT2 flags set. However, ext4_split_extent_at()<br /> failed to insert extent since a temporary lack -ENOSPC. It zeroes out<br /> the first half but convert the entire on-disk extent to written since<br /> the EXT4_EXT_DATA_VALID2 flag set, but left the second half as unwritten<br /> in the extent status tree.<br /> <br /> [0000000000SSSSSS] data S: stale data, 0: zeroed<br /> [WWWWWWWWWWWWWWWW] on-disk extent W: written extent<br /> [WWWWWWWWWWUUUUUU] extent status tree<br /> <br /> Finally, if the DIO failed to write data to the disk, the stale data in<br /> the second half will be exposed once the cached extent entry is gone.<br /> <br /> Fix this issue by not passing EXT4_GET_BLOCKS_CONVERT when splitting<br /> an unwritten extent before submitting I/O, and make<br /> ext4_split_convert_extents() to zero out the entire extent range<br /> to zero for this case, and also mark the extent in the extent status<br /> tree for consistency.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> gfs2: Fix use-after-free in iomap inline data write path<br /> <br /> The inline data buffer head (dibh) is being released prematurely in<br /> gfs2_iomap_begin() via release_metapath() while iomap-&gt;inline_data<br /> still points to dibh-&gt;b_data. This causes a use-after-free when<br /> iomap_write_end_inline() later attempts to write to the inline data<br /> area.<br /> <br /> The bug sequence:<br /> 1. gfs2_iomap_begin() calls gfs2_meta_inode_buffer() to read inode<br /> metadata into dibh<br /> 2. Sets iomap-&gt;inline_data = dibh-&gt;b_data + sizeof(struct gfs2_dinode)<br /> 3. Calls release_metapath() which calls brelse(dibh), dropping refcount<br /> to 0<br /> 4. kswapd reclaims the page (~39ms later in the syzbot report)<br /> 5. iomap_write_end_inline() tries to memcpy() to iomap-&gt;inline_data<br /> 6. KASAN detects use-after-free write to freed memory<br /> <br /> Fix by storing dibh in iomap-&gt;private and incrementing its refcount<br /> with get_bh() in gfs2_iomap_begin(). The buffer is then properly<br /> released in gfs2_iomap_end() after the inline write completes,<br /> ensuring the page stays alive for the entire iomap operation.<br /> <br /> Note: A C reproducer is not available for this issue. The fix is based<br /> on analysis of the KASAN report and code review showing the buffer head<br /> is freed before use.<br /> <br /> [agruenba: Take buffer head reference in gfs2_iomap_begin() to avoid<br /> leaks in gfs2_iomap_get() and gfs2_iomap_alloc().]

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> staging: greybus: lights: avoid NULL deref<br /> <br /> gb_lights_light_config() stores channel_count before allocating the<br /> channels array. If kcalloc() fails, gb_lights_release() iterates the<br /> non-zero count and dereferences light-&gt;channels, which is NULL.<br /> <br /> Allocate channels first and only then publish channels_count so the<br /> cleanup path can&amp;#39;t walk a NULL pointer.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fbnic: close fw_log race between users and teardown<br /> <br /> Fixes a theoretical race on fw_log between the teardown path and fw_log<br /> write functions.<br /> <br /> fw_log is written inside fbnic_fw_log_write() and can be reached from<br /> the mailbox handler fbnic_fw_msix_intr(), but fw_log is freed before<br /> IRQ/MBX teardown during cleanup, resulting in a potential data race of<br /> dereferencing a freed/null variable.<br /> <br /> Possible Interleaving Scenario:<br /> CPU0: fbnic_fw_msix_intr() // Entry<br /> fbnic_fw_log_write()<br /> if (fbnic_fw_log_ready()) // true<br /> ... preempt ...<br /> CPU1: fbnic_remove() // Entry<br /> fbnic_fw_log_free()<br /> vfree(log-&gt;data_start);<br /> log-&gt;data_start = NULL;<br /> CPU0: continues, walks log-&gt;entries or writes to log-&gt;data_start<br /> <br /> The initialization also has an incorrect order problem, as the fw_log<br /> is currently allocated after MBX setup during initialization.<br /> Fix the problems by adjusting the synchronization order to put<br /> initialization in place before the mailbox is enabled, and not cleared<br /> until after the mailbox has been disabled.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu: Fix memory leak in amdgpu_ras_init()<br /> <br /> When amdgpu_nbio_ras_sw_init() fails in amdgpu_ras_init(), the function<br /> returns directly without freeing the allocated con structure, leading<br /> to a memory leak.<br /> <br /> Fix this by jumping to the release_con label to properly clean up the<br /> allocated memory before returning the error code.<br /> <br /> Compile tested only. Issue found using a prototype static analysis tool<br /> and code review.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ublk: use READ_ONCE() to read struct ublksrv_ctrl_cmd<br /> <br /> struct ublksrv_ctrl_cmd is part of the io_uring_sqe, which may lie in<br /> userspace-mapped memory. It&amp;#39;s racy to access its fields with normal<br /> loads, as userspace may write to them concurrently. Use READ_ONCE() to<br /> copy the ublksrv_ctrl_cmd from the io_uring_sqe to the stack. Use the<br /> local copy in place of the one in the io_uring_sqe.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: fix invalid leaf access in btrfs_quota_enable() if ref key not found<br /> <br /> If btrfs_search_slot_for_read() returns 1, it means we did not find any<br /> key greater than or equals to the key we asked for, meaning we have<br /> reached the end of the tree and therefore the path is not valid. If<br /> this happens we need to break out of the loop and stop, instead of<br /> continuing and accessing an invalid path.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/mlx5: Fix UMR hang in LAG error state unload<br /> <br /> During firmware reset in LAG mode, a race condition causes the driver<br /> to hang indefinitely while waiting for UMR completion during device<br /> unload. See [1].<br /> <br /> In LAG mode the bond device is only registered on the master, so it<br /> never sees sys_error events from the slave.<br /> During firmware reset this causes UMR waits to hang forever on unload<br /> as the slave is dead but the master hasn&amp;#39;t entered error state yet, so<br /> UMR posts succeed but completions never arrive.<br /> <br /> Fix this by adding a sys_error notifier that gets registered before<br /> MLX5_IB_STAGE_IB_REG and stays alive until after ib_unregister_device().<br /> This ensures error events reach the bond device throughout teardown.<br /> <br /> [1]<br /> Call Trace:<br /> __schedule+0x2bd/0x760<br /> schedule+0x37/0xa0<br /> schedule_preempt_disabled+0xa/0x10<br /> __mutex_lock.isra.6+0x2b5/0x4a0<br /> __mlx5_ib_dereg_mr+0x606/0x870 [mlx5_ib]<br /> ? __xa_erase+0x4a/0xa0<br /> ? _cond_resched+0x15/0x30<br /> ? wait_for_completion+0x31/0x100<br /> ib_dereg_mr_user+0x48/0xc0 [ib_core]<br /> ? rdmacg_uncharge_hierarchy+0xa0/0x100<br /> destroy_hw_idr_uobject+0x20/0x50 [ib_uverbs]<br /> uverbs_destroy_uobject+0x37/0x150 [ib_uverbs]<br /> __uverbs_cleanup_ufile+0xda/0x140 [ib_uverbs]<br /> uverbs_destroy_ufile_hw+0x3a/0xf0 [ib_uverbs]<br /> ib_uverbs_remove_one+0xc3/0x140 [ib_uverbs]<br /> remove_client_context+0x8b/0xd0 [ib_core]<br /> disable_device+0x8c/0x130 [ib_core]<br /> __ib_unregister_device+0x10d/0x180 [ib_core]<br /> ib_unregister_device+0x21/0x30 [ib_core]<br /> __mlx5_ib_remove+0x1e4/0x1f0 [mlx5_ib]<br /> auxiliary_bus_remove+0x1e/0x30<br /> device_release_driver_internal+0x103/0x1f0<br /> bus_remove_device+0xf7/0x170<br /> device_del+0x181/0x410<br /> mlx5_rescan_drivers_locked.part.10+0xa9/0x1d0 [mlx5_core]<br /> mlx5_disable_lag+0x253/0x260 [mlx5_core]<br /> mlx5_lag_disable_change+0x89/0xc0 [mlx5_core]<br /> mlx5_eswitch_disable+0x67/0xa0 [mlx5_core]<br /> mlx5_unload+0x15/0xd0 [mlx5_core]<br /> mlx5_unload_one+0x71/0xc0 [mlx5_core]<br /> mlx5_sync_reset_reload_work+0x83/0x100 [mlx5_core]<br /> process_one_work+0x1a7/0x360<br /> worker_thread+0x30/0x390<br /> ? create_worker+0x1a0/0x1a0<br /> kthread+0x116/0x130<br /> ? kthread_flush_work_fn+0x10/0x10<br /> ret_from_fork+0x22/0x40

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Limit bpf program signature size<br /> <br /> Practical BPF signatures are significantly smaller than<br /> KMALLOC_MAX_CACHE_SIZE<br /> <br /> Allowing larger sizes opens the door for abuse by passing excessive<br /> size values and forcing the kernel into expensive allocation paths (via<br /> kmalloc_large or vmalloc).