Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iio: gyro: bmg160: bail out when bandwidth/filter is not in table<br /> <br /> bmg160_get_filter() walks bmg160_samp_freq_table[] looking for the entry<br /> matching the bw_bits value read from the chip:<br /> <br /> for (i = 0; i

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.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iio: chemical: scd30: Cleanup initializations and fix sign-extension bug<br /> <br /> Include linux/bitfield.h for FIELD_GET().<br /> <br /> Create new macros for bit manipulation in combination with manual bit<br /> manipulation being replaced with FIELD_GET().<br /> <br /> The current variable declaration and initializations are barely readable<br /> and use comma separations across multiple lines. Refactor the<br /> initializations so that mantissa and exp have separate declarations and<br /> sign gets initialized later.<br /> <br /> In addition (and due to the nature of the cleanup), fix a sign-extension<br /> bug where, float32 would get bitwise anded with ~BIT(31)<br /> (which is 0xFFFFFFFF7FFFFFFF) which corrupted the exponent.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iio: buffer: hw-consumer: free scan_mask on buffer release<br /> <br /> The scan_mask lifetime changed in commit 9a2e1233d38c ("iio: buffer:<br /> hw-consumer: remove redundant scan_mask flexible array").<br /> <br /> Before that change, the scan mask storage was embedded in struct<br /> hw_consumer_buffer, so iio_hw_buf_release() could free the whole<br /> allocation with a single kfree(hw_buf).<br /> <br /> That commit moved the scan mask to a separate bitmap_zalloc() allocation<br /> stored in buffer.scan_mask, but left iio_hw_buf_release() unchanged.<br /> <br /> Free the scan mask in iio_hw_buf_release() before freeing the buffer<br /> wrapper.

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.

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().

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.

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.

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.

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.

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.

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.