Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iio: adc: ti-ads1119: fix PM reference leak in buffer preenable<br /> <br /> ads1119_triggered_buffer_preenable() resumes the device with<br /> pm_runtime_resume_and_get() before starting a conversion.<br /> <br /> If i2c_smbus_write_byte() fails, the function returns the error directly<br /> and leaves the runtime PM usage counter elevated. The matching<br /> postdisable callback is not called when preenable fails, so the reference<br /> is leaked and the device may remain runtime-active indefinitely.<br /> <br /> Store the I2C transfer result in ret and drop the runtime PM reference on<br /> failure before returning the error.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iio: adc: lpc32xx: Initialize completion before requesting IRQ<br /> <br /> In the report from Jaeyoung Chung:<br /> <br /> "lpc32xx_adc_probe() in drivers/iio/adc/lpc32xx_adc.c registers its<br /> interrupt handler with devm_request_irq() before it initializes<br /> st-&gt;completion with init_completion(). If an interrupt arrives after<br /> devm_request_irq() and before init_completion(), the handler calls<br /> complete() on an uninitialized completion, causing a kernel panic.<br /> <br /> The probe path, in lpc32xx_adc_probe():<br /> <br /> iodev = devm_iio_device_alloc(&amp;pdev-&gt;dev, sizeof(*st)); /* st kzalloc-zeroed */<br /> ...<br /> retval = devm_request_irq(&amp;pdev-&gt;dev, irq, lpc32xx_adc_isr, 0,<br /> LPC32XXAD_NAME, st); /* register handler */<br /> ...<br /> init_completion(&amp;st-&gt;completion); /* initialize completion */<br /> <br /> lpc32xx_adc_isr() calls complete():<br /> <br /> complete(&amp;st-&gt;completion);<br /> <br /> If the device raises an interrupt before init_completion() runs,<br /> complete() acquires the uninitialized wait.lock and walks the zeroed<br /> task_list in swake_up_locked(). The zeroed task_list makes list_empty()<br /> return false, so swake_up_locked() dereferences a NULL list entry,<br /> triggering a KASAN wild-memory-access."<br /> <br /> Fix the chance of a spurious IRQ causing an uninitialized pointer<br /> dereference by moving init_completion() above devm_request_irq().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iio: event: Fix event FIFO reset race<br /> <br /> `iio_event_getfd()` creates the event file descriptor with<br /> `anon_inode_getfd()`, which allocates a new fd, creates the anonymous<br /> file and installs it in the process fd table before returning to the<br /> caller.<br /> <br /> The IIO code resets the event FIFO after `anon_inode_getfd()` has returned,<br /> but before `IIO_GET_EVENT_FD_IOCTL` has copied the fd number to userspace.<br /> But since fd tables are shared between threads, another thread can guess<br /> the newly allocated fd number and issue a `read()` on it as soon as the fd<br /> has been installed.<br /> <br /> This means the `kfifo_to_user()` in `iio_event_chrdev_read()` can run in<br /> parallel with the `kfifo_reset_out()` in `iio_event_getfd()`.<br /> <br /> The kfifo documentation says that `kfifo_reset_out()` is only safe when it<br /> is called from the reader thread and there is only one concurrent reader.<br /> Otherwise it is dangerous and must be handled in the same way as<br /> `kfifo_reset()`.<br /> <br /> If that happens, `kfifo_to_user()` can advance the FIFO `out` index based<br /> on state from before the reset, after the reset has already moved the `out`<br /> index to the current `in` index. That can leave the FIFO with an `out`<br /> index past the `in` index. A later `read()` can then see an underflowed<br /> FIFO length and copy more data than the event FIFO buffer contains. This<br /> can result in an out-of-bounds read and leak adjacent kernel memory to<br /> userspace.<br /> <br /> Move the FIFO reset before `anon_inode_getfd()`. At that point the event fd is<br /> marked busy, but the new fd has not been installed yet, so userspace cannot<br /> access it while the FIFO is reset.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: es1938: check snd_ctl_new1() return value<br /> <br /> snd_ctl_new1() can return NULL when memory allocation fails.<br /> snd_es1938_mixer() does not check the return value before dereferencing<br /> the pointer, which can lead to a NULL pointer dereference.<br /> <br /> Add a NULL check after snd_ctl_new1() and return -ENOMEM if it fails.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: cmipci: check snd_ctl_new1() return value<br /> <br /> snd_ctl_new1() can return NULL when memory allocation fails.<br /> snd_cmipci_spdif_controls() does not check the return value before<br /> dereferencing kctl-&gt;id.device, which can lead to a NULL pointer<br /> dereference.<br /> <br /> Add NULL checks after snd_ctl_new1() calls and return -ENOMEM if any<br /> fails.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: caiaq: fix out-of-bounds read in the Traktor Kontrol S4 input parser<br /> <br /> snd_usb_caiaq_tks4_dispatch() decodes the Traktor Kontrol S4 input<br /> stream in fixed 16-byte (TKS4_MSGBLOCK_SIZE) message blocks. On every<br /> iteration it advances buf and subtracts the block size while looping on<br /> "while (len)".<br /> <br /> len is urb-&gt;actual_length. That value is supplied by the device and is<br /> not guaranteed to be a multiple of 16. When a final short block leaves<br /> len between 1 and 15, the loop runs once more, reads up to buf[15], and<br /> then does "len -= TKS4_MSGBLOCK_SIZE". As len is unsigned this underflows<br /> to a huge value. The loop then keeps iterating and walking buf far past<br /> the end of the 512-byte ep4_in_buf, reading out of bounds until a bogus<br /> block id happens to be hit.<br /> <br /> Iterate only while a full message block is available. This stops the<br /> unsigned underflow and silently drops any trailing partial block, which<br /> carries no complete control value anyway.<br /> <br /> The sibling endpoint-4 parsers are not affected. The Traktor Kontrol X1<br /> and Maschine arms in snd_usb_caiaq_ep4_reply_dispatch() floor<br /> urb-&gt;actual_length before dispatching.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: aoa: check snd_ctl_new1() return value<br /> <br /> snd_ctl_new1() can return NULL when memory allocation fails. In<br /> layout.c, the function does not check the return value before<br /> dereferencing ctl-&gt;id.name or passing to aoa_snd_ctl_add(), which can<br /> lead to a NULL pointer dereference.<br /> <br /> Add NULL checks after snd_ctl_new1() calls and return early if any<br /> fails.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: ymfpci: check snd_ctl_new1() return value<br /> <br /> snd_ctl_new1() can return NULL when memory allocation fails.<br /> snd_ymfpci_create_spdif_controls() does not check the return value<br /> before dereferencing kctl-&gt;id.device, which can lead to a NULL pointer<br /> dereference.<br /> <br /> Add NULL checks after snd_ctl_new1() calls and return -ENOMEM if any<br /> fails.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: usx2y: us144mkii: fix work UAF on disconnect<br /> <br /> tascam_disconnect() cancels capture_work and midi_in_work before<br /> usb_kill_anchored_urbs() kills the capture/MIDI-in URBs. Those URBs<br /> self-resubmit, and their completion handlers reschedule the work.<br /> <br /> A URB that completes in the small window between cancel_work_sync() and<br /> usb_kill_anchored_urbs() therefore re-arms the work after its only<br /> cancel. Nothing cancels it again before snd_card_free() frees the<br /> card-private tascam structure, so the work handler then runs on freed<br /> memory.<br /> <br /> Kill the anchored URBs before cancelling the work; once the work is<br /> cancelled no remaining URB can complete to re-arm it.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: compress: Fix task creation error unwind<br /> <br /> snd_compr_task_new() allocates the driver task before validating the<br /> returned DMA buffers and reserving file descriptors. When either of<br /> those later steps fails, the core frees its task wrapper and DMA-buffer<br /> references without calling the driver&amp;#39;s task_free() callback. Any<br /> driver resources allocated by task_create() are therefore leaked.<br /> <br /> The dual-fd allocation path also jumps to cleanup without storing the<br /> negative get_unused_fd_flags() result in retval. Since retval still<br /> contains the successful task_create() return value, TASK_CREATE can<br /> incorrectly report success although the task was discarded.<br /> <br /> Preserve the fd allocation errors and call task_free() when failure<br /> occurs after a successful task_create() callback.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: virtio: Validate control metadata from the device<br /> <br /> virtio-snd control handling trusts the device-provided control type and<br /> value count returned by the device.<br /> <br /> That metadata is then used directly to index g_v2a_type_map[] in<br /> virtsnd_kctl_info(), and to size loops and memcpy() operations in<br /> virtsnd_kctl_get() and virtsnd_kctl_put() against fixed-size<br /> virtio_snd_ctl_value and snd_ctl_elem_value arrays.<br /> <br /> A buggy or malicious device can therefore trigger out-of-bounds access by<br /> advertising an invalid control type or an oversized value count.<br /> <br /> Validate control type and count once in virtsnd_kctl_parse_cfg(), before<br /> querying enumerated items or exposing the control to ALSA.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vfio/pci: Latch disable_idle_d3 per device<br /> <br /> When disable_idle_d3 was introduced in vfio-pci, it directly manipulated<br /> the device power state with pci_set_power_state(). There were no<br /> refcounts to maintain or balanced operations, we could unconditionally<br /> bring the device to D0 and conditionally move it to D3hot. Therefore<br /> the module parameter was made writable.<br /> <br /> Later, in commit c61302aa48f7 ("vfio/pci: Move module parameters to<br /> vfio_pci.c"), as part of the vfio-pci-core split, the writable aspect<br /> of the module parameter was nullified. The parameter value could still<br /> be changed through sysfs, but the vfio-pci driver latched the values<br /> into vfio-pci-core globals at module init. Loading the vfio-pci module,<br /> or unloading and reloading, with non-default or different values could<br /> change the globals relative to existing devices bound to vfio-pci<br /> variant drivers.<br /> <br /> Runtime PM was introduced in commit 7ab5e10eda02 ("vfio/pci: Move the<br /> unused device into low power state with runtime PM"), which marks the<br /> point where power states became refcounted. PM get and put operations<br /> need to be balanced, but the same module operations noted above can<br /> change the global variables relative to those devices already bound to<br /> vfio-pci variant drivers. This introduces a window where PM operations<br /> can now become unbalanced.<br /> <br /> To resolve this with a narrow footprint for stable backports, the<br /> disable_idle_d3 flag is latched into the vfio_pci_core_device at the<br /> time of initialization, such that the device always operates with a<br /> consistent value.<br /> <br /> NB. vfio_pci_dev_set_try_reset() now unconditionally raises the<br /> runtime PM usage count around bus reset to account for disable_idle_d3<br /> becoming a per-device rather than global flag. When this flag is set,<br /> the additional get/put pair is harmless and allows continued use of the<br /> shared vfio_pci_dev_set_pm_runtime_get() helper.