Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iio: gyro: mpu3050: Fix irq resource leak<br /> <br /> The interrupt handler is setup but only a few lines down if<br /> iio_trigger_register() fails the function returns without properly<br /> releasing the handler.<br /> <br /> Add cleanup goto to resolve resource leak.<br /> <br /> Detected by Smatch:<br /> drivers/iio/gyro/mpu3050-core.c:1128 mpu3050_trigger_probe() warn:<br /> &amp;#39;irq&amp;#39; from request_threaded_irq() not released on lines: 1124.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iio: gyro: mpu3050: Move iio_device_register() to correct location<br /> <br /> iio_device_register() should be at the end of the probe function to<br /> prevent race conditions.<br /> <br /> Place iio_device_register() at the end of the probe function and place<br /> iio_device_unregister() accordingly.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> gpib: lpvo_usb: fix memory leak on disconnect<br /> <br /> The driver iterates over the registered USB interfaces during GPIB<br /> attach and takes a reference to their USB devices until a match is<br /> found. These references are never released which leads to a memory leak<br /> when devices are disconnected.<br /> <br /> Fix the leak by dropping the unnecessary references.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu: Change AMDGPU_VA_RESERVED_TRAP_SIZE to 64KB<br /> <br /> Currently, AMDGPU_VA_RESERVED_TRAP_SIZE is hardcoded to 8KB, while<br /> KFD_CWSR_TBA_TMA_SIZE is defined as 2 * PAGE_SIZE. On systems with<br /> 4K pages, both values match (8KB), so allocation and reserved space<br /> are consistent.<br /> <br /> However, on 64K page-size systems, KFD_CWSR_TBA_TMA_SIZE becomes 128KB,<br /> while the reserved trap area remains 8KB. This mismatch causes the<br /> kernel to crash when running rocminfo or rccl unit tests.<br /> <br /> Kernel attempted to read user page (2) - exploit attempt? (uid: 1001)<br /> BUG: Kernel NULL pointer dereference on read at 0x00000002<br /> Faulting instruction address: 0xc0000000002c8a64<br /> Oops: Kernel access of bad area, sig: 11 [#1]<br /> LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA pSeries<br /> CPU: 34 UID: 1001 PID: 9379 Comm: rocminfo Tainted: G E<br /> 6.19.0-rc4-amdgpu-00320-gf23176405700 #56 VOLUNTARY<br /> Tainted: [E]=UNSIGNED_MODULE<br /> Hardware name: IBM,9105-42A POWER10 (architected) 0x800200 0xf000006<br /> of:IBM,FW1060.30 (ML1060_896) hv:phyp pSeries<br /> NIP: c0000000002c8a64 LR: c00000000125dbc8 CTR: c00000000125e730<br /> REGS: c0000001e0957580 TRAP: 0300 Tainted: G E<br /> MSR: 8000000000009033 CR: 24008268<br /> XER: 00000036<br /> CFAR: c00000000125dbc4 DAR: 0000000000000002 DSISR: 40000000<br /> IRQMASK: 1<br /> GPR00: c00000000125d908 c0000001e0957820 c0000000016e8100<br /> c00000013d814540<br /> GPR04: 0000000000000002 c00000013d814550 0000000000000045<br /> 0000000000000000<br /> GPR08: c00000013444d000 c00000013d814538 c00000013d814538<br /> 0000000084002268<br /> GPR12: c00000000125e730 c000007e2ffd5f00 ffffffffffffffff<br /> 0000000000020000<br /> GPR16: 0000000000000000 0000000000000002 c00000015f653000<br /> 0000000000000000<br /> GPR20: c000000138662400 c00000013d814540 0000000000000000<br /> c00000013d814500<br /> GPR24: 0000000000000000 0000000000000002 c0000001e0957888<br /> c0000001e0957878<br /> GPR28: c00000013d814548 0000000000000000 c00000013d814540<br /> c0000001e0957888<br /> NIP [c0000000002c8a64] __mutex_add_waiter+0x24/0xc0<br /> LR [c00000000125dbc8] __mutex_lock.constprop.0+0x318/0xd00<br /> Call Trace:<br /> 0xc0000001e0957890 (unreliable)<br /> __mutex_lock.constprop.0+0x58/0xd00<br /> amdgpu_amdkfd_gpuvm_alloc_memory_of_gpu+0x6fc/0xb60 [amdgpu]<br /> kfd_process_alloc_gpuvm+0x54/0x1f0 [amdgpu]<br /> kfd_process_device_init_cwsr_dgpu+0xa4/0x1a0 [amdgpu]<br /> kfd_process_device_init_vm+0xd8/0x2e0 [amdgpu]<br /> kfd_ioctl_acquire_vm+0xd0/0x130 [amdgpu]<br /> kfd_ioctl+0x514/0x670 [amdgpu]<br /> sys_ioctl+0x134/0x180<br /> system_call_exception+0x114/0x300<br /> system_call_vectored_common+0x15c/0x2ec<br /> <br /> This patch changes AMDGPU_VA_RESERVED_TRAP_SIZE to 64 KB and<br /> KFD_CWSR_TBA_TMA_SIZE to the AMD GPU page size. This means we reserve<br /> 64 KB for the trap in the address space, but only allocate 8 KB within<br /> it. With this approach, the allocation size never exceeds the reserved<br /> area.<br /> <br /> (cherry picked from commit 31b8de5e55666f26ea7ece5f412b83eab3f56dbb)

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu: validate doorbell_offset in user queue creation<br /> <br /> amdgpu_userq_get_doorbell_index() passes the user-provided<br /> doorbell_offset to amdgpu_doorbell_index_on_bar() without bounds<br /> checking. An arbitrarily large doorbell_offset can cause the<br /> calculated doorbell index to fall outside the allocated doorbell BO,<br /> potentially corrupting kernel doorbell space.<br /> <br /> Validate that doorbell_offset falls within the doorbell BO before<br /> computing the BAR index, using u64 arithmetic to prevent overflow.<br /> <br /> (cherry picked from commit de1ef4ffd70e1d15f0bf584fd22b1f28cbd5e2ec)

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/i915/dsi: Don&amp;#39;t do DSC horizontal timing adjustments in command mode<br /> <br /> Stop adjusting the horizontal timing values based on the<br /> compression ratio in command mode. Bspec seems to be telling<br /> us to do this only in video mode, and this is also how the<br /> Windows driver does things.<br /> <br /> This should also fix a div-by-zero on some machines because<br /> the adjusted htotal ends up being so small that we end up with<br /> line_time_us==0 when trying to determine the vtotal value in<br /> command mode.<br /> <br /> Note that this doesn&amp;#39;t actually make the display on the<br /> Huawei Matebook E work, but at least the kernel no longer<br /> explodes when the driver loads.<br /> <br /> (cherry picked from commit 0b475e91ecc2313207196c6d7fd5c53e1a878525)

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iio: adc: ti-adc161s626: use DMA-safe memory for spi_read()<br /> <br /> Add a DMA-safe buffer and use it for spi_read() instead of a stack<br /> memory. All SPI buffers must be DMA-safe.<br /> <br /> Since we only need up to 3 bytes, we just use a u8[] instead of __be16<br /> and __be32 and change the conversion functions appropriately.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bridge: br_nd_send: validate ND option lengths<br /> <br /> br_nd_send() walks ND options according to option-provided lengths.<br /> A malformed option can make the parser advance beyond the computed<br /> option span or use a too-short source LLADDR option payload.<br /> <br /> Validate option lengths against the remaining NS option area before<br /> advancing, and only read source LLADDR when the option is large enough<br /> for an Ethernet address.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: ulpi: fix double free in ulpi_register_interface() error path<br /> <br /> When device_register() fails, ulpi_register() calls put_device() on<br /> ulpi-&gt;dev.<br /> <br /> The device release callback ulpi_dev_release() drops the OF node<br /> reference and frees ulpi, but the current error path in<br /> ulpi_register_interface() then calls kfree(ulpi) again, causing a<br /> double free.<br /> <br /> Let put_device() handle the cleanup through ulpi_dev_release() and<br /> avoid freeing ulpi again in ulpi_register_interface().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: usbtmc: Flush anchored URBs in usbtmc_release<br /> <br /> When calling usbtmc_release, pending anchored URBs must be flushed or<br /> killed to prevent use-after-free errors (e.g. in the HCD giveback<br /> path). Call usbtmc_draw_down() to allow anchored URBs to be completed.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: misc: usbio: Fix URB memory leak on submit failure<br /> <br /> When usb_submit_urb() fails in usbio_probe(), the previously allocated<br /> URB is never freed, causing a memory leak.<br /> <br /> Fix this by jumping to err_free_urb label to properly release the URB<br /> on the error path.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: dwc2: gadget: Fix spin_lock/unlock mismatch in dwc2_hsotg_udc_stop()<br /> <br /> dwc2_gadget_exit_clock_gating() internally calls call_gadget() macro,<br /> which expects hsotg-&gt;lock to be held since it does spin_unlock/spin_lock<br /> around the gadget driver callback invocation.<br /> <br /> However, dwc2_hsotg_udc_stop() calls dwc2_gadget_exit_clock_gating()<br /> without holding the lock. This leads to:<br /> - spin_unlock on a lock that is not held (undefined behavior)<br /> - The lock remaining held after dwc2_gadget_exit_clock_gating() returns,<br /> causing a deadlock when spin_lock_irqsave() is called later in the<br /> same function.<br /> <br /> Fix this by acquiring hsotg-&gt;lock before calling<br /> dwc2_gadget_exit_clock_gating() and releasing it afterwards, which<br /> satisfies the locking requirement of the call_gadget() macro.