Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: gadget: function: rndis: add length check for header<br /> <br /> Add a length check for the rndis header in rndis_rm_hdr, to ensure that<br /> MessageType, MessageLength, DataOffset, and DataLength fields are<br /> present before they are accessed.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> x86/bugs: Enable IBPB flush on BPF JIT allocation<br /> <br /> Enable hardening against JIT spraying when Spectre-v2 mitigations are in<br /> use. Specifically, issue an IBPB flush on BPF JIT memory reuse. Skip<br /> enabling the IBPB flush if the BPF dispatcher is already using a retpoline<br /> sequence.<br /> <br /> This hardening applies only when BPF-JIT is in use. Guard the enabling<br /> under CONFIG_BPF_JIT so that bugs.c still builds with CONFIG_BPF_JIT=n.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Support for hardening against JIT spraying<br /> <br /> The BPF JIT allocator packs many small programs into larger executable<br /> allocations and reuses space within those allocations as programs are<br /> loaded and freed. When fresh code is written into space that a previous<br /> program occupied, an indirect jump into the new program can reuse a branch<br /> prediction left behind by the old one.<br /> <br /> Flush the indirect branch predictors before reusing JIT memory so that<br /> indirect jumps into a newly written program don&amp;#39;t reuse predictions from an<br /> old program that occupied the same space.<br /> <br /> Introduce bpf_arch_pred_flush_enabled static key and bpf_arch_pred_flush<br /> static call for flushing the branch predictors on JIT memory reuse.<br /> Architectures that need a flush, can update it to a predictor flush<br /> function. By default, its a NOP and does not emit any CALL.<br /> <br /> Allocations larger than a pack are not covered by this flush. That is safe<br /> because cBPF programs (the unprivileged attack surface) are bounded well<br /> below a pack size. Issue a warning if this assumption is ever violated<br /> while the flush is active.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iio: temperature: tmp006: use devm_iio_trigger_register<br /> <br /> tmp006_probe() allocates the DRDY trigger with devm_iio_trigger_alloc()<br /> but registers it with plain iio_trigger_register(). The driver has no<br /> .remove() callback, so on module unload the trigger stays in the global<br /> trigger list while its memory is freed by devm, leaving a dangling<br /> entry.<br /> <br /> Switch to devm_iio_trigger_register() so the registration is undone in<br /> the same devm scope as the allocation.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iio: pressure: mpl115: fix runtime PM leak on read error<br /> <br /> mpl115_read_raw() takes a runtime PM reference with pm_runtime_get_sync()<br /> before reading the processed pressure or raw temperature, but on the read<br /> error path it returns without calling pm_runtime_put_autosuspend(). Each<br /> failed read therefore leaks a runtime PM reference and prevents the device<br /> from autosuspending.<br /> <br /> Drop the reference before checking the return value so both the success<br /> and error paths are balanced.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iio: light: gp2ap002: fix runtime PM leak on read error<br /> <br /> gp2ap002_read_raw() calls pm_runtime_get_sync() before reading the<br /> lux value, but if gp2ap002_get_lux() fails, it returns directly. This<br /> skips the pm_runtime_put_autosuspend() call at the "out" label,<br /> permanently leaking a runtime PM reference and preventing the device<br /> from autosuspending.<br /> <br /> Replace the direct return with a "goto out" to ensure the reference<br /> is properly dropped on the error path.

*** Pendiente de traducción *** 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

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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.

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