Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bus: mhi: host: Range check CHDBOFF and ERDBOFF<br /> <br /> If the value read from the CHDBOFF and ERDBOFF registers is outside the<br /> range of the MHI register space then an invalid address might be computed<br /> which later causes a kernel panic. Range check the read value to prevent<br /> a crash due to bad data from the device.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: af_alg - Fix missing initialisation affecting gcm-aes-s390<br /> <br /> Fix af_alg_alloc_areq() to initialise areq-&gt;first_rsgl.sgl.sgt.sgl to point<br /> to the scatterlist array in areq-&gt;first_rsgl.sgl.sgl.<br /> <br /> Without this, the gcm-aes-s390 driver will oops when it tries to do<br /> gcm_walk_start() on req-&gt;dst because req-&gt;dst is set to the value of<br /> areq-&gt;first_rsgl.sgl.sgl by _aead_recvmsg() calling<br /> aead_request_set_crypt().<br /> <br /> The problem comes if an empty ciphertext is passed: the loop in<br /> af_alg_get_rsgl() just passes straight out and doesn&amp;#39;t set areq-&gt;first_rsgl<br /> up.<br /> <br /> This isn&amp;#39;t a problem on x86_64 using gcmaes_crypt_by_sg() because, as far<br /> as I can tell, that ignores req-&gt;dst and only uses req-&gt;src[*].<br /> <br /> [*] Is this a bug in aesni-intel_glue.c?<br /> <br /> The s390x oops looks something like:<br /> <br /> Unable to handle kernel pointer dereference in virtual kernel address space<br /> Failing address: 0000000a00000000 TEID: 0000000a00000803<br /> Fault in home space mode while using kernel ASCE.<br /> AS:00000000a43a0007 R3:0000000000000024<br /> Oops: 003b ilc:2 [#1] SMP<br /> ...<br /> Call Trace:<br /> [] gcm_walk_start+0x16/0x28 [aes_s390]<br /> [] crypto_aead_decrypt+0x9a/0xb8<br /> [] aead_recvmsg+0x478/0x698<br /> [] sock_recvmsg+0x70/0xb0<br /> [] sock_read_iter+0x76/0xa0<br /> [] vfs_read+0x26e/0x2a8<br /> [] ksys_read+0xbc/0x100<br /> [] __do_syscall+0x1d0/0x1f8<br /> [] system_call+0x70/0x98<br /> Last Breaking-Event-Address:<br /> [] gcm_aes_crypt+0x104/0xa68 [aes_s390]

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tunnels: fix kasan splat when generating ipv4 pmtu error<br /> <br /> If we try to emit an icmp error in response to a nonliner skb, we get<br /> <br /> BUG: KASAN: slab-out-of-bounds in ip_compute_csum+0x134/0x220<br /> Read of size 4 at addr ffff88811c50db00 by task iperf3/1691<br /> CPU: 2 PID: 1691 Comm: iperf3 Not tainted 6.5.0-rc3+ #309<br /> [..]<br /> kasan_report+0x105/0x140<br /> ip_compute_csum+0x134/0x220<br /> iptunnel_pmtud_build_icmp+0x554/0x1020<br /> skb_tunnel_check_pmtu+0x513/0xb80<br /> vxlan_xmit_one+0x139e/0x2ef0<br /> vxlan_xmit+0x1867/0x2760<br /> dev_hard_start_xmit+0x1ee/0x4f0<br /> br_dev_queue_push_xmit+0x4d1/0x660<br /> [..]<br /> <br /> ip_compute_csum() cannot deal with nonlinear skbs, so avoid it.<br /> After this change, splat is gone and iperf3 is no longer stuck.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bonding: do not assume skb mac_header is set<br /> <br /> Drivers must not assume in their ndo_start_xmit() that<br /> skbs have their mac_header set. skb-&gt;data is all what is needed.<br /> <br /> bonding seems to be one of the last offender as caught by syzbot:<br /> <br /> WARNING: CPU: 1 PID: 12155 at include/linux/skbuff.h:2907 skb_mac_offset include/linux/skbuff.h:2913 [inline]<br /> WARNING: CPU: 1 PID: 12155 at include/linux/skbuff.h:2907 bond_xmit_hash drivers/net/bonding/bond_main.c:4170 [inline]<br /> WARNING: CPU: 1 PID: 12155 at include/linux/skbuff.h:2907 bond_xmit_3ad_xor_slave_get drivers/net/bonding/bond_main.c:5149 [inline]<br /> WARNING: CPU: 1 PID: 12155 at include/linux/skbuff.h:2907 bond_3ad_xor_xmit drivers/net/bonding/bond_main.c:5186 [inline]<br /> WARNING: CPU: 1 PID: 12155 at include/linux/skbuff.h:2907 __bond_start_xmit drivers/net/bonding/bond_main.c:5442 [inline]<br /> WARNING: CPU: 1 PID: 12155 at include/linux/skbuff.h:2907 bond_start_xmit+0x14ab/0x19d0 drivers/net/bonding/bond_main.c:5470<br /> Modules linked in:<br /> CPU: 1 PID: 12155 Comm: syz-executor.3 Not tainted 6.1.30-syzkaller #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/25/2023<br /> RIP: 0010:skb_mac_header include/linux/skbuff.h:2907 [inline]<br /> RIP: 0010:skb_mac_offset include/linux/skbuff.h:2913 [inline]<br /> RIP: 0010:bond_xmit_hash drivers/net/bonding/bond_main.c:4170 [inline]<br /> RIP: 0010:bond_xmit_3ad_xor_slave_get drivers/net/bonding/bond_main.c:5149 [inline]<br /> RIP: 0010:bond_3ad_xor_xmit drivers/net/bonding/bond_main.c:5186 [inline]<br /> RIP: 0010:__bond_start_xmit drivers/net/bonding/bond_main.c:5442 [inline]<br /> RIP: 0010:bond_start_xmit+0x14ab/0x19d0 drivers/net/bonding/bond_main.c:5470<br /> Code: 8b 7c 24 30 e8 76 dd 1a 01 48 85 c0 74 0d 48 89 c3 e8 29 67 2e fe e9 15 ef ff ff e8 1f 67 2e fe e9 10 ef ff ff e8 15 67 2e fe 0b e9 45 f8 ff ff e8 09 67 2e fe e9 dc fa ff ff e8 ff 66 2e fe<br /> RSP: 0018:ffffc90002fff6e0 EFLAGS: 00010283<br /> RAX: ffffffff835874db RBX: 000000000000ffff RCX: 0000000000040000<br /> RDX: ffffc90004dcf000 RSI: 00000000000000b5 RDI: 00000000000000b6<br /> RBP: ffffc90002fff8b8 R08: ffffffff83586d16 R09: ffffffff83586584<br /> R10: 0000000000000007 R11: ffff8881599fc780 R12: ffff88811b6a7b7e<br /> R13: 1ffff110236d4f6f R14: ffff88811b6a7ac0 R15: 1ffff110236d4f76<br /> FS: 00007f2e9eb47700(0000) GS:ffff8881f6b00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000001b2e421000 CR3: 000000010e6d4000 CR4: 00000000003526e0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> [] netdev_start_xmit include/linux/netdevice.h:4925 [inline]<br /> [] __dev_direct_xmit+0x4ef/0x850 net/core/dev.c:4380<br /> [] dev_direct_xmit include/linux/netdevice.h:3043 [inline]<br /> [] packet_direct_xmit+0x18b/0x300 net/packet/af_packet.c:284<br /> [] packet_snd net/packet/af_packet.c:3112 [inline]<br /> [] packet_sendmsg+0x4a22/0x64d0 net/packet/af_packet.c:3143<br /> [] sock_sendmsg_nosec net/socket.c:716 [inline]<br /> [] sock_sendmsg net/socket.c:736 [inline]<br /> [] __sys_sendto+0x472/0x5f0 net/socket.c:2139<br /> [] __do_sys_sendto net/socket.c:2151 [inline]<br /> [] __se_sys_sendto net/socket.c:2147 [inline]<br /> [] __x64_sys_sendto+0xe5/0x100 net/socket.c:2147<br /> [] do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> [] do_syscall_64+0x2f/0x50 arch/x86/entry/common.c:80<br /> [] entry_SYSCALL_64_after_hwframe+0x63/0xcd

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: ath11k: fix memory leak in WMI firmware stats<br /> <br /> Memory allocated for firmware pdev, vdev and beacon statistics<br /> are not released during rmmod.<br /> <br /> Fix it by calling ath11k_fw_stats_free() function before hardware<br /> unregister.<br /> <br /> While at it, avoid calling ath11k_fw_stats_free() while processing<br /> the firmware stats received in the WMI event because the local list<br /> is getting spliced and reinitialised and hence there are no elements<br /> in the list after splicing.<br /> <br /> Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: qla2xxx: Avoid fcport pointer dereference<br /> <br /> Klocwork reported warning of NULL pointer may be dereferenced. The routine<br /> exits when sa_ctl is NULL and fcport is allocated after the exit call thus<br /> causing NULL fcport pointer to dereference at the time of exit.<br /> <br /> To avoid fcport pointer dereference, exit the routine when sa_ctl is NULL.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ring-buffer: Sync IRQ works before buffer destruction<br /> <br /> If something was written to the buffer just before destruction,<br /> it may be possible (maybe not in a real system, but it did<br /> happen in ARCH=um with time-travel) to destroy the ringbuffer<br /> before the IRQ work ran, leading this KASAN report (or a crash<br /> without KASAN):<br /> <br /> BUG: KASAN: slab-use-after-free in irq_work_run_list+0x11a/0x13a<br /> Read of size 8 at addr 000000006d640a48 by task swapper/0<br /> <br /> CPU: 0 PID: 0 Comm: swapper Tainted: G W O 6.3.0-rc1 #7<br /> Stack:<br /> 60c4f20f 0c203d48 41b58ab3 60f224fc<br /> 600477fa 60f35687 60c4f20f 601273dd<br /> 00000008 6101eb00 6101eab0 615be548<br /> Call Trace:<br /> [] show_stack+0x25e/0x282<br /> [] dump_stack_lvl+0x96/0xfd<br /> [] print_report+0x1a7/0x5a8<br /> [] kasan_report+0xc1/0xe9<br /> [] __asan_report_load8_noabort+0x1b/0x1d<br /> [] irq_work_run_list+0x11a/0x13a<br /> [] irq_work_tick+0x24/0x34<br /> [] update_process_times+0x162/0x196<br /> [] tick_sched_handle+0x1a4/0x1c3<br /> [] tick_sched_timer+0x79/0x10c<br /> [] __hrtimer_run_queues.constprop.0+0x425/0x695<br /> [] hrtimer_interrupt+0x16c/0x2c4<br /> [] um_timer+0x164/0x183<br /> [...]<br /> <br /> Allocated by task 411:<br /> save_stack_trace+0x99/0xb5<br /> stack_trace_save+0x81/0x9b<br /> kasan_save_stack+0x2d/0x54<br /> kasan_set_track+0x34/0x3e<br /> kasan_save_alloc_info+0x25/0x28<br /> ____kasan_kmalloc+0x8b/0x97<br /> __kasan_kmalloc+0x10/0x12<br /> __kmalloc+0xb2/0xe8<br /> load_elf_phdrs+0xee/0x182<br /> [...]<br /> <br /> The buggy address belongs to the object at 000000006d640800<br /> which belongs to the cache kmalloc-1k of size 1024<br /> The buggy address is located 584 bytes inside of<br /> freed 1024-byte region [000000006d640800, 000000006d640c00)<br /> <br /> Add the appropriate irq_work_sync() so the work finishes before<br /> the buffers are destroyed.<br /> <br /> Prior to the commit in the Fixes tag below, there was only a<br /> single global IRQ work, so this issue didn&amp;#39;t exist.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mac80211: check for station first in client probe<br /> <br /> When probing a client, first check if we have it, and then<br /> check for the channel context, otherwise you can trigger<br /> the warning there easily by probing when the AP isn&amp;#39;t even<br /> started yet. Since a client existing means the AP is also<br /> operating, we can then keep the warning.<br /> <br /> Also simplify the moved code a bit.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: iwlwifi: mvm: don&amp;#39;t trust firmware n_channels<br /> <br /> If the firmware sends us a corrupted MCC response with<br /> n_channels much larger than the command response can be,<br /> we might copy far too much (uninitialized) memory and<br /> even crash if the n_channels is large enough to make it<br /> run out of the one page allocated for the FW response.<br /> <br /> Fix that by checking the lengths. Doing a

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sctp: add a refcnt in sctp_stream_priorities to avoid a nested loop<br /> <br /> With this refcnt added in sctp_stream_priorities, we don&amp;#39;t need to<br /> traverse all streams to check if the prio is used by other streams<br /> when freeing one stream&amp;#39;s prio in sctp_sched_prio_free_sid(). This<br /> can avoid a nested loop (up to 65535 * 65535), which may cause a<br /> stuck as Ying reported:<br /> <br /> watchdog: BUG: soft lockup - CPU#23 stuck for 26s! [ksoftirqd/23:136]<br /> Call Trace:<br /> <br /> sctp_sched_prio_free_sid+0xab/0x100 [sctp]<br /> sctp_stream_free_ext+0x64/0xa0 [sctp]<br /> sctp_stream_free+0x31/0x50 [sctp]<br /> sctp_association_free+0xa5/0x200 [sctp]<br /> <br /> Note that it doesn&amp;#39;t need to use refcount_t type for this counter,<br /> as its accessing is always protected under the sock lock.<br /> <br /> v1-&gt;v2:<br /> - add a check in sctp_sched_prio_set to avoid the possible prio_head<br /> refcnt overflow.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5e: Fix deadlock in tc route query code<br /> <br /> Cited commit causes ABBA deadlock[0] when peer flows are created while<br /> holding the devcom rw semaphore. Due to peer flows offload implementation<br /> the lock is taken much higher up the call chain and there is no obvious way<br /> to easily fix the deadlock. Instead, since tc route query code needs the<br /> peer eswitch structure only to perform a lookup in xarray and doesn&amp;#39;t<br /> perform any sleeping operations with it, refactor the code for lockless<br /> execution in following ways:<br /> <br /> - RCUify the devcom &amp;#39;data&amp;#39; pointer. When resetting the pointer<br /> synchronously wait for RCU grace period before returning. This is fine<br /> since devcom is currently only used for synchronization of<br /> pairing/unpairing of eswitches which is rare and already expensive as-is.<br /> <br /> - Wrap all usages of &amp;#39;paired&amp;#39; boolean in {READ|WRITE}_ONCE(). The flag has<br /> already been used in some unlocked contexts without proper<br /> annotations (e.g. users of mlx5_devcom_is_paired() function), but it wasn&amp;#39;t<br /> an issue since all relevant code paths checked it again after obtaining the<br /> devcom semaphore. Now it is also used by mlx5_devcom_get_peer_data_rcu() as<br /> "best effort" check to return NULL when devcom is being unpaired. Note that<br /> while RCU read lock doesn&amp;#39;t prevent the unpaired flag from being changed<br /> concurrently it still guarantees that reader can continue to use &amp;#39;data&amp;#39;.<br /> <br /> - Refactor mlx5e_tc_query_route_vport() function to use new<br /> mlx5_devcom_get_peer_data_rcu() API which fixes the deadlock.<br /> <br /> [0]:<br /> <br /> [ 164.599612] ======================================================<br /> [ 164.600142] WARNING: possible circular locking dependency detected<br /> [ 164.600667] 6.3.0-rc3+ #1 Not tainted<br /> [ 164.601021] ------------------------------------------------------<br /> [ 164.601557] handler1/3456 is trying to acquire lock:<br /> [ 164.601998] ffff88811f1714b0 (&amp;esw-&gt;offloads.encap_tbl_lock){+.+.}-{3:3}, at: mlx5e_attach_encap+0xd8/0x8b0 [mlx5_core]<br /> [ 164.603078]<br /> but task is already holding lock:<br /> [ 164.603617] ffff88810137fc98 (&amp;comp-&gt;sem){++++}-{3:3}, at: mlx5_devcom_get_peer_data+0x37/0x80 [mlx5_core]<br /> [ 164.604459]<br /> which lock already depends on the new lock.<br /> <br /> [ 164.605190]<br /> the existing dependency chain (in reverse order) is:<br /> [ 164.605848]<br /> -&gt; #1 (&amp;comp-&gt;sem){++++}-{3:3}:<br /> [ 164.606380] down_read+0x39/0x50<br /> [ 164.606772] mlx5_devcom_get_peer_data+0x37/0x80 [mlx5_core]<br /> [ 164.607336] mlx5e_tc_query_route_vport+0x86/0xc0 [mlx5_core]<br /> [ 164.607914] mlx5e_tc_tun_route_lookup+0x1a4/0x1d0 [mlx5_core]<br /> [ 164.608495] mlx5e_attach_decap_route+0xc6/0x1e0 [mlx5_core]<br /> [ 164.609063] mlx5e_tc_add_fdb_flow+0x1ea/0x360 [mlx5_core]<br /> [ 164.609627] __mlx5e_add_fdb_flow+0x2d2/0x430 [mlx5_core]<br /> [ 164.610175] mlx5e_configure_flower+0x952/0x1a20 [mlx5_core]<br /> [ 164.610741] tc_setup_cb_add+0xd4/0x200<br /> [ 164.611146] fl_hw_replace_filter+0x14c/0x1f0 [cls_flower]<br /> [ 164.611661] fl_change+0xc95/0x18a0 [cls_flower]<br /> [ 164.612116] tc_new_tfilter+0x3fc/0xd20<br /> [ 164.612516] rtnetlink_rcv_msg+0x418/0x5b0<br /> [ 164.612936] netlink_rcv_skb+0x54/0x100<br /> [ 164.613339] netlink_unicast+0x190/0x250<br /> [ 164.613746] netlink_sendmsg+0x245/0x4a0<br /> [ 164.614150] sock_sendmsg+0x38/0x60<br /> [ 164.614522] ____sys_sendmsg+0x1d0/0x1e0<br /> [ 164.614934] ___sys_sendmsg+0x80/0xc0<br /> [ 164.615320] __sys_sendmsg+0x51/0x90<br /> [ 164.615701] do_syscall_64+0x3d/0x90<br /> [ 164.616083] entry_SYSCALL_64_after_hwframe+0x46/0xb0<br /> [ 164.616568]<br /> -&gt; #0 (&amp;esw-&gt;offloads.encap_tbl_lock){+.+.}-{3:3}:<br /> [ 164.617210] __lock_acquire+0x159e/0x26e0<br /> [ 164.617638] lock_acquire+0xc2/0x2a0<br /> [ 164.618018] __mutex_lock+0x92/0xcd0<br /> [ 164.618401] mlx5e_attach_encap+0xd8/0x8b0 [mlx5_core]<br /> [ 164.618943] post_process_attr+0x153/0x2d0 [<br /> ---truncated---

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> gpio: sifive: Fix refcount leak in sifive_gpio_probe<br /> <br /> of_irq_find_parent() returns a node pointer with refcount incremented,<br /> We should use of_node_put() on it when not needed anymore.<br /> Add missing of_node_put() to avoid refcount leak.