Vulnerabilities

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

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.

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.

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.

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.

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.

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.

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.

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.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fuse-uring: end fuse_req on io-uring cancel task work<br /> <br /> When io_uring delivers task work with tw.cancel set (PF_EXITING,<br /> PF_KTHREAD fallback, or percpu_ref_is_dying on the ring context),<br /> fuse_uring_send_in_task() takes the cancel branch, assigns<br /> -ECANCELED, and falls through to fuse_uring_send(). That path only<br /> flips the entry to FRRS_USERSPACE and completes the io_uring cmd;<br /> it never discharges the ring entry&amp;#39;s owning reference to the<br /> fuse_req that fuse_uring_add_req_to_ring_ent() handed it at<br /> dispatch time.<br /> <br /> fuse_uring_send_in_task()<br /> tw.cancel == true<br /> err = -ECANCELED<br /> fuse_uring_send(ent, cmd, err, issue_flags)<br /> ent-&gt;state = FRRS_USERSPACE<br /> list_move(&amp;ent-&gt;list, &amp;queue-&gt;ent_in_userspace)<br /> ent-&gt;cmd = NULL<br /> io_uring_cmd_done(-ECANCELED)<br /> /* ent-&gt;fuse_req still set, req still hashed */<br /> <br /> The fuse_req stays linked on fpq-&gt;processing[hash] and<br /> fuse_request_end() is never invoked. The originating syscall<br /> thread blocks in D-state in request_wait_answer() until<br /> fuse_abort_conn() runs, which can be the entire connection<br /> lifetime. For FR_BACKGROUND requests fc-&gt;num_background is never<br /> decremented either, so repeated cancels inflate the counter until<br /> max_background is hit and all later background ops stall. tw.cancel does<br /> not imply a connection abort (e.g. a single io_uring worker thread exits<br /> while the fuse connection stays up), so this cannot be left for<br /> fuse_abort_conn() to clean up.<br /> <br /> Ending the req but still routing the entry through fuse_uring_send()<br /> is not enough: that leaves a req-less entry on ent_in_userspace, and<br /> ent_list_request_expired() dereferences ent-&gt;fuse_req unconditionally<br /> on the head of that list, which would then NULL-deref.<br /> <br /> Fix the cancel branch to release the entry directly. Remove it from the<br /> queue, complete the io_uring cmd, end the fuse_req, free the entry, and<br /> drop its queue_refs (waking the teardown waiter if it was the last).

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fuse-uring: fix moving cancelled entry to ent_in_userspace list<br /> <br /> fuse_uring_cancel() moves entries that are available (these have no reqs<br /> attached) to the ent_in_userspace list. ent_list_request_expired()<br /> checks the first entry on ent_in_userspace and dereferences<br /> ent-&gt;fuse_req unconditionally, which will crash on a cancelled entry<br /> that was moved to this list.<br /> <br /> Fix this by freeing the entry and dropping queue_refs directly in<br /> fuse_uring_cancel(). This is safe because cancel is the cancel handler<br /> itself - after io_uring_cmd_done(), no more cancels will be dispatched<br /> for this command, and teardown serializes with cancel via queue-&gt;lock.<br /> <br /> Since cancel now decrements queue_refs, fuse_uring_abort() must no<br /> longer gate fuse_uring_abort_end_requests() on queue_refs &gt; 0, as<br /> cancelled entries may have already dropped queue_refs while requests are<br /> still queued. Remove the gate so abort always flushes requests and stops<br /> queues.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fuse-uring: fix EFAULT clobber in fuse_uring_commit<br /> <br /> copy_from_user() returns the number of bytes not copied as an unsigned<br /> residual on failure (1..sizeof(struct fuse_out_header)). fuse_uring_commit<br /> stores that residual in ssize_t err, sets req-&gt;out.h.error to -EFAULT,<br /> then jumps to out: with err still holding the positive residual.<br /> <br /> err = copy_from_user(&amp;req-&gt;out.h, &amp;ent-&gt;headers-&gt;in_out,<br /> sizeof(req-&gt;out.h));<br /> if (err) {<br /> req-&gt;out.h.error = -EFAULT;<br /> goto out; /* err is the positive residual */<br /> }<br /> ...<br /> out:<br /> fuse_uring_req_end(ent, req, err);<br /> <br /> fuse_uring_req_end() then runs<br /> <br /> if (error)<br /> req-&gt;out.h.error = error;<br /> <br /> which overwrites the just-assigned -EFAULT with the positive residual.<br /> FUSE callers such as fuse_simple_request() test err out.args.<br /> <br /> Fix by assigning err = -EFAULT in the failure branch before jumping<br /> to out, so fuse_uring_req_end() receives a negative errno and sets<br /> req-&gt;out.h.error to -EFAULT.