Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cpufreq: qcom-cpufreq-hw: Fix possible double free<br /> <br /> qcom_cpufreq.data is allocated with devm_kzalloc() in probe() as an<br /> array of per-domain data. qcom_cpufreq_hw_cpu_init() stores a pointer to<br /> one element of this array in policy-&gt;driver_data.<br /> <br /> qcom_cpufreq_hw_cpu_exit() currently calls kfree() on policy-&gt;driver_data.<br /> This is not valid because the memory is devm-managed. For the first<br /> domain, this can free the devm-managed allocation while the devres entry<br /> is still active, leading to a possible double free when the platform<br /> device is later detached. For other domains, the pointer may refer to an<br /> element inside the array rather than the allocation base.<br /> <br /> Remove the kfree(data) call and let devres release qcom_cpufreq.data.<br /> <br /> This issue was found by a static analysis tool I am developing.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cpufreq: pcc: fix use-after-free and double free in _OSC evaluation<br /> <br /> pcc_cpufreq_do_osc() calls acpi_evaluate_object() twice for the<br /> two-phase _OSC negotiation. Between the two calls it freed<br /> output.pointer but left output.length unchanged. Since<br /> acpi_evaluate_object() treats a non-zero length with a non-NULL<br /> pointer as an existing buffer to write into, the second call wrote<br /> into freed memory (use-after-free). The subsequent kfree(output.pointer)<br /> at out_free then freed the same pointer a second time (double free).<br /> <br /> Reset output.pointer to NULL and output.length to ACPI_ALLOCATE_BUFFER<br /> after freeing the first result, so ACPICA allocates a fresh buffer for<br /> each phase independently.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sched/rt: Have RT_PUSH_IPI be default off for non PREEMPT_RT<br /> <br /> RT migration is done aggressively. When a CPU schedules out a high<br /> priority RT task for a lower priority task, it will look to see if there&amp;#39;s<br /> any RT tasks that are waiting to run on another CPU that is of higher<br /> priority than the task this CPU is about to run. If it finds one, it will<br /> pull that task over to the CPU and allow it to run there instead.<br /> <br /> Normally, this pulling is done by looking at the RT overloaded mask (rto)<br /> which contains all the CPUs in the scheduler domain with RT tasks that are<br /> waiting to run due to a higher priority RT task currently running on their<br /> CPU. The CPU that is about to schedule a lower priority task will grab the<br /> rq lock of the overloaded CPU and move the RT task from that CPU&amp;#39;s runqueue<br /> to the local one and schedule the higher priority RT task.<br /> <br /> This caused issues when a lot of CPUs would schedule a lower priority task<br /> at the same time. They would all try to grab the same runqueue lock of<br /> the CPU with the overloaded RT tasks. Only the first CPU that got in will<br /> get that task. All the others would wait until they got the runqueue lock<br /> and see there&amp;#39;s nothing to pull and do nothing. On systems with lots of<br /> CPUs, this caused a large latency (up to 500us) which is beyond what<br /> PREEMPT_RT is to allow.<br /> <br /> The solution to that was to create an RT_PUSH_IPI logic. When any CPU<br /> wanted to pull a task, instead of grabbing the runqueue lock of the<br /> overloaded CPU, it would start by sending an IPI to the overloaded CPU,<br /> and that IPI handler would have the CPU with the waiting RT task do a push<br /> instead. Then that handler would send an IPI to the next CPU with<br /> overloaded RT tasks, and so on. Note, after the first CPU starts this<br /> process, if another CPU wanted to do a pull, it would see that the process<br /> has already begun and would only increment a counter to have the IPIs<br /> continue again.<br /> <br /> The RT_PUSH_IPI solved the latency problem with PREEMPT_RT but could cause<br /> a new issue with non PREEMPT_RT. Namely, softirqs run in a threaded<br /> context on PREEMPT_RT but they can run in an interrupt context in non-RT.<br /> <br /> If an IPI lands on a CPU that has just woken up multiple RT tasks and the<br /> current CPU is running a non RT or a low priority RT task, instead of<br /> doing a push, it would simply do a schedule on that CPU. But if a softirq<br /> was also executing on this CPU, the schedule would need to wait until the<br /> softirq finished. Until then, the CPU would still be considered overloaded<br /> as there are RT tasks still waiting to run on it.<br /> <br /> A live lock occurred on a workload that was doing heavy networking traffic<br /> on a large machine where the softirqs would run 500us out of 750us. And it<br /> would also be waking up RT tasks, causing the RT pull logic to be<br /> constantly executed.<br /> <br /> When a softirq triggered on a CPU with RT tasks queued but not running<br /> yet, and the other CPUs would see this CPU as being overloaded, they would<br /> send an IPI over to it. The CPU would notice that the waiting RT tasks are<br /> of higher priority than the currently running task and simply schedule<br /> that CPU instead. But because the softirq was executing, before it could<br /> schedule, it would receive another IPI to do the same. The amount of IPIs<br /> would slow down the currently running softirq so much that before it could<br /> return back to task context, it would execute another softirq never<br /> allowing the CPU to schedule. This live locked that CPU.<br /> <br /> As RT_PUSH_IPI was created to help PREEMPT_RT, make it default off if<br /> PREEMPT_RT is not enabled.

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.