Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> HID: multitouch: fix out-of-bounds bit access on mt_io_flags<br /> <br /> mt_io_flags is a single unsigned long, but mt_process_slot(),<br /> mt_release_pending_palms() and mt_release_contacts() use it as a<br /> per-slot bitmap indexed by the slot number. That slot number is only<br /> bounded by td-&gt;maxcontacts, which is taken from the device&amp;#39;s<br /> ContactCountMaximum feature report and can be up to 255, not by<br /> BITS_PER_LONG.<br /> <br /> As a result, a multitouch device that advertises a large contact count<br /> makes set_bit()/clear_bit() operate past the mt_io_flags word and<br /> corrupt the adjacent members of struct mt_device. The sticky-fingers<br /> release timer is the easiest way to reach this. mt_release_contacts()<br /> runs<br /> <br /> for (i = 0; i num_slots; i++)<br /> clear_bit(i, &amp;td-&gt;mt_io_flags);<br /> <br /> with num_slots == maxcontacts. For maxcontacts around 250 the loop<br /> clears the bits that overlap td-&gt;applications.next, zeroing that list<br /> head, and the list_for_each_entry() that immediately follows then<br /> dereferences NULL. The kernel panics from timer (softirq) context. On a<br /> KASAN build this shows up as a general protection fault in<br /> mt_release_contacts() with a null-ptr-deref at offset 0x58, which is<br /> offsetof(struct mt_application, num_received).<br /> <br /> The state is reachable from an untrusted USB or Bluetooth HID<br /> multitouch device; no local privileges are required.<br /> <br /> Store the per-slot active state in a separately allocated bitmap sized<br /> for maxcontacts, the same pattern already used for pending_palm_slots,<br /> and keep only MT_IO_FLAGS_RUNNING in mt_io_flags. The two<br /> "mt_io_flags &amp; MT_IO_SLOTS_MASK" arming checks become<br /> bitmap_empty(td-&gt;active_slots, td-&gt;maxcontacts).<br /> <br /> Move MT_IO_FLAGS_RUNNING back to bit 0. It was bumped to bit 32 by the<br /> same commit to leave the low byte for the slot bits; with the slot bits<br /> gone it fits in bit 0 again, which also keeps it within the unsigned<br /> long on 32-bit.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> HID: wacom: fix slab-out-of-bounds write in wacom_wac_queue_insert<br /> <br /> wacom_wac_queue_insert() calls kfifo_skip() in a loop when the kfifo<br /> doesn&amp;#39;t have enough space for the incoming report. If the kfifo is<br /> empty, kfifo_skip() reads stale data left in the kmalloc&amp;#39;d buffer<br /> via __kfifo_peek_n() and interprets it as a record length, advancing<br /> fifo-&gt;out by that garbage value. This corrupts the internal kfifo<br /> state, causing kfifo_unused() to return a value much larger than the<br /> actual buffer size, which bypasses __kfifo_in_r()&amp;#39;s guard:<br /> <br /> if (len + recsize &gt; kfifo_unused(fifo))<br /> return 0;<br /> <br /> kfifo_copy_in() then performs an out-of-bounds memcpy, writing up to<br /> 3842 bytes past the 256-byte buffer.<br /> <br /> Add a !kfifo_is_empty() condition to the while loop so kfifo_skip()<br /> is never called on an empty fifo, and check the return value of<br /> kfifo_in() to reject reports that are too large for the fifo.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> HID: hid-goodix-spi: validate report size to prevent stack buffer overflow<br /> <br /> goodix_hid_set_raw_report() builds a protocol frame in a 128-byte stack<br /> buffer (tmp_buf), writing an 11-12 byte header followed by the<br /> caller-supplied report data. The HID core caps report size at<br /> HID_MAX_BUFFER_SIZE (16384) by default, while the driver does not set<br /> hid_ll_driver.max_buffer_size and performs no bounds checking before<br /> copying the payload:<br /> <br /> memcpy(tmp_buf + tx_len, buf, len);<br /> <br /> A hidraw SET_REPORT ioctl with a report larger than ~116 bytes<br /> overflows the stack buffer.<br /> <br /> Add a size check after constructing the header, rejecting reports that<br /> would exceed the buffer capacity.<br /> <br /> Discovered by Atuin - Automated Vulnerability Discovery Engine.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/slab: do not limit zeroing to orig_size when only red zoning is enabled<br /> <br /> When init (zeroing) on allocation is requested, for kmalloc() we<br /> generally have to zero the full object size even if a smaller size is<br /> requested, in order to provide krealloc()&amp;#39;s __GFP_ZERO guarantees.<br /> <br /> But if we track the requested size, krealloc() uses that information to<br /> do the right thing, so we can zero only the requested size. With red<br /> zoning also enabled, any extra size became part of the red zone, so it<br /> must not be zeroed and thus we must zero only the requested size.<br /> <br /> However the current check is imprecise, and will trigger also when only<br /> SLAB_RED_ZONE is enabled without SLAB_STORE_USER (which enables tracking<br /> the requested size). This means enabling red zoning alone can compromise<br /> krealloc()&amp;#39;s __GFP_ZERO contract.<br /> <br /> Fix this by using slub_debug_orig_size() instead, which is the exact<br /> check for whether the requested size is tracked. We don&amp;#39;t need to care<br /> if red zoning is also enabled or not. Also update and expand the<br /> comment accordingly.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xfs: fix memory leak in xfs_dqinode_metadir_create()<br /> <br /> If xfs_metadir_create() fails in xfs_dqinode_metadir_create(), the current<br /> code returns directly, leaking the allocated update and transaction state.<br /> If the subsequent commit fails, the caller-owned inode reference is left<br /> behind.<br /> <br /> Fix this memory leak by routing the create failure path through<br /> xfs_metadir_cancel(). For both create and commit failures, finish and<br /> release any inode returned to the caller, mirroring the unwind pattern in<br /> xfs_metadir_mkdir().<br /> <br /> The bug was first flagged by an experimental analysis tool we are<br /> developing for kernel memory-management bugs while analyzing<br /> v6.13-rc1. The tool is still under development and is not yet publicly<br /> available. Manual inspection confirms that the bug is still<br /> present in v7.1.1.<br /> <br /> An x86_64 allyesconfig build showed no new warnings. Runtime validation<br /> used kprobe fault injection during `mount -o uquota` on a metadir XFS<br /> image. Injecting xfs_metadir_create() reproduced the old active-update path<br /> that left mount stuck later in mount setup; after this change, the same<br /> injection reported cancel_hits=1 and irele_hits=1. Injecting<br /> xfs_metadir_commit() exercised the old inode-reference leak path; after<br /> this change, it reported irele_hits=1.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xfs: fix exchmaps reservation limit check<br /> <br /> xfs_exchmaps_estimate_overhead() adds the bmbt and rmapbt<br /> overhead to a local resblks variable, but the final UINT_MAX<br /> check still tests req-&gt;resblks. That is the reservation value<br /> from before the overhead was added.<br /> <br /> The computed value is stored back in req-&gt;resblks and later passed<br /> to xfs_trans_alloc(), whose block reservation argument is unsigned<br /> int. Check the computed reservation so the existing limit applies<br /> to the value that will be used.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: mtk-jpeg: cancel workqueue on release for supported platforms only<br /> <br /> Since a recent fix the mtk_jpeg_release function cancels any pending<br /> or running work present in the driver workqueue using<br /> cancel_work_sync function.<br /> Currently, only the multicore based variants use this workqueue and they<br /> have the jpeg_worker platform data field initialized with a workqueue<br /> callback function. For the others, this field value remain NULL by<br /> default.<br /> The cancel_work_sync function is unconditionally called in<br /> mtk_jpeg_release function, even for the variants that do not use the<br /> workqueue. This call generates a WARN_ON print in __flush_work because<br /> the workqueue callback function presence check fails in __flush_work<br /> function (used by cancel_work_sync).<br /> <br /> So, to avoid these warnings, call cancel_work_sync only if a workqueue<br /> callback is defined in platform data.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nilfs2: reject CLEAN_SEGMENTS ioctl with out-of-range segment numbers<br /> <br /> Syzbot reported a hung task in nilfs_transaction_begin() where multiple<br /> tasks performing chmod() on a nilfs2 mount blocked for over 143 seconds<br /> waiting to acquire ns_segctor_sem for read:<br /> <br /> INFO: task syz.0.17:5918 blocked for more than 143 seconds.<br /> Call Trace:<br /> schedule+0x164/0x360<br /> rwsem_down_read_slowpath+0x6d9/0x940<br /> down_read+0x99/0x2e0<br /> nilfs_transaction_begin+0x364/0x710 fs/nilfs2/segment.c:221<br /> nilfs_setattr+0x124/0x2c0 fs/nilfs2/inode.c:921<br /> notify_change+0xc1a/0xf40<br /> chmod_common+0x273/0x4a0<br /> do_fchmodat+0x12d/0x230<br /> <br /> The writer holding ns_segctor_sem was a concurrent<br /> NILFS_IOCTL_CLEAN_SEGMENTS caller, stuck inside printk while emitting<br /> per-element warnings from nilfs_sufile_updatev():<br /> <br /> __nilfs_msg+0x373/0x450 fs/nilfs2/super.c:78<br /> nilfs_sufile_updatev+0x21c/0x6d0 fs/nilfs2/sufile.c:186<br /> nilfs_sufile_freev fs/nilfs2/sufile.h:93 [inline]<br /> nilfs_free_segments fs/nilfs2/segment.c:1140 [inline]<br /> nilfs_segctor_collect_blocks fs/nilfs2/segment.c:1261 [inline]<br /> nilfs_segctor_do_construct+0x1f55/0x76c0<br /> nilfs_clean_segments+0x3bd/0xa50<br /> nilfs_ioctl_clean_segments fs/nilfs2/ioctl.c:922 [inline]<br /> nilfs_ioctl+0x261f/0x2780<br /> <br /> The root cause is that user-supplied segment numbers are not validated<br /> before nilfs_clean_segments() begins doing work; the range check on<br /> each segnum is performed deep inside the call chain by<br /> nilfs_sufile_updatev(), which emits a nilfs_warn() per invalid entry<br /> while still holding the segctor lock and the sufile mi_sem. Under load<br /> (repeated invocations across multiple mounts saturating the global<br /> printk path), the cumulative printk latency keeps ns_segctor_sem held<br /> long enough to trip the hung_task watchdog, blocking concurrent<br /> operations such as chmod() that need ns_segctor_sem for read.<br /> <br /> Fix by validating the contents of kbufs[4] in nilfs_clean_segments()<br /> immediately after acquiring ns_segctor_sem via nilfs_transaction_lock().<br /> Holding ns_segctor_sem serializes the check against<br /> nilfs_ioctl_resize(), which can modify ns_nsegments, so the validation<br /> uses a consistent value. Out-of-range segment numbers are rejected<br /> with -EINVAL before any segment-cleaning work begins, so the bad<br /> entries never reach the per-element diagnostic path inside<br /> nilfs_sufile_updatev().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> hfs/hfsplus: zero-initialize buffer in hfs_bnode_read<br /> <br /> hfs_bnode_read() can return early without writing to the output buffer<br /> when is_bnode_offset_valid() fails or when check_and_correct_requested_<br /> length() corrects the length to zero. Callers such as hfs_bnode_read_<br /> u16() and hfs_bnode_read_u8() pass stack-allocated buffers and use the<br /> result unconditionally, leading to KMSAN uninit-value reports.<br /> <br /> Rather than initializing at each individual call site, zero the buffer<br /> at the start of hfs_bnode_read() before any validation checks. This<br /> ensures all callers in both hfs and hfsplus get a deterministic zero<br /> value regardless of which early-return path is taken.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> HID: lg-g15: cancel pending work on remove to fix a use-after-free<br /> <br /> lg_g15_data is allocated with devm and holds a work item. The report<br /> handlers schedule that work straight from device input.<br /> lg_g15_event() and lg_g15_v2_event() do it on the backlight cycle key,<br /> and lg_g510_leds_event() does it too. The worker dereferences the<br /> lg_g15_data back through container_of.<br /> <br /> The driver had no remove callback and never cancelled the work. So if a<br /> report scheduled the work and the keyboard was then unplugged, devres<br /> freed lg_g15_data while the work was still pending or running, and the<br /> worker touched freed memory. This is a use-after-free. It is reachable<br /> as a race on device unplug.<br /> <br /> Add a remove callback that cancels the work before devres frees the<br /> state. g15-&gt;work is only initialized for the models that schedule it<br /> (G15, G15 v2, G510). The G13 and Z-10 leave it zeroed, so guard the<br /> cancel on g15-&gt;work.func to avoid cancelling a work that was never set<br /> up. The g15 NULL test mirrors the one already in lg_g15_raw_event().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> HID: appleir: fix UAF on pending key_up_timer in remove()<br /> <br /> appleir_remove() runs hid_hw_stop() before timer_delete_sync().<br /> hid_hw_stop() synchronously unregisters the HID input device via<br /> hid_disconnect() -&gt; hidinput_disconnect() -&gt; input_unregister_device(),<br /> which drops the last reference and frees the underlying input_dev when<br /> no userspace handle holds it open.<br /> <br /> key_up_tick() reads appleir-&gt;input_dev and calls input_report_key() /<br /> input_sync() on it. The timer is armed from appleir_raw_event() with<br /> a HZ/8 (~125 ms) timeout on every keydown and key-repeat report. If a<br /> key was pressed shortly before the device is disconnected, the timer<br /> can fire after hid_hw_stop() has freed input_dev but before the<br /> teardown drains it.<br /> <br /> A simple reorder is not sufficient. Putting the timer drain first<br /> still leaves a window where a USB URB completion (raw_event) running<br /> during hid_hw_stop() can call mod_timer() and re-arm the timer, which<br /> then fires after hidinput_disconnect() has freed input_dev. The same<br /> URB-completion window also lets raw_event() reach key_up(), key_down()<br /> and battery_flat() directly, all of which dereference<br /> appleir-&gt;input_dev.<br /> <br /> Introduce a &amp;#39;removing&amp;#39; flag on struct appleir, gated by the existing<br /> spinlock. appleir_remove() sets the flag under the lock and then<br /> shuts down the timer with timer_shutdown_sync(), which both drains any<br /> in-flight callback and permanently disables further mod_timer() calls.<br /> appleir_raw_event() and key_up_tick() bail out early if the flag is<br /> set, so no path can arm or run the timer, or dereference<br /> appleir-&gt;input_dev, after remove() has started tearing down.<br /> <br /> The keyrepeat and flatbattery branches of appleir_raw_event()<br /> previously called into the input layer without holding the spinlock;<br /> take it now so the flag check is well-defined. This incidentally<br /> closes a pre-existing read-side race on appleir-&gt;current_key in the<br /> keyrepeat branch.<br /> <br /> This bug is structurally a sibling of commit 4db2af929279 ("HID:<br /> appletb-kbd: fix UAF in inactivity-timer cleanup path") and has been<br /> present since the driver was introduced.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> hfs/hfsplus: fix u32 overflow in check_and_correct_requested_length<br /> <br /> check_and_correct_requested_length() compares (off + len) against<br /> node_size using u32 arithmetic. When the caller passes a large len<br /> value (e.g. from an underflowed subtraction in hfs_brec_remove()),<br /> off + len can wrap past 2^32 and produce a small result, causing the<br /> bounds check to pass when it should fail.<br /> <br /> For example, with off=14 and len=0xFFFFFFF2 (underflowed from<br /> data_off - keyoffset - size in hfs_brec_remove), off + len wraps to 6,<br /> which is less than a typical node_size of 512, so the check passes and<br /> the subsequent memmove reads ~4GB past the node buffer.<br /> <br /> Fix this by widening the addition to u64 before comparing against<br /> node_size. This prevents the u32 wrap while keeping the logic<br /> straightforward.