Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/tcp: Fix socket memory leak in TCP-AO failure handling for IPv6<br /> <br /> When tcp_ao_copy_all_matching() fails in tcp_v6_syn_recv_sock() it just<br /> exits the function. This ends up causing a memory-leak:<br /> <br /> unreferenced object 0xffff0000281a8200 (size 2496):<br /> comm "softirq", pid 0, jiffies 4295174684<br /> hex dump (first 32 bytes):<br /> 7f 00 00 06 7f 00 00 06 00 00 00 00 cb a8 88 13 ................<br /> 0a 00 03 61 00 00 00 00 00 00 00 00 00 00 00 00 ...a............<br /> backtrace (crc 5ebdbe15):<br /> kmemleak_alloc+0x44/0xe0<br /> kmem_cache_alloc_noprof+0x248/0x470<br /> sk_prot_alloc+0x48/0x120<br /> sk_clone_lock+0x38/0x3b0<br /> inet_csk_clone_lock+0x34/0x150<br /> tcp_create_openreq_child+0x3c/0x4a8<br /> tcp_v6_syn_recv_sock+0x1c0/0x620<br /> tcp_check_req+0x588/0x790<br /> tcp_v6_rcv+0x5d0/0xc18<br /> ip6_protocol_deliver_rcu+0x2d8/0x4c0<br /> ip6_input_finish+0x74/0x148<br /> ip6_input+0x50/0x118<br /> ip6_sublist_rcv+0x2fc/0x3b0<br /> ipv6_list_rcv+0x114/0x170<br /> __netif_receive_skb_list_core+0x16c/0x200<br /> netif_receive_skb_list_internal+0x1f0/0x2d0<br /> <br /> This is because in tcp_v6_syn_recv_sock (and the IPv4 counterpart), when<br /> exiting upon error, inet_csk_prepare_forced_close() and tcp_done() need<br /> to be called. They make sure the newsk will end up being correctly<br /> free&amp;#39;d.<br /> <br /> tcp_v4_syn_recv_sock() makes this very clear by having the put_and_exit<br /> label that takes care of things. So, this patch here makes sure<br /> tcp_v4_syn_recv_sock and tcp_v6_syn_recv_sock have similar<br /> error-handling and thus fixes the leak for TCP-AO.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ice: fix NULL access of tx-&gt;in_use in ice_ll_ts_intr<br /> <br /> Recent versions of the E810 firmware have support for an extra interrupt to<br /> handle report of the "low latency" Tx timestamps coming from the<br /> specialized low latency firmware interface. Instead of polling the<br /> registers, software can wait until the low latency interrupt is fired.<br /> <br /> This logic makes use of the Tx timestamp tracking structure, ice_ptp_tx, as<br /> it uses the same "ready" bitmap to track which Tx timestamps complete.<br /> <br /> Unfortunately, the ice_ll_ts_intr() function does not check if the<br /> tracker is initialized before its first access. This results in NULL<br /> dereference or use-after-free bugs similar to the issues fixed in the<br /> ice_ptp_ts_irq() function.<br /> <br /> Fix this by only checking the in_use bitmap (and other fields) if the<br /> tracker is marked as initialized. The reset flow will clear the init field<br /> under lock before it tears the tracker down, thus preventing any<br /> use-after-free or NULL access.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ice: fix NULL access of tx-&gt;in_use in ice_ptp_ts_irq<br /> <br /> The E810 device has support for a "low latency" firmware interface to<br /> access and read the Tx timestamps. This interface does not use the standard<br /> Tx timestamp logic, due to the latency overhead of proxying sideband<br /> command requests over the firmware AdminQ.<br /> <br /> The logic still makes use of the Tx timestamp tracking structure,<br /> ice_ptp_tx, as it uses the same "ready" bitmap to track which Tx<br /> timestamps complete.<br /> <br /> Unfortunately, the ice_ptp_ts_irq() function does not check if the tracker<br /> is initialized before its first access. This results in NULL dereference or<br /> use-after-free bugs similar to the following:<br /> <br /> [245977.278756] BUG: kernel NULL pointer dereference, address: 0000000000000000<br /> [245977.278774] RIP: 0010:_find_first_bit+0x19/0x40<br /> [245977.278796] Call Trace:<br /> [245977.278809] ? ice_misc_intr+0x364/0x380 [ice]<br /> <br /> This can occur if a Tx timestamp interrupt races with the driver reset<br /> logic.<br /> <br /> Fix this by only checking the in_use bitmap (and other fields) if the<br /> tracker is marked as initialized. The reset flow will clear the init field<br /> under lock before it tears the tracker down, thus preventing any<br /> use-after-free or NULL access.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: ethernet: ti: am65-cpsw-nuss: Fix null pointer dereference for ndev<br /> <br /> In the TX completion packet stage of TI SoCs with CPSW2G instance, which<br /> has single external ethernet port, ndev is accessed without being<br /> initialized if no TX packets have been processed. It results into null<br /> pointer dereference, causing kernel to crash. Fix this by having a check<br /> on the number of TX packets which have been processed.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> eth: mlx4: Fix IS_ERR() vs NULL check bug in mlx4_en_create_rx_ring<br /> <br /> Replace NULL check with IS_ERR() check after calling page_pool_create()<br /> since this function returns error pointers (ERR_PTR).<br /> Using NULL check could lead to invalid pointer dereference.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ptp: ocp: fix use-after-free bugs causing by ptp_ocp_watchdog<br /> <br /> The ptp_ocp_detach() only shuts down the watchdog timer if it is<br /> pending. However, if the timer handler is already running, the<br /> timer_delete_sync() is not called. This leads to race conditions<br /> where the devlink that contains the ptp_ocp is deallocated while<br /> the timer handler is still accessing it, resulting in use-after-free<br /> bugs. The following details one of the race scenarios.<br /> <br /> (thread 1) | (thread 2)<br /> ptp_ocp_remove() |<br /> ptp_ocp_detach() | ptp_ocp_watchdog()<br /> if (timer_pending(&amp;bp-&gt;watchdog))| bp = timer_container_of()<br /> timer_delete_sync() |<br /> |<br /> devlink_free(devlink) //free |<br /> | bp-&gt; //use<br /> <br /> Resolve this by unconditionally calling timer_delete_sync() to ensure<br /> the timer is reliably deactivated, preventing any access after free.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: Fix use-after-free in l2cap_sock_cleanup_listen()<br /> <br /> syzbot reported the splat below without a repro.<br /> <br /> In the splat, a single thread calling bt_accept_dequeue() freed sk<br /> and touched it after that.<br /> <br /> The root cause would be the racy l2cap_sock_cleanup_listen() call<br /> added by the cited commit.<br /> <br /> bt_accept_dequeue() is called under lock_sock() except for<br /> l2cap_sock_release().<br /> <br /> Two threads could see the same socket during the list iteration<br /> in bt_accept_dequeue():<br /> <br /> CPU1 CPU2 (close())<br /> ---- ----<br /> sock_hold(sk) sock_hold(sk);<br /> lock_sock(sk)

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/smc: fix one NULL pointer dereference in smc_ib_is_sg_need_sync()<br /> <br /> BUG: kernel NULL pointer dereference, address: 00000000000002ec<br /> PGD 0 P4D 0<br /> Oops: Oops: 0000 [#1] SMP PTI<br /> CPU: 28 UID: 0 PID: 343 Comm: kworker/28:1 Kdump: loaded Tainted: G OE 6.17.0-rc2+ #9 NONE<br /> Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014<br /> Workqueue: smc_hs_wq smc_listen_work [smc]<br /> RIP: 0010:smc_ib_is_sg_need_sync+0x9e/0xd0 [smc]<br /> ...<br /> Call Trace:<br /> <br /> smcr_buf_map_link+0x211/0x2a0 [smc]<br /> __smc_buf_create+0x522/0x970 [smc]<br /> smc_buf_create+0x3a/0x110 [smc]<br /> smc_find_rdma_v2_device_serv+0x18f/0x240 [smc]<br /> ? smc_vlan_by_tcpsk+0x7e/0xe0 [smc]<br /> smc_listen_find_device+0x1dd/0x2b0 [smc]<br /> smc_listen_work+0x30f/0x580 [smc]<br /> process_one_work+0x18c/0x340<br /> worker_thread+0x242/0x360<br /> kthread+0xe7/0x220<br /> ret_from_fork+0x13a/0x160<br /> ret_from_fork_asm+0x1a/0x30<br /> <br /> <br /> If the software RoCE device is used, ibdev-&gt;dma_device is a null pointer.<br /> As a result, the problem occurs. Null pointer detection is added to<br /> prevent problems.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> i40e: Fix potential invalid access when MAC list is empty<br /> <br /> list_first_entry() never returns NULL - if the list is empty, it still<br /> returns a pointer to an invalid object, leading to potential invalid<br /> memory access when dereferenced.<br /> <br /> Fix this by using list_first_entry_or_null instead of list_first_entry.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vxlan: Fix NPD in {arp,neigh}_reduce() when using nexthop objects<br /> <br /> When the "proxy" option is enabled on a VXLAN device, the device will<br /> suppress ARP requests and IPv6 Neighbor Solicitation messages if it is<br /> able to reply on behalf of the remote host. That is, if a matching and<br /> valid neighbor entry is configured on the VXLAN device whose MAC address<br /> is not behind the "any" remote (0.0.0.0 / ::).<br /> <br /> The code currently assumes that the FDB entry for the neighbor&amp;#39;s MAC<br /> address points to a valid remote destination, but this is incorrect if<br /> the entry is associated with an FDB nexthop group. This can result in a<br /> NPD [1][3] which can be reproduced using [2][4].<br /> <br /> Fix by checking that the remote destination exists before dereferencing<br /> it.<br /> <br /> [1]<br /> BUG: kernel NULL pointer dereference, address: 0000000000000000<br /> [...]<br /> CPU: 4 UID: 0 PID: 365 Comm: arping Not tainted 6.17.0-rc2-virtme-g2a89cb21162c #2 PREEMPT(voluntary)<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-4.fc41 04/01/2014<br /> RIP: 0010:vxlan_xmit+0xb58/0x15f0<br /> [...]<br /> Call Trace:<br /> <br /> dev_hard_start_xmit+0x5d/0x1c0<br /> __dev_queue_xmit+0x246/0xfd0<br /> packet_sendmsg+0x113a/0x1850<br /> __sock_sendmsg+0x38/0x70<br /> __sys_sendto+0x126/0x180<br /> __x64_sys_sendto+0x24/0x30<br /> do_syscall_64+0xa4/0x260<br /> entry_SYSCALL_64_after_hwframe+0x4b/0x53<br /> <br /> [2]<br /> #!/bin/bash<br /> <br /> ip address add 192.0.2.1/32 dev lo<br /> <br /> ip nexthop add id 1 via 192.0.2.2 fdb<br /> ip nexthop add id 10 group 1 fdb<br /> <br /> ip link add name vx0 up type vxlan id 10010 local 192.0.2.1 dstport 4789 proxy<br /> <br /> ip neigh add 192.0.2.3 lladdr 00:11:22:33:44:55 nud perm dev vx0<br /> <br /> bridge fdb add 00:11:22:33:44:55 dev vx0 self static nhid 10<br /> <br /> arping -b -c 1 -s 192.0.2.1 -I vx0 192.0.2.3<br /> <br /> [3]<br /> BUG: kernel NULL pointer dereference, address: 0000000000000000<br /> [...]<br /> CPU: 13 UID: 0 PID: 372 Comm: ndisc6 Not tainted 6.17.0-rc2-virtmne-g6ee90cb26014 #3 PREEMPT(voluntary)<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1v996), BIOS 1.17.0-4.fc41 04/01/2x014<br /> RIP: 0010:vxlan_xmit+0x803/0x1600<br /> [...]<br /> Call Trace:<br /> <br /> dev_hard_start_xmit+0x5d/0x1c0<br /> __dev_queue_xmit+0x246/0xfd0<br /> ip6_finish_output2+0x210/0x6c0<br /> ip6_finish_output+0x1af/0x2b0<br /> ip6_mr_output+0x92/0x3e0<br /> ip6_send_skb+0x30/0x90<br /> rawv6_sendmsg+0xe6e/0x12e0<br /> __sock_sendmsg+0x38/0x70<br /> __sys_sendto+0x126/0x180<br /> __x64_sys_sendto+0x24/0x30<br /> do_syscall_64+0xa4/0x260<br /> entry_SYSCALL_64_after_hwframe+0x4b/0x53<br /> RIP: 0033:0x7f383422ec77<br /> <br /> [4]<br /> #!/bin/bash<br /> <br /> ip address add 2001:db8:1::1/128 dev lo<br /> <br /> ip nexthop add id 1 via 2001:db8:1::1 fdb<br /> ip nexthop add id 10 group 1 fdb<br /> <br /> ip link add name vx0 up type vxlan id 10010 local 2001:db8:1::1 dstport 4789 proxy<br /> <br /> ip neigh add 2001:db8:1::3 lladdr 00:11:22:33:44:55 nud perm dev vx0<br /> <br /> bridge fdb add 00:11:22:33:44:55 dev vx0 self static nhid 10<br /> <br /> ndisc6 -r 1 -s 2001:db8:1::1 -w 1 2001:db8:1::3 vx0

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vxlan: Fix NPD when refreshing an FDB entry with a nexthop object<br /> <br /> VXLAN FDB entries can point to either a remote destination or an FDB<br /> nexthop group. The latter is usually used in EVPN deployments where<br /> learning is disabled.<br /> <br /> However, when learning is enabled, an incoming packet might try to<br /> refresh an FDB entry that points to an FDB nexthop group and therefore<br /> does not have a remote. Such packets should be dropped, but they are<br /> only dropped after dereferencing the non-existent remote, resulting in a<br /> NPD [1] which can be reproduced using [2].<br /> <br /> Fix by dropping such packets earlier. Remove the misleading comment from<br /> first_remote_rcu().<br /> <br /> [1]<br /> BUG: kernel NULL pointer dereference, address: 0000000000000000<br /> [...]<br /> CPU: 13 UID: 0 PID: 361 Comm: mausezahn Not tainted 6.17.0-rc1-virtme-g9f6b606b6b37 #1 PREEMPT(voluntary)<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-4.fc41 04/01/2014<br /> RIP: 0010:vxlan_snoop+0x98/0x1e0<br /> [...]<br /> Call Trace:<br /> <br /> vxlan_encap_bypass+0x209/0x240<br /> encap_bypass_if_local+0xb1/0x100<br /> vxlan_xmit_one+0x1375/0x17e0<br /> vxlan_xmit+0x6b4/0x15f0<br /> dev_hard_start_xmit+0x5d/0x1c0<br /> __dev_queue_xmit+0x246/0xfd0<br /> packet_sendmsg+0x113a/0x1850<br /> __sock_sendmsg+0x38/0x70<br /> __sys_sendto+0x126/0x180<br /> __x64_sys_sendto+0x24/0x30<br /> do_syscall_64+0xa4/0x260<br /> entry_SYSCALL_64_after_hwframe+0x4b/0x53<br /> <br /> [2]<br /> #!/bin/bash<br /> <br /> ip address add 192.0.2.1/32 dev lo<br /> ip address add 192.0.2.2/32 dev lo<br /> <br /> ip nexthop add id 1 via 192.0.2.3 fdb<br /> ip nexthop add id 10 group 1 fdb<br /> <br /> ip link add name vx0 up type vxlan id 10010 local 192.0.2.1 dstport 12345 localbypass<br /> ip link add name vx1 up type vxlan id 10020 local 192.0.2.2 dstport 54321 learning<br /> <br /> bridge fdb add 00:11:22:33:44:55 dev vx0 self static dst 192.0.2.2 port 54321 vni 10020<br /> bridge fdb add 00:aa:bb:cc:dd:ee dev vx1 self static nhid 10<br /> <br /> mausezahn vx0 -a 00:aa:bb:cc:dd:ee -b 00:11:22:33:44:55 -c 1 -q

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> pcmcia: Fix a NULL pointer dereference in __iodyn_find_io_region()<br /> <br /> In __iodyn_find_io_region(), pcmcia_make_resource() is assigned to<br /> res and used in pci_bus_alloc_resource(). There is a dereference of res<br /> in pci_bus_alloc_resource(), which could lead to a NULL pointer<br /> dereference on failure of pcmcia_make_resource().<br /> <br /> Fix this bug by adding a check of res.