Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: macb: properly unregister fixed rate clocks<br /> <br /> The additional resources allocated with clk_register_fixed_rate() need<br /> to be released with clk_unregister_fixed_rate(), otherwise they are lost.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: macb: fix clk handling on PCI glue driver removal<br /> <br /> platform_device_unregister() may still want to use the registered clks<br /> during runtime resume callback.<br /> <br /> Note that there is a commit d82d5303c4c5 ("net: macb: fix use after free<br /> on rmmod") that addressed the similar problem of clk vs platform device<br /> unregistration but just moved the bug to another place.<br /> <br /> Save the pointers to clks into local variables for reuse after platform<br /> device is unregistered.<br /> <br /> BUG: KASAN: use-after-free in clk_prepare+0x5a/0x60<br /> Read of size 8 at addr ffff888104f85e00 by task modprobe/597<br /> <br /> CPU: 2 PID: 597 Comm: modprobe Not tainted 6.1.164+ #114<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.1-0-g3208b098f51a-prebuilt.qemu.org 04/01/2014<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x8d/0xba<br /> print_report+0x17f/0x496<br /> kasan_report+0xd9/0x180<br /> clk_prepare+0x5a/0x60<br /> macb_runtime_resume+0x13d/0x410 [macb]<br /> pm_generic_runtime_resume+0x97/0xd0<br /> __rpm_callback+0xc8/0x4d0<br /> rpm_callback+0xf6/0x230<br /> rpm_resume+0xeeb/0x1a70<br /> __pm_runtime_resume+0xb4/0x170<br /> bus_remove_device+0x2e3/0x4b0<br /> device_del+0x5b3/0xdc0<br /> platform_device_del+0x4e/0x280<br /> platform_device_unregister+0x11/0x50<br /> pci_device_remove+0xae/0x210<br /> device_remove+0xcb/0x180<br /> device_release_driver_internal+0x529/0x770<br /> driver_detach+0xd4/0x1a0<br /> bus_remove_driver+0x135/0x260<br /> driver_unregister+0x72/0xb0<br /> pci_unregister_driver+0x26/0x220<br /> __do_sys_delete_module+0x32e/0x550<br /> do_syscall_64+0x35/0x80<br /> entry_SYSCALL_64_after_hwframe+0x6e/0xd8<br /> <br /> <br /> Allocated by task 519:<br /> kasan_save_stack+0x2c/0x50<br /> kasan_set_track+0x21/0x30<br /> __kasan_kmalloc+0x8e/0x90<br /> __clk_register+0x458/0x2890<br /> clk_hw_register+0x1a/0x60<br /> __clk_hw_register_fixed_rate+0x255/0x410<br /> clk_register_fixed_rate+0x3c/0xa0<br /> macb_probe+0x1d8/0x42e [macb_pci]<br /> local_pci_probe+0xd7/0x190<br /> pci_device_probe+0x252/0x600<br /> really_probe+0x255/0x7f0<br /> __driver_probe_device+0x1ee/0x330<br /> driver_probe_device+0x4c/0x1f0<br /> __driver_attach+0x1df/0x4e0<br /> bus_for_each_dev+0x15d/0x1f0<br /> bus_add_driver+0x486/0x5e0<br /> driver_register+0x23a/0x3d0<br /> do_one_initcall+0xfd/0x4d0<br /> do_init_module+0x18b/0x5a0<br /> load_module+0x5663/0x7950<br /> __do_sys_finit_module+0x101/0x180<br /> do_syscall_64+0x35/0x80<br /> entry_SYSCALL_64_after_hwframe+0x6e/0xd8<br /> <br /> Freed by task 597:<br /> kasan_save_stack+0x2c/0x50<br /> kasan_set_track+0x21/0x30<br /> kasan_save_free_info+0x2a/0x50<br /> __kasan_slab_free+0x106/0x180<br /> __kmem_cache_free+0xbc/0x320<br /> clk_unregister+0x6de/0x8d0<br /> macb_remove+0x73/0xc0 [macb_pci]<br /> pci_device_remove+0xae/0x210<br /> device_remove+0xcb/0x180<br /> device_release_driver_internal+0x529/0x770<br /> driver_detach+0xd4/0x1a0<br /> bus_remove_driver+0x135/0x260<br /> driver_unregister+0x72/0xb0<br /> pci_unregister_driver+0x26/0x220<br /> __do_sys_delete_module+0x32e/0x550<br /> do_syscall_64+0x35/0x80<br /> entry_SYSCALL_64_after_hwframe+0x6e/0xd8

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: sockmap: Fix use-after-free of sk-&gt;sk_socket in sk_psock_verdict_data_ready().<br /> <br /> syzbot reported use-after-free of AF_UNIX socket&amp;#39;s sk-&gt;sk_socket<br /> in sk_psock_verdict_data_ready(). [0]<br /> <br /> In unix_stream_sendmsg(), the peer socket&amp;#39;s -&gt;sk_data_ready() is<br /> called after dropping its unix_state_lock().<br /> <br /> Although the sender socket holds the peer&amp;#39;s refcount, it does not<br /> prevent the peer&amp;#39;s sock_orphan(), and the peer&amp;#39;s sk_socket might<br /> be freed after one RCU grace period.<br /> <br /> Let&amp;#39;s fetch the peer&amp;#39;s sk-&gt;sk_socket and sk-&gt;sk_socket-&gt;ops under<br /> RCU in sk_psock_verdict_data_ready().<br /> <br /> [0]:<br /> BUG: KASAN: slab-use-after-free in sk_psock_verdict_data_ready+0xec/0x590 net/core/skmsg.c:1278<br /> Read of size 8 at addr ffff8880594da860 by task syz.4.1842/11013<br /> <br /> CPU: 1 UID: 0 PID: 11013 Comm: syz.4.1842 Not tainted syzkaller #0 PREEMPT(full)<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2026<br /> Call Trace:<br /> <br /> dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120<br /> print_address_description mm/kasan/report.c:378 [inline]<br /> print_report+0xba/0x230 mm/kasan/report.c:482<br /> kasan_report+0x117/0x150 mm/kasan/report.c:595<br /> sk_psock_verdict_data_ready+0xec/0x590 net/core/skmsg.c:1278<br /> unix_stream_sendmsg+0x8a3/0xe80 net/unix/af_unix.c:2482<br /> sock_sendmsg_nosec net/socket.c:721 [inline]<br /> __sock_sendmsg net/socket.c:736 [inline]<br /> ____sys_sendmsg+0x972/0x9f0 net/socket.c:2585<br /> ___sys_sendmsg+0x2a5/0x360 net/socket.c:2639<br /> __sys_sendmsg net/socket.c:2671 [inline]<br /> __do_sys_sendmsg net/socket.c:2676 [inline]<br /> __se_sys_sendmsg net/socket.c:2674 [inline]<br /> __x64_sys_sendmsg+0x1bd/0x2a0 net/socket.c:2674<br /> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]<br /> do_syscall_64+0x14d/0xf80 arch/x86/entry/syscall_64.c:94<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> RIP: 0033:0x7facf899c819<br /> Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 3d 01 f0 ff ff 73 01 c3 48 c7 c1 e8 ff ff ff f7 d8 64 89 01 48<br /> RSP: 002b:00007facf9827028 EFLAGS: 00000246 ORIG_RAX: 000000000000002e<br /> RAX: ffffffffffffffda RBX: 00007facf8c15fa0 RCX: 00007facf899c819<br /> RDX: 0000000000000000 RSI: 0000200000000500 RDI: 0000000000000004<br /> RBP: 00007facf8a32c91 R08: 0000000000000000 R09: 0000000000000000<br /> R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000<br /> R13: 00007facf8c16038 R14: 00007facf8c15fa0 R15: 00007ffd41b01c78<br /> <br /> <br /> Allocated by task 11013:<br /> kasan_save_stack mm/kasan/common.c:57 [inline]<br /> kasan_save_track+0x3e/0x80 mm/kasan/common.c:78<br /> unpoison_slab_object mm/kasan/common.c:340 [inline]<br /> __kasan_slab_alloc+0x6c/0x80 mm/kasan/common.c:366<br /> kasan_slab_alloc include/linux/kasan.h:253 [inline]<br /> slab_post_alloc_hook mm/slub.c:4538 [inline]<br /> slab_alloc_node mm/slub.c:4866 [inline]<br /> kmem_cache_alloc_lru_noprof+0x2b8/0x640 mm/slub.c:4885<br /> sock_alloc_inode+0x28/0xc0 net/socket.c:316<br /> alloc_inode+0x6a/0x1b0 fs/inode.c:347<br /> new_inode_pseudo include/linux/fs.h:3003 [inline]<br /> sock_alloc net/socket.c:631 [inline]<br /> __sock_create+0x12d/0x9d0 net/socket.c:1562<br /> sock_create net/socket.c:1656 [inline]<br /> __sys_socketpair+0x1c4/0x560 net/socket.c:1803<br /> __do_sys_socketpair net/socket.c:1856 [inline]<br /> __se_sys_socketpair net/socket.c:1853 [inline]<br /> __x64_sys_socketpair+0x9b/0xb0 net/socket.c:1853<br /> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]<br /> do_syscall_64+0x14d/0xf80 arch/x86/entry/syscall_64.c:94<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> Freed by task 15:<br /> kasan_save_stack mm/kasan/common.c:57 [inline]<br /> kasan_save_track+0x3e/0x80 mm/kasan/common.c:78<br /> kasan_save_free_info+0x46/0x50 mm/kasan/generic.c:584<br /> poison_slab_object mm/kasan/common.c:253 [inline]<br /> __kasan_slab_free+0x5c/0x80 mm/kasan/common.c:285<br /> kasan_slab_free include/linux/kasan.h:235 [inline]<br /> slab_free_hook mm/slub.c:2685 [inline]<br /> slab_free mm/slub.c:6165 [inline]<br /> kmem_cache_free+0x187/0x630 mm/slub.c:6295<br /> rcu_do_batch kernel/rcu/tree.c:<br /> ---truncated---

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: MGMT: validate mesh send advertising payload length<br /> <br /> mesh_send() currently bounds MGMT_OP_MESH_SEND by total command<br /> length, but it never verifies that the bytes supplied for the<br /> flexible adv_data[] array actually match the embedded adv_data_len<br /> field. MGMT_MESH_SEND_SIZE only covers the fixed header, so a<br /> truncated command can still pass the existing 20..50 byte range<br /> check and later drive the async mesh send path past the end of the<br /> queued command buffer.<br /> <br /> Keep rejecting zero-length and oversized advertising payloads, but<br /> validate adv_data_len explicitly and require the command length to<br /> exactly match the flexible array size before queueing the request.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: hci_event: fix potential UAF in hci_le_remote_conn_param_req_evt<br /> <br /> hci_conn lookup and field access must be covered by hdev lock in<br /> hci_le_remote_conn_param_req_evt, otherwise it&amp;#39;s possible it is freed<br /> concurrently.<br /> <br /> Extend the hci_dev_lock critical section to cover all conn usage.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> accel/qaic: Handle DBC deactivation if the owner went away<br /> <br /> When a DBC is released, the device sends a QAIC_TRANS_DEACTIVATE_FROM_DEV<br /> transaction to the host over the QAIC_CONTROL MHI channel. QAIC handles<br /> this by calling decode_deactivate() to release the resources allocated for<br /> that DBC. Since that handling is done in the qaic_manage_ioctl() context,<br /> if the user goes away before receiving and handling the deactivation, the<br /> host will be out-of-sync with the DBCs available for use, and the DBC<br /> resources will not be freed unless the device is removed. If another user<br /> loads and requests to activate a network, then the device assigns the same<br /> DBC to that network, QAIC will "indefinitely" wait for dbc-&gt;in_use = false,<br /> leading the user process to hang.<br /> <br /> As a solution to this, handle QAIC_TRANS_DEACTIVATE_FROM_DEV transactions<br /> that are received after the user has gone away.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> gpio: qixis-fpga: Fix error handling for devm_regmap_init_mmio()<br /> <br /> devm_regmap_init_mmio() returns an ERR_PTR() on failure, not NULL.<br /> The original code checked for NULL which would never trigger on error,<br /> potentially leading to an invalid pointer dereference.<br /> Use IS_ERR() and PTR_ERR() to properly handle the error case.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Fix incorrect pruning due to atomic fetch precision tracking<br /> <br /> When backtrack_insn encounters a BPF_STX instruction with BPF_ATOMIC<br /> and BPF_FETCH, the src register (or r0 for BPF_CMPXCHG) also acts as<br /> a destination, thus receiving the old value from the memory location.<br /> <br /> The current backtracking logic does not account for this. It treats<br /> atomic fetch operations the same as regular stores where the src<br /> register is only an input. This leads the backtrack_insn to fail to<br /> propagate precision to the stack location, which is then not marked<br /> as precise!<br /> <br /> Later, the verifier&amp;#39;s path pruning can incorrectly consider two states<br /> equivalent when they differ in terms of stack state. Meaning, two<br /> branches can be treated as equivalent and thus get pruned when they<br /> should not be seen as such.<br /> <br /> Fix it as follows: Extend the BPF_LDX handling in backtrack_insn to<br /> also cover atomic fetch operations via is_atomic_fetch_insn() helper.<br /> When the fetch dst register is being tracked for precision, clear it,<br /> and propagate precision over to the stack slot. For non-stack memory,<br /> the precision walk stops at the atomic instruction, same as regular<br /> BPF_LDX. This covers all fetch variants.<br /> <br /> Before:<br /> <br /> 0: (b7) r1 = 8 ; R1=8<br /> 1: (7b) *(u64 *)(r10 -8) = r1 ; R1=8 R10=fp0 fp-8=8<br /> 2: (b7) r2 = 0 ; R2=0<br /> 3: (db) r2 = atomic64_fetch_add((u64 *)(r10 -8), r2) ; R2=8 R10=fp0 fp-8=mmmmmmmm<br /> 4: (bf) r3 = r10 ; R3=fp0 R10=fp0<br /> 5: (0f) r3 += r2<br /> mark_precise: frame0: last_idx 5 first_idx 0 subseq_idx -1<br /> mark_precise: frame0: regs=r2 stack= before 4: (bf) r3 = r10<br /> mark_precise: frame0: regs=r2 stack= before 3: (db) r2 = atomic64_fetch_add((u64 *)(r10 -8), r2)<br /> mark_precise: frame0: regs=r2 stack= before 2: (b7) r2 = 0<br /> 6: R2=8 R3=fp8<br /> 6: (b7) r0 = 0 ; R0=0<br /> 7: (95) exit<br /> <br /> After:<br /> <br /> 0: (b7) r1 = 8 ; R1=8<br /> 1: (7b) *(u64 *)(r10 -8) = r1 ; R1=8 R10=fp0 fp-8=8<br /> 2: (b7) r2 = 0 ; R2=0<br /> 3: (db) r2 = atomic64_fetch_add((u64 *)(r10 -8), r2) ; R2=8 R10=fp0 fp-8=mmmmmmmm<br /> 4: (bf) r3 = r10 ; R3=fp0 R10=fp0<br /> 5: (0f) r3 += r2<br /> mark_precise: frame0: last_idx 5 first_idx 0 subseq_idx -1<br /> mark_precise: frame0: regs=r2 stack= before 4: (bf) r3 = r10<br /> mark_precise: frame0: regs=r2 stack= before 3: (db) r2 = atomic64_fetch_add((u64 *)(r10 -8), r2)<br /> mark_precise: frame0: regs= stack=-8 before 2: (b7) r2 = 0<br /> mark_precise: frame0: regs= stack=-8 before 1: (7b) *(u64 *)(r10 -8) = r1<br /> mark_precise: frame0: regs=r1 stack= before 0: (b7) r1 = 8<br /> 6: R2=8 R3=fp8<br /> 6: (b7) r0 = 0 ; R0=0<br /> 7: (95) exit

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Reject sleepable kprobe_multi programs at attach time<br /> <br /> kprobe.multi programs run in atomic/RCU context and cannot sleep.<br /> However, bpf_kprobe_multi_link_attach() did not validate whether the<br /> program being attached had the sleepable flag set, allowing sleepable<br /> helpers such as bpf_copy_from_user() to be invoked from a non-sleepable<br /> context.<br /> <br /> This causes a "sleeping function called from invalid context" splat:<br /> <br /> BUG: sleeping function called from invalid context at ./include/linux/uaccess.h:169<br /> in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 1787, name: sudo<br /> preempt_count: 1, expected: 0<br /> RCU nest depth: 2, expected: 0<br /> <br /> Fix this by rejecting sleepable programs early in<br /> bpf_kprobe_multi_link_attach(), before any further processing.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/x25: Fix potential double free of skb<br /> <br /> When alloc_skb fails in x25_queue_rx_frame it calls kfree_skb(skb) at<br /> line 48 and returns 1 (error).<br /> This error propagates back through the call chain:<br /> <br /> x25_queue_rx_frame returns 1<br /> |<br /> v<br /> x25_state3_machine receives the return value 1 and takes the else<br /> branch at line 278, setting queued=0 and returning 0<br /> |<br /> v<br /> x25_process_rx_frame returns queued=0<br /> |<br /> v<br /> x25_backlog_rcv at line 452 sees queued=0 and calls kfree_skb(skb)<br /> again<br /> <br /> This would free the same skb twice. Looking at x25_backlog_rcv:<br /> <br /> net/x25/x25_in.c:x25_backlog_rcv() {<br /> ...<br /> queued = x25_process_rx_frame(sk, skb);<br /> ...<br /> if (!queued)<br /> kfree_skb(skb);<br /> }

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> spi: stm32-ospi: Fix resource leak in remove() callback<br /> <br /> The remove() callback returned early if pm_runtime_resume_and_get()<br /> failed, skipping the cleanup of spi controller and other resources.<br /> <br /> Remove the early return so cleanup completes regardless of PM resume<br /> result.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> hwmon: (tps53679) Fix array access with zero-length block read<br /> <br /> i2c_smbus_read_block_data() can return 0, indicating a zero-length<br /> read. When this happens, tps53679_identify_chip() accesses buf[ret - 1]<br /> which is buf[-1], reading one byte before the buffer on the stack.<br /> <br /> Fix by changing the check from "ret