Vulnerabilidades

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

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Input: synaptics-rmi4 - bound the F54 report size to the allocated buffer<br /> <br /> rmi_f54_work() reads a diagnostics report from the device into<br /> f54-&gt;report_data, sizing the transfer with rmi_f54_get_report_size():<br /> <br /> report_size = rmi_f54_get_report_size(f54);<br /> ...<br /> for (i = 0; i report_data + i, size);<br /> }<br /> <br /> report_data is allocated once at probe from F54&amp;#39;s own electrode counts<br /> (array3_size(f54-&gt;num_tx_electrodes, f54-&gt;num_rx_electrodes, sizeof(u16))),<br /> but rmi_f54_get_report_size() computes the size from<br /> drv_data-&gt;num_*_electrodes when those are set, i.e. from the F55<br /> function&amp;#39;s electrode counts. Both counts come straight from device<br /> queries (F54 and F55 each report up to 255 electrodes) and nothing<br /> constrains the F55 counts to the F54 ones.<br /> <br /> A malicious or malfunctioning RMI4 device that reports larger F55<br /> electrode counts than its F54 counts makes report_size exceed the<br /> allocation, so the read loop writes past report_data (and the V4L2<br /> dequeue memcpy() then reads past it). On conforming hardware the F55<br /> configured electrodes are a subset of the F54 physical electrodes, so<br /> report_size never exceeds the buffer and well-behaved devices are<br /> unaffected.<br /> <br /> Record the allocation size and reject a report that does not fit,<br /> mirroring the existing zero-size check.

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