Vulnerabilidades

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

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: macb: use the current queue number for stats<br /> <br /> There&amp;#39;s a potential mismatch between the memory reserved for statistics<br /> and the amount of memory written.<br /> <br /> gem_get_sset_count() correctly computes the number of stats based on the<br /> active queues, whereas gem_get_ethtool_stats() indiscriminately copies<br /> data using the maximum number of queues, and in the case the number of<br /> active queues is less than MACB_MAX_QUEUES, this results in a OOB write<br /> as observed in the KASAN splat.<br /> <br /> ==================================================================<br /> BUG: KASAN: vmalloc-out-of-bounds in gem_get_ethtool_stats+0x54/0x78<br /> [macb]<br /> Write of size 760 at addr ffff80008080b000 by task ethtool/1027<br /> <br /> CPU: [...]<br /> Tainted: [E]=UNSIGNED_MODULE<br /> Hardware name: raspberrypi rpi/rpi, BIOS 2025.10 10/01/2025<br /> Call trace:<br /> show_stack+0x20/0x38 (C)<br /> dump_stack_lvl+0x80/0xf8<br /> print_report+0x384/0x5e0<br /> kasan_report+0xa0/0xf0<br /> kasan_check_range+0xe8/0x190<br /> __asan_memcpy+0x54/0x98<br /> gem_get_ethtool_stats+0x54/0x78 [macb<br /> 926c13f3af83b0c6fe64badb21ec87d5e93fcf65]<br /> dev_ethtool+0x1220/0x38c0<br /> dev_ioctl+0x4ac/0xca8<br /> sock_do_ioctl+0x170/0x1d8<br /> sock_ioctl+0x484/0x5d8<br /> __arm64_sys_ioctl+0x12c/0x1b8<br /> invoke_syscall+0xd4/0x258<br /> el0_svc_common.constprop.0+0xb4/0x240<br /> do_el0_svc+0x48/0x68<br /> el0_svc+0x40/0xf8<br /> el0t_64_sync_handler+0xa0/0xe8<br /> el0t_64_sync+0x1b0/0x1b8<br /> <br /> The buggy address belongs to a 1-page vmalloc region starting at<br /> 0xffff80008080b000 allocated at dev_ethtool+0x11f0/0x38c0<br /> The buggy address belongs to the physical page:<br /> page: refcount:1 mapcount:0 mapping:0000000000000000<br /> index:0xffff00000a333000 pfn:0xa333<br /> flags: 0x7fffc000000000(node=0|zone=0|lastcpupid=0x1ffff)<br /> raw: 007fffc000000000 0000000000000000 dead000000000122 0000000000000000<br /> raw: ffff00000a333000 0000000000000000 00000001ffffffff 0000000000000000<br /> page dumped because: kasan: bad access detected<br /> <br /> Memory state around the buggy address:<br /> ffff80008080b080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00<br /> ffff80008080b100: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00<br /> &gt;ffff80008080b180: 00 00 00 00 00 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8<br /> ^<br /> ffff80008080b200: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8<br /> ffff80008080b280: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8<br /> ==================================================================<br /> <br /> Fix it by making sure the copied size only considers the active number of<br /> queues.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: ctnetlink: use netlink policy range checks<br /> <br /> Replace manual range and mask validations with netlink policy<br /> annotations in ctnetlink code paths, so that the netlink core rejects<br /> invalid values early and can generate extack errors.<br /> <br /> - CTA_PROTOINFO_TCP_STATE: reject values &gt; TCP_CONNTRACK_SYN_SENT2 at<br /> policy level, removing the manual &gt;= TCP_CONNTRACK_MAX check.<br /> - CTA_PROTOINFO_TCP_WSCALE_ORIGINAL/REPLY: reject values &gt; TCP_MAX_WSCALE<br /> (14). The normal TCP option parsing path already clamps to this value,<br /> but the ctnetlink path accepted 0-255, causing undefined behavior when<br /> used as a u32 shift count.<br /> - CTA_FILTER_ORIG_FLAGS/REPLY_FLAGS: use NLA_POLICY_MASK with<br /> CTA_FILTER_F_ALL, removing the manual mask checks.<br /> - CTA_EXPECT_FLAGS: use NLA_POLICY_MASK with NF_CT_EXPECT_MASK, adding<br /> a new mask define grouping all valid expect flags.<br /> <br /> Extracted from a broader nf-next patch by Florian Westphal, scoped to<br /> ctnetlink for the fixes tree.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nf_conntrack_expect: skip expectations in other netns via proc<br /> <br /> Skip expectations that do not reside in this netns.<br /> <br /> Similar to e77e6ff502ea ("netfilter: conntrack: do not dump other netns&amp;#39;s<br /> conntrack entries via proc").