Vulnerabilidades

*** 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 /> 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 /> 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 /> 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 /> 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 /> can: isotp: fix tx.buf use-after-free in isotp_sendmsg()<br /> <br /> isotp_sendmsg() uses only cmpxchg() on so-&gt;tx.state to serialize access<br /> to so-&gt;tx.buf. isotp_release() waits for ISOTP_IDLE via<br /> wait_event_interruptible() and then calls kfree(so-&gt;tx.buf).<br /> <br /> If a signal interrupts the wait_event_interruptible() inside close()<br /> while tx.state is ISOTP_SENDING, the loop exits early and release<br /> proceeds to force ISOTP_SHUTDOWN and continues to kfree(so-&gt;tx.buf)<br /> while sendmsg may still be reading so-&gt;tx.buf for the final CAN frame<br /> in isotp_fill_dataframe().<br /> <br /> The so-&gt;tx.buf can be allocated once when the standard tx.buf length needs<br /> to be extended. Move the kfree() of this potentially extended tx.buf to<br /> sk_destruct time when either isotp_sendmsg() and isotp_release() are done.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: sma1307: fix double free of devm_kzalloc() memory<br /> <br /> A previous change added NULL checks and cleanup for allocation<br /> failures in sma1307_setting_loaded().<br /> <br /> However, the cleanup for mode_set entries is wrong. Those entries are<br /> allocated with devm_kzalloc(), so they are device-managed resources and<br /> must not be freed with kfree(). Manually freeing them in the error path<br /> can lead to a double free when devres later releases the same memory.<br /> <br /> Drop the manual kfree() loop and let devres handle the cleanup.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: do not expire session on binding failure<br /> <br /> When a multichannel session binding request fails (e.g. wrong password),<br /> the error path unconditionally sets sess-&gt;state = SMB2_SESSION_EXPIRED.<br /> However, during binding, sess points to the target session looked up via<br /> ksmbd_session_lookup_slowpath() -- which belongs to another connection&amp;#39;s<br /> user. This allows a remote attacker to invalidate any active session by<br /> simply sending a binding request with a wrong password (DoS).<br /> <br /> Fix this by skipping session expiration when the failed request was<br /> a binding attempt, since the session does not belong to the current<br /> connection. The reference taken by ksmbd_session_lookup_slowpath() is<br /> still correctly released via ksmbd_user_session_put().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: fix memory leaks and NULL deref in smb2_lock()<br /> <br /> smb2_lock() has three error handling issues after list_del() detaches<br /> smb_lock from lock_list at no_check_cl:<br /> <br /> 1) If vfs_lock_file() returns an unexpected error in the non-UNLOCK<br /> path, goto out leaks smb_lock and its flock because the out:<br /> handler only iterates lock_list and rollback_list, neither of<br /> which contains the detached smb_lock.<br /> <br /> 2) If vfs_lock_file() returns -ENOENT in the UNLOCK path, goto out<br /> leaks smb_lock and flock for the same reason. The error code<br /> returned to the dispatcher is also stale.<br /> <br /> 3) In the rollback path, smb_flock_init() can return NULL on<br /> allocation failure. The result is dereferenced unconditionally,<br /> causing a kernel NULL pointer dereference. Add a NULL check to<br /> prevent the crash and clean up the bookkeeping; the VFS lock<br /> itself cannot be rolled back without the allocation and will be<br /> released at file or connection teardown.<br /> <br /> Fix cases 1 and 2 by hoisting the locks_free_lock()/kfree() to before<br /> the if(!rc) check in the UNLOCK branch so all exit paths share one<br /> free site, and by freeing smb_lock and flock before goto out in the<br /> non-UNLOCK branch. Propagate the correct error code in both cases.<br /> Fix case 3 by wrapping the VFS unlock in an if(rlock) guard and adding<br /> a NULL check for locks_free_lock(rlock) in the shared cleanup.<br /> <br /> Found via call-graph analysis using sqry.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: replace hardcoded hdr2_len with offsetof() in smb2_calc_max_out_buf_len()<br /> <br /> After this commit (e2b76ab8b5c9 "ksmbd: add support for read compound"),<br /> response buffer management was changed to use dynamic iov array.<br /> In the new design, smb2_calc_max_out_buf_len() expects the second<br /> argument (hdr2_len) to be the offset of -&gt;Buffer field in the<br /> response structure, not a hardcoded magic number.<br /> Fix the remaining call sites to use the correct offsetof() value.

*** 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)

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vfio/pci: Fix double free in dma-buf feature<br /> <br /> The error path through vfio_pci_core_feature_dma_buf() ignores its<br /> own advice to only use dma_buf_put() after dma_buf_export(), instead<br /> falling through the entire unwind chain. In the unlikely event that<br /> we encounter file descriptor exhaustion, this can result in an<br /> unbalanced refcount on the vfio device and double free of allocated<br /> objects.<br /> <br /> Avoid this by moving the "put" directly into the error path and return<br /> the errno rather than entering the unwind chain.