Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> smb: client: fix double-free in SMB2_flush() replay<br /> <br /> SMB2_flush() keeps its response buffer bookkeeping across replay<br /> attempts. If a replayable flush response is received and the retry then<br /> fails before cifs_send_recv() stores a replacement response, flush_exit<br /> will free the stale response pointer a second time.<br /> <br /> Reinitialize resp_buftype and rsp_iov at the top of the replay loop so<br /> cleanup only acts on response state produced by the current attempt.<br /> This fixes a double-free without changing replay handling for successful<br /> requests.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> smb: client: fix change notify replay double-free<br /> <br /> A response-bearing attempt can return a replayable error and free its<br /> response buffer. If SMB2_notify_init() fails before the next send, cleanup<br /> retains the previous buffer type and frees that response again.<br /> <br /> Reset response bookkeeping before each attempt to prevent the stale free.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> smb: client: fix double-free in SMB2_ioctl() replay<br /> <br /> A response-bearing attempt can return a replayable error and free its<br /> response buffer. If SMB2_ioctl_init() fails before the next send, cleanup<br /> retains the previous buffer type and frees that response again.<br /> <br /> Reset response bookkeeping before each attempt to prevent the stale free.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> smb: client: fix query_info() replay double-free<br /> <br /> A response-bearing attempt can return a replayable error and free its<br /> response buffer. If SMB2_query_info_init() fails before the next send,<br /> cleanup retains the previous buffer type and frees that response again.<br /> <br /> Reset response bookkeeping before each attempt to prevent the stale free.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> proc: protect ptrace_may_access() with exec_update_lock (part 1)<br /> <br /> Fix the easy cases where procfs currently calls ptrace_may_access() without<br /> exec_update_lock protection, where the fix is to simply add the extra lock<br /> or use mm_access():<br /> <br /> - do_task_stat(): grab exec_update_lock<br /> - proc_pid_wchan(): grab exec_update_lock<br /> - proc_map_files_lookup(): use mm_access() instead of get_task_mm()<br /> - proc_map_files_readdir(): use mm_access() instead of get_task_mm()<br /> - proc_ns_get_link(): grab exec_update_lock<br /> - proc_ns_readlink(): grab exec_update_lock

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cpufreq: Fix hotplug-suspend race during reboot<br /> <br /> During system reboot, cpufreq_suspend() is called via the<br /> kernel_restart() -&gt; device_shutdown() path. Unlike the normal system<br /> suspend path, the reboot path does not call freeze_processes(), so<br /> userspace processes and kernel threads remain active.<br /> <br /> This allows CPU hotplug operations to run concurrently with<br /> cpufreq_suspend(). The original code has no synchronization with CPU<br /> hotplug, leading to a race condition where governor_data can be freed<br /> by the hotplug path while cpufreq_suspend() is still accessing it,<br /> resulting in a null pointer dereference:<br /> <br /> Unable to handle kernel NULL pointer dereference<br /> Call Trace:<br /> do_kernel_fault+0x28/0x3c<br /> cpufreq_suspend+0xdc/0x160<br /> device_shutdown+0x18/0x200<br /> kernel_restart+0x40/0x80<br /> arm64_sys_reboot+0x1b0/0x200<br /> <br /> Fix this by adding cpus_read_lock()/cpus_read_unlock() to<br /> cpufreq_suspend() to block CPU hotplug operations while suspend is in<br /> progress.<br /> <br /> [ rjw: Changelog edits ]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> firmware_loader: fix device reference leak in firmware_upload_register()<br /> <br /> firmware_upload_register()<br /> -&gt; fw_create_instance()<br /> -&gt; device_initialize()<br /> <br /> After fw_create_instance() succeeds, the lifetime of the embedded struct<br /> device is expected to be managed through the device core reference<br /> counting, since fw_create_instance() has already called<br /> device_initialize().<br /> <br /> In firmware_upload_register(), if alloc_lookup_fw_priv() fails after<br /> fw_create_instance() succeeds, the code reaches free_fw_sysfs and frees<br /> fw_sysfs directly instead of releasing the device reference with<br /> put_device(). This may leave the reference count of the embedded struct<br /> device unbalanced, resulting in a refcount leak.<br /> <br /> The issue was identified by a static analysis tool I developed and<br /> confirmed by manual review. Fix this by using put_device(fw_dev) in the<br /> failure path and letting fw_dev_release() handle the final cleanup,<br /> instead of freeing the instance directly from the error path.

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.