Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rcu: Fix rcu_read_unlock() deadloop due to softirq<br /> <br /> Commit 5f5fa7ea89dc ("rcu: Don&amp;#39;t use negative nesting depth in<br /> __rcu_read_unlock()") removes the recursion-protection code from<br /> __rcu_read_unlock(). Therefore, we could invoke the deadloop in<br /> raise_softirq_irqoff() with ftrace enabled as follows:<br /> <br /> WARNING: CPU: 0 PID: 0 at kernel/trace/trace.c:3021 __ftrace_trace_stack.constprop.0+0x172/0x180<br /> Modules linked in: my_irq_work(O)<br /> CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Tainted: G O 6.18.0-rc7-dirty #23 PREEMPT(full)<br /> Tainted: [O]=OOT_MODULE<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014<br /> RIP: 0010:__ftrace_trace_stack.constprop.0+0x172/0x180<br /> RSP: 0018:ffffc900000034a8 EFLAGS: 00010002<br /> RAX: 0000000000000000 RBX: 0000000000000004 RCX: 0000000000000000<br /> RDX: 0000000000000003 RSI: ffffffff826d7b87 RDI: ffffffff826e9329<br /> RBP: 0000000000090009 R08: 0000000000000005 R09: ffffffff82afbc4c<br /> R10: 0000000000000008 R11: 0000000000011d7a R12: 0000000000000000<br /> R13: ffff888003874100 R14: 0000000000000003 R15: ffff8880038c1054<br /> FS: 0000000000000000(0000) GS:ffff8880fa8ea000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 000055b31fa7f540 CR3: 00000000078f4005 CR4: 0000000000770ef0<br /> PKRU: 55555554<br /> Call Trace:<br /> <br /> trace_buffer_unlock_commit_regs+0x6d/0x220<br /> trace_event_buffer_commit+0x5c/0x260<br /> trace_event_raw_event_softirq+0x47/0x80<br /> raise_softirq_irqoff+0x6e/0xa0<br /> rcu_read_unlock_special+0xb1/0x160<br /> unwind_next_frame+0x203/0x9b0<br /> __unwind_start+0x15d/0x1c0<br /> arch_stack_walk+0x62/0xf0<br /> stack_trace_save+0x48/0x70<br /> __ftrace_trace_stack.constprop.0+0x144/0x180<br /> trace_buffer_unlock_commit_regs+0x6d/0x220<br /> trace_event_buffer_commit+0x5c/0x260<br /> trace_event_raw_event_softirq+0x47/0x80<br /> raise_softirq_irqoff+0x6e/0xa0<br /> rcu_read_unlock_special+0xb1/0x160<br /> unwind_next_frame+0x203/0x9b0<br /> __unwind_start+0x15d/0x1c0<br /> arch_stack_walk+0x62/0xf0<br /> stack_trace_save+0x48/0x70<br /> __ftrace_trace_stack.constprop.0+0x144/0x180<br /> trace_buffer_unlock_commit_regs+0x6d/0x220<br /> trace_event_buffer_commit+0x5c/0x260<br /> trace_event_raw_event_softirq+0x47/0x80<br /> raise_softirq_irqoff+0x6e/0xa0<br /> rcu_read_unlock_special+0xb1/0x160<br /> unwind_next_frame+0x203/0x9b0<br /> __unwind_start+0x15d/0x1c0<br /> arch_stack_walk+0x62/0xf0<br /> stack_trace_save+0x48/0x70<br /> __ftrace_trace_stack.constprop.0+0x144/0x180<br /> trace_buffer_unlock_commit_regs+0x6d/0x220<br /> trace_event_buffer_commit+0x5c/0x260<br /> trace_event_raw_event_softirq+0x47/0x80<br /> raise_softirq_irqoff+0x6e/0xa0<br /> rcu_read_unlock_special+0xb1/0x160<br /> __is_insn_slot_addr+0x54/0x70<br /> kernel_text_address+0x48/0xc0<br /> __kernel_text_address+0xd/0x40<br /> unwind_get_return_address+0x1e/0x40<br /> arch_stack_walk+0x9c/0xf0<br /> stack_trace_save+0x48/0x70<br /> __ftrace_trace_stack.constprop.0+0x144/0x180<br /> trace_buffer_unlock_commit_regs+0x6d/0x220<br /> trace_event_buffer_commit+0x5c/0x260<br /> trace_event_raw_event_softirq+0x47/0x80<br /> __raise_softirq_irqoff+0x61/0x80<br /> __flush_smp_call_function_queue+0x115/0x420<br /> __sysvec_call_function_single+0x17/0xb0<br /> sysvec_call_function_single+0x8c/0xc0<br /> <br /> <br /> Commit b41642c87716 ("rcu: Fix rcu_read_unlock() deadloop due to IRQ work")<br /> fixed the infinite loop in rcu_read_unlock_special() for IRQ work by<br /> setting a flag before calling irq_work_queue_on(). We fix this issue by<br /> setting the same flag before calling raise_softirq_irqoff() and rename the<br /> flag to defer_qs_pending for more common.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/exynos: vidi: use priv-&gt;vidi_dev for ctx lookup in vidi_connection_ioctl()<br /> <br /> vidi_connection_ioctl() retrieves the driver_data from drm_dev-&gt;dev to<br /> obtain a struct vidi_context pointer. However, drm_dev-&gt;dev is the<br /> exynos-drm master device, and the driver_data contained therein is not<br /> the vidi component device, but a completely different device.<br /> <br /> This can lead to various bugs, ranging from null pointer dereferences and<br /> garbage value accesses to, in unlucky cases, out-of-bounds errors,<br /> use-after-free errors, and more.<br /> <br /> To resolve this issue, we need to store/delete the vidi device pointer in<br /> exynos_drm_private-&gt;vidi_dev during bind/unbind, and then read this<br /> exynos_drm_private-&gt;vidi_dev within ioctl() to obtain the correct<br /> struct vidi_context pointer.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> md/md-llbitmap: fix percpu_ref not resurrected on suspend timeout<br /> <br /> When llbitmap_suspend_timeout() times out waiting for percpu_ref to<br /> become zero, it returns -ETIMEDOUT without resurrecting the percpu_ref.<br /> The caller (md_llbitmap_daemon_fn) then continues to the next page<br /> without calling llbitmap_resume(), leaving the percpu_ref in a killed<br /> state permanently.<br /> <br /> Fix this by resurrecting the percpu_ref before returning the error,<br /> ensuring the page control structure remains usable for subsequent<br /> operations.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> eth: fbnic: Add validation for MTU changes<br /> <br /> Increasing the MTU beyond the HDS threshold causes the hardware to<br /> fragment packets across multiple buffers. If a single-buffer XDP program<br /> is attached, the driver will drop all multi-frag frames. While we can&amp;#39;t<br /> prevent a remote sender from sending non-TCP packets larger than the MTU,<br /> this will prevent users from inadvertently breaking new TCP streams.<br /> <br /> Traditionally, drivers supported XDP with MTU less than 4Kb<br /> (packet per page). Fbnic currently prevents attaching XDP when MTU is too high.<br /> But it does not prevent increasing MTU after XDP is attached.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fbdev: au1200fb: Fix a memory leak in au1200fb_drv_probe()<br /> <br /> In au1200fb_drv_probe(), when platform_get_irq fails(), it directly<br /> returns from the function with an error code, which causes a memory<br /> leak.<br /> <br /> Replace it with a goto label to ensure proper cleanup.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> md/raid5: fix IO hang with degraded array with llbitmap<br /> <br /> When llbitmap bit state is still unwritten, any new write should force<br /> rcw, as bitmap_ops-&gt;blocks_synced() is checked in handle_stripe_dirtying().<br /> However, later the same check is missing in need_this_block(), causing<br /> stripe to deadloop during handling because handle_stripe() will decide<br /> to go to handle_stripe_fill(), meanwhile need_this_block() always return<br /> 0 and nothing is handled.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Fix a potential use-after-free of BTF object<br /> <br /> Refcounting in the check_pseudo_btf_id() function is incorrect:<br /> the __check_pseudo_btf_id() function might get called with a zero<br /> refcounted btf. Fix this, and patch related code accordingly.<br /> <br /> v3: rephrase a comment (AI)<br /> v2: fix a refcount leak introduced in v1 (AI)

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: starfive - Fix memory leak in starfive_aes_aead_do_one_req()<br /> <br /> The starfive_aes_aead_do_one_req() function allocates rctx-&gt;adata with<br /> kzalloc() but fails to free it if sg_copy_to_buffer() or<br /> starfive_aes_hw_init() fails, which lead to memory leaks.<br /> <br /> Since rctx-&gt;adata is unconditionally freed after the write_adata<br /> operations, ensure consistent cleanup by freeing the allocation in these<br /> earlier error paths as well.<br /> <br /> Compile tested only. Issue found using a prototype static analysis tool<br /> and code review.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> hwrng: core - use RCU and work_struct to fix race condition<br /> <br /> Currently, hwrng_fill is not cleared until the hwrng_fillfn() thread<br /> exits. Since hwrng_unregister() reads hwrng_fill outside the rng_mutex<br /> lock, a concurrent hwrng_unregister() may call kthread_stop() again on<br /> the same task.<br /> <br /> Additionally, if hwrng_unregister() is called immediately after<br /> hwrng_register(), the stopped thread may have never been executed. Thus,<br /> hwrng_fill remains dirty even after hwrng_unregister() returns. In this<br /> case, subsequent calls to hwrng_register() will fail to start new<br /> threads, and hwrng_unregister() will call kthread_stop() on the same<br /> freed task. In both cases, a use-after-free occurs:<br /> <br /> refcount_t: addition on 0; use-after-free.<br /> WARNING: ... at lib/refcount.c:25 refcount_warn_saturate+0xec/0x1c0<br /> Call Trace:<br /> kthread_stop+0x181/0x360<br /> hwrng_unregister+0x288/0x380<br /> virtrng_remove+0xe3/0x200<br /> <br /> This patch fixes the race by protecting the global hwrng_fill pointer<br /> inside the rng_mutex lock, so that hwrng_fillfn() thread is stopped only<br /> once, and calls to kthread_run() and kthread_stop() are serialized<br /> with the lock held.<br /> <br /> To avoid deadlock in hwrng_fillfn() while being stopped with the lock<br /> held, we convert current_rng to RCU, so that get_current_rng() can read<br /> current_rng without holding the lock. To remove the lock from put_rng(),<br /> we also delay the actual cleanup into a work_struct.<br /> <br /> Since get_current_rng() no longer returns ERR_PTR values, the IS_ERR()<br /> checks are removed from its callers.<br /> <br /> With hwrng_fill protected by the rng_mutex lock, hwrng_fillfn() can no<br /> longer clear hwrng_fill itself. Therefore, if hwrng_fillfn() returns<br /> directly after current_rng is dropped, kthread_stop() would be called on<br /> a freed task_struct later. To fix this, hwrng_fillfn() calls schedule()<br /> now to keep the task alive until being stopped. The kthread_stop() call<br /> is also moved from hwrng_unregister() to drop_current_rng(), ensuring<br /> kthread_stop() is called on all possible paths where current_rng becomes<br /> NULL, so that the thread would not wait forever.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: fix memory leak in ext4_ext_shift_extents()<br /> <br /> In ext4_ext_shift_extents(), if the extent is NULL in the while loop, the<br /> function returns immediately without releasing the path obtained via<br /> ext4_find_extent(), leading to a memory leak.<br /> <br /> Fix this by jumping to the out label to ensure the path is properly<br /> released.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu: Fix memory leak in amdgpu_acpi_enumerate_xcc()<br /> <br /> In amdgpu_acpi_enumerate_xcc(), if amdgpu_acpi_dev_init() returns -ENOMEM,<br /> the function returns directly without releasing the allocated xcc_info,<br /> resulting in a memory leak.<br /> <br /> Fix this by ensuring that xcc_info is properly freed in the error paths.<br /> <br /> Compile tested only. Issue found using a prototype static analysis tool<br /> and code review.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> power: supply: ab8500: Fix use-after-free in power_supply_changed()<br /> <br /> Using the `devm_` variant for requesting IRQ _before_ the `devm_`<br /> variant for allocating/registering the `power_supply` handle, means that<br /> the `power_supply` handle will be deallocated/unregistered _before_ the<br /> interrupt handler (since `devm_` naturally deallocates in reverse<br /> allocation order). This means that during removal, there is a race<br /> condition where an interrupt can fire just _after_ the `power_supply`<br /> handle has been freed, *but* just _before_ the corresponding<br /> unregistration of the IRQ handler has run.<br /> <br /> This will lead to the IRQ handler calling `power_supply_changed()` with<br /> a freed `power_supply` handle. Which usually crashes the system or<br /> otherwise silently corrupts the memory...<br /> <br /> Note that there is a similar situation which can also happen during<br /> `probe()`; the possibility of an interrupt firing _before_ registering<br /> the `power_supply` handle. This would then lead to the nasty situation<br /> of using the `power_supply` handle *uninitialized* in<br /> `power_supply_changed()`.<br /> <br /> Commit 1c1f13a006ed ("power: supply: ab8500: Move to componentized<br /> binding") introduced this issue during a refactorization. Fix this racy<br /> use-after-free by making sure the IRQ is requested _after_ the<br /> registration of the `power_supply` handle.