Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mptcp: fastopen: only mark MPTFO subflows with SYN data<br /> <br /> Passive TCP Fast Open accepts a valid-cookie SYN even when it carries<br /> no data. In that case the child socket&amp;#39;s receive queue is intentionally<br /> left empty.<br /> <br /> mptcp_fastopen_subflow_synack_set_params() set is_mptfo before checking<br /> for queued SYN data. That made data-less TFO SYNs hit a WARN and, if<br /> the warning was non-fatal, left stale MPTFO state behind. The stale<br /> flag could later trigger a state-confusion bug in<br /> check_fully_established().<br /> <br /> Only mark the subflow as MPTFO after confirming that an SKB was queued.<br /> Return quietly when the receive queue is empty.<br /> <br /> Note that mptcp_subflow_context&amp;#39;s is_mptfo field is now not just about<br /> subflows where the TFO was present, but about MPTFO subflow that<br /> consumed SYN data. Only having a valid cookie but not carrying data is<br /> not really "doing TFO".

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mptcp: options: reset DSS fields in case of unexpected size<br /> <br /> A remote peer could send a malformed DSS with a wrong size, followed by<br /> another DSS or MPC + Data. In this case, the first suboption will be<br /> ignored, but leaving some fields written, which could lead to<br /> inconsistency or access uninitialized data.<br /> <br /> Explicitly reset the fields that could have been modified in case of<br /> unexpected size.

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

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