Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: SCO: fix race conditions in sco_sock_connect()<br /> <br /> sco_sock_connect() checks sk_state and sk_type without holding<br /> the socket lock. Two concurrent connect() syscalls on the same<br /> socket can both pass the check and enter sco_connect(), leading<br /> to use-after-free.<br /> <br /> The buggy scenario involves three participants and was confirmed<br /> with additional logging instrumentation:<br /> <br /> Thread A (connect): HCI disconnect: Thread B (connect):<br /> <br /> sco_sock_connect(sk) sco_sock_connect(sk)<br /> sk_state==BT_OPEN sk_state==BT_OPEN<br /> (pass, no lock) (pass, no lock)<br /> sco_connect(sk): sco_connect(sk):<br /> hci_dev_lock hci_dev_lock<br /> hci_connect_sco hcon1<br /> sco_conn_add-&gt;conn1<br /> lock_sock(sk)<br /> sco_chan_add:<br /> conn1-&gt;sk = sk<br /> sk-&gt;conn = conn1<br /> sk_state=BT_CONNECT<br /> release_sock<br /> hci_dev_unlock<br /> hci_dev_lock<br /> sco_conn_del:<br /> lock_sock(sk)<br /> sco_chan_del:<br /> sk-&gt;conn=NULL<br /> conn1-&gt;sk=NULL<br /> sk_state=<br /> BT_CLOSED<br /> SOCK_ZAPPED<br /> release_sock<br /> hci_dev_unlock<br /> (unblocked)<br /> hci_connect_sco<br /> -&gt; hcon2<br /> sco_conn_add<br /> -&gt; conn2<br /> lock_sock(sk)<br /> sco_chan_add:<br /> sk-&gt;conn=conn2<br /> sk_state=<br /> BT_CONNECT<br /> // zombie sk!<br /> release_sock<br /> hci_dev_unlock<br /> <br /> Thread B revives a BT_CLOSED + SOCK_ZAPPED socket back to<br /> BT_CONNECT. Subsequent cleanup triggers double sock_put() and<br /> use-after-free. Meanwhile conn1 is leaked as it was orphaned<br /> when sco_conn_del() cleared the association.<br /> <br /> Fix this by:<br /> - Moving lock_sock() before the sk_state/sk_type checks in<br /> sco_sock_connect() to serialize concurrent connect attempts<br /> - Fixing the sk_type != SOCK_SEQPACKET check to actually<br /> return the error instead of just assigning it<br /> - Adding a state re-check in sco_connect() after lock_sock()<br /> to catch state changes during the window between the locks<br /> - Adding sco_pi(sk)-&gt;conn check in sco_chan_add() to prevent<br /> double-attach of a socket to multiple connections<br /> - Adding hci_conn_drop() on sco_chan_add failure to prevent<br /> HCI connection leaks

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nf_tables: reject immediate NF_QUEUE verdict<br /> <br /> nft_queue is always used from userspace nftables to deliver the NF_QUEUE<br /> verdict. Immediately emitting an NF_QUEUE verdict is never used by the<br /> userspace nft tools, so reject immediate NF_QUEUE verdicts.<br /> <br /> The arp family does not provide queue support, but such an immediate<br /> verdict is still reachable. Globally reject NF_QUEUE immediate verdicts<br /> to address this issue.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: ctnetlink: ignore explicit helper on new expectations<br /> <br /> Use the existing master conntrack helper, anything else is not really<br /> supported and it just makes validation more complicated, so just ignore<br /> what helper userspace suggests for this expectation.<br /> <br /> This was uncovered when validating CTA_EXPECT_CLASS via different helper<br /> provided by userspace than the existing master conntrack helper:<br /> <br /> BUG: KASAN: slab-out-of-bounds in nf_ct_expect_related_report+0x2479/0x27c0<br /> Read of size 4 at addr ffff8880043fe408 by task poc/102<br /> Call Trace:<br /> nf_ct_expect_related_report+0x2479/0x27c0<br /> ctnetlink_create_expect+0x22b/0x3b0<br /> ctnetlink_new_expect+0x4bd/0x5c0<br /> nfnetlink_rcv_msg+0x67a/0x950<br /> netlink_rcv_skb+0x120/0x350<br /> <br /> Allowing to read kernel memory bytes off the expectation boundary.<br /> <br /> CTA_EXPECT_HELP_NAME is still used to offer the helper name to userspace<br /> via netlink dump.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5: Fix switchdev mode rollback in case of failure<br /> <br /> If for some internal reason switchdev mode fails, we rollback to legacy<br /> mode, before this patch, rollback will unregister the uplink netdev and<br /> leave it unregistered causing the below kernel bug.<br /> <br /> To fix this, we need to avoid netdev unregister by setting the proper<br /> rollback flag &amp;#39;MLX5_PRIV_FLAGS_SWITCH_LEGACY&amp;#39; to indicate legacy mode.<br /> <br /> devlink (431) used greatest stack depth: 11048 bytes left<br /> mlx5_core 0000:00:03.0: E-Switch: Disable: mode(LEGACY), nvfs(0), \<br /> necvfs(0), active vports(0)<br /> mlx5_core 0000:00:03.0: E-Switch: Supported tc chains and prios offload<br /> mlx5_core 0000:00:03.0: Loading uplink representor for vport 65535<br /> mlx5_core 0000:00:03.0: mlx5_cmd_out_err:816:(pid 456): \<br /> QUERY_HCA_CAP(0x100) op_mod(0x0) failed, \<br /> status bad parameter(0x3), syndrome (0x3a3846), err(-22)<br /> mlx5_core 0000:00:03.0 enp0s3np0 (unregistered): Unloading uplink \<br /> representor for vport 65535<br /> ------------[ cut here ]------------<br /> kernel BUG at net/core/dev.c:12070!<br /> Oops: invalid opcode: 0000 [#1] SMP NOPTI<br /> CPU: 2 UID: 0 PID: 456 Comm: devlink Not tainted 6.16.0-rc3+ \<br /> #9 PREEMPT(voluntary)<br /> RIP: 0010:unregister_netdevice_many_notify+0x123/0xae0<br /> ...<br /> Call Trace:<br /> [ 90.923094] unregister_netdevice_queue+0xad/0xf0<br /> [ 90.923323] unregister_netdev+0x1c/0x40<br /> [ 90.923522] mlx5e_vport_rep_unload+0x61/0xc6<br /> [ 90.923736] esw_offloads_enable+0x8e6/0x920<br /> [ 90.923947] mlx5_eswitch_enable_locked+0x349/0x430<br /> [ 90.924182] ? is_mp_supported+0x57/0xb0<br /> [ 90.924376] mlx5_devlink_eswitch_mode_set+0x167/0x350<br /> [ 90.924628] devlink_nl_eswitch_set_doit+0x6f/0xf0<br /> [ 90.924862] genl_family_rcv_msg_doit+0xe8/0x140<br /> [ 90.925088] genl_rcv_msg+0x18b/0x290<br /> [ 90.925269] ? __pfx_devlink_nl_pre_doit+0x10/0x10<br /> [ 90.925506] ? __pfx_devlink_nl_eswitch_set_doit+0x10/0x10<br /> [ 90.925766] ? __pfx_devlink_nl_post_doit+0x10/0x10<br /> [ 90.926001] ? __pfx_genl_rcv_msg+0x10/0x10<br /> [ 90.926206] netlink_rcv_skb+0x52/0x100<br /> [ 90.926393] genl_rcv+0x28/0x40<br /> [ 90.926557] netlink_unicast+0x27d/0x3d0<br /> [ 90.926749] netlink_sendmsg+0x1f7/0x430<br /> [ 90.926942] __sys_sendto+0x213/0x220<br /> [ 90.927127] ? __sys_recvmsg+0x6a/0xd0<br /> [ 90.927312] __x64_sys_sendto+0x24/0x30<br /> [ 90.927504] do_syscall_64+0x50/0x1c0<br /> [ 90.927687] entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> [ 90.927929] RIP: 0033:0x7f7d0363e047

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5: lag: Check for LAG device before creating debugfs<br /> <br /> __mlx5_lag_dev_add_mdev() may return 0 (success) even when an error<br /> occurs that is handled gracefully. Consequently, the initialization<br /> flow proceeds to call mlx5_ldev_add_debugfs() even when there is no<br /> valid LAG context.<br /> <br /> mlx5_ldev_add_debugfs() blindly created the debugfs directory and<br /> attributes. This exposed interfaces (like the members file) that rely on<br /> a valid ldev pointer, leading to potential NULL pointer dereferences if<br /> accessed when ldev is NULL.<br /> <br /> Add a check to verify that mlx5_lag_dev(dev) returns a valid pointer<br /> before attempting to create the debugfs entries.

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