Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: rockchip: rkcif: Add missing MUST_CONNECT flag to pads<br /> <br /> The pads missed checks for connected devices which may a null dereference<br /> when the stream is enabled.<br /> <br /> Unable to handle kernel NULL pointer dereference at virtual address<br /> 0000000000000020<br /> pc : rkcif_interface_enable_streams+0x48/0xf0<br /> lr : rkcif_interface_enable_streams+0x44/0xf0<br /> Call trace:<br /> rkcif_interface_enable_streams+0x48/0xf0<br /> v4l2_subdev_enable_streams+0x26c/0x3f0<br /> rkcif_stream_start_streaming+0x140/0x278<br /> vb2_start_streaming+0x74/0x188<br /> vb2_core_streamon+0xe0/0x1d8<br /> vb2_ioctl_streamon+0x60/0xa8<br /> v4l_streamon+0x2c/0x40<br /> __video_do_ioctl+0x34c/0x400<br /> video_usercopy+0x2d0/0x800<br /> video_ioctl2+0x20/0x60<br /> v4l2_ioctl+0x48/0x78

*** 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 /> drm/xe/hdcp: Add NULL check for media_gt in intel_hdcp_gsc_check_status()<br /> <br /> When media GT is disabled via configfs, there is no allocation for<br /> media_gt, which is kept as NULL. In such scenario,<br /> intel_hdcp_gsc_check_status() results in a kernel pagefault error due to<br /> &amp;gt-&gt;uc.gsc being evaluated as an invalid memory address.<br /> <br /> Fix that by introducing a NULL check on media_gt and bailing out early<br /> if so.<br /> <br /> While at it, also drop the NULL check for gsc, since it can&amp;#39;t be NULL if<br /> media_gt is not NULL.<br /> <br /> v2:<br /> - Get address for gsc only after checking that gt is not NULL.<br /> (Shuicheng)<br /> - Drop the NULL check for gsc. (Shuicheng)<br /> v3:<br /> - Add "Fixes" and "Cc: " tags. (Matt)<br /> <br /> (cherry picked from commit bfaf87e84ca3ca3f6e275f9ae56da47a8b55ffd1)

*** 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 /> vsock/virtio: fix accept queue count leak on transport mismatch<br /> <br /> virtio_transport_recv_listen() calls sk_acceptq_added() before<br /> vsock_assign_transport(). If vsock_assign_transport() fails or<br /> selects a different transport, the error path returns without<br /> calling sk_acceptq_removed(), permanently incrementing<br /> sk_ack_backlog.<br /> <br /> After approximately backlog+1 such failures, sk_acceptq_is_full()<br /> returns true, causing the listener to reject all new connections.<br /> <br /> Fix by moving sk_acceptq_added() to after the transport validation,<br /> matching the pattern used by vmci_transport and hyperv_transport.

*** 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 *** Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

*** 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 /> 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 /> batman-adv: bla: prevent use-after-free when deleting claims<br /> <br /> When batadv_bla_del_backbone_claims() removes all claims for a backbone, it<br /> does this by dropping the link entry in the hash list. This list entry<br /> itself was one of the references which need to be dropped at the same time<br /> via batadv_claim_put().<br /> <br /> But the batadv_claim_put() must not be done before the last access to the<br /> claim object in this function. Otherwise the claim might be freed already<br /> by the batadv_claim_release() function before the list entry was dropped.

*** 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 /> 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.