Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> HID: intel-ish-hid: Fix kernel panic during warm reset<br /> <br /> During warm reset device-&gt;fw_client is set to NULL. If a bus driver is<br /> registered after this NULL setting and before new firmware clients are<br /> enumerated by ISHTP, kernel panic will result in the function<br /> ishtp_cl_bus_match(). This is because of reference to<br /> device-&gt;fw_client-&gt;props.protocol_name.<br /> <br /> ISH firmware after getting successfully loaded, sends a warm reset<br /> notification to remove all clients from the bus and sets<br /> device-&gt;fw_client to NULL. Until kernel v5.15, all enabled ISHTP kernel<br /> module drivers were loaded right after any of the first ISHTP device was<br /> registered, regardless of whether it was a matched or an unmatched<br /> device. This resulted in all drivers getting registered much before the<br /> warm reset notification from ISH.<br /> <br /> Starting kernel v5.16, this issue got exposed after the change was<br /> introduced to load only bus drivers for the respective matching devices.<br /> In this scenario, cros_ec_ishtp device and cros_ec_ishtp driver are<br /> registered after the warm reset device fw_client NULL setting.<br /> cros_ec_ishtp driver_register() triggers the callback to<br /> ishtp_cl_bus_match() to match ISHTP driver to the device and causes kernel<br /> panic in guid_equal() when dereferencing fw_client NULL pointer to get<br /> protocol_name.

*** 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 /> 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 /> 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 /> 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 /> 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 /> 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 /> 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 /> 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 /> Bluetooth: hci_conn: fail SCO/ISO via hci_conn_failed if ACL gone early<br /> <br /> Not calling hci_(dis)connect_cfm before deleting conn referred to by a<br /> socket generally results to use-after-free.<br /> <br /> When cleaning up SCO connections when the parent ACL is deleted too<br /> early, use hci_conn_failed to do the connection cleanup properly.<br /> <br /> We also need to clean up ISO connections in a similar situation when<br /> connecting has started but LE Create CIS is not yet sent, so do it too<br /> here.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tracing: Free error logs of tracing instances<br /> <br /> When a tracing instance is removed, the error messages that hold errors<br /> that occurred in the instance needs to be freed. The following reports a<br /> memory leak:<br /> <br /> # cd /sys/kernel/tracing<br /> # mkdir instances/foo<br /> # echo &amp;#39;hist:keys=x&amp;#39; &gt; instances/foo/events/sched/sched_switch/trigger<br /> # cat instances/foo/error_log<br /> [ 117.404795] hist:sched:sched_switch: error: Couldn&amp;#39;t find field<br /> Command: hist:keys=x<br /> ^<br /> # rmdir instances/foo<br /> <br /> Then check for memory leaks:<br /> <br /> # echo scan &gt; /sys/kernel/debug/kmemleak<br /> # cat /sys/kernel/debug/kmemleak<br /> unreferenced object 0xffff88810d8ec700 (size 192):<br /> comm "bash", pid 869, jiffies 4294950577 (age 215.752s)<br /> hex dump (first 32 bytes):<br /> 60 dd 68 61 81 88 ff ff 60 dd 68 61 81 88 ff ff `.ha....`.ha....<br /> a0 30 8c 83 ff ff ff ff 26 00 0a 00 00 00 00 00 .0......&amp;.......<br /> backtrace:<br /> [] kmalloc_trace+0x2a/0xa0<br /> [] tracing_log_err+0x277/0x2e0<br /> [] parse_atom+0x966/0xb40<br /> [] parse_expr+0x5f3/0xdb0<br /> [] event_hist_trigger_parse+0x27f8/0x3560<br /> [] trigger_process_regex+0x135/0x1a0<br /> [] event_trigger_write+0x87/0xf0<br /> [] vfs_write+0x162/0x670<br /> [] ksys_write+0xca/0x170<br /> [] do_syscall_64+0x3e/0xc0<br /> [] entry_SYSCALL_64_after_hwframe+0x72/0xdc<br /> unreferenced object 0xffff888170c35a00 (size 32):<br /> comm "bash", pid 869, jiffies 4294950577 (age 215.752s)<br /> hex dump (first 32 bytes):<br /> 0a 20 20 43 6f 6d 6d 61 6e 64 3a 20 68 69 73 74 . Command: hist<br /> 3a 6b 65 79 73 3d 78 0a 00 00 00 00 00 00 00 00 :keys=x.........<br /> backtrace:<br /> [] __kmalloc+0x4d/0x160<br /> [] tracing_log_err+0x29b/0x2e0<br /> [] parse_atom+0x966/0xb40<br /> [] parse_expr+0x5f3/0xdb0<br /> [] event_hist_trigger_parse+0x27f8/0x3560<br /> [] trigger_process_regex+0x135/0x1a0<br /> [] event_trigger_write+0x87/0xf0<br /> [] vfs_write+0x162/0x670<br /> [] ksys_write+0xca/0x170<br /> [] do_syscall_64+0x3e/0xc0<br /> [] entry_SYSCALL_64_after_hwframe+0x72/0xdc<br /> <br /> The problem is that the error log needs to be freed when the instance is<br /> removed.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: mpi3mr: Use number of bits to manage bitmap sizes<br /> <br /> To allocate bitmaps, the mpi3mr driver calculates sizes of bitmaps using<br /> byte as unit. However, bitmap helper functions assume that bitmaps are<br /> allocated using unsigned long as unit. This gap causes memory access beyond<br /> the bitmap sizes and results in "BUG: KASAN: slab-out-of-bounds". The BUG<br /> was observed at firmware download to eHBA-9600. Call trace indicated that<br /> the out-of-bounds access happened in find_first_zero_bit() called from<br /> mpi3mr_send_event_ack() for miroc-&gt;evtack_cmds_bitmap.<br /> <br /> To fix the BUG, do not use bytes to manage bitmap sizes. Instead, use<br /> number of bits, and call bitmap helper functions which take number of bits<br /> as arguments. For memory allocation, call bitmap_zalloc() instead of<br /> kzalloc() and krealloc(). For memory free, call bitmap_free() instead of<br /> kfree(). For zero clear, call bitmap_clear() instead of memset().<br /> <br /> Remove three fields for bitmap byte sizes in struct scmd_priv which are no<br /> longer required. Replace the field dev_handle_bitmap_sz with<br /> dev_handle_bitmap_bits to keep number of bits of removepend_bitmap across<br /> resize.