Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: bcmasp: fix double free of WoL irq<br /> <br /> We do not need to free wol_irq since it was instantiated with<br /> devm_request_irq(). So devres will free for us.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/smc: fix double-free of smc_spd_priv when tee() duplicates splice pipe buffer<br /> <br /> smc_rx_splice() allocates one smc_spd_priv per pipe_buffer and stores<br /> the pointer in pipe_buffer.private. The pipe_buf_operations for these<br /> buffers used .get = generic_pipe_buf_get, which only increments the page<br /> reference count when tee(2) duplicates a pipe buffer. The smc_spd_priv<br /> pointer itself was not handled, so after tee() both the original and the<br /> cloned pipe_buffer share the same smc_spd_priv *.<br /> <br /> When both pipes are subsequently released, smc_rx_pipe_buf_release() is<br /> called twice against the same object:<br /> <br /> 1st call: kfree(priv) sock_put(sk) smc_rx_update_cons() [correct]<br /> 2nd call: kfree(priv) sock_put(sk) smc_rx_update_cons() [UAF]<br /> <br /> KASAN reports a slab-use-after-free in smc_rx_pipe_buf_release(), which<br /> then escalates to a NULL-pointer dereference and kernel panic via<br /> smc_rx_update_consumer() when it chases the freed priv-&gt;smc pointer:<br /> <br /> BUG: KASAN: slab-use-after-free in smc_rx_pipe_buf_release+0x78/0x2a0<br /> Read of size 8 at addr ffff888004a45740 by task smc_splice_tee_/74<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x53/0x70<br /> print_report+0xce/0x650<br /> kasan_report+0xc6/0x100<br /> smc_rx_pipe_buf_release+0x78/0x2a0<br /> free_pipe_info+0xd4/0x130<br /> pipe_release+0x142/0x160<br /> __fput+0x1c6/0x490<br /> __x64_sys_close+0x4f/0x90<br /> do_syscall_64+0xa6/0x1a0<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000020<br /> RIP: 0010:smc_rx_update_consumer+0x8d/0x350<br /> Call Trace:<br /> <br /> smc_rx_pipe_buf_release+0x121/0x2a0<br /> free_pipe_info+0xd4/0x130<br /> pipe_release+0x142/0x160<br /> __fput+0x1c6/0x490<br /> __x64_sys_close+0x4f/0x90<br /> do_syscall_64+0xa6/0x1a0<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> Kernel panic - not syncing: Fatal exception<br /> <br /> Beyond the memory-safety problem, duplicating an SMC splice buffer is<br /> semantically questionable: smc_rx_update_cons() would advance the<br /> consumer cursor twice for the same data, corrupting receive-window<br /> accounting. A refcount on smc_spd_priv could fix the double-free, but<br /> the cursor-accounting issue would still need to be addressed separately.<br /> <br /> The .get callback is invoked by both tee(2) and splice_pipe_to_pipe()<br /> for partial transfers; both will now return -EFAULT. Users who need<br /> to duplicate SMC socket data must use a copy-based read path.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: openvswitch: Avoid releasing netdev before teardown completes<br /> <br /> The patch cited in the Fixes tag below changed the teardown code for<br /> OVS ports to no longer unconditionally take the RTNL. After this change,<br /> the netdev_destroy() callback can proceed immediately to the call_rcu()<br /> invocation if the IFF_OVS_DATAPATH flag is already cleared on the<br /> netdev.<br /> <br /> The ovs_netdev_detach_dev() function clears the flag before completing<br /> the unregistration, and if it gets preempted after clearing the flag (as<br /> can happen on an -rt kernel), netdev_destroy() can complete and the<br /> device can be freed before the unregistration completes. This leads to a<br /> splat like:<br /> <br /> [ 998.393867] Oops: general protection fault, probably for non-canonical address 0xff00000001000239: 0000 [#1] SMP PTI<br /> [ 998.393877] CPU: 42 UID: 0 PID: 55177 Comm: ip Kdump: loaded Not tainted 6.12.0-211.1.1.el10_2.x86_64+rt #1 PREEMPT_RT<br /> [ 998.393886] Hardware name: Dell Inc. PowerEdge R740/0JMK61, BIOS 2.24.0 03/27/2025<br /> [ 998.393889] RIP: 0010:dev_set_promiscuity+0x8d/0xa0<br /> [ 998.393901] Code: 00 00 75 d8 48 8b 53 08 48 83 ba b0 02 00 00 00 75 ca 48 83 c4 08 5b c3 cc cc cc cc 48 83 bf 48 09 00 00 00 75 91 48 8b 47 08 83 b8 b0 02 00 00 00 74 97 eb 81 0f 1f 80 00 00 00 00 90 90 90<br /> [ 998.393906] RSP: 0018:ffffce5864a5f6a0 EFLAGS: 00010246<br /> [ 998.393912] RAX: ff00000000ffff89 RBX: ffff894d0adf5a05 RCX: 0000000000000000<br /> [ 998.393917] RDX: 0000000000000000 RSI: 00000000ffffffff RDI: ffff894d0adf5a05<br /> [ 998.393921] RBP: ffff894d19252000 R08: ffff894d19252000 R09: 0000000000000000<br /> [ 998.393924] R10: ffff894d19252000 R11: ffff894d192521b8 R12: 0000000000000006<br /> [ 998.393927] R13: ffffce5864a5f738 R14: 00000000ffffffe2 R15: 0000000000000000<br /> [ 998.393931] FS: 00007fad61971800(0000) GS:ffff894cc0140000(0000) knlGS:0000000000000000<br /> [ 998.393936] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 998.393940] CR2: 000055df0a2a6e40 CR3: 000000011c7fe003 CR4: 00000000007726f0<br /> [ 998.393944] PKRU: 55555554<br /> [ 998.393946] Call Trace:<br /> [ 998.393949] <br /> [ 998.393952] ? show_trace_log_lvl+0x1b0/0x2f0<br /> [ 998.393961] ? show_trace_log_lvl+0x1b0/0x2f0<br /> [ 998.393975] ? dp_device_event+0x41/0x80 [openvswitch]<br /> [ 998.394009] ? __die_body.cold+0x8/0x12<br /> [ 998.394016] ? die_addr+0x3c/0x60<br /> [ 998.394027] ? exc_general_protection+0x16d/0x390<br /> [ 998.394042] ? asm_exc_general_protection+0x26/0x30<br /> [ 998.394058] ? dev_set_promiscuity+0x8d/0xa0<br /> [ 998.394066] ? ovs_netdev_detach_dev+0x3a/0x80 [openvswitch]<br /> [ 998.394092] dp_device_event+0x41/0x80 [openvswitch]<br /> [ 998.394102] notifier_call_chain+0x5a/0xd0<br /> [ 998.394106] unregister_netdevice_many_notify+0x51b/0xa60<br /> [ 998.394110] rtnl_dellink+0x169/0x3e0<br /> [ 998.394121] ? rt_mutex_slowlock.constprop.0+0x95/0xd0<br /> [ 998.394125] rtnetlink_rcv_msg+0x142/0x3f0<br /> [ 998.394128] ? avc_has_perm_noaudit+0x69/0xf0<br /> [ 998.394130] ? __pfx_rtnetlink_rcv_msg+0x10/0x10<br /> [ 998.394132] netlink_rcv_skb+0x50/0x100<br /> [ 998.394138] netlink_unicast+0x292/0x3f0<br /> [ 998.394141] netlink_sendmsg+0x21b/0x470<br /> [ 998.394145] ____sys_sendmsg+0x39d/0x3d0<br /> [ 998.394149] ___sys_sendmsg+0x9a/0xe0<br /> [ 998.394156] __sys_sendmsg+0x7a/0xd0<br /> [ 998.394160] do_syscall_64+0x7f/0x170<br /> [ 998.394162] entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> [ 998.394165] RIP: 0033:0x7fad61bf4724<br /> [ 998.394188] Code: 89 02 b8 ff ff ff ff eb bb 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 f3 0f 1e fa 80 3d c5 e9 0c 00 00 74 13 b8 2e 00 00 00 0f 05 3d 00 f0 ff ff 77 54 c3 0f 1f 00 48 83 ec 28 89 54 24 1c 48 89<br /> [ 998.394189] RSP: 002b:00007ffd7e2f7cb8 EFLAGS: 00000202 ORIG_RAX: 000000000000002e<br /> [ 998.394191] RAX: ffffffffffffffda RBX: 0000000000000001 RCX: 00007fad61bf4724<br /> [ 998.394193] RDX: 0000000000000000 RSI: 00007ffd7e2f7d20 RDI: 0000000000000003<br /> [ 998.394194] RBP: 00007ffd7e2f7d90 R08: 0000000000000010 R09: 000000000000003f<br /> [ 998.394195] R10: 000055df11558010 R11: 0000000000000202 R12: 00007ffd7e2<br /> ---truncated---

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nfc: nci: fix circular locking dependency in nci_close_device<br /> <br /> nci_close_device() flushes rx_wq and tx_wq while holding req_lock.<br /> This causes a circular locking dependency because nci_rx_work()<br /> running on rx_wq can end up taking req_lock too:<br /> <br /> nci_rx_work -&gt; nci_rx_data_packet -&gt; nci_data_exchange_complete<br /> -&gt; __sk_destruct -&gt; rawsock_destruct -&gt; nfc_deactivate_target<br /> -&gt; nci_deactivate_target -&gt; nci_request -&gt; mutex_lock(&amp;ndev-&gt;req_lock)<br /> <br /> Move the flush of rx_wq after req_lock has been released.<br /> This should safe (I think) because NCI_UP has already been cleared<br /> and the transport is closed, so the work will see it and return<br /> -ENETDOWN.<br /> <br /> NIPA has been hitting this running the nci selftest with a debug<br /> kernel on roughly 4% of the runs.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: L2CAP: Fix ERTM re-init and zero pdu_len infinite loop<br /> <br /> l2cap_config_req() processes CONFIG_REQ for channels in BT_CONNECTED<br /> state to support L2CAP reconfiguration (e.g. MTU changes). However,<br /> since both CONF_INPUT_DONE and CONF_OUTPUT_DONE are already set from<br /> the initial configuration, the reconfiguration path falls through to<br /> l2cap_ertm_init(), which re-initializes tx_q, srej_q, srej_list, and<br /> retrans_list without freeing the previous allocations and sets<br /> chan-&gt;sdu to NULL without freeing the existing skb. This leaks all<br /> previously allocated ERTM resources.<br /> <br /> Additionally, l2cap_parse_conf_req() does not validate the minimum<br /> value of remote_mps derived from the RFC max_pdu_size option. A zero<br /> value propagates to l2cap_segment_sdu() where pdu_len becomes zero,<br /> causing the while loop to never terminate since len is never<br /> decremented, exhausting all available memory.<br /> <br /> Fix the double-init by skipping l2cap_ertm_init() and<br /> l2cap_chan_ready() when the channel is already in BT_CONNECTED state,<br /> while still allowing the reconfiguration parameters to be updated<br /> through l2cap_parse_conf_req(). Also add a pdu_len zero check in<br /> l2cap_segment_sdu() as a safeguard.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: L2CAP: Fix deadlock in l2cap_conn_del()<br /> <br /> l2cap_conn_del() calls cancel_delayed_work_sync() for both info_timer<br /> and id_addr_timer while holding conn-&gt;lock. However, the work functions<br /> l2cap_info_timeout() and l2cap_conn_update_id_addr() both acquire<br /> conn-&gt;lock, creating a potential AB-BA deadlock if the work is already<br /> executing when l2cap_conn_del() takes the lock.<br /> <br /> Move the work cancellations before acquiring conn-&gt;lock and use<br /> disable_delayed_work_sync() to additionally prevent the works from<br /> being rearmed after cancellation, consistent with the pattern used in<br /> hci_conn_del().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: btintel: serialize btintel_hw_error() with hci_req_sync_lock<br /> <br /> btintel_hw_error() issues two __hci_cmd_sync() calls (HCI_OP_RESET<br /> and Intel exception-info retrieval) without holding<br /> hci_req_sync_lock(). This lets it race against<br /> hci_dev_do_close() -&gt; btintel_shutdown_combined(), which also runs<br /> __hci_cmd_sync() under the same lock. When both paths manipulate<br /> hdev-&gt;req_status/req_rsp concurrently, the close path may free the<br /> response skb first, and the still-running hw_error path hits a<br /> slab-use-after-free in kfree_skb().<br /> <br /> Wrap the whole recovery sequence in hci_req_sync_lock/unlock so it<br /> is serialized with every other synchronous HCI command issuer.<br /> <br /> Below is the data race report and the kasan report:<br /> <br /> BUG: data-race in __hci_cmd_sync_sk / btintel_shutdown_combined<br /> <br /> read of hdev-&gt;req_rsp at net/bluetooth/hci_sync.c:199<br /> by task kworker/u17:1/83:<br /> __hci_cmd_sync_sk+0x12f2/0x1c30 net/bluetooth/hci_sync.c:200<br /> __hci_cmd_sync+0x55/0x80 net/bluetooth/hci_sync.c:223<br /> btintel_hw_error+0x114/0x670 drivers/bluetooth/btintel.c:254<br /> hci_error_reset+0x348/0xa30 net/bluetooth/hci_core.c:1030<br /> <br /> write/free by task ioctl/22580:<br /> btintel_shutdown_combined+0xd0/0x360<br /> drivers/bluetooth/btintel.c:3648<br /> hci_dev_close_sync+0x9ae/0x2c10 net/bluetooth/hci_sync.c:5246<br /> hci_dev_do_close+0x232/0x460 net/bluetooth/hci_core.c:526<br /> <br /> BUG: KASAN: slab-use-after-free in<br /> sk_skb_reason_drop+0x43/0x380 net/core/skbuff.c:1202<br /> Read of size 4 at addr ffff888144a738dc<br /> by task kworker/u17:1/83:<br /> __hci_cmd_sync_sk+0x12f2/0x1c30 net/bluetooth/hci_sync.c:200<br /> __hci_cmd_sync+0x55/0x80 net/bluetooth/hci_sync.c:223<br /> btintel_hw_error+0x186/0x670 drivers/bluetooth/btintel.c:260

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: ti: icssg-prueth: fix use-after-free of CPPI descriptor in RX path<br /> <br /> cppi5_hdesc_get_psdata() returns a pointer into the CPPI descriptor.<br /> In both emac_rx_packet() and emac_rx_packet_zc(), the descriptor is<br /> freed via k3_cppi_desc_pool_free() before the psdata pointer is used<br /> by emac_rx_timestamp(), which dereferences psdata[0] and psdata[1].<br /> This constitutes a use-after-free on every received packet that goes<br /> through the timestamp path.<br /> <br /> Defer the descriptor free until after all accesses through the psdata<br /> pointer are complete. For emac_rx_packet(), move the free into the<br /> requeue label so both early-exit and success paths free the descriptor<br /> after all accesses are done. For emac_rx_packet_zc(), move the free to<br /> the end of the loop body after emac_dispatch_skb_zc() (which calls<br /> emac_rx_timestamp()) has returned.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> team: fix header_ops type confusion with non-Ethernet ports<br /> <br /> Similar to commit 950803f72547 ("bonding: fix type confusion in<br /> bond_setup_by_slave()") team has the same class of header_ops type<br /> confusion.<br /> <br /> For non-Ethernet ports, team_setup_by_port() copies port_dev-&gt;header_ops<br /> directly. When the team device later calls dev_hard_header() or<br /> dev_parse_header(), these callbacks can run with the team net_device<br /> instead of the real lower device, so netdev_priv(dev) is interpreted as<br /> the wrong private type and can crash.<br /> <br /> The syzbot report shows a crash in bond_header_create(), but the root<br /> cause is in team: the topology is gre -&gt; bond -&gt; team, and team calls<br /> the inherited header_ops with its own net_device instead of the lower<br /> device, so bond_header_create() receives a team device and interprets<br /> netdev_priv() as bonding private data, causing a type confusion crash.<br /> <br /> Fix this by introducing team header_ops wrappers for create/parse,<br /> selecting a team port under RCU, and calling the lower device callbacks<br /> with port-&gt;dev, so each callback always sees the correct net_device<br /> context.<br /> <br /> Also pass the selected lower device to the lower parse callback, so<br /> recursion is bounded in stacked non-Ethernet topologies and parse<br /> callbacks always run with the correct device context.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> udp: Fix wildcard bind conflict check when using hash2<br /> <br /> When binding a udp_sock to a local address and port, UDP uses<br /> two hashes (udptable-&gt;hash and udptable-&gt;hash2) for collision<br /> detection. The current code switches to "hash2" when<br /> hslot-&gt;count &gt; 10.<br /> <br /> "hash2" is keyed by local address and local port.<br /> "hash" is keyed by local port only.<br /> <br /> The issue can be shown in the following bind sequence (pseudo code):<br /> <br /> bind(fd1, "[fd00::1]:8888")<br /> bind(fd2, "[fd00::2]:8888")<br /> bind(fd3, "[fd00::3]:8888")<br /> bind(fd4, "[fd00::4]:8888")<br /> bind(fd5, "[fd00::5]:8888")<br /> bind(fd6, "[fd00::6]:8888")<br /> bind(fd7, "[fd00::7]:8888")<br /> bind(fd8, "[fd00::8]:8888")<br /> bind(fd9, "[fd00::9]:8888")<br /> bind(fd10, "[fd00::10]:8888")<br /> <br /> /* Correctly return -EADDRINUSE because "hash" is used<br /> * instead of "hash2". udp_lib_lport_inuse() detects the<br /> * conflict.<br /> */<br /> bind(fail_fd, "[::]:8888")<br /> <br /> /* After one more socket is bound to "[fd00::11]:8888",<br /> * hslot-&gt;count exceeds 10 and "hash2" is used instead.<br /> */<br /> bind(fd11, "[fd00::11]:8888")<br /> bind(fail_fd, "[::]:8888") /* succeeds unexpectedly */<br /> <br /> The same issue applies to the IPv4 wildcard address "0.0.0.0"<br /> and the IPv4-mapped wildcard address "::ffff:0.0.0.0". For<br /> example, if there are existing sockets bound to<br /> "192.168.1.[1-11]:8888", then binding "0.0.0.0:8888" or<br /> "[::ffff:0.0.0.0]:8888" can also miss the conflict when<br /> hslot-&gt;count &gt; 10.<br /> <br /> TCP inet_csk_get_port() already has the correct check in<br /> inet_use_bhash2_on_bind(). Rename it to<br /> inet_use_hash2_on_bind() and move it to inet_hashtables.h<br /> so udp.c can reuse it in this fix.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/irdma: Initialize free_qp completion before using it<br /> <br /> In irdma_create_qp, if ib_copy_to_udata fails, it will call<br /> irdma_destroy_qp to clean up which will attempt to wait on<br /> the free_qp completion, which is not initialized yet. Fix this<br /> by initializing the completion before the ib_copy_to_udata call.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/efa: Fix use of completion ctx after free<br /> <br /> On admin queue completion handling, if the admin command completed with<br /> error we print data from the completion context. The issue is that we<br /> already freed the completion context in polling/interrupts handler which<br /> means we print data from context in an unknown state (it might be<br /> already used again).<br /> Change the admin submission flow so alloc/dealloc of the context will be<br /> symmetric and dealloc will be called after any potential use of the<br /> context.