Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tipc: fix divide-by-zero in tipc_sk_filter_connect()<br /> <br /> A user can set conn_timeout to any value via<br /> setsockopt(TIPC_CONN_TIMEOUT), including values less than 4. When a<br /> SYN is rejected with TIPC_ERR_OVERLOAD and the retry path in<br /> tipc_sk_filter_connect() executes:<br /> <br /> delay %= (tsk-&gt;conn_timeout / 4);<br /> <br /> If conn_timeout is in the range [0, 3], the integer division yields 0,<br /> and the modulo operation triggers a divide-by-zero exception, causing a<br /> kernel oops/panic.<br /> <br /> Fix this by clamping conn_timeout to a minimum of 4 at the point of use<br /> in tipc_sk_filter_connect().<br /> <br /> Oops: divide error: 0000 [#1] SMP KASAN NOPTI<br /> CPU: 0 UID: 0 PID: 119 Comm: poc-F144 Not tainted 7.0.0-rc2+<br /> RIP: 0010:tipc_sk_filter_rcv (net/tipc/socket.c:2236 net/tipc/socket.c:2362)<br /> Call Trace:<br /> tipc_sk_backlog_rcv (include/linux/instrumented.h:82 include/linux/atomic/atomic-instrumented.h:32 include/net/sock.h:2357 net/tipc/socket.c:2406)<br /> __release_sock (include/net/sock.h:1185 net/core/sock.c:3213)<br /> release_sock (net/core/sock.c:3797)<br /> tipc_connect (net/tipc/socket.c:2570)<br /> __sys_connect (include/linux/file.h:62 include/linux/file.h:83 net/socket.c:2098)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/xe/sync: Fix user fence leak on alloc failure<br /> <br /> When dma_fence_chain_alloc() fails, properly release the user fence<br /> reference to prevent a memory leak.<br /> <br /> (cherry picked from commit a5d5634cde48a9fcd68c8504aa07f89f175074a0)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/bridge: samsung-dsim: Fix memory leak in error path<br /> <br /> In samsung_dsim_host_attach(), drm_bridge_add() is called to add the<br /> bridge. However, if samsung_dsim_register_te_irq() or<br /> pdata-&gt;host_ops-&gt;attach() fails afterwards, the function returns<br /> without removing the bridge, causing a memory leak.<br /> <br /> Fix this by adding proper error handling with goto labels to ensure<br /> drm_bridge_remove() is called in all error paths. Also ensure that<br /> samsung_dsim_unregister_te_irq() is called if the attach operation<br /> fails after the TE IRQ has been registered.<br /> <br /> samsung_dsim_unregister_te_irq() function is moved without changes<br /> to be before samsung_dsim_host_attach() to avoid forward declaration.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu: add upper bound check on user inputs in wait ioctl<br /> <br /> Huge input values in amdgpu_userq_wait_ioctl can lead to a OOM and<br /> could be exploited.<br /> <br /> So check these input value against AMDGPU_USERQ_MAX_HANDLES<br /> which is big enough value for genuine use cases and could<br /> potentially avoid OOM.<br /> <br /> v2: squash in Srini&amp;#39;s fix<br /> <br /> (cherry picked from commit fcec012c664247531aed3e662f4280ff804d1476)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu/userq: Fix reference leak in amdgpu_userq_wait_ioctl<br /> <br /> Drop reference to syncobj and timeline fence when aborting the ioctl due<br /> output array being too small.<br /> <br /> (cherry picked from commit 68951e9c3e6bb22396bc42ef2359751c8315dd27)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu: add upper bound check on user inputs in signal ioctl<br /> <br /> Huge input values in amdgpu_userq_signal_ioctl can lead to a OOM and<br /> could be exploited.<br /> <br /> So check these input value against AMDGPU_USERQ_MAX_HANDLES<br /> which is big enough value for genuine use cases and could<br /> potentially avoid OOM.<br /> <br /> (cherry picked from commit be267e15f99bc97cbe202cd556717797cdcf79a5)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cpufreq: intel_pstate: Fix NULL pointer dereference in update_cpu_qos_request()<br /> <br /> The update_cpu_qos_request() function attempts to initialize the &amp;#39;freq&amp;#39;<br /> variable by dereferencing &amp;#39;cpudata&amp;#39; before verifying if the &amp;#39;policy&amp;#39;<br /> is valid.<br /> <br /> This issue occurs on systems booted with the "nosmt" parameter, where<br /> all_cpu_data[cpu] is NULL for the SMT sibling threads. As a result,<br /> any call to update_qos_requests() will result in a NULL pointer<br /> dereference as the code will attempt to access pstate.turbo_freq using<br /> the NULL cpudata pointer.<br /> <br /> Also, pstate.turbo_freq may be updated by intel_pstate_get_hwp_cap()<br /> after initializing the &amp;#39;freq&amp;#39; variable, so it is better to defer the<br /> &amp;#39;freq&amp;#39; until intel_pstate_get_hwp_cap() has been called.<br /> <br /> Fix this by deferring the &amp;#39;freq&amp;#39; assignment until after the policy and<br /> driver_data have been validated.<br /> <br /> [ rjw: Added one paragraph to the changelog ]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> kthread: consolidate kthread exit paths to prevent use-after-free<br /> <br /> Guillaume reported crashes via corrupted RCU callback function pointers<br /> during KUnit testing. The crash was traced back to the pidfs rhashtable<br /> conversion which replaced the 24-byte rb_node with an 8-byte rhash_head<br /> in struct pid, shrinking it from 160 to 144 bytes.<br /> <br /> struct kthread (without CONFIG_BLK_CGROUP) is also 144 bytes. With<br /> CONFIG_SLAB_MERGE_DEFAULT and SLAB_HWCACHE_ALIGN both round up to<br /> 192 bytes and share the same slab cache. struct pid.rcu.func and<br /> struct kthread.affinity_node both sit at offset 0x78.<br /> <br /> When a kthread exits via make_task_dead() it bypasses kthread_exit() and<br /> misses the affinity_node cleanup. free_kthread_struct() frees the memory<br /> while the node is still linked into the global kthread_affinity_list. A<br /> subsequent list_del() by another kthread writes through dangling list<br /> pointers into the freed and reused memory, corrupting the pid&amp;#39;s<br /> rcu.func pointer.<br /> <br /> Instead of patching free_kthread_struct() to handle the missed cleanup,<br /> consolidate all kthread exit paths. Turn kthread_exit() into a macro<br /> that calls do_exit() and add kthread_do_exit() which is called from<br /> do_exit() for any task with PF_KTHREAD set. This guarantees that<br /> kthread-specific cleanup always happens regardless of the exit path -<br /> make_task_dead(), direct do_exit(), or kthread_exit().<br /> <br /> Replace __to_kthread() with a new tsk_is_kthread() accessor in the<br /> public header. Export do_exit() since module code using the<br /> kthread_exit() macro now needs it directly.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nsfs: tighten permission checks for ns iteration ioctls<br /> <br /> Even privileged services should not necessarily be able to see other<br /> privileged service&amp;#39;s namespaces so they can&amp;#39;t leak information to each<br /> other. Use may_see_all_namespaces() helper that centralizes this policy<br /> until the nstree adapts.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm: Fix a hmm_range_fault() livelock / starvation problem<br /> <br /> If hmm_range_fault() fails a folio_trylock() in do_swap_page,<br /> trying to acquire the lock of a device-private folio for migration,<br /> to ram, the function will spin until it succeeds grabbing the lock.<br /> <br /> However, if the process holding the lock is depending on a work<br /> item to be completed, which is scheduled on the same CPU as the<br /> spinning hmm_range_fault(), that work item might be starved and<br /> we end up in a livelock / starvation situation which is never<br /> resolved.<br /> <br /> This can happen, for example if the process holding the<br /> device-private folio lock is stuck in<br /> migrate_device_unmap()-&gt;lru_add_drain_all()<br /> sinc lru_add_drain_all() requires a short work-item<br /> to be run on all online cpus to complete.<br /> <br /> A prerequisite for this to happen is:<br /> a) Both zone device and system memory folios are considered in<br /> migrate_device_unmap(), so that there is a reason to call<br /> lru_add_drain_all() for a system memory folio while a<br /> folio lock is held on a zone device folio.<br /> b) The zone device folio has an initial mapcount &gt; 1 which causes<br /> at least one migration PTE entry insertion to be deferred to<br /> try_to_migrate(), which can happen after the call to<br /> lru_add_drain_all().<br /> c) No or voluntary only preemption.<br /> <br /> This all seems pretty unlikely to happen, but indeed is hit by<br /> the "xe_exec_system_allocator" igt test.<br /> <br /> Resolve this by waiting for the folio to be unlocked if the<br /> folio_trylock() fails in do_swap_page().<br /> <br /> Rename migration_entry_wait_on_locked() to<br /> softleaf_entry_wait_unlock() and update its documentation to<br /> indicate the new use-case.<br /> <br /> Future code improvements might consider moving<br /> the lru_add_drain_all() call in migrate_device_unmap() to be<br /> called *after* all pages have migration entries inserted.<br /> That would eliminate also b) above.<br /> <br /> v2:<br /> - Instead of a cond_resched() in hmm_range_fault(),<br /> eliminate the problem by waiting for the folio to be unlocked<br /> in do_swap_page() (Alistair Popple, Andrew Morton)<br /> v3:<br /> - Add a stub migration_entry_wait_on_locked() for the<br /> !CONFIG_MIGRATION case. (Kernel Test Robot)<br /> v4:<br /> - Rename migrate_entry_wait_on_locked() to<br /> softleaf_entry_wait_on_locked() and update docs (Alistair Popple)<br /> v5:<br /> - Add a WARN_ON_ONCE() for the !CONFIG_MIGRATION<br /> version of softleaf_entry_wait_on_locked().<br /> - Modify wording around function names in the commit message<br /> (Andrew Morton)<br /> <br /> (cherry picked from commit a69d1ab971a624c6f112cea61536569d579c3215)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> staging: rtl8723bs: properly validate the data in rtw_get_ie_ex()<br /> <br /> Just like in commit 154828bf9559 ("staging: rtl8723bs: fix out-of-bounds<br /> read in rtw_get_ie() parser"), we don&amp;#39;t trust the data in the frame so<br /> we should check the length better before acting on it

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/damon/core: clear walk_control on inactive context in damos_walk()<br /> <br /> damos_walk() sets ctx-&gt;walk_control to the caller-provided control<br /> structure before checking whether the context is running. If the context<br /> is inactive (damon_is_running() returns false), the function returns<br /> -EINVAL without clearing ctx-&gt;walk_control. This leaves a dangling<br /> pointer to a stack-allocated structure that will be freed when the caller<br /> returns.<br /> <br /> This is structurally identical to the bug fixed in commit f9132fbc2e83<br /> ("mm/damon/core: remove call_control in inactive contexts") for<br /> damon_call(), which had the same pattern of linking a control object and<br /> returning an error without unlinking it.<br /> <br /> The dangling walk_control pointer can cause:<br /> 1. Use-after-free if the context is later started and kdamond<br />    dereferences ctx-&gt;walk_control (e.g., in damos_walk_cancel()<br />    which writes to control-&gt;canceled and calls complete())<br /> 2. Permanent -EBUSY from subsequent damos_walk() calls, since the<br />    stale pointer is non-NULL<br /> <br /> Nonetheless, the real user impact is quite restrictive. The<br /> use-after-free is impossible because there is no damos_walk() callers who<br /> starts the context later. The permanent -EBUSY can actually confuse<br /> users, as DAMON is not running. But the symptom is kept only while the<br /> context is turned off. Turning it on again will make DAMON internally<br /> uses a newly generated damon_ctx object that doesn&amp;#39;t have the invalid<br /> damos_walk_control pointer, so everything will work fine again.<br /> <br /> Fix this by clearing ctx-&gt;walk_control under walk_control_lock before<br /> returning -EINVAL, mirroring the fix pattern from f9132fbc2e83.