Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> proc: protect ptrace_may_access() with exec_update_lock (FD links)<br /> <br /> proc_pid_get_link() and proc_pid_readlink() currently look up the task from<br /> the pid once, then do the ptrace access check on that task, then look up<br /> the task from the pid a second time to do the actual access.<br /> That&amp;#39;s racy in several ways.<br /> <br /> To fix it, pass the task to the -&gt;proc_get_link() handler, and instead of<br /> proc_fd_access_allowed(), introduce a new helper call_proc_get_link() that<br /> looks up and locks the task, does the access check, and calls<br /> -&gt;proc_get_link().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> writeback: fix race between cgroup_writeback_umount() and inode_switch_wbs()<br /> <br /> When a container exits, the following BUG_ON() is occasionally triggered:<br /> <br /> ==================================================================<br /> VFS: Busy inodes after unmount of sdb (ext4)<br /> ------------[ cut here ]------------<br /> kernel BUG at fs/super.c:695!<br /> CPU: 3 PID: 6 Comm: containerd-shim Tainted: G OE K 6.6 #1<br /> pstate: 63400009 (nZCv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--)<br /> pc : generic_shutdown_super+0xf0/0x100<br /> lr : generic_shutdown_super+0xf0/0x100<br /> Call trace:<br /> generic_shutdown_super+0xf0/0x100<br /> kill_block_super+0x20/0x48<br /> ext4_kill_sb+0x28/0x60<br /> deactivate_locked_super+0x54/0x130<br /> deactivate_super+0x84/0xa0<br /> cleanup_mnt+0xa4/0x140<br /> __cleanup_mnt+0x18/0x28<br /> task_work_run+0x78/0xe0<br /> do_notify_resume+0x204/0x240<br /> ==================================================================<br /> <br /> The root cause is a race between cgroup_writeback_umount() and<br /> inode_switch_wbs()/cleanup_offline_cgwb(). There is a window between<br /> inode_prepare_wbs_switch() returning true and the subsequent<br /> wb_queue_isw() call. Following is the process that triggers the issue:<br /> <br /> CPU A (umount) | CPU B (writeback)<br /> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~<br /> inode_switch_wbs/cleanup_offline_cgwb<br /> atomic_inc(&amp;isw_nr_in_flight)<br /> inode_prepare_wbs_switch<br /> -&gt; passes SB_ACTIVE check<br /> __iget(inode)<br /> generic_shutdown_super<br /> sb-&gt;s_flags &amp;= ~SB_ACTIVE<br /> cgroup_writeback_umount(sb)<br /> smp_mb()<br /> atomic_read(&amp;isw_nr_in_flight)<br /> rcu_barrier()<br /> -&gt; no pending RCU callbacks<br /> flush_workqueue(isw_wq)<br /> -&gt; nothing queued, returns<br /> evict_inodes(sb)<br /> -&gt; Inode skipped as isw still holds a ref.<br /> sop-&gt;put_super(sb)<br /> /* destroys percpu counters */<br /> -&gt; VFS: Busy inodes after unmount!<br /> wb_queue_isw()<br /> queue_work(isw_wq, ...)<br /> /* later in work function */<br /> inode_switch_wbs_work_fn<br /> process_inode_switch_wbs<br /> iput() -&gt; evict<br /> percpu_counter_dec() // UAF!<br /> <br /> Fix this by extending the RCU read-side critical section in<br /> inode_switch_wbs() and cleanup_offline_cgwb() to cover from<br /> inode_prepare_wbs_switch() through wb_queue_isw(). Since there is<br /> no sleep in this window, rcu_read_lock() can be used. Then add a<br /> synchronize_rcu() in cgroup_writeback_umount() before the existing<br /> rcu_barrier(), so that all in-flight switchers that have passed the<br /> SB_ACTIVE check have completed queue_work() before flush_workqueue()<br /> is called.<br /> <br /> The existing rcu_barrier() is intentionally retained so this fix can<br /> be backported unchanged to stable kernels (5.10.y, 6.6.y, ...) that<br /> still queue switches via queue_rcu_work(). It is a no-op on current<br /> mainline (since commit e1b849cfa6b6 ("writeback: Avoid contention on<br /> wb-&gt;list_lock when switching inodes")) and is removed in a follow-up<br /> patch.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> HID: letsketch: fix UAF on inrange_timer at driver unbind<br /> <br /> letsketch_driver does not provide a .remove callback, but<br /> letsketch_probe() arms a per-device timer:<br /> <br /> timer_setup(&amp;data-&gt;inrange_timer, letsketch_inrange_timeout, 0);<br /> <br /> The timer is re-armed from letsketch_raw_event() with a 100 ms<br /> timeout on every pen-in-range report, and its callback dereferences<br /> data-&gt;input_tablet to deliver a synthetic BTN_TOOL_PEN release.<br /> <br /> letsketch_data is allocated with devm_kzalloc(), and its input_dev<br /> fields are devm-allocated via letsketch_setup_input_tablet(). On<br /> device unbind (USB unplug or rmmod), the HID core runs its default<br /> teardown and devm cleanup frees both letsketch_data and the input<br /> devices. Because no .remove callback exists, nothing drains the<br /> timer first: if raw_event armed it within ~100 ms of the unbind,<br /> the pending timer fires on freed memory. This is a UAF read of<br /> data and of data-&gt;input_tablet, followed by input_report_key() /<br /> input_sync() into the freed input_dev.<br /> <br /> The same problem can occur on the probe error path: if<br /> hid_hw_start() enabled I/O on an always-poll-quirk device and then<br /> failed, raw_event may have armed the timer before devm releases<br /> data.<br /> <br /> Fix by adding a .remove callback that calls hid_hw_stop() first.<br /> hid_hw_stop() synchronously kills the URBs that deliver raw_event(),<br /> so once it returns no path can re-arm the timer. timer_shutdown_sync()<br /> then drains any in-flight callback and permanently disables further<br /> mod_timer() calls. Apply the same timer_shutdown_sync() in the probe<br /> error path so the timer is guaranteed not to outlive data.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> s390: Revert support for DCACHE_WORD_ACCESS<br /> <br /> load_unaligned_zeropad() reads eight bytes from unaligned addresses and may<br /> cross page boundaries. It handles exceptions which may happen if reading<br /> from the second page results in an exception.<br /> <br /> For pages which are donated to the Ultravisor for secure execution purposes<br /> the do_secure_storage_access() exception handler however does not handle<br /> such exceptions correctly. Such an exception may result in an endless<br /> exception loop which will never be resolved.<br /> <br /> An attempt to fix this [1] turned out to be not sufficient. For now revert<br /> load_unaligned_zeropad() until this problem has been resolved in a proper<br /> way.<br /> <br /> Note that the implementation of load_unaligned_zeropad() itself is<br /> correct. The revert is just a temporary workaround until there is complete<br /> fix for secure storage access exceptions.<br /> <br /> [1] commit b00be77302d7 ("s390/mm: Add missing secure storage access fixups for donated memory")

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> posix-cpu-timers: Fix pid refcount leak in do_cpu_nanosleep() error path<br /> <br /> In do_cpu_nanosleep(), posix_cpu_timer_create() takes a pid reference<br /> via get_pid() and stores it in timer.it.cpu.pid. If the subsequent<br /> posix_cpu_timer_set() call fails, the function returns immediately<br /> without calling posix_cpu_timer_del() to release the pid reference,<br /> causing a leak.<br /> <br /> Fix it by calling posix_cpu_timer_del() before the unlock-and-return<br /> on the error path, consistent with the other exit paths in the same<br /> function.

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.

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.

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.

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.

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.

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.

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.