Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: wan: farsync: Fix use-after-free bugs caused by unfinished tasklets<br /> <br /> When the FarSync T-series card is being detached, the fst_card_info is<br /> deallocated in fst_remove_one(). However, the fst_tx_task or fst_int_task<br /> may still be running or pending, leading to use-after-free bugs when the<br /> already freed fst_card_info is accessed in fst_process_tx_work_q() or<br /> fst_process_int_work_q().<br /> <br /> A typical race condition is depicted below:<br /> <br /> CPU 0 (cleanup) | CPU 1 (tasklet)<br /> | fst_start_xmit()<br /> fst_remove_one() | tasklet_schedule()<br /> unregister_hdlc_device()|<br /> | fst_process_tx_work_q() //handler<br /> kfree(card) //free | do_bottom_half_tx()<br /> | card-&gt; //use<br /> <br /> The following KASAN trace was captured:<br /> <br /> ==================================================================<br /> BUG: KASAN: slab-use-after-free in do_bottom_half_tx+0xb88/0xd00<br /> Read of size 4 at addr ffff88800aad101c by task ksoftirqd/3/32<br /> ...<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x55/0x70<br /> print_report+0xcb/0x5d0<br /> ? do_bottom_half_tx+0xb88/0xd00<br /> kasan_report+0xb8/0xf0<br /> ? do_bottom_half_tx+0xb88/0xd00<br /> do_bottom_half_tx+0xb88/0xd00<br /> ? _raw_spin_lock_irqsave+0x85/0xe0<br /> ? __pfx__raw_spin_lock_irqsave+0x10/0x10<br /> ? __pfx___hrtimer_run_queues+0x10/0x10<br /> fst_process_tx_work_q+0x67/0x90<br /> tasklet_action_common+0x1fa/0x720<br /> ? hrtimer_interrupt+0x31f/0x780<br /> handle_softirqs+0x176/0x530<br /> __irq_exit_rcu+0xab/0xe0<br /> sysvec_apic_timer_interrupt+0x70/0x80<br /> ...<br /> <br /> Allocated by task 41 on cpu 3 at 72.330843s:<br /> kasan_save_stack+0x24/0x50<br /> kasan_save_track+0x17/0x60<br /> __kasan_kmalloc+0x7f/0x90<br /> fst_add_one+0x1a5/0x1cd0<br /> local_pci_probe+0xdd/0x190<br /> pci_device_probe+0x341/0x480<br /> really_probe+0x1c6/0x6a0<br /> __driver_probe_device+0x248/0x310<br /> driver_probe_device+0x48/0x210<br /> __device_attach_driver+0x160/0x320<br /> bus_for_each_drv+0x101/0x190<br /> __device_attach+0x198/0x3a0<br /> device_initial_probe+0x78/0xa0<br /> pci_bus_add_device+0x81/0xc0<br /> pci_bus_add_devices+0x7e/0x190<br /> enable_slot+0x9b9/0x1130<br /> acpiphp_check_bridge.part.0+0x2e1/0x460<br /> acpiphp_hotplug_notify+0x36c/0x3c0<br /> acpi_device_hotplug+0x203/0xb10<br /> acpi_hotplug_work_fn+0x59/0x80<br /> ...<br /> <br /> Freed by task 41 on cpu 1 at 75.138639s:<br /> kasan_save_stack+0x24/0x50<br /> kasan_save_track+0x17/0x60<br /> kasan_save_free_info+0x3b/0x60<br /> __kasan_slab_free+0x43/0x70<br /> kfree+0x135/0x410<br /> fst_remove_one+0x2ca/0x540<br /> pci_device_remove+0xa6/0x1d0<br /> device_release_driver_internal+0x364/0x530<br /> pci_stop_bus_device+0x105/0x150<br /> pci_stop_and_remove_bus_device+0xd/0x20<br /> disable_slot+0x116/0x260<br /> acpiphp_disable_and_eject_slot+0x4b/0x190<br /> acpiphp_hotplug_notify+0x230/0x3c0<br /> acpi_device_hotplug+0x203/0xb10<br /> acpi_hotplug_work_fn+0x59/0x80<br /> ...<br /> <br /> The buggy address belongs to the object at ffff88800aad1000<br /> which belongs to the cache kmalloc-1k of size 1024<br /> The buggy address is located 28 bytes inside of<br /> freed 1024-byte region<br /> The buggy address belongs to the physical page:<br /> page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0xaad0<br /> head: order:3 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0<br /> flags: 0x100000000000040(head|node=0|zone=1)<br /> page_type: f5(slab)<br /> raw: 0100000000000040 ffff888007042dc0 dead000000000122 0000000000000000<br /> raw: 0000000000000000 0000000080100010 00000000f5000000 0000000000000000<br /> head: 0100000000000040 ffff888007042dc0 dead000000000122 0000000000000000<br /> head: 0000000000000000 0000000080100010 00000000f5000000 0000000000000000<br /> head: 0100000000000003 ffffea00002ab401 00000000ffffffff 00000000ffffffff<br /> head: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000<br /> page dumped because: kasan: bad access detected<br /> <br /> Memory state around the buggy address:<br /> ffff88800aad0f00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc<br /> ffff88800aad0f80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc<br /> &gt;ffff88800aad1000: fa fb<br /> ---truncated---

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nf_conntrack_h323: fix OOB read in decode_choice()<br /> <br /> In decode_choice(), the boundary check before get_len() uses the<br /> variable `len`, which is still 0 from its initialization at the top of<br /> the function:<br /> <br /> unsigned int type, ext, len = 0;<br /> ...<br /> if (ext || (son-&gt;attr &amp; OPEN)) {<br /> BYTE_ALIGN(bs);<br /> if (nf_h323_error_boundary(bs, len, 0)) /* len is 0 here */<br /> return H323_ERROR_BOUND;<br /> len = get_len(bs); /* OOB read */<br /> <br /> When the bitstream is exactly consumed (bs-&gt;cur == bs-&gt;end), the check<br /> nf_h323_error_boundary(bs, 0, 0) evaluates to (bs-&gt;cur + 0 &gt; bs-&gt;end),<br /> which is false. The subsequent get_len() call then dereferences<br /> *bs-&gt;cur++, reading 1 byte past the end of the buffer. If that byte<br /> has bit 7 set, get_len() reads a second byte as well.<br /> <br /> This can be triggered remotely by sending a crafted Q.931 SETUP message<br /> with a User-User Information Element containing exactly 2 bytes of<br /> PER-encoded data ({0x08, 0x00}) to port 1720 through a firewall with<br /> the nf_conntrack_h323 helper active. The decoder fully consumes the<br /> PER buffer before reaching this code path, resulting in a 1-2 byte<br /> heap-buffer-overflow read confirmed by AddressSanitizer.<br /> <br /> Fix this by checking for 2 bytes (the maximum that get_len() may read)<br /> instead of the uninitialized `len`. This matches the pattern used at<br /> every other get_len() call site in the same file, where the caller<br /> checks for 2 bytes of available data before calling get_len().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/atmel-hlcdc: fix use-after-free of drm_crtc_commit after release<br /> <br /> The atmel_hlcdc_plane_atomic_duplicate_state() callback was copying<br /> the atmel_hlcdc_plane state structure without properly duplicating the<br /> drm_plane_state. In particular, state-&gt;commit remained set to the old<br /> state commit, which can lead to a use-after-free in the next<br /> drm_atomic_commit() call.<br /> <br /> Fix this by calling<br /> __drm_atomic_helper_duplicate_plane_state(), which correctly clones<br /> the base drm_plane_state (including the -&gt;commit pointer).<br /> <br /> It has been seen when closing and re-opening the device node while<br /> another DRM client (e.g. fbdev) is still attached:<br /> <br /> =============================================================================<br /> BUG kmalloc-64 (Not tainted): Poison overwritten<br /> -----------------------------------------------------------------------------<br /> <br /> 0xc611b344-0xc611b344 @offset=836. First byte 0x6a instead of 0x6b<br /> FIX kmalloc-64: Restoring Poison 0xc611b344-0xc611b344=0x6b<br /> Allocated in drm_atomic_helper_setup_commit+0x1e8/0x7bc age=178 cpu=0<br /> pid=29<br /> drm_atomic_helper_setup_commit+0x1e8/0x7bc<br /> drm_atomic_helper_commit+0x3c/0x15c<br /> drm_atomic_commit+0xc0/0xf4<br /> drm_framebuffer_remove+0x4cc/0x5a8<br /> drm_mode_rmfb_work_fn+0x6c/0x80<br /> process_one_work+0x12c/0x2cc<br /> worker_thread+0x2a8/0x400<br /> kthread+0xc0/0xdc<br /> ret_from_fork+0x14/0x28<br /> Freed in drm_atomic_helper_commit_hw_done+0x100/0x150 age=8 cpu=0<br /> pid=169<br /> drm_atomic_helper_commit_hw_done+0x100/0x150<br /> drm_atomic_helper_commit_tail+0x64/0x8c<br /> commit_tail+0x168/0x18c<br /> drm_atomic_helper_commit+0x138/0x15c<br /> drm_atomic_commit+0xc0/0xf4<br /> drm_atomic_helper_set_config+0x84/0xb8<br /> drm_mode_setcrtc+0x32c/0x810<br /> drm_ioctl+0x20c/0x488<br /> sys_ioctl+0x14c/0xc20<br /> ret_fast_syscall+0x0/0x54<br /> Slab 0xef8bc360 objects=21 used=16 fp=0xc611b7c0<br /> flags=0x200(workingset|zone=0)<br /> Object 0xc611b340 @offset=832 fp=0xc611b7c0

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu: Refactor amdgpu_gem_va_ioctl for Handling Last Fence Update and Timeline Management v4<br /> <br /> This commit simplifies the amdgpu_gem_va_ioctl function, key updates<br /> include:<br /> - Moved the logic for managing the last update fence directly into<br /> amdgpu_gem_va_update_vm.<br /> - Introduced checks for the timeline point to enable conditional<br /> replacement or addition of fences.<br /> <br /> v2: Addressed review comments from Christian.<br /> v3: Updated comments (Christian).<br /> v4: The previous version selected the fence too early and did not manage its<br /> reference correctly, which could lead to stale or freed fences being used.<br /> This resulted in refcount underflows and could crash when updating GPU<br /> timelines.<br /> The fence is now chosen only after the VA mapping work is completed, and its<br /> reference is taken safely. After exporting it to the VM timeline syncobj, the<br /> driver always drops its local fence reference, ensuring balanced refcounting<br /> and avoiding use-after-free on dma_fence.<br /> <br /> Crash signature:<br /> [ 205.828135] refcount_t: underflow; use-after-free.<br /> [ 205.832963] WARNING: CPU: 30 PID: 7274 at lib/refcount.c:28 refcount_warn_saturate+0xbe/0x110<br /> ...<br /> [ 206.074014] Call Trace:<br /> [ 206.076488] <br /> [ 206.078608] amdgpu_gem_va_ioctl+0x6ea/0x740 [amdgpu]<br /> [ 206.084040] ? __pfx_amdgpu_gem_va_ioctl+0x10/0x10 [amdgpu]<br /> [ 206.089994] drm_ioctl_kernel+0x86/0xe0 [drm]<br /> [ 206.094415] drm_ioctl+0x26e/0x520 [drm]<br /> [ 206.098424] ? __pfx_amdgpu_gem_va_ioctl+0x10/0x10 [amdgpu]<br /> [ 206.104402] amdgpu_drm_ioctl+0x4b/0x80 [amdgpu]<br /> [ 206.109387] __x64_sys_ioctl+0x96/0xe0<br /> [ 206.113156] do_syscall_64+0x66/0x2d0<br /> ...<br /> [ 206.553351] BUG: unable to handle page fault for address: ffffffffc0dfde90<br /> ...<br /> [ 206.553378] RIP: 0010:dma_fence_signal_timestamp_locked+0x39/0xe0<br /> ...<br /> [ 206.553405] Call Trace:<br /> [ 206.553409] <br /> [ 206.553415] ? __pfx_drm_sched_fence_free_rcu+0x10/0x10 [gpu_sched]<br /> [ 206.553424] dma_fence_signal+0x30/0x60<br /> [ 206.553427] drm_sched_job_done.isra.0+0x123/0x150 [gpu_sched]<br /> [ 206.553434] dma_fence_signal_timestamp_locked+0x6e/0xe0<br /> [ 206.553437] dma_fence_signal+0x30/0x60<br /> [ 206.553441] amdgpu_fence_process+0xd8/0x150 [amdgpu]<br /> [ 206.553854] sdma_v4_0_process_trap_irq+0x97/0xb0 [amdgpu]<br /> [ 206.554353] edac_mce_amd(E) ee1004(E)<br /> [ 206.554270] amdgpu_irq_dispatch+0x150/0x230 [amdgpu]<br /> [ 206.554702] amdgpu_ih_process+0x6a/0x180 [amdgpu]<br /> [ 206.555101] amdgpu_irq_handler+0x23/0x60 [amdgpu]<br /> [ 206.555500] __handle_irq_event_percpu+0x4a/0x1c0<br /> [ 206.555506] handle_irq_event+0x38/0x80<br /> [ 206.555509] handle_edge_irq+0x92/0x1e0<br /> [ 206.555513] __common_interrupt+0x3e/0xb0<br /> [ 206.555519] common_interrupt+0x80/0xa0<br /> [ 206.555525] <br /> [ 206.555527] <br /> ...<br /> [ 206.555650] RIP: 0010:dma_fence_signal_timestamp_locked+0x39/0xe0<br /> ...<br /> [ 206.555667] Kernel panic - not syncing: Fatal exception in interrupt

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: radio-keene: fix memory leak in error path<br /> <br /> Fix a memory leak in usb_keene_probe(). The v4l2 control handler is<br /> initialized and controls are added, but if v4l2_device_register() or<br /> video_register_device() fails afterward, the handler was never freed,<br /> leaking memory.<br /> <br /> Add v4l2_ctrl_handler_free() call in the err_v4l2 error path to ensure<br /> the control handler is properly freed for all error paths after it is<br /> initialized.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: chips-media: wave5: Fix device cleanup order to prevent kernel panic<br /> <br /> Move video device unregistration to the beginning of the remove function<br /> to ensure all video operations are stopped before cleaning up the worker<br /> thread and disabling PM runtime. This prevents hardware register access<br /> after the device has been powered down.<br /> <br /> In polling mode, the hrtimer periodically triggers<br /> wave5_vpu_timer_callback() which queues work to the kthread worker.<br /> The worker executes wave5_vpu_irq_work_fn() which reads hardware<br /> registers via wave5_vdi_read_register().<br /> <br /> The original cleanup order disabled PM runtime and powered down hardware<br /> before unregistering video devices. When autosuspend triggers and powers<br /> off the hardware, the video devices are still registered and the worker<br /> thread can still be triggered by the hrtimer, causing it to attempt<br /> reading registers from powered-off hardware. This results in a bus error<br /> (synchronous external abort) and kernel panic.<br /> <br /> This causes random kernel panics during encoding operations:<br /> <br /> Internal error: synchronous external abort: 0000000096000010<br /> [#1] PREEMPT SMP<br /> Modules linked in: wave5 rpmsg_ctrl rpmsg_char ...<br /> CPU: 0 UID: 0 PID: 1520 Comm: vpu_irq_thread<br /> Tainted: G M W<br /> pc : wave5_vdi_read_register+0x10/0x38 [wave5]<br /> lr : wave5_vpu_irq_work_fn+0x28/0x60 [wave5]<br /> Call trace:<br /> wave5_vdi_read_register+0x10/0x38 [wave5]<br /> kthread_worker_fn+0xd8/0x238<br /> kthread+0x104/0x120<br /> ret_from_fork+0x10/0x20<br /> Code: aa1e03e9 d503201f f9416800 8b214000 (b9400000)<br /> ---[ end trace 0000000000000000 ]---<br /> Kernel panic - not syncing: synchronous external abort:<br /> Fatal exception

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> clocksource/drivers/sh_tmu: Always leave device running after probe<br /> <br /> The TMU device can be used as both a clocksource and a clockevent<br /> provider. The driver tries to be smart and power itself on and off, as<br /> well as enabling and disabling its clock when it&amp;#39;s not in operation.<br /> This behavior is slightly altered if the TMU is used as an early<br /> platform device in which case the device is left powered on after probe,<br /> but the clock is still enabled and disabled at runtime.<br /> <br /> This has worked for a long time, but recent improvements in PREEMPT_RT<br /> and PROVE_LOCKING have highlighted an issue. As the TMU registers itself<br /> as a clockevent provider, clockevents_register_device(), it needs to use<br /> raw spinlocks internally as this is the context of which the clockevent<br /> framework interacts with the TMU driver. However in the context of<br /> holding a raw spinlock the TMU driver can&amp;#39;t really manage its power<br /> state or clock with calls to pm_runtime_*() and clk_*() as these calls<br /> end up in other platform drivers using regular spinlocks to control<br /> power and clocks.<br /> <br /> This mix of spinlock contexts trips a lockdep warning.<br /> <br /> =============================<br /> [ BUG: Invalid wait context ]<br /> 6.18.0-arm64-renesas-09926-gee959e7c5e34 #1 Not tainted<br /> -----------------------------<br /> swapper/0/0 is trying to lock:<br /> ffff000008c9e180 (&amp;dev-&gt;power.lock){-...}-{3:3}, at: __pm_runtime_resume+0x38/0x88<br /> other info that might help us debug this:<br /> context-{5:5}<br /> 1 lock held by swapper/0/0:<br /> ccree e6601000.crypto: ARM CryptoCell 630P Driver: HW version 0xAF400001/0xDCC63000, Driver version 5.0<br /> #0: ffff8000817ec298<br /> ccree e6601000.crypto: ARM ccree device initialized<br /> (tick_broadcast_lock){-...}-{2:2}, at: __tick_broadcast_oneshot_control+0xa4/0x3a8<br /> stack backtrace:<br /> CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.18.0-arm64-renesas-09926-gee959e7c5e34 #1 PREEMPT<br /> Hardware name: Renesas Salvator-X 2nd version board based on r8a77965 (DT)<br /> Call trace:<br /> show_stack+0x14/0x1c (C)<br /> dump_stack_lvl+0x6c/0x90<br /> dump_stack+0x14/0x1c<br /> __lock_acquire+0x904/0x1584<br /> lock_acquire+0x220/0x34c<br /> _raw_spin_lock_irqsave+0x58/0x80<br /> __pm_runtime_resume+0x38/0x88<br /> sh_tmu_clock_event_set_oneshot+0x84/0xd4<br /> clockevents_switch_state+0xfc/0x13c<br /> tick_broadcast_set_event+0x30/0xa4<br /> __tick_broadcast_oneshot_control+0x1e0/0x3a8<br /> tick_broadcast_oneshot_control+0x30/0x40<br /> cpuidle_enter_state+0x40c/0x680<br /> cpuidle_enter+0x30/0x40<br /> do_idle+0x1f4/0x280<br /> cpu_startup_entry+0x34/0x40<br /> kernel_init+0x0/0x130<br /> do_one_initcall+0x0/0x230<br /> __primary_switched+0x88/0x90<br /> <br /> For non-PREEMPT_RT builds this is not really an issue, but for<br /> PREEMPT_RT builds where normal spinlocks can sleep this might be an<br /> issue. Be cautious and always leave the power and clock running after<br /> probe.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> io_uring/zcrx: fix sgtable leak on mapping failures<br /> <br /> In an unlikely case when io_populate_area_dma() fails, which could only<br /> happen on a PAGE_POOL_32BIT_ARCH_WITH_64BIT_DMA machine,<br /> io_zcrx_map_area() will have an initialised and not freed table. It was<br /> supposed to be cleaned up in the error path, but !is_mapped prevents<br /> that.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: pvrusb2: fix URB leak in pvr2_send_request_ex<br /> <br /> When pvr2_send_request_ex() submits a write URB successfully but fails to<br /> submit the read URB (e.g. returns -ENOMEM), it returns immediately without<br /> waiting for the write URB to complete. Since the driver reuses the same<br /> URB structure, a subsequent call to pvr2_send_request_ex() attempts to<br /> submit the still-active write URB, triggering a &amp;#39;URB submitted while<br /> active&amp;#39; warning in usb_submit_urb().<br /> <br /> Fix this by ensuring the write URB is unlinked and waited upon if the read<br /> URB submission fails.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> hfs: Replace BUG_ON with error handling for CNID count checks<br /> <br /> In a06ec283e125 next_id, folder_count, and file_count in the super block<br /> info were expanded to 64 bits, and BUG_ONs were added to detect<br /> overflow. This triggered an error reported by syzbot: if the MDB is<br /> corrupted, the BUG_ON is triggered. This patch replaces this mechanism<br /> with proper error handling and resolves the syzbot reported bug.<br /> <br /> Singed-off-by: Jori Koolstra

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/rds: No shortcut out of RDS_CONN_ERROR<br /> <br /> RDS connections carry a state "rds_conn_path::cp_state"<br /> and transitions from one state to another and are conditional<br /> upon an expected state: "rds_conn_path_transition."<br /> <br /> There is one exception to this conditionality, which is<br /> "RDS_CONN_ERROR" that can be enforced by "rds_conn_path_drop"<br /> regardless of what state the condition is currently in.<br /> <br /> But as soon as a connection enters state "RDS_CONN_ERROR",<br /> the connection handling code expects it to go through the<br /> shutdown-path.<br /> <br /> The RDS/TCP multipath changes added a shortcut out of<br /> "RDS_CONN_ERROR" straight back to "RDS_CONN_CONNECTING"<br /> via "rds_tcp_accept_one_path" (e.g. after "rds_tcp_state_change").<br /> <br /> A subsequent "rds_tcp_reset_callbacks" can then transition<br /> the state to "RDS_CONN_RESETTING" with a shutdown-worker queued.<br /> <br /> That&amp;#39;ll trip up "rds_conn_init_shutdown", which was<br /> never adjusted to handle "RDS_CONN_RESETTING" and subsequently<br /> drops the connection with the dreaded "DR_INV_CONN_STATE",<br /> which leaves "RDS_SHUTDOWN_WORK_QUEUED" on forever.<br /> <br /> So we do two things here:<br /> <br /> a) Don&amp;#39;t shortcut "RDS_CONN_ERROR", but take the longer<br /> path through the shutdown code.<br /> <br /> b) Add "RDS_CONN_RESETTING" to the expected states in<br /> "rds_conn_init_shutdown" so that we won&amp;#39;t error out<br /> and get stuck, if we ever hit weird state transitions<br /> like this again."

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/rds: Clear reconnect pending bit<br /> <br /> When canceling the reconnect worker, care must be taken to reset the<br /> reconnect-pending bit. If the reconnect worker has not yet been<br /> scheduled before it is canceled, the reconnect-pending bit will stay<br /> on forever.