Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/mlx5: Fix mlx5_ib_get_hw_stats when used for device<br /> <br /> Currently, when mlx5_ib_get_hw_stats() is used for device (port_num = 0),<br /> there is a special handling in order to use the correct counters, but,<br /> port_num is being passed down the stack without any change. Also, some<br /> functions assume that port_num &gt;=1. As a result, the following oops can<br /> occur.<br /> <br /> BUG: unable to handle page fault for address: ffff89510294f1a8<br /> #PF: supervisor write access in kernel mode<br /> #PF: error_code(0x0002) - not-present page<br /> PGD 0 P4D 0<br /> Oops: 0002 [#1] SMP<br /> CPU: 8 PID: 1382 Comm: devlink Tainted: G W 6.1.0-rc4_for_upstream_base_2022_11_10_16_12 #1<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014<br /> RIP: 0010:_raw_spin_lock+0xc/0x20<br /> Call Trace:<br /> <br /> mlx5_ib_get_native_port_mdev+0x73/0xe0 [mlx5_ib]<br /> do_get_hw_stats.constprop.0+0x109/0x160 [mlx5_ib]<br /> mlx5_ib_get_hw_stats+0xad/0x180 [mlx5_ib]<br /> ib_setup_device_attrs+0xf0/0x290 [ib_core]<br /> ib_register_device+0x3bb/0x510 [ib_core]<br /> ? atomic_notifier_chain_register+0x67/0x80<br /> __mlx5_ib_add+0x2b/0x80 [mlx5_ib]<br /> mlx5r_probe+0xb8/0x150 [mlx5_ib]<br /> ? auxiliary_match_id+0x6a/0x90<br /> auxiliary_bus_probe+0x3c/0x70<br /> ? driver_sysfs_add+0x6b/0x90<br /> really_probe+0xcd/0x380<br /> __driver_probe_device+0x80/0x170<br /> driver_probe_device+0x1e/0x90<br /> __device_attach_driver+0x7d/0x100<br /> ? driver_allows_async_probing+0x60/0x60<br /> ? driver_allows_async_probing+0x60/0x60<br /> bus_for_each_drv+0x7b/0xc0<br /> __device_attach+0xbc/0x200<br /> bus_probe_device+0x87/0xa0<br /> device_add+0x404/0x940<br /> ? dev_set_name+0x53/0x70<br /> __auxiliary_device_add+0x43/0x60<br /> add_adev+0x99/0xe0 [mlx5_core]<br /> mlx5_attach_device+0xc8/0x120 [mlx5_core]<br /> mlx5_load_one_devl_locked+0xb2/0xe0 [mlx5_core]<br /> devlink_reload+0x133/0x250<br /> devlink_nl_cmd_reload+0x480/0x570<br /> ? devlink_nl_pre_doit+0x44/0x2b0<br /> genl_family_rcv_msg_doit.isra.0+0xc2/0x110<br /> genl_rcv_msg+0x180/0x2b0<br /> ? devlink_nl_cmd_region_read_dumpit+0x540/0x540<br /> ? devlink_reload+0x250/0x250<br /> ? devlink_put+0x50/0x50<br /> ? genl_family_rcv_msg_doit.isra.0+0x110/0x110<br /> netlink_rcv_skb+0x54/0x100<br /> genl_rcv+0x24/0x40<br /> netlink_unicast+0x1f6/0x2c0<br /> netlink_sendmsg+0x237/0x490<br /> sock_sendmsg+0x33/0x40<br /> __sys_sendto+0x103/0x160<br /> ? handle_mm_fault+0x10e/0x290<br /> ? do_user_addr_fault+0x1c0/0x5f0<br /> __x64_sys_sendto+0x25/0x30<br /> do_syscall_64+0x3d/0x90<br /> entry_SYSCALL_64_after_hwframe+0x46/0xb0<br /> <br /> Fix it by setting port_num to 1 in order to get device status and remove<br /> unused variable.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5e: xsk: Fix crash on regular rq reactivation<br /> <br /> When the regular rq is reactivated after the XSK socket is closed<br /> it could be reading stale cqes which eventually corrupts the rq.<br /> This leads to no more traffic being received on the regular rq and a<br /> crash on the next close or deactivation of the rq.<br /> <br /> Kal Cuttler Conely reported this issue as a crash on the release<br /> path when the xdpsock sample program is stopped (killed) and restarted<br /> in sequence while traffic is running.<br /> <br /> This patch flushes all cqes when during the rq flush. The cqe flushing<br /> is done in the reset state of the rq. mlx5e_rq_to_ready code is moved<br /> into the flush function to allow for this.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ACPICA: Add AML_NO_OPERAND_RESOLVE flag to Timer<br /> <br /> ACPICA commit 90310989a0790032f5a0140741ff09b545af4bc5<br /> <br /> According to the ACPI specification 19.6.134, no argument is required to be passed for ASL Timer instruction. For taking care of no argument, AML_NO_OPERAND_RESOLVE flag is added to ASL Timer instruction opcode.<br /> <br /> When ASL timer instruction interpreted by ACPI interpreter, getting error. After adding AML_NO_OPERAND_RESOLVE flag to ASL Timer instruction opcode, issue is not observed.<br /> <br /> =============================================================<br /> UBSAN: array-index-out-of-bounds in acpica/dswexec.c:401:12 index -1 is out of range for type &amp;#39;union acpi_operand_object *[9]&amp;#39;<br /> CPU: 37 PID: 1678 Comm: cat Not tainted<br /> 6.0.0-dev-th500-6.0.y-1+bcf8c46459e407-generic-64k<br /> HW name: NVIDIA BIOS v1.1.1-d7acbfc-dirty 12/19/2022 Call trace:<br /> dump_backtrace+0xe0/0x130<br /> show_stack+0x20/0x60<br /> dump_stack_lvl+0x68/0x84<br /> dump_stack+0x18/0x34<br /> ubsan_epilogue+0x10/0x50<br /> __ubsan_handle_out_of_bounds+0x80/0x90<br /> acpi_ds_exec_end_op+0x1bc/0x6d8<br /> acpi_ps_parse_loop+0x57c/0x618<br /> acpi_ps_parse_aml+0x1e0/0x4b4<br /> acpi_ps_execute_method+0x24c/0x2b8<br /> acpi_ns_evaluate+0x3a8/0x4bc<br /> acpi_evaluate_object+0x15c/0x37c<br /> acpi_evaluate_integer+0x54/0x15c<br /> show_power+0x8c/0x12c [acpi_power_meter]

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/mediatek: Clean dangling pointer on bind error path<br /> <br /> mtk_drm_bind() can fail, in which case drm_dev_put() is called,<br /> destroying the drm_device object. However a pointer to it was still<br /> being held in the private object, and that pointer would be passed along<br /> to DRM in mtk_drm_sys_prepare() if a suspend were triggered at that<br /> point, resulting in a panic. Clean the pointer when destroying the<br /> object in the error path to prevent this from happening.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: ufs: core: Fix device management cmd timeout flow<br /> <br /> In the UFS error handling flow, the host will send a device management cmd<br /> (NOP OUT) to the device for link recovery. If this cmd times out and<br /> clearing the doorbell fails, ufshcd_wait_for_dev_cmd() will do nothing and<br /> return. hba-&gt;dev_cmd.complete struct is not set to NULL.<br /> <br /> When this happens, if cmd has been completed by device, then we will call<br /> complete() in __ufshcd_transfer_req_compl(). Because the complete struct is<br /> allocated on the stack, the following crash will occur:<br /> <br /> ipanic_die+0x24/0x38 [mrdump]<br /> die+0x344/0x748<br /> arm64_notify_die+0x44/0x104<br /> do_debug_exception+0x104/0x1e0<br /> el1_dbg+0x38/0x54<br /> el1_sync_handler+0x40/0x88<br /> el1_sync+0x8c/0x140<br /> queued_spin_lock_slowpath+0x2e4/0x3c0<br /> __ufshcd_transfer_req_compl+0x3b0/0x1164<br /> ufshcd_trc_handler+0x15c/0x308<br /> ufshcd_host_reset_and_restore+0x54/0x260<br /> ufshcd_reset_and_restore+0x28c/0x57c<br /> ufshcd_err_handler+0xeb8/0x1b6c<br /> process_one_work+0x288/0x964<br /> worker_thread+0x4bc/0xc7c<br /> kthread+0x15c/0x264<br /> ret_from_fork+0x10/0x30

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: Fix potential use-after-free when clear keys<br /> <br /> Similar to commit c5d2b6fa26b5 ("Bluetooth: Fix use-after-free in<br /> hci_remove_ltk/hci_remove_irk"). We can not access k after kfree_rcu()<br /> call.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: mdp3: Fix resource leaks in of_find_device_by_node<br /> <br /> Use put_device to release the object get through of_find_device_by_node,<br /> avoiding resource leaks.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mwifiex: avoid possible NULL skb pointer dereference<br /> <br /> In &amp;#39;mwifiex_handle_uap_rx_forward()&amp;#39;, always check the value<br /> returned by &amp;#39;skb_copy()&amp;#39; to avoid potential NULL pointer<br /> dereference in &amp;#39;mwifiex_uap_queue_bridged_pkt()&amp;#39;, and drop<br /> original skb in case of copying failure.<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with SVACE.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> irqchip/gicv3: Workaround for NVIDIA erratum T241-FABRIC-4<br /> <br /> The T241 platform suffers from the T241-FABRIC-4 erratum which causes<br /> unexpected behavior in the GIC when multiple transactions are received<br /> simultaneously from different sources. This hardware issue impacts<br /> NVIDIA server platforms that use more than two T241 chips<br /> interconnected. Each chip has support for 320 {E}SPIs.<br /> <br /> This issue occurs when multiple packets from different GICs are<br /> incorrectly interleaved at the target chip. The erratum text below<br /> specifies exactly what can cause multiple transfer packets susceptible<br /> to interleaving and GIC state corruption. GIC state corruption can<br /> lead to a range of problems, including kernel panics, and unexpected<br /> behavior.<br /> <br /> &gt;From the erratum text:<br /> "In some cases, inter-socket AXI4 Stream packets with multiple<br /> transfers, may be interleaved by the fabric when presented to ARM<br /> Generic Interrupt Controller. GIC expects all transfers of a packet<br /> to be delivered without any interleaving.<br /> <br /> The following GICv3 commands may result in multiple transfer packets<br /> over inter-socket AXI4 Stream interface:<br /> - Register reads from GICD_I* and GICD_N*<br /> - Register writes to 64-bit GICD registers other than GICD_IROUTERn*<br /> - ITS command MOVALL<br /> <br /> Multiple commands in GICv4+ utilize multiple transfer packets,<br /> including VMOVP, VMOVI, VMAPP, and 64-bit register accesses."<br /> <br /> This issue impacts system configurations with more than 2 sockets,<br /> that require multi-transfer packets to be sent over inter-socket<br /> AXI4 Stream interface between GIC instances on different sockets.<br /> GICv4 cannot be supported. GICv3 SW model can only be supported<br /> with the workaround. Single and Dual socket configurations are not<br /> impacted by this issue and support GICv3 and GICv4."<br /> <br /> <br /> Writing to the chip alias region of the GICD_In{E} registers except<br /> GICD_ICENABLERn has an equivalent effect as writing to the global<br /> distributor. The SPI interrupt deactivate path is not impacted by<br /> the erratum.<br /> <br /> To fix this problem, implement a workaround that ensures read accesses<br /> to the GICD_In{E} registers are directed to the chip that owns the<br /> SPI, and disable GICv4.x features. To simplify code changes, the<br /> gic_configure_irq() function uses the same alias region for both read<br /> and write operations to GICD_ICFGR.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/smc: Reset connection when trying to use SMCRv2 fails.<br /> <br /> We found a crash when using SMCRv2 with 2 Mellanox ConnectX-4. It<br /> can be reproduced by:<br /> <br /> - smc_run nginx<br /> - smc_run wrk -t 32 -c 500 -d 30 http://:<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000014<br /> #PF: supervisor read access in kernel mode<br /> #PF: error_code(0x0000) - not-present page<br /> PGD 8000000108713067 P4D 8000000108713067 PUD 151127067 PMD 0<br /> Oops: 0000 [#1] PREEMPT SMP PTI<br /> CPU: 4 PID: 2441 Comm: kworker/4:249 Kdump: loaded Tainted: G W E 6.4.0-rc1+ #42<br /> Workqueue: smc_hs_wq smc_listen_work [smc]<br /> RIP: 0010:smc_clc_send_confirm_accept+0x284/0x580 [smc]<br /> RSP: 0018:ffffb8294b2d7c78 EFLAGS: 00010a06<br /> RAX: ffff8f1873238880 RBX: ffffb8294b2d7dc8 RCX: 0000000000000000<br /> RDX: 00000000000000b4 RSI: 0000000000000001 RDI: 0000000000b40c00<br /> RBP: ffffb8294b2d7db8 R08: ffff8f1815c5860c R09: 0000000000000000<br /> R10: 0000000000000400 R11: 0000000000000000 R12: ffff8f1846f56180<br /> R13: ffff8f1815c5860c R14: 0000000000000001 R15: 0000000000000001<br /> FS: 0000000000000000(0000) GS:ffff8f1aefd00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000000000000014 CR3: 00000001027a0001 CR4: 00000000003706e0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> ? mlx5_ib_map_mr_sg+0xa1/0xd0 [mlx5_ib]<br /> ? smcr_buf_map_link+0x24b/0x290 [smc]<br /> ? __smc_buf_create+0x4ee/0x9b0 [smc]<br /> smc_clc_send_accept+0x4c/0xb0 [smc]<br /> smc_listen_work+0x346/0x650 [smc]<br /> ? __schedule+0x279/0x820<br /> process_one_work+0x1e5/0x3f0<br /> worker_thread+0x4d/0x2f0<br /> ? __pfx_worker_thread+0x10/0x10<br /> kthread+0xe5/0x120<br /> ? __pfx_kthread+0x10/0x10<br /> ret_from_fork+0x2c/0x50<br /> <br /> <br /> During the CLC handshake, server sequentially tries available SMCRv2<br /> and SMCRv1 devices in smc_listen_work().<br /> <br /> If an SMCRv2 device is found. SMCv2 based link group and link will be<br /> assigned to the connection. Then assumed that some buffer assignment<br /> errors happen later in the CLC handshake, such as RMB registration<br /> failure, server will give up SMCRv2 and try SMCRv1 device instead. But<br /> the resources assigned to the connection won&amp;#39;t be reset.<br /> <br /> When server tries SMCRv1 device, the connection creation process will<br /> be executed again. Since conn-&gt;lnk has been assigned when trying SMCRv2,<br /> it will not be set to the correct SMCRv1 link in<br /> smcr_lgr_conn_assign_link(). So in such situation, conn-&gt;lgr points to<br /> correct SMCRv1 link group but conn-&gt;lnk points to the SMCRv2 link<br /> mistakenly.<br /> <br /> Then in smc_clc_send_confirm_accept(), conn-&gt;rmb_desc-&gt;mr[link-&gt;link_idx]<br /> will be accessed. Since the link-&gt;link_idx is not correct, the related<br /> MR may not have been initialized, so crash happens.<br /> <br /> | Try SMCRv2 device first<br /> | |-&gt; conn-&gt;lgr: assign existed SMCRv2 link group;<br /> | |-&gt; conn-&gt;link: assign existed SMCRv2 link (link_idx may be 1 in SMC_LGR_SYMMETRIC);<br /> | |-&gt; sndbuf &amp; RMB creation fails, quit;<br /> |<br /> | Try SMCRv1 device then<br /> | |-&gt; conn-&gt;lgr: create SMCRv1 link group and assign;<br /> | |-&gt; conn-&gt;link: keep SMCRv2 link mistakenly;<br /> | |-&gt; sndbuf &amp; RMB creation succeed, only RMB-&gt;mr[link_idx = 0]<br /> | initialized.<br /> |<br /> | Then smc_clc_send_confirm_accept() accesses<br /> | conn-&gt;rmb_desc-&gt;mr[conn-&gt;link-&gt;link_idx, which is 1], then crash.<br /> v<br /> <br /> This patch tries to fix this by cleaning conn-&gt;lnk before assigning<br /> link. In addition, it is better to reset the connection and clean the<br /> resources assigned if trying SMCRv2 failed in buffer creation or<br /> registration.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> NFSD: fix leaked reference count of nfsd4_ssc_umount_item<br /> <br /> The reference count of nfsd4_ssc_umount_item is not decremented<br /> on error conditions. This prevents the laundromat from unmounting<br /> the vfsmount of the source file.<br /> <br /> This patch decrements the reference count of nfsd4_ssc_umount_item<br /> on error.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> md/raid10: fix null-ptr-deref of mreplace in raid10_sync_request<br /> <br /> There are two check of &amp;#39;mreplace&amp;#39; in raid10_sync_request(). In the first<br /> check, &amp;#39;need_replace&amp;#39; will be set and &amp;#39;mreplace&amp;#39; will be used later if<br /> no-Faulty &amp;#39;mreplace&amp;#39; exists, In the second check, &amp;#39;mreplace&amp;#39; will be<br /> set to NULL if it is Faulty, but &amp;#39;need_replace&amp;#39; will not be changed<br /> accordingly. null-ptr-deref occurs if Faulty is set between two check.<br /> <br /> Fix it by merging two checks into one. And replace &amp;#39;need_replace&amp;#39; with<br /> &amp;#39;mreplace&amp;#39; because their values are always the same.