Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: pcm: fix use-after-free on linked stream runtime in snd_pcm_drain()<br /> <br /> In the drain loop, the local variable &amp;#39;runtime&amp;#39; is reassigned to a<br /> linked stream&amp;#39;s runtime (runtime = s-&gt;runtime at line 2157). After<br /> releasing the stream lock at line 2169, the code accesses<br /> runtime-&gt;no_period_wakeup, runtime-&gt;rate, and runtime-&gt;buffer_size<br /> (lines 2170-2178) — all referencing the linked stream&amp;#39;s runtime without<br /> any lock or refcount protecting its lifetime.<br /> <br /> A concurrent close() on the linked stream&amp;#39;s fd triggers<br /> snd_pcm_release_substream() → snd_pcm_drop() → pcm_release_private()<br /> → snd_pcm_unlink() → snd_pcm_detach_substream() → kfree(runtime).<br /> No synchronization prevents kfree(runtime) from completing while the<br /> drain path dereferences the stale pointer.<br /> <br /> Fix by caching the needed runtime fields (no_period_wakeup, rate,<br /> buffer_size) into local variables while still holding the stream lock,<br /> and using the cached values after the lock is released.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sched_ext: Remove redundant css_put() in scx_cgroup_init()<br /> <br /> The iterator css_for_each_descendant_pre() walks the cgroup hierarchy<br /> under cgroup_lock(). It does not increment the reference counts on<br /> yielded css structs.<br /> <br /> According to the cgroup documentation, css_put() should only be used<br /> to release a reference obtained via css_get() or css_tryget_online().<br /> Since the iterator does not use either of these to acquire a reference,<br /> calling css_put() in the error path of scx_cgroup_init() causes a<br /> refcount underflow.<br /> <br /> Remove the unbalanced css_put() to prevent a potential Use-After-Free<br /> (UAF) vulnerability.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cgroup: fix race between task migration and iteration<br /> <br /> When a task is migrated out of a css_set, cgroup_migrate_add_task()<br /> first moves it from cset-&gt;tasks to cset-&gt;mg_tasks via:<br /> <br /> list_move_tail(&amp;task-&gt;cg_list, &amp;cset-&gt;mg_tasks);<br /> <br /> If a css_task_iter currently has it-&gt;task_pos pointing to this task,<br /> css_set_move_task() calls css_task_iter_skip() to keep the iterator<br /> valid. However, since the task has already been moved to -&gt;mg_tasks,<br /> the iterator is advanced relative to the mg_tasks list instead of the<br /> original tasks list. As a result, remaining tasks on cset-&gt;tasks, as<br /> well as tasks queued on cset-&gt;mg_tasks, can be skipped by iteration.<br /> <br /> Fix this by calling css_set_skip_task_iters() before unlinking<br /> task-&gt;cg_list from cset-&gt;tasks. This advances all active iterators to<br /> the next task on cset-&gt;tasks, so iteration continues correctly even<br /> when a task is concurrently being migrated.<br /> <br /> This race is hard to hit in practice without instrumentation, but it<br /> can be reproduced by artificially slowing down cgroup_procs_show().<br /> For example, on an Android device a temporary<br /> /sys/kernel/cgroup/cgroup_test knob can be added to inject a delay<br /> into cgroup_procs_show(), and then:<br /> <br /> 1) Spawn three long-running tasks (PIDs 101, 102, 103).<br /> 2) Create a test cgroup and move the tasks into it.<br /> 3) Enable a large delay via /sys/kernel/cgroup/cgroup_test.<br /> 4) In one shell, read cgroup.procs from the test cgroup.<br /> 5) Within the delay window, in another shell migrate PID 102 by<br /> writing it to a different cgroup.procs file.<br /> <br /> Under this setup, cgroup.procs can intermittently show only PID 101<br /> while skipping PID 103. Once the migration completes, reading the<br /> file again shows all tasks as expected.<br /> <br /> Note that this change does not allow removing the existing<br /> css_set_skip_task_iters() call in css_set_move_task(). The new call<br /> in cgroup_migrate_add_task() only handles iterators that are racing<br /> with migration while the task is still on cset-&gt;tasks. Iterators may<br /> also start after the task has been moved to cset-&gt;mg_tasks. If we<br /> dropped css_set_skip_task_iters() from css_set_move_task(), such<br /> iterators could keep task_pos pointing to a migrating task, causing<br /> css_task_iter_advance() to malfunction on the destination css_set,<br /> up to and including crashes or infinite loops.<br /> <br /> The race window between migration and iteration is very small, and<br /> css_task_iter is not on a hot path. In the worst case, when an<br /> iterator is positioned on the first thread of the migrating process,<br /> cgroup_migrate_add_task() may have to skip multiple tasks via<br /> css_set_skip_task_iters(). However, this only happens when migration<br /> and iteration actually race, so the performance impact is negligible<br /> compared to the correctness fix provided here.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mana: Null service_wq on setup error to prevent double destroy<br /> <br /> In mana_gd_setup() error path, set gc-&gt;service_wq to NULL after<br /> destroy_workqueue() to match the cleanup in mana_gd_cleanup().<br /> This prevents a use-after-free if the workqueue pointer is checked<br /> after a failed setup.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: bonding: Fix nd_tbl NULL dereference when IPv6 is disabled<br /> <br /> When booting with the &amp;#39;ipv6.disable=1&amp;#39; parameter, the nd_tbl is never<br /> initialized because inet6_init() exits before ndisc_init() is called<br /> which initializes it. If bonding ARP/NS validation is enabled, an IPv6<br /> NS/NA packet received on a slave can reach bond_validate_na(), which<br /> calls bond_has_this_ip6(). That path calls ipv6_chk_addr() and can<br /> crash in __ipv6_chk_addr_and_flags().<br /> <br /> BUG: kernel NULL pointer dereference, address: 00000000000005d8<br /> Oops: Oops: 0000 [#1] SMP NOPTI<br /> RIP: 0010:__ipv6_chk_addr_and_flags+0x69/0x170<br /> Call Trace:<br /> <br /> ipv6_chk_addr+0x1f/0x30<br /> bond_validate_na+0x12e/0x1d0 [bonding]<br /> ? __pfx_bond_handle_frame+0x10/0x10 [bonding]<br /> bond_rcv_validate+0x1a0/0x450 [bonding]<br /> bond_handle_frame+0x5e/0x290 [bonding]<br /> ? srso_alias_return_thunk+0x5/0xfbef5<br /> __netif_receive_skb_core.constprop.0+0x3e8/0xe50<br /> ? srso_alias_return_thunk+0x5/0xfbef5<br /> ? update_cfs_rq_load_avg+0x1a/0x240<br /> ? srso_alias_return_thunk+0x5/0xfbef5<br /> ? __enqueue_entity+0x5e/0x240<br /> __netif_receive_skb_one_core+0x39/0xa0<br /> process_backlog+0x9c/0x150<br /> __napi_poll+0x30/0x200<br /> ? srso_alias_return_thunk+0x5/0xfbef5<br /> net_rx_action+0x338/0x3b0<br /> handle_softirqs+0xc9/0x2a0<br /> do_softirq+0x42/0x60<br /> <br /> <br /> __local_bh_enable_ip+0x62/0x70<br /> __dev_queue_xmit+0x2d3/0x1000<br /> ? srso_alias_return_thunk+0x5/0xfbef5<br /> ? srso_alias_return_thunk+0x5/0xfbef5<br /> ? packet_parse_headers+0x10a/0x1a0<br /> packet_sendmsg+0x10da/0x1700<br /> ? kick_pool+0x5f/0x140<br /> ? srso_alias_return_thunk+0x5/0xfbef5<br /> ? __queue_work+0x12d/0x4f0<br /> __sys_sendto+0x1f3/0x220<br /> __x64_sys_sendto+0x24/0x30<br /> do_syscall_64+0x101/0xf80<br /> ? exc_page_fault+0x6e/0x170<br /> ? srso_alias_return_thunk+0x5/0xfbef5<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> <br /> Fix this by checking ipv6_mod_enabled() before dispatching IPv6 packets to<br /> bond_na_rcv(). If IPv6 is disabled, return early from bond_rcv_validate()<br /> and avoid the path to ipv6_chk_addr().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> io_uring: fix physical SQE bounds check for SQE_MIXED 128-byte ops<br /> <br /> When IORING_SETUP_SQE_MIXED is used without IORING_SETUP_NO_SQARRAY,<br /> the boundary check for 128-byte SQE operations in io_init_req()<br /> validated the logical SQ head position rather than the physical SQE<br /> index.<br /> <br /> The existing check:<br /> <br /> !(ctx-&gt;cached_sq_head &amp; (ctx-&gt;sq_entries - 1))<br /> <br /> ensures the logical position isn&amp;#39;t at the end of the ring, which is<br /> correct for NO_SQARRAY rings where physical == logical. However, when<br /> sq_array is present, an unprivileged user can remap any logical<br /> position to an arbitrary physical index via sq_array. Setting<br /> sq_array[N] = sq_entries - 1 places a 128-byte operation at the last<br /> physical SQE slot, causing the 128-byte memcpy in<br /> io_uring_cmd_sqe_copy() to read 64 bytes past the end of the SQE<br /> array.<br /> <br /> Replace the cached_sq_head alignment check with a direct validation<br /> of the physical SQE index, which correctly handles both sq_array and<br /> NO_SQARRAY cases.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: amd: acp-mach-common: Add missing error check for clock acquisition<br /> <br /> The acp_card_rt5682_init() and acp_card_rt5682s_init() functions did not<br /> check the return values of clk_get(). This could lead to a kernel crash<br /> when the invalid pointers are later dereferenced by clock core<br /> functions.<br /> <br /> Fix this by:<br /> 1. Changing clk_get() to the device-managed devm_clk_get().<br /> 2. Adding IS_ERR() checks immediately after each clock acquisition.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdkfd: Unreserve bo if queue update failed<br /> <br /> Error handling path should unreserve bo then return failed.<br /> <br /> (cherry picked from commit c24afed7de9ecce341825d8ab55a43a254348b33)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> e1000/e1000e: Fix leak in DMA error cleanup<br /> <br /> If an error is encountered while mapping TX buffers, the driver should<br /> unmap any buffers already mapped for that skb.<br /> <br /> Because count is incremented after a successful mapping, it will always<br /> match the correct number of unmappings needed when dma_error is reached.<br /> Decrementing count before the while loop in dma_error causes an<br /> off-by-one error. If any mapping was successful before an unsuccessful<br /> mapping, exactly one DMA mapping would leak.<br /> <br /> In these commits, a faulty while condition caused an infinite loop in<br /> dma_error:<br /> Commit 03b1320dfcee ("e1000e: remove use of skb_dma_map from e1000e<br /> driver")<br /> Commit 602c0554d7b0 ("e1000: remove use of skb_dma_map from e1000 driver")<br /> <br /> Commit c1fa347f20f1 ("e1000/e1000e/igb/igbvf/ixgb/ixgbe: Fix tests of<br /> unsigned in *_tx_map()") fixed the infinite loop, but introduced the<br /> off-by-one error.<br /> <br /> This issue may still exist in the igbvf driver, but I did not address it<br /> in this patch.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rust_binder: avoid reading the written value in offsets array<br /> <br /> When sending a transaction, its offsets array is first copied into the<br /> target proc&amp;#39;s vma, and then the values are read back from there. This is<br /> normally fine because the vma is a read-only mapping, so the target<br /> process cannot change the value under us.<br /> <br /> However, if the target process somehow gains the ability to write to its<br /> own vma, it could change the offset before it&amp;#39;s read back, causing the<br /> kernel to misinterpret what the sender meant. If the sender happens to<br /> send a payload with a specific shape, this could in the worst case lead<br /> to the receiver being able to privilege escalate into the sender.<br /> <br /> The intent is that gaining the ability to change the read-only vma of<br /> your own process should not be exploitable, so remove this TOCTOU read<br /> even though it&amp;#39;s unexploitable without another Binder bug.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rust_binder: check ownership before using vma<br /> <br /> When installing missing pages (or zapping them), Rust Binder will look<br /> up the vma in the mm by address, and then call vm_insert_page (or<br /> zap_page_range_single). However, if the vma is closed and replaced with<br /> a different vma at the same address, this can lead to Rust Binder<br /> installing pages into the wrong vma.<br /> <br /> By installing the page into a writable vma, it becomes possible to write<br /> to your own binder pages, which are normally read-only. Although you&amp;#39;re<br /> not supposed to be able to write to those pages, the intent behind the<br /> design of Rust Binder is that even if you get that ability, it should not<br /> lead to anything bad. Unfortunately, due to another bug, that is not the<br /> case.<br /> <br /> To fix this, store a pointer in vm_private_data and check that the vma<br /> returned by vma_lookup() has the right vm_ops and vm_private_data before<br /> trying to use the vma. This should ensure that Rust Binder will refuse<br /> to interact with any other VMA. The plan is to introduce more vma<br /> abstractions to avoid this unsafe access to vm_ops and vm_private_data,<br /> but for now let&amp;#39;s start with the simplest possible fix.<br /> <br /> C Binder performs the same check in a slightly different way: it<br /> provides a vm_ops-&gt;close that sets a boolean to true, then checks that<br /> boolean after calling vma_lookup(), but this is more fragile<br /> than the solution in this patch. (We probably still want to do both, but<br /> the vm_ops-&gt;close callback will be added later as part of the follow-up<br /> vma API changes.)<br /> <br /> It&amp;#39;s still possible to remap the vma so that pages appear in the right<br /> vma, but at the wrong offset, but this is a separate issue and will be<br /> fixed when Rust Binder gets a vm_ops-&gt;close callback.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rust_binder: fix oneway spam detection<br /> <br /> The spam detection logic in TreeRange was executed before the current<br /> request was inserted into the tree. So the new request was not being<br /> factored in the spam calculation. Fix this by moving the logic after<br /> the new range has been inserted.<br /> <br /> Also, the detection logic for ArrayRange was missing altogether which<br /> meant large spamming transactions could get away without being detected.<br /> Fix this by implementing an equivalent low_oneway_space() in ArrayRange.<br /> <br /> Note that I looked into centralizing this logic in RangeAllocator but<br /> iterating through &amp;#39;state&amp;#39; and &amp;#39;size&amp;#39; got a bit too complicated (for me)<br /> and I abandoned this effort.