Vulnerabilidades

*** 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 /> gpio: sloppy-logic-analyzer: fix use-after-free via debugfs trigger on unbind<br /> <br /> The "trigger" debugfs file has a hand-rolled -&gt;write handler<br /> (trigger_write()) that dereferences the per-device gpio_la_poll_priv. The<br /> file is created with debugfs_create_file_unsafe(), and the handler never<br /> takes a debugfs reference. Nothing keeps the object alive while the<br /> handler runs.<br /> <br /> priv is allocated with devm_kzalloc(). devres frees it when the platform<br /> device is unbound. debugfs_create_file_unsafe() installs no full_proxy<br /> wrapper, so debugfs_remove_recursive() in gpio_la_poll_remove() does not<br /> wait for an in-flight trigger_write(). The blob_lock taken there does not<br /> help, because trigger_write() never takes it. A write that races an unbind<br /> therefore writes into freed memory:<br /> <br /> trigger_write() gpio_la_poll_remove()<br /> priv = m-&gt;private<br /> buf = memdup_user() [may sleep]<br /> mutex_lock(&amp;priv-&gt;blob_lock)<br /> debugfs_remove_recursive() [no wait]<br /> mutex_unlock(&amp;priv-&gt;blob_lock)<br /> (remove returns; devres frees priv)<br /> priv-&gt;trig_data = buf trig_len = count<br /> <br /> The race is reachable by root via<br /> /sys/bus/platform/drivers/gpio-sloppy-logic-analyzer/unbind.<br /> <br /> Create "trigger" with debugfs_create_file() instead. Its full_proxy<br /> wrapper makes debugfs_remove_recursive() drain any in-flight -&gt;write<br /> before it returns.<br /> <br /> The use-after-free is confirmed under KASAN with a minimal reproducer of<br /> the same debugfs_create_file_unsafe() plus devm_kzalloc() pattern<br /> (available on request); it produces a slab-use-after-free write in the<br /> handler.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> gve: fix NULL dereference due to missing ptp adjfine<br /> <br /> Fix NULL dereference due to missing implementation of adjfine, which can<br /> be triggered from usermode as follows:<br /> <br /> sudo ./testptp -d /dev/ptp0 -f 0<br /> [ 551.943697] BUG: kernel NULL pointer dereference, address: 0000000000000000<br /> [...]<br /> [ 552.061946] Call Trace:<br /> [ 552.064487] <br /> [ 552.066681] ptp_clock_adjtime+0x1c0/0x2c0<br /> [ 552.070874] ? get_clock_desc+0x6b/0xb0<br /> [ 552.074825] pc_clock_adjtime+0x78/0xc0<br /> [ 552.078755] __do_sys_clock_adjtime+0x85/0x110<br /> [ 552.083293] do_syscall_64+0xea/0x610

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Input: hynitron_cstxxx - validate touch count and finger IDs<br /> <br /> The driver allocates max_touch_num input slots, which are indexed from<br /> zero through max_touch_num - 1. The current check allows a finger ID<br /> equal to max_touch_num to reach cst3xx_report_contact(). While the input<br /> core ignores out-of-range slot indices, reporting touch data without a<br /> valid slot change corrupts the touch state of the previously active slot.<br /> <br /> The touch count is read from the controller&amp;#39;s report and is used to<br /> index the fixed-size report buffer without first checking its range.<br /> Reject counts larger than the supported number of touch slots before<br /> checking the trailing byte or parsing touch data.<br /> <br /> Reject finger IDs equal to or greater than max_touch_num, and return<br /> immediately when an invalid finger ID is encountered so that corrupt<br /> touch frames are discarded instead of reporting partial contact state.<br /> <br /> The V821 Avaota F1 board configures the vendor driver with one touch<br /> slot, so finger ID 1 is already invalid on that device.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> libceph: fix multiple unsafe decodes in decode_locker()<br /> <br /> decode_locker() in cls_lock_client.c contains three unsafe decode<br /> operations that allow a malicious or compromised OSD to trigger<br /> slab-out-of-bounds reads:<br /> <br /> 1. ceph_decode_copy() at the locker_id_t name field has no preceding<br /> bounds check. With p == end after ceph_start_decoding() accepts<br /> struct_len=0, this reads sizeof(ceph_entity_name) = 9 bytes past<br /> the validated buffer boundary.<br /> <br /> 2. *p += sizeof(struct ceph_timespec) after the locker_info_t header<br /> is an unchecked pointer advance. A malicious OSD can position p<br /> past end, causing all subsequent _safe checks to pass against a<br /> bogus boundary.<br /> <br /> 3. len = ceph_decode_32(p) has no preceding bounds check, and the<br /> immediately following *p += len is uncapped. A malicious OSD can<br /> send len=0xffffffff, advancing p gigabytes past end and escaping<br /> the decode window entirely.<br /> <br /> Fix all three by replacing bare operations with their safe variants:<br /> ceph_decode_copy -&gt; ceph_decode_copy_safe<br /> *p += sizeof(...) -&gt; ceph_decode_skip_n<br /> ceph_decode_32(p) -&gt; ceph_decode_32_safe<br /> *p += len -&gt; ceph_decode_skip_n<br /> <br /> A new label is added to return -EINVAL on any bounds violation.<br /> -EINVAL is appropriate here: the data received from the OSD<br /> is structurally malformed, which is an invalid argument to the decode<br /> contract regardless of whether the caller or the wire is at fault.<br /> <br /> Attacker model: a malicious or compromised OSD in a multi-tenant Ceph<br /> deployment can trigger this against any kernel client that issues the<br /> lock.get_info class method (e.g. during RBD exclusive lock acquisition)<br /> without any further privileges beyond OSD session establishment.<br /> <br /> [ idryomov: use ceph_decode_skip_string() to skip description, trim<br /> changelog ]

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: qce - fix error path in devm_qce_register_algs<br /> <br /> If ops-&gt;register_algs() fails, the error path repeatedly calls the same<br /> ops-&gt;unregister_algs() from the failed registration. Use the loop index<br /> to unregister the previously registered algorithms instead.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> gpio: ml-ioh: use raw_spinlock_t for the register lock<br /> <br /> ioh_irq_type() is registered as the irq_chip .irq_set_type callback and<br /> takes chip-&gt;spinlock with spin_lock_irqsave(). This callback is reached<br /> from __setup_irq() -&gt; __irq_set_trigger() -&gt; chip-&gt;irq_set_type() while<br /> the caller holds desc-&gt;lock, a raw_spinlock_t, with hardirqs disabled.<br /> That context is not sleepable, but on PREEMPT_RT a regular spinlock_t is<br /> an rtmutex-backed sleeping lock, so acquiring it there is invalid.<br /> ioh_irq_enable() and ioh_irq_disable() take the same lock from the<br /> .irq_enable/.irq_disable callbacks, which are likewise invoked with<br /> desc-&gt;lock held.<br /> <br /> Convert the register lock to raw_spinlock_t. The same lock also<br /> serializes the GPIO direction/value callbacks and the suspend/resume<br /> register save/restore, and those critical sections only perform short<br /> sequences of MMIO register accesses (ioread32()/iowrite32()); the<br /> .irq_set_type callback additionally emits a dev_warn() on an unsupported<br /> type. None of these are sleepable operations, so keeping this register<br /> lock non-sleeping is appropriate for the irqchip callbacks and does not<br /> change the GPIO-side locking contract.<br /> <br /> This is the same fix as commit a02b8950d619 ("gpio: pch: use<br /> raw_spinlock_t for the register lock"); this driver shares the same<br /> structure as gpio-pch.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mmc: atmel-mci: Fix use-after-free in atmci_remove due to race condition<br /> <br /> In atmci_probe, &amp;host-&gt;bh_work is bound with atmci_work_func, and<br /> atmci_interrupt, atmci_timeout_timer and atmci_dma_complete can all<br /> queue this work on system_bh_wq.<br /> <br /> If we remove the module, atmci_remove makes cleanup and the memory<br /> allocated for host with devm_kzalloc() is released after the remove<br /> callback returns, while the work mentioned above may still be pending<br /> or running. The sequence of operations that may lead to a UAF bug is<br /> as follows:<br /> <br /> CPU0 CPU1<br /> <br /> | atmci_interrupt<br /> | queue_work(system_bh_wq,<br /> | &amp;host-&gt;bh_work)<br /> atmci_remove |<br /> atmci_cleanup_slot(...) |<br /> atmci_writel(host, ATMCI_IDR, ~0UL) |<br /> timer_delete_sync(&amp;host-&gt;timer) |<br /> dma_release_channel(host-&gt;dma.chan) |<br /> free_irq(platform_get_irq(pdev, 0), host) |<br /> | atmci_work_func<br /> | // use host<br /> // devm resources released after |<br /> // remove returns, host is freed |<br /> | // use host (use-after-free)<br /> <br /> Fix it by canceling the work after all the sources that can schedule<br /> it (IRQ handler, timeout timer and DMA completion callback) have been<br /> stopped, and before proceeding with the remaining cleanup in<br /> atmci_remove.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> libceph: Avoid using invalid osd indices from primary_temp<br /> <br /> A corrupted osdmap received from a Ceph monitor or OSD may contain osd<br /> indices in its pg_temp, primary_temp, pg_upmap, and pg_upmap_items parts<br /> that don&amp;#39;t exist, i.e., that are greater than max_osd or smaller than<br /> CEPH_HOMELESS_OSD (-1). These indices are used to create the up and<br /> acting set in ceph_pg_to_up_acting_osds(), called from calc_target().<br /> While most of these osd indices are checked, the one from primary_temp<br /> is not. Subsequently, this may lead to calc_target() returning this<br /> (potentially invalid) index as target osd for a (linger) request.<br /> Because the osd_state, osd_weight, and osd_addr arrays only contain<br /> max_osd entries (with indices 0 to max_osd -1), this leads to<br /> out-of-bounds accesses when trying to read values from these arrays.<br /> <br /> This patch fixes the issue by adding a check to get_temp_osds(), so that<br /> only valid osd indices from primary_temp are used, and it falls back to<br /> using the primary from pg_temp or the up set if it is invalid.<br /> <br /> [ idryomov: changelog ]

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Input: sur40 - fix input device registration ordering<br /> <br /> In sur40_probe(), input_register_device() was previously called early before<br /> the V4L2 video device and vb2_queue components were fully initialized. If<br /> userspace opened the input device immediately upon registration, sur40_open()<br /> would trigger and start the sur40_poll() worker thread. This worker thread<br /> invokes sur40_process_video() and accesses the uninitialized vb2_queue<br /> structure, leading to a data race and potential system crash.<br /> <br /> Furthermore, if V4L2 or video registration failed after input_register_device()<br /> succeeded, the error path fell through to calling input_free_device() on a<br /> successfully registered device instead of input_unregister_device(), corrupting<br /> input core state.<br /> <br /> Move input_register_device() to the very end of sur40_probe(). This ensures<br /> the V4L2 and video queue structures are fully initialized before polling can<br /> start, and naturally resolves the error path bug since input_free_device()<br /> is now only called when input registration has not yet occurred.<br /> <br /> To maintain strict LIFO (Last-In, First-Out) teardown ordering, also move<br /> input_unregister_device() to the very beginning of sur40_disconnect(). This<br /> guarantees that the input polling worker thread is stopped before V4L2<br /> video components or control handlers are unregistered.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> openrisc: signal: do not restore privileged SR bits on sigreturn<br /> <br /> restore_sigcontext() copies the whole supervision register (SR) from the<br /> signal frame and only clears SPR_SR_SM before the value is reloaded into<br /> the hardware SR (through ESR and l.rfe) on the return to user space. All<br /> other SR bits are left under user control.<br /> <br /> An unprivileged task can thus return from a signal handler through a<br /> crafted sigframe that clears SPR_SR_DME. With the data MMU disabled the<br /> CPU performs no translation or protection on data accesses, so the task<br /> gains read and write access to arbitrary physical memory, a local<br /> privilege escalation. SPR_SR_IME, SPR_SR_SUMRA, SPR_SR_LEE, SPR_SR_EPH<br /> and the cache-enable bits are exposed the same way. The ptrace GPR regset<br /> already refuses any change to SR for exactly this reason.<br /> <br /> Restore only the arithmetic flag bits (F, CY, OV) from the signal frame<br /> and take every privileged control bit from the SR the kernel saved on<br /> signal entry.<br /> <br /> Verified with qemu-system-or1k -M or1k-sim: before this change an<br /> unprivileged PoC clears SPR_SR_DME in rt_sigreturn and writes a marker to<br /> physical address 0x03000000 (beyond the kernel&amp;#39;s mem=32M); afterwards the<br /> same PoC receives SIGSEGV and physical memory is unchanged.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> s390/vfio_ccw: Free all memory if cp_init() fails<br /> <br /> The routine cp_free() is called to unpin/free any memory once an I/O<br /> is completed successfully, or if cp_prefetch() fails. But if cp_init()<br /> fails, and cp-&gt;initialized is not enabled, the same routine cannot be<br /> used to free all the memory.<br /> <br /> An attempt to address this exists in ccwchain_handle_ccw(), where a<br /> single call to ccwchain_free() is made for the currently-processed<br /> CCW segment. But this will leak other segments (created as a result<br /> of a Transfer in Channel) that had been allocated as part of the same<br /> channel program.<br /> <br /> Address this by performing the cleanup outside of the recursive<br /> ccwchain_handle_ccw()/ccwchain_loop_tic() logic.