Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Input: byd - synchronize timer deletion before freeing private data<br /> <br /> byd_disconnect() uses timer_delete() before freeing the driver&amp;#39;s private<br /> data. This does not wait for a running byd_clear_touch() callback, which<br /> dereferences the private data and its psmouse pointer. A callback racing<br /> with disconnect can therefore access the private data after it has been<br /> freed. The timer can also still be re-armed by byd_process_byte() while<br /> the disconnect is in progress.<br /> <br /> Use timer_shutdown_sync() before freeing the private data: it waits for<br /> a running callback and turns any later re-arm attempt into a no-op.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Input: iforce - validate input packet lengths<br /> <br /> iforce_process_packet() reads fixed fields from joystick, wheel and<br /> status packets without first checking their lengths. In particular, the<br /> shared hats-and-buttons helper unconditionally reads data[6]. The status<br /> tail is a sequence of 16-bit effect addresses, but an incomplete final<br /> address is also consumed. A successful zero-length USB URB additionally<br /> reads the packet ID before the common parser is called.<br /> <br /> Reject the zero-length USB transfer, require the seven-byte joystick and<br /> wheel prefixes and the two-byte status prefix, and consume only complete<br /> status-tail addresses.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Input: focaltech - fix array out-of-bounds in focaltech_process_rel_packet<br /> <br /> Make finger2 (and also finger1) unsigned, so that if the finger index in<br /> the packet is 0 then subtracting 1 creates an array index which overflows<br /> above the existing check for FOC_MAX_FINGERS, as the existing comment says<br /> it should, instead of writing to state-&gt;fingers[-1].

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Input: cs40l50-vibra - validate custom data from user space<br /> <br /> cs40l50_add() copies the custom data of an FF_PERIODIC/FF_CUSTOM effect<br /> straight from the ff_effect the user passed to EVIOCSFF, without<br /> requiring it to hold anything:<br /> <br /> work_data.custom_data = memdup_array_user(periodic-&gt;custom_data,<br /> periodic-&gt;custom_len,<br /> sizeof(s16));<br /> work_data.custom_len = periodic-&gt;custom_len;<br /> <br /> The driver then reads two words out of that buffer: custom_data[0] as the<br /> waveform bank in cs40l50_effect_bank_set(), and custom_data[1] as the<br /> index within the bank in cs40l50_effect_index_set(). Neither read is<br /> covered by a length check, and custom_len is fully user controlled:<br /> <br /> - custom_len == 0 makes memdup_array_user() call memdup_user() with a<br /> length of zero, which returns ZERO_SIZE_PTR rather than an error, so<br /> custom_data[0] dereferences it.<br /> <br /> - custom_len == 1 allocates two bytes. A bank of ROM or RAM keeps<br /> effect-&gt;type out of the OWT case, and custom_data[1] is then read one<br /> word past the allocation.<br /> <br /> The bank value itself is also mishandled. It is masked with<br /> CS40L50_CUSTOM_DATA_MASK (0xffff) but stored in an s16, so a<br /> custom_data[0] of 0x8000 or above wraps to a negative value that passes<br /> the "bank_type &gt;= CS40L50_WVFRM_BANK_NUM" test.<br /> cs40l50_effect_index_set() indexes vib-&gt;dsp.banks[] with it before the<br /> switch statement&amp;#39;s default case gets a chance to reject it:<br /> <br /> base_index = vib-&gt;dsp.banks[effect-&gt;type].base_index;<br /> max_index = vib-&gt;dsp.banks[effect-&gt;type].max_index;<br /> <br /> Require the two words the driver reads to be present, and hold the masked<br /> bank in a u32 so the existing upper-bound test covers the whole range.<br /> The da7280 haptic driver already range checks custom_len this way.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu: reject oversized IBs with per-ring packet limits<br /> <br /> On GFX rings, amdgpu_cs_p2_ib() passed user-supplied ib_bytes through<br /> to ib-&gt;length_dw without a limit, while ring_emit_ib() encodes length<br /> into packet fields. Oversized values can corrupt adjacent control bits<br /> and destabilize command submission.<br /> <br /> Add a per-ring IB packet size limit helper and reject command<br /> submissions exceeding the corresponding dword limit before IB<br /> allocation. Use the documented 20-bit limit for GFX/compute/SDMA/VPE,<br /> and apply the MM fallback limit for other ring types.<br /> <br /> (cherry picked from commit 7f48fa2cf62e3fa6c9c3870aa74988f773247e52)

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fbdev: core: Fix pointer desynchronization in fb_io_read()<br /> <br /> In fb_io_read(), if copy_to_user() performs a partial copy (e.g., due to<br /> a faulty user buffer), the loop adjusts the chunk size &amp;#39;c&amp;#39; and updates<br /> the remaining &amp;#39;count&amp;#39;. However, the hardware &amp;#39;src&amp;#39; pointer has already<br /> been eagerly advanced by the original chunk size.<br /> <br /> If the loop is allowed to continue, the read will resume from an<br /> incorrect, over-advanced offset. Since the remaining &amp;#39;count&amp;#39; was only<br /> decremented by the successful bytes, this desynchronization causes the<br /> next iterations to execute more hardware reads than originally bounded,<br /> eventually leading to out-of-bounds I/O reads.<br /> <br /> Fix this by breaking out of the loop immediately upon a partial<br /> copy_to_user(). A partial copy indicates a faulty user buffer, making<br /> subsequent read attempts futile. Breaking out ensures we return the<br /> number of successfully read bytes without risking out-of-bounds hardware<br /> accesses in subsequent mismatched iterations.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> powerpc/pseries: papr-phy-attest - validate cmd.length, plug mem leak<br /> <br /> In papr_phy_attest_create_handle(), the params-&gt;cmd.length is not<br /> validated before use, which can result in a buffer overlow. Check it and<br /> return -EINVAL if it is either 0 or exceeds sizeof(params-&gt;cmd).<br /> <br /> Also, params is freed on the success path but not error. Free it on<br /> errors after memory allocation. And free it on negative fd.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/panthor: skip zero-sized firmware sections<br /> <br /> panthor_fw_load_section_entry() skips BO creation when the firmware section<br /> VA range is empty. If such a section is added to the firmware section list,<br /> section-&gt;mem is left as NULL.<br /> <br /> Later reload and unplug paths iterate over all firmware sections and<br /> dereference section-&gt;mem, which can lead to a NULL pointer dereference.<br /> <br /> Zero-sized firmware sections are valid, so accept them as no-op entries but<br /> skip adding them to the section list.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Input: synaptics-rmi4 - block s_input when F54 queue is busy<br /> <br /> Changing the input (diagnostic report type) mid-stream changes the<br /> report size. Since V4L2 buffers are allocated based on the size at<br /> stream start, changing the input while streaming could lead to a<br /> heap buffer overflow if the new size is larger than the allocated<br /> buffers.<br /> <br /> Prevent this by blocking VIDIOC_S_INPUT with -EBUSY if the V4L2 queue<br /> is busy (streaming).

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Input: synaptics-rmi4 - bound the F54 report size to the allocated buffer<br /> <br /> rmi_f54_work() reads a diagnostics report from the device into<br /> f54-&gt;report_data, sizing the transfer with rmi_f54_get_report_size():<br /> <br /> report_size = rmi_f54_get_report_size(f54);<br /> ...<br /> for (i = 0; i report_data + i, size);<br /> }<br /> <br /> report_data is allocated once at probe from F54&amp;#39;s own electrode counts<br /> (array3_size(f54-&gt;num_tx_electrodes, f54-&gt;num_rx_electrodes, sizeof(u16))),<br /> but rmi_f54_get_report_size() computes the size from<br /> drv_data-&gt;num_*_electrodes when those are set, i.e. from the F55<br /> function&amp;#39;s electrode counts. Both counts come straight from device<br /> queries (F54 and F55 each report up to 255 electrodes) and nothing<br /> constrains the F55 counts to the F54 ones.<br /> <br /> A malicious or malfunctioning RMI4 device that reports larger F55<br /> electrode counts than its F54 counts makes report_size exceed the<br /> allocation, so the read loop writes past report_data (and the V4L2<br /> dequeue memcpy() then reads past it). On conforming hardware the F55<br /> configured electrodes are a subset of the F54 physical electrodes, so<br /> report_size never exceeds the buffer and well-behaved devices are<br /> unaffected.<br /> <br /> Record the allocation size and reject a report that does not fit,<br /> mirroring the existing zero-size check.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Input: synaptics-rmi4 - zero report size on F54 work error<br /> <br /> In rmi_f54_work(), if an error occurs during report request or command<br /> verification, the code jumped directly to the &amp;#39;error&amp;#39; label, bypassing<br /> the &amp;#39;abort&amp;#39; label where f54-&gt;report_size was normally zeroed out.<br /> <br /> This left f54-&gt;report_size containing its previous successful payload<br /> size. If a user then altered the V4L2 format to a smaller size, and a<br /> subsequent run failed, rmi_f54_buffer_queue() would copy the stale,<br /> larger payload size into the shrunken V4L2 buffer, causing a heap<br /> buffer overflow.<br /> <br /> Fix this by merging the &amp;#39;abort&amp;#39; and &amp;#39;error&amp;#39; labels into a single &amp;#39;out&amp;#39;<br /> exit path, and ensuring that f54-&gt;report_size is always set to 0 on<br /> failure by checking for error and zeroing the local report_size first.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Input: synaptics-rmi4 - propagate F54 worker errors to V4L2 queue<br /> <br /> Previously, rmi_f54_buffer_queue() waited for the worker thread to<br /> finish but ignored whether it succeeded. If the worker failed (e.g.,<br /> due to a timeout or register read failure), the queue thread would<br /> silently return success, delivering stale or uninitialized memory to<br /> userspace.<br /> <br /> Add a &amp;#39;report_error&amp;#39; field to struct f54_data to store the worker&amp;#39;s exit<br /> status. Check this field in rmi_f54_buffer_queue() after the worker<br /> finishes, and mark the buffer as VB2_BUF_STATE_ERROR if an error<br /> occurred.