Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cgroup: Defer css percpu_ref kill on rmdir until cgroup is depopulated<br /> <br /> A chain of commits going back to v7.0 reworked rmdir to satisfy the<br /> controller invariant that a subsystem&amp;#39;s -&gt;css_offline() must not run while<br /> tasks are still doing kernel-side work in the cgroup.<br /> <br /> [1] d245698d727a ("cgroup: Defer task cgroup unlink until after the task is done switching out")<br /> [2] a72f73c4dd9b ("cgroup: Don&amp;#39;t expose dead tasks in cgroup")<br /> [3] 1b164b876c36 ("cgroup: Wait for dying tasks to leave on rmdir")<br /> [4] 4c56a8ac6869 ("cgroup: Fix cgroup_drain_dying() testing the wrong condition")<br /> [5] 13e786b64bd3 ("cgroup: Increment nr_dying_subsys_* from rmdir context")<br /> <br /> [1] moved task cset unlink from do_exit() to finish_task_switch() so a<br /> task&amp;#39;s cset link drops only after the task has fully stopped scheduling.<br /> That made tasks past exit_signals() linger on cset-&gt;tasks until their final<br /> context switch, which led to a series of problems as what userspace expected<br /> to see after rmdir diverged from what the kernel needs to wait for. [2]-[5]<br /> tried to bridge that divergence: [2] filtered the exiting tasks from<br /> cgroup.procs; [3] had rmdir(2) sleep in TASK_UNINTERRUPTIBLE for them; [4]<br /> fixed the wait&amp;#39;s condition; [5] made nr_dying_subsys_* visible<br /> synchronously.<br /> <br /> The cgroup_drain_dying() wait in [3] turned out to be a dead end. When the<br /> rmdir caller is also the reaper of a zombie that pins a pidns teardown (e.g.<br /> host PID 1 systemd reaping orphan pids that were re-parented to it during<br /> the same teardown), rmdir blocks in TASK_UNINTERRUPTIBLE waiting for those<br /> pids to free, the pids can&amp;#39;t free because PID 1 is the reaper and it&amp;#39;s stuck<br /> in rmdir, and the system A-A deadlocks. No internal lock ordering breaks<br /> this; the wait itself is the bug.<br /> <br /> The css killing side that drove the original reorder, however, can be made<br /> cleanly asynchronous: -&gt;css_offline() is already async, run from<br /> css_killed_work_fn() driven by percpu_ref_kill_and_confirm(). The fix is to<br /> make that chain start only after all tasks have left the cgroup. rmdir&amp;#39;s<br /> user-visible side then returns as soon as cgroup.procs and friends are<br /> empty, while -&gt;css_offline() still runs only after the cgroup is fully<br /> drained.<br /> <br /> Verified by the original reproducer (pidns teardown + zombie reaper, runs<br /> under vng) which hangs vanilla and succeeds here, and by per-commit<br /> deterministic repros for [2], [3], [4], [5] with a boot parameter that<br /> widens the post-exit_signals() window so each state is reliably reachable.<br /> Some stress tests on top of that.<br /> <br /> cgroup_apply_control_disable() has the same shape of pre-existing race:<br /> when a controller is disabled via subtree_control, kill_css() ran<br /> synchronously while tasks past exit_signals() could still be linked to<br /> the cgroup&amp;#39;s csets, and -&gt;css_offline() could fire before they drained.<br /> This patch preserves the existing synchronous behavior at that call site<br /> (kill_css_sync() + kill_css_finish() back-to-back) and a follow-up patch<br /> will defer kill_css_finish() there using a per-css trigger.<br /> <br /> This seems like the right approach and I don&amp;#39;t see problems with it. The<br /> changes are somewhat invasive but not excessively so, so backporting to<br /> -stable should be okay. If something does turn out to be wrong, the fallback<br /> is to revert the entire chain ([1]-[5]) and rework in the development branch<br /> instead.<br /> <br /> v2: Pin cgrp across the deferred destroy work with explicit<br /> cgroup_get()/cgroup_put() around queue_work() and the work_fn. v1<br /> wasn&amp;#39;t actually broken (ordered cgroup_offline_wq + queue_work order<br /> in cgroup_task_dead() saved it) but the explicit ref removes the<br /> dependency on those non-obvious invariants. Also note the<br /> pre-existing cgroup_apply_control_disable() race in the description;<br /> a follow-up will defer kill_css_finish() there.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm: Set old handle to NULL before prime swap in change_handle<br /> <br /> There was a potential race condition in change_handle. The ioctl<br /> briefly had a single object with two idr entries; a concurrent<br /> gem_close could delete the object and remove one of the handles<br /> while leaving the other one dangling, which could subsequently<br /> be dereferenced for a use-after-free.<br /> <br /> To fix this, do the same dance that gem_close itself does.<br /> (f6cd7daecff5 drm: Release driver references to handle before making it available again)<br /> First idr_replace the old handle to NULL. Later, if the prime<br /> operations are successful, actually close it.<br /> <br /> create_tail required a similar dance to avoid a similar problem.<br /> (bd46cece51a3 drm/gem: Fix race in drm_gem_handle_create_tail())<br /> It idr_allocs the new handle with NULL, then swaps in the correct<br /> object later to avoid races. We don&amp;#39;t need to do that here, since<br /> the only operations that could race are drm_prime, and<br /> change_handle holds the prime lock for the entire duration.<br /> <br /> v2: cleanups of error paths

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu: Add bounds checking to ib_{get,set}_value<br /> <br /> The uvd/vce/vcn code accesses the IB at predefined offsets without<br /> checking that the IB is large enough. Check the bounds here. The caller<br /> is responsible for making sure it can handle arbitrary return values.<br /> <br /> Also make the idx a uint32_t to prevent overflows causing the condition<br /> to fail.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vsock/virtio: fix empty payload in tap skb for non-linear buffers<br /> <br /> For non-linear skbs, virtio_transport_build_skb() goes through<br /> virtio_transport_copy_nonlinear_skb() to copy the original payload<br /> in the new skb to be delivered to the vsockmon tap device.<br /> This manually initializes an iov_iter but does not set iov_iter.count.<br /> Since the iov_iter is zero-initialized, the copy length is zero and no<br /> payload is actually copied to the monitor interface, leaving data<br /> un-initialized.<br /> <br /> Fix this by removing the linear vs non-linear split and using<br /> skb_copy_datagram_iter() with iov_iter_kvec() for all cases, as<br /> vhost-vsock already does. This handles both linear and non-linear skbs,<br /> properly initializes the iov_iter, and removes the now unused<br /> virtio_transport_copy_nonlinear_skb().<br /> <br /> While touching this code, let&amp;#39;s also check the return value of<br /> skb_copy_datagram_iter(), even though it&amp;#39;s unlikely to fail.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/msm/gem: fix error handling in msm_ioctl_gem_info_get_metadata()<br /> <br /> msm_ioctl_gem_info_get_metadata() always returns 0 regardless of<br /> errors. When copy_to_user() fails or the user buffer is too small,<br /> the error code stored in ret is ignored because the function<br /> unconditionally returns 0. This causes userspace to believe the<br /> ioctl succeeded when it did not.<br /> <br /> Additionally, kmemdup() can return NULL on allocation failure, but<br /> the return value is not checked. This leads to a NULL pointer<br /> dereference in the subsequent copy_to_user() call.<br /> <br /> Add the missing NULL check for kmemdup() and return ret instead of 0.<br /> <br /> Note that the SET counterpart (msm_ioctl_gem_info_set_metadata)<br /> correctly returns ret.<br /> <br /> Patchwork: https://patchwork.freedesktop.org/patch/714478/

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> HID: appletb-kbd: fix UAF in inactivity-timer cleanup path<br /> <br /> Commit 38224c472a03 ("HID: appletb-kbd: fix slab use-after-free bug in<br /> appletb_kbd_probe") added timer_delete_sync(&amp;kbd-&gt;inactivity_timer) to<br /> both the probe close_hw error path and appletb_kbd_remove(), but the<br /> way it was wired in left the inactivity timer reachable during driver<br /> tear-down via two distinct windows.<br /> <br /> Window A -- put_device() before timer_delete_sync():<br /> <br /> put_device(&amp;kbd-&gt;backlight_dev-&gt;dev);<br /> timer_delete_sync(&amp;kbd-&gt;inactivity_timer);<br /> <br /> The inactivity_timer softirq reads kbd-&gt;backlight_dev and calls<br /> backlight_device_set_brightness() -&gt; mutex_lock(&amp;ops_lock). If a<br /> concurrent hid_appletb_bl unbind drops the last devm reference<br /> between these two calls, the backlight_device is freed and the<br /> mutex_lock() touches freed memory.<br /> <br /> Window B -- backlight cleanup before hid_hw_stop():<br /> <br /> if (kbd-&gt;backlight_dev) {<br /> timer_delete_sync(...);<br /> put_device(...);<br /> }<br /> hid_hw_close(hdev);<br /> hid_hw_stop(hdev);<br /> <br /> Even after Window A is closed, hid_hw_close()/hid_hw_stop() still run<br /> afterwards, so a late ".event" callback from the HID core (USB URB<br /> completion on real Apple hardware) can arrive after<br /> timer_delete_sync() drained the softirq but before put_device() drops<br /> the reference. That callback reaches reset_inactivity_timer(), which<br /> calls mod_timer() and re-arms the timer. The freshly re-armed timer<br /> can then fire on the about-to-be-freed backlight_device.<br /> <br /> Both windows produce the same KASAN slab-use-after-free:<br /> <br /> BUG: KASAN: slab-use-after-free in __mutex_lock+0x1aab/0x21c0<br /> Read of size 8 at addr ffff88803ee9a108 by task swapper/0/0<br /> Call Trace:<br /> <br /> __mutex_lock<br /> backlight_device_set_brightness<br /> appletb_inactivity_timer<br /> call_timer_fn<br /> run_timer_softirq<br /> handle_softirqs<br /> Allocated by task N:<br /> devm_backlight_device_register<br /> appletb_bl_probe<br /> Freed by task M:<br /> (concurrent hid_appletb_bl unbind path)<br /> <br /> Close both windows at once by reworking the tear-down in<br /> appletb_kbd_remove() and in the probe close_hw error path so that<br /> <br /> 1) hid_hw_close()/hid_hw_stop() run before the backlight cleanup,<br /> guaranteeing no further .event callback can fire and re-arm the<br /> timer, and<br /> 2) inside the "if (kbd-&gt;backlight_dev)" block, timer_delete_sync()<br /> runs before put_device(), so the softirq is drained before the<br /> final reference is dropped.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu/vcn4: Prevent OOB reads when parsing IB<br /> <br /> Rewrite the IB parsing to use amdgpu_ib_get_value() which handles the<br /> bounds checks.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> staging: media: atomisp: Disallow all private IOCTLs<br /> <br /> Disallow all private IOCTLs. These aren&amp;#39;t quite as safe as one could<br /> assume of IOCTL handlers; disable them for now. Instead of removing the<br /> code, return in the beginning of the function if cmd is non-zero in order<br /> to keep static checkers happy.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> batman-adv: reject new tp_meter sessions during teardown<br /> <br /> Prevent tp_meter from starting new sender or receiver sessions after<br /> mesh_state has left BATADV_MESH_ACTIVE.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> batman-adv: stop tp_meter sessions during mesh teardown<br /> <br /> TP meter sessions remain linked on bat_priv-&gt;tp_list after the netlink<br /> request has already finished. When the mesh interface is removed,<br /> batadv_mesh_free() currently tears down the mesh without first draining<br /> these sessions.<br /> <br /> A running sender thread or a late incoming tp_meter packet can then keep<br /> processing against a mesh instance which is already shutting down.<br /> Synchronize tp_meter with the mesh lifetime by stopping all active<br /> sessions from batadv_mesh_free() and waiting for sender threads to exit<br /> before teardown continues.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/gem: Fix inconsistent plane dimension calculation in drm_gem_fb_init_with_funcs()<br /> <br /> drm_gem_fb_init_with_funcs() computes sub-sampled plane dimensions<br /> using plain integer division:<br /> <br /> unsigned int width = mode_cmd-&gt;width / (i ? info-&gt;hsub : 1);<br /> unsigned int height = mode_cmd-&gt;height / (i ? info-&gt;vsub : 1);<br /> <br /> However, the ioctl-level framebuffer_check() in drm_framebuffer.c uses<br /> drm_format_info_plane_width/height() which round up dimensions via<br /> DIV_ROUND_UP(). This inconsistency corrupts the subsequent GEM object<br /> size check for certain pixel format and dimension combinations.<br /> <br /> For example, with NV12 (vsub=2) and a 1-pixel-tall framebuffer the<br /> GEM size validation path sees height=0 instead of height=1. The<br /> expression (height - 1) then wraps to UINT_MAX as an unsigned int,<br /> causing min_size to overflow and wrap back to a small value. A tiny<br /> GEM object therefore passes the size guard, yet when the GPU accesses<br /> the chroma plane it will read or write memory beyond the object&amp;#39;s<br /> bounds.<br /> <br /> Fix by replacing the open-coded divisions with drm_format_info_plane_width()<br /> and drm_format_info_plane_height(), which use DIV_ROUND_UP() and match<br /> the calculation already used in framebuffer_check().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: iris: fix use-after-free of fmt_src during MBPF check<br /> <br /> During concurrency testing, multiple instances can run in parallel, and<br /> each instance uses its own inst-&gt;lock while the core-&gt;lock protects the<br /> list of active instances. The race happens because these locks cover<br /> different scopes, inst-&gt;lock protects only the internals of a single<br /> instance, while the Macro Blocks Per Frame (MBPF) checker walks the<br /> core list under core-&gt;lock and reads fields like fmt_src-&gt;width and<br /> fmt_src-&gt;height. At the same time, iris_close() may free fmt_src and<br /> fmt_dst under inst-&gt;lock while the instance is still present in the core<br /> list. This allows a situation where the MBPF checker, still iterating<br /> through the core list, reaches an instance whose fmt_src was already<br /> freed by another thread and ends up dereferencing a dangling pointer,<br /> resulting in a use-after-free. This happens because the MBPF checker<br /> assumes that any instance in the core list is fully valid, but the<br /> freeing of fmt_src and fmt_dst without removing the instance from the<br /> core list is not correct.<br /> <br /> The correct ordering is to defer freeing fmt_src and fmt_dst until after<br /> the instance has been removed from the core list and all teardown under<br /> the core lock has completed, ensuring that no dangling pointers are ever<br /> exposed during MBPF checks.