Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/xe/pf: Fix use-after-free in migration restore<br /> <br /> When an error is returned from xe_sriov_pf_migration_restore_produce(),<br /> the data pointer is not set to NULL, which can trigger use-after-free<br /> in subsequent .write() calls.<br /> Set the pointer to NULL upon error to fix the problem.<br /> <br /> (cherry picked from commit 4f53d8c6d23527d734fe3531d08e15cb170a0819)

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> spi: use generic driver_override infrastructure<br /> <br /> When a driver is probed through __driver_attach(), the bus&amp;#39; match()<br /> callback is called without the device lock held, thus accessing the<br /> driver_override field without a lock, which can cause a UAF.<br /> <br /> Fix this by using the driver-core driver_override infrastructure taking<br /> care of proper locking internally.<br /> <br /> Note that calling match() from __driver_attach() without the device lock<br /> held is intentional. [1]<br /> <br /> Also note that we do not enable the driver_override feature of struct<br /> bus_type, as SPI - in contrast to most other buses - passes "" to<br /> sysfs_emit() when the driver_override pointer is NULL. Thus, printing<br /> "\n" instead of "(null)\n".

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> hwmon: (pmbus/core) Protect regulator operations with mutex<br /> <br /> The regulator operations pmbus_regulator_get_voltage(),<br /> pmbus_regulator_set_voltage(), and pmbus_regulator_list_voltage()<br /> access PMBus registers and shared data but were not protected by<br /> the update_lock mutex. This could lead to race conditions.<br /> <br /> However, adding mutex protection directly to these functions causes<br /> a deadlock because pmbus_regulator_notify() (which calls<br /> regulator_notifier_call_chain()) is often called with the mutex<br /> already held (e.g., from pmbus_fault_handler()). If a regulator<br /> callback then calls one of the now-protected voltage functions,<br /> it will attempt to acquire the same mutex.<br /> <br /> Rework pmbus_regulator_notify() to utilize a worker function to<br /> send notifications outside of the mutex protection. Events are<br /> stored as atomics in a per-page bitmask and processed by the worker.<br /> <br /> Initialize the worker and its associated data during regulator<br /> registration, and ensure it is cancelled on device removal using<br /> devm_add_action_or_reset().<br /> <br /> While at it, remove the unnecessary include of linux/of.h.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Do not skip unrelated mode changes in DSC validation<br /> <br /> Starting with commit 17ce8a6907f7 ("drm/amd/display: Add dsc pre-validation in<br /> atomic check"), amdgpu resets the CRTC state mode_changed flag to false when<br /> recomputing the DSC configuration results in no timing change for a particular<br /> stream.<br /> <br /> However, this is incorrect in scenarios where a change in MST/DSC configuration<br /> happens in the same KMS commit as another (unrelated) mode change. For example,<br /> the integrated panel of a laptop may be configured differently (e.g., HDR<br /> enabled/disabled) depending on whether external screens are attached. In this<br /> case, plugging in external DP-MST screens may result in the mode_changed flag<br /> being dropped incorrectly for the integrated panel if its DSC configuration<br /> did not change during precomputation in pre_validate_dsc().<br /> <br /> At this point, however, dm_update_crtc_state() has already created new streams<br /> for CRTCs with DSC-independent mode changes. In turn,<br /> amdgpu_dm_commit_streams() will never release the old stream, resulting in a<br /> memory leak. amdgpu_dm_atomic_commit_tail() will never acquire a reference to<br /> the new stream either, which manifests as a use-after-free when the stream gets<br /> disabled later on:<br /> <br /> BUG: KASAN: use-after-free in dc_stream_release+0x25/0x90 [amdgpu]<br /> Write of size 4 at addr ffff88813d836524 by task kworker/9:9/29977<br /> <br /> Workqueue: events drm_mode_rmfb_work_fn<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x6e/0xa0<br /> print_address_description.constprop.0+0x88/0x320<br /> ? dc_stream_release+0x25/0x90 [amdgpu]<br /> print_report+0xfc/0x1ff<br /> ? srso_alias_return_thunk+0x5/0xfbef5<br /> ? __virt_addr_valid+0x225/0x4e0<br /> ? dc_stream_release+0x25/0x90 [amdgpu]<br /> kasan_report+0xe1/0x180<br /> ? dc_stream_release+0x25/0x90 [amdgpu]<br /> kasan_check_range+0x125/0x200<br /> dc_stream_release+0x25/0x90 [amdgpu]<br /> dc_state_destruct+0x14d/0x5c0 [amdgpu]<br /> dc_state_release.part.0+0x4e/0x130 [amdgpu]<br /> dm_atomic_destroy_state+0x3f/0x70 [amdgpu]<br /> drm_atomic_state_default_clear+0x8ee/0xf30<br /> ? drm_mode_object_put.part.0+0xb1/0x130<br /> __drm_atomic_state_free+0x15c/0x2d0<br /> atomic_remove_fb+0x67e/0x980<br /> <br /> Since there is no reliable way of figuring out whether a CRTC has unrelated<br /> mode changes pending at the time of DSC validation, remember the value of the<br /> mode_changed flag from before the point where a CRTC was marked as potentially<br /> affected by a change in DSC configuration. Reset the mode_changed flag to this<br /> earlier value instead in pre_validate_dsc().<br /> <br /> (cherry picked from commit cc7c7121ae082b7b82891baa7280f1ff2608f22b)

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> spi: meson-spicc: Fix double-put in remove path<br /> <br /> meson_spicc_probe() registers the controller with<br /> devm_spi_register_controller(), so teardown already drops the<br /> controller reference via devm cleanup.<br /> <br /> Calling spi_controller_put() again in meson_spicc_remove()<br /> causes a double-put.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tracing: Drain deferred trigger frees if kthread creation fails<br /> <br /> Boot-time trigger registration can fail before the trigger-data cleanup<br /> kthread exists. Deferring those frees until late init is fine, but the<br /> post-boot fallback must still drain the deferred list if kthread<br /> creation never succeeds.<br /> <br /> Otherwise, boot-deferred nodes can accumulate on<br /> trigger_data_free_list, later frees fall back to synchronously freeing<br /> only the current object, and the older queued entries are leaked<br /> forever.<br /> <br /> To trigger this, add the following to the kernel command line:<br /> <br /> trace_event=sched_switch trace_trigger=sched_switch.traceon,sched_switch.traceon<br /> <br /> The second traceon trigger will fail and be freed. This triggers a NULL<br /> pointer dereference and crashes the kernel.<br /> <br /> Keep the deferred boot-time behavior, but when kthread creation fails,<br /> drain the whole queued list synchronously. Do the same in the late-init<br /> drain path so queued entries are not stranded there either.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> spi: spi-fsl-lpspi: fix teardown order issue (UAF)<br /> <br /> There is a teardown order issue in the driver. The SPI controller is<br /> registered using devm_spi_register_controller(), which delays<br /> unregistration of the SPI controller until after the fsl_lpspi_remove()<br /> function returns.<br /> <br /> As the fsl_lpspi_remove() function synchronously tears down the DMA<br /> channels, a running SPI transfer triggers the following NULL pointer<br /> dereference due to use after free:<br /> <br /> | fsl_lpspi 42550000.spi: I/O Error in DMA RX<br /> | Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000<br /> [...]<br /> | Call trace:<br /> | fsl_lpspi_dma_transfer+0x260/0x340 [spi_fsl_lpspi]<br /> | fsl_lpspi_transfer_one+0x198/0x448 [spi_fsl_lpspi]<br /> | spi_transfer_one_message+0x49c/0x7c8<br /> | __spi_pump_transfer_message+0x120/0x420<br /> | __spi_sync+0x2c4/0x520<br /> | spi_sync+0x34/0x60<br /> | spidev_message+0x20c/0x378 [spidev]<br /> | spidev_ioctl+0x398/0x750 [spidev]<br /> [...]<br /> <br /> Switch from devm_spi_register_controller() to spi_register_controller() in<br /> fsl_lpspi_probe() and add the corresponding spi_unregister_controller() in<br /> fsl_lpspi_remove().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> io_uring/fdinfo: fix OOB read in SQE_MIXED wrap check<br /> <br /> __io_uring_show_fdinfo() iterates over pending SQEs and, for 128-byte<br /> SQEs on an IORING_SETUP_SQE_MIXED ring, needs to detect when the second<br /> half of the SQE would be past the end of the sq_sqes array. The current<br /> check tests (++sq_head &amp; sq_mask) == 0, but sq_head is only incremented<br /> when a 128-byte SQE is encountered, not on every iteration. The actual<br /> array index is sq_idx = (i + sq_head) &amp; sq_mask, which can be sq_mask<br /> (the last slot) while the wrap check passes.<br /> <br /> Fix by checking sq_idx directly. Keep the sq_head increment so the loop<br /> still skips the second half of the 128-byte SQE on the next iteration.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> s390/syscalls: Add spectre boundary for syscall dispatch table<br /> <br /> The s390 syscall number is directly controlled by userspace, but does<br /> not have an array_index_nospec() boundary to prevent access past the<br /> syscall function pointer tables.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> s390/entry: Scrub r12 register on kernel entry<br /> <br /> Before commit f33f2d4c7c80 ("s390/bp: remove TIF_ISOLATE_BP"),<br /> all entry handlers loaded r12 with the current task pointer<br /> (lg %r12,__LC_CURRENT) for use by the BPENTER/BPEXIT macros. That<br /> commit removed TIF_ISOLATE_BP, dropping both the branch prediction<br /> macros and the r12 load, but did not add r12 to the register clearing<br /> sequence.<br /> <br /> Add the missing xgr %r12,%r12 to make the register scrub consistent<br /> across all entry points.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tracing: Fix potential deadlock in cpu hotplug with osnoise<br /> <br /> The following sequence may leads deadlock in cpu hotplug:<br /> <br /> task1 task2 task3<br /> ----- ----- -----<br /> <br /> mutex_lock(&amp;interface_lock)<br /> <br /> [CPU GOING OFFLINE]<br /> <br /> cpus_write_lock();<br /> osnoise_cpu_die();<br /> kthread_stop(task3);<br /> wait_for_completion();<br /> <br /> osnoise_sleep();<br /> mutex_lock(&amp;interface_lock);<br /> <br /> cpus_read_lock();<br /> <br /> [DEAD LOCK]<br /> <br /> Fix by swap the order of cpus_read_lock() and mutex_lock(&amp;interface_lock).

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/xe: always keep track of remap prev/next<br /> <br /> During 3D workload, user is reporting hitting:<br /> <br /> [ 413.361679] WARNING: drivers/gpu/drm/xe/xe_vm.c:1217 at vm_bind_ioctl_ops_unwind+0x1e2/0x2e0 [xe], CPU#7: vkd3d_queue/9925<br /> [ 413.361944] CPU: 7 UID: 1000 PID: 9925 Comm: vkd3d_queue Kdump: loaded Not tainted 7.0.0-070000rc3-generic #202603090038 PREEMPT(lazy)<br /> [ 413.361949] RIP: 0010:vm_bind_ioctl_ops_unwind+0x1e2/0x2e0 [xe]<br /> [ 413.362074] RSP: 0018:ffffd4c25c3df930 EFLAGS: 00010282<br /> [ 413.362077] RAX: 0000000000000000 RBX: ffff8f3ee817ed10 RCX: 0000000000000000<br /> [ 413.362078] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000<br /> [ 413.362079] RBP: ffffd4c25c3df980 R08: 0000000000000000 R09: 0000000000000000<br /> [ 413.362081] R10: 0000000000000000 R11: 0000000000000000 R12: ffff8f41fbf99380<br /> [ 413.362082] R13: ffff8f3ee817e968 R14: 00000000ffffffef R15: ffff8f43d00bd380<br /> [ 413.362083] FS: 00000001040ff6c0(0000) GS:ffff8f4696d89000(0000) knlGS:00000000330b0000<br /> [ 413.362085] CS: 0010 DS: 002b ES: 002b CR0: 0000000080050033<br /> [ 413.362086] CR2: 00007ddfc4747000 CR3: 00000002e6262005 CR4: 0000000000f72ef0<br /> [ 413.362088] PKRU: 55555554<br /> [ 413.362089] Call Trace:<br /> [ 413.362092] <br /> [ 413.362096] xe_vm_bind_ioctl+0xa9a/0xc60 [xe]<br /> <br /> Which seems to hint that the vma we are re-inserting for the ops unwind<br /> is either invalid or overlapping with something already inserted in the<br /> vm. It shouldn&amp;#39;t be invalid since this is a re-insertion, so must have<br /> worked before. Leaving the likely culprit as something already placed<br /> where we want to insert the vma.<br /> <br /> Following from that, for the case where we do something like a rebind in<br /> the middle of a vma, and one or both mapped ends are already compatible,<br /> we skip doing the rebind of those vma and set next/prev to NULL. As well<br /> as then adjust the original unmap va range, to avoid unmapping the ends.<br /> However, if we trigger the unwind path, we end up with three va, with<br /> the two ends never being removed and the original va range in the middle<br /> still being the shrunken size.<br /> <br /> If this occurs, one failure mode is when another unwind op needs to<br /> interact with that range, which can happen with a vector of binds. For<br /> example, if we need to re-insert something in place of the original va.<br /> In this case the va is still the shrunken version, so when removing it<br /> and then doing a re-insert it can overlap with the ends, which were<br /> never removed, triggering a warning like above, plus leaving the vm in a<br /> bad state.<br /> <br /> With that, we need two things here:<br /> <br /> 1) Stop nuking the prev/next tracking for the skip cases. Instead<br /> relying on checking for skip prev/next, where needed. That way on the<br /> unwind path, we now correctly remove both ends.<br /> <br /> 2) Undo the unmap va shrinkage, on the unwind path. With the two ends<br /> now removed the unmap va should expand back to the original size again,<br /> before re-insertion.<br /> <br /> v2:<br /> - Update the explanation in the commit message, based on an actual IGT of<br /> triggering this issue, rather than conjecture.<br /> - Also undo the unmap shrinkage, for the skip case. With the two ends<br /> now removed, the original unmap va range should expand back to the<br /> original range.<br /> v3:<br /> - Track the old start/range separately. vma_size/start() uses the va<br /> info directly.<br /> <br /> (cherry picked from commit aec6969f75afbf4e01fd5fb5850ed3e9c27043ac)