Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fpga: dfl-afu: validate DMA mapping length in afu_dma_map_region()<br /> <br /> afu_ioctl_dma_map() accepts a 64-bit length from userspace via<br /> DFL_FPGA_PORT_DMA_MAP ioctl without an upper bound check. The value<br /> is passed to afu_dma_pin_pages() where npages is derived as<br /> length &gt;&gt; PAGE_SHIFT and passed to pin_user_pages_fast() which takes<br /> int nr_pages, causing implicit truncation if length is very large.<br /> <br /> Validate map.length at the ioctl entry point before calling<br /> afu_dma_map_region(), rejecting values whose page count exceeds<br /> INT_MAX.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/siw: bound Read Response placement to the RREAD length<br /> <br /> In drivers/infiniband/sw/siw/siw_qp_rx.c, siw_proc_rresp() places each<br /> inbound Read Response DDP segment at sge-&gt;laddr + wqe-&gt;processed and then<br /> accumulates wqe-&gt;processed, but it never checks the running total against<br /> the sink buffer length on continuation segments. siw_check_sge() resolves<br /> and validates the sink memory only on the first fragment (the if (!*mem)<br /> branch), and siw_rresp_check_ntoh() compares the cumulative length against<br /> wqe-&gt;bytes only on the final segment (the !frx-&gt;more_ddp_segs guard).<br /> <br /> A connected siw peer that answers an outstanding RREAD with Read Response<br /> segments that keep the DDP Last flag clear, carrying more total payload<br /> than the RREAD requested, drives wqe-&gt;processed past the validated sink<br /> buffer; the next siw_rx_data() call writes out of bounds at<br /> sge-&gt;laddr + wqe-&gt;processed. siw runs iWARP over ordinary routable TCP,<br /> so the peer is the remote end of an established RDMA connection and needs<br /> no local privilege.<br /> <br /> Bound every segment before placement, exactly as siw_proc_send() and<br /> siw_proc_write() already do for their tagged and untagged paths, and<br /> terminate the connection with a base-or-bounds DDP error when the<br /> Read Response would overrun the sink buffer.<br /> <br /> This is the second receive-path length fix for this file. A separate<br /> change rejects an MPA FPDU length that underflows the per-fragment<br /> remainder in the header decode; that guard does not cover this case,<br /> because here each individual segment length is self-consistent and only<br /> the accumulated placement offset overruns the buffer.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/rtrs-srv: Bound RDMA-Write length to chunk size in rdma_write_sg<br /> <br /> When the server answers an RTRS READ, rdma_write_sg() builds the source<br /> scatter/gather entry for the IB_WR_RDMA_WRITE that returns data to the<br /> peer. Its length is taken directly from the wire descriptor:<br /> <br /> plist-&gt;length = le32_to_cpu(id-&gt;rd_msg-&gt;desc[0].len);<br /> <br /> rd_msg points into the chunk buffer that the remote peer filled via<br /> RDMA-WRITE-WITH-IMM (rtrs_srv_rdma_done() -&gt; process_io_req() -&gt;<br /> process_read()), so desc[0].len is attacker-controlled and, before this<br /> change, was only rejected when zero. The source address is the fixed<br /> chunk start (dma_addr[msg_id]) and the source lkey is the PD-wide<br /> local_dma_lkey, which is not tied to the chunk&amp;#39;s MR mapping, so the verbs<br /> layer does not constrain the transfer length to max_chunk_size. msg_id<br /> and off are bounded against queue_depth and max_chunk_size in<br /> rtrs_srv_rdma_done(), but desc[0].len is a separate field that was not<br /> checked against the chunk size.<br /> <br /> A peer that advertises desc[0].len larger than max_chunk_size can make<br /> the posted RDMA write read past the chunk&amp;#39;s mapped region. The resulting<br /> behaviour depends on the IOMMU configuration: with no IOMMU or in<br /> passthrough mode the read may extend into memory adjacent to the chunk<br /> and be returned to the peer, which can disclose host memory; with a<br /> translating IOMMU the out-of-range access is expected to fault and abort<br /> the connection. In either case the transfer exceeds what the protocol<br /> permits and is driven by a remote peer.<br /> <br /> Reject a descriptor length above max_chunk_size, mirroring the existing<br /> off &gt;= max_chunk_size bound in rtrs_srv_rdma_done(). Legitimate clients<br /> do not exceed it: the client sets desc[0].len to its MR length, which is<br /> capped at the negotiated max_io_size (max_chunk_size - MAX_HDR_SIZE).

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Input: mms114 - reject an oversized device packet size<br /> <br /> mms114_interrupt() reads a packet of touch data from the device into a<br /> fixed-size on-stack buffer<br /> <br /> struct mms114_touch touch[MMS114_MAX_TOUCH];<br /> <br /> which holds MMS114_MAX_TOUCH (10) events of MMS114_EVENT_SIZE (8) bytes,<br /> i.e. 80 bytes. The length of the I2C read into it is taken verbatim from<br /> the device:<br /> <br /> packet_size = mms114_read_reg(data, MMS114_PACKET_SIZE);<br /> if (packet_size

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Input: touchwin - reset the packet index on every complete packet<br /> <br /> tw_interrupt() accumulates each non-zero serial byte into a fixed<br /> three-byte buffer with a running index that is only reset once a full<br /> packet has been received *and* the device&amp;#39;s two Y bytes agree:<br /> <br /> tw-&gt;data[tw-&gt;idx++] = data;<br /> if (tw-&gt;idx == TW_LENGTH &amp;&amp; tw-&gt;data[1] == tw-&gt;data[2]) {<br /> ...<br /> tw-&gt;idx = 0;<br /> }<br /> <br /> The reset is gated on tw-&gt;data[1] == tw-&gt;data[2], a value the device<br /> controls. A malicious, malfunctioning or counterfeit Touchwindow<br /> peripheral can stream non-zero bytes whose 2nd and 3rd bytes differ: the<br /> index reaches TW_LENGTH without the equality holding, is never reset, and<br /> keeps growing, so tw-&gt;data[tw-&gt;idx++] walks off the end of the three-byte<br /> array and the rest of the heap-allocated struct tw, one attacker-chosen<br /> byte at a time -- an unbounded, device-driven heap out-of-bounds write.<br /> <br /> Reset the index on every completed packet and report an event only when<br /> the two Y bytes match, like the other serio touchscreen drivers do.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Input: mms114 - fix touch indexing for MMS134S and MMS136<br /> <br /> The MMS134S and MMS136 touch controllers have an event size of 6 bytes<br /> rather than 8 bytes. When __mms114_read_reg() reads the touch data<br /> packet from the device into the touch buffer, the events are packed<br /> tightly at 6-byte intervals. However, the driver iterates through the<br /> events using standard C array indexing (touch[index]), where each<br /> element is sizeof(struct mms114_touch) (8 bytes) apart. As a result, any<br /> touch events beyond the first one are read from incorrect offsets and<br /> parsed improperly.<br /> <br /> Fix this by explicitly calculating the byte offset for each touch event<br /> based on the device&amp;#39;s specific event size.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Input: iforce - bound the device-reported force-feedback effect index<br /> <br /> iforce_process_packet() handles a status report (packet id 0x02) by<br /> taking a force-feedback effect index straight from the device wire and<br /> using it to address the per-effect state array:<br /> <br /> i = data[1] &amp; 0x7f;<br /> if (data[1] &amp; 0x80) {<br /> if (!test_and_set_bit(FF_CORE_IS_PLAYED,<br /> iforce-&gt;core_effects[i].flags))<br /> ...<br /> } else if (test_and_clear_bit(FF_CORE_IS_PLAYED,<br /> iforce-&gt;core_effects[i].flags)) {<br /> ...<br /> }<br /> <br /> The index is masked only with 0x7f, so it ranges 0..127, but<br /> core_effects[] holds only IFORCE_EFFECTS_MAX (32) entries. For an index<br /> of 32..127 the test_and_set_bit()/test_and_clear_bit() is an<br /> out-of-bounds single-bit read-modify-write past the array. core_effects[]<br /> is the second-to-last member of struct iforce, so the write lands in the<br /> trailing members and beyond the embedding kzalloc()&amp;#39;d iforce_serio /<br /> iforce_usb object.<br /> <br /> data[1] is unvalidated device payload on both transports (the USB<br /> interrupt endpoint and serio), and the status path is not gated on force<br /> feedback being present, so a malicious or counterfeit device can set or<br /> clear a bit at an attacker-chosen offset past the object.<br /> <br /> Reject an out-of-range index instead of indexing with it. Bound against<br /> the array dimension IFORCE_EFFECTS_MAX rather than dev-&gt;ff-&gt;max_effects so<br /> the check guarantees memory safety regardless of how many effects the<br /> device registered. A legitimate "effect started/stopped" status always<br /> carries an index below IFORCE_EFFECTS_MAX, so well-formed devices are<br /> unaffected; the neighbouring mark_core_as_ready() loop is already bounded<br /> and is left untouched.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Input: goodix - clamp the device-reported contact count<br /> <br /> goodix_ts_read_input_report() copies the number of touch points reported<br /> by the device into an on-stack buffer<br /> <br /> u8 point_data[2 + GOODIX_MAX_CONTACT_SIZE * GOODIX_MAX_CONTACTS];<br /> <br /> which is sized for at most GOODIX_MAX_CONTACTS (10) contacts. The only<br /> runtime check bounds the per-interrupt count against ts-&gt;max_touch_num,<br /> but that value is taken verbatim from a 4-bit field of the device<br /> configuration block and is never clamped:<br /> <br /> ts-&gt;max_touch_num = ts-&gt;config[MAX_CONTACTS_LOC] &amp; 0x0f;<br /> <br /> The nibble can be 0..15, so a malfunctioning, malicious or counterfeit<br /> controller (or an attacker tampering with the I2C bus) can advertise up<br /> to 15 contacts. goodix_ts_read_input_report() then accepts a touch_num<br /> of up to 15 and the second goodix_i2c_read() writes<br /> ts-&gt;contact_size * (touch_num - 1) bytes past the one-contact header into<br /> point_data - up to 30 bytes (45 with the 9-byte report format) beyond the<br /> 92-byte buffer: a stack out-of-bounds write.<br /> <br /> Clamp max_touch_num to GOODIX_MAX_CONTACTS, the number of contacts<br /> point_data[] is sized for, when reading it from the configuration.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Input: elan_i2c - prevent division by zero and arithmetic underflow<br /> <br /> The Elan I2C touchpad driver queries the device for its physical<br /> dimensions and trace counts to calculate the device resolution and width.<br /> However, if the device firmware or device tree provides invalid zero<br /> values for x_traces or y_traces, it results in a fatal division-by-zero<br /> exception leading to a kernel panic during device probe.<br /> <br /> Add checks to ensure these parameters are non-zero before performing<br /> the division. If invalid trace values are detected, fall back to a safe<br /> default of 1.<br /> <br /> Additionally, prevent an arithmetic underflow in the touch reporting<br /> logic. Previously, if the calculated or fallback width was smaller than<br /> ETP_FWIDTH_REDUCE (90), the subtraction would underflow, resulting in a<br /> massive unsigned integer being reported to userspace. Clamp the adjusted<br /> width to a minimum of 0 to safely handle small physical dimensions and<br /> fallback scenarios.<br /> <br /> Completing the probe with safe fallback values ensures the sysfs nodes<br /> are created, keeping the firmware update path intact so a recovery<br /> firmware can be flashed to the device.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fuse-uring: make a fuse_req on SQE commit only findable after memcpy<br /> <br /> Bad userspace might try to trick us and send commit SQEs request<br /> unique / commit-id of requests that are not even send to<br /> fuse-server (io_uring_cmd_done() not called) yet.<br /> <br /> fuse_uring_commit_fetch() ends the fuse request when the ring entry<br /> has a wrong state, but that could have caused a use-after-free<br /> with the memcpy operations in fuse_uring_send_in_task().<br /> In order to avoid such races the call of fuse_uring_add_to_pq()<br /> is moved after the copy operations and just before completing<br /> the io-uring request - malicious userspace cannot find the request<br /> anymore until all prepration work in fuse-client/kernel is completed.<br /> <br /> This also moves fuse_uring_add_to_pq() a bit up in the code to<br /> avoid a forward declaration. Also not with a preparation commit,<br /> to make it easier to back port to older kernels.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fuse-uring: Avoid queue-&gt;stopped races and set/read that value under lock<br /> <br /> There are several readers of queue-&gt;stopped that check the value<br /> under lock, but fuse_uring_commit_fetch() did not and actually<br /> the value was not set under the lock in fuse_uring_abort_end_requests()<br /> either. Especially in fuse_uring_commit_fetch it is important<br /> to check under a lock, because due to races &amp;#39;struct fuse_req&amp;#39;<br /> might be freed with fuse_request_end, but another thread/cpu<br /> might already do teardown work.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fuse-uring: Avoid use-after-free in fuse_uring_async_stop_queues<br /> <br /> fuse_uring_async_stop_queues() might run when the last reference<br /> on ring-&gt;queue_refs was already dropped.<br /> <br /> In order to avoid an early destruction a reference on struct fuse_conn<br /> is now taken before starting fuse_uring_async_stop_queues() and that<br /> reference is only released when that delayed work queue terminates.