Vulnerabilidades

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

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

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: phy: phy-tahvo: fix memory leak in tahvo_usb_probe()<br /> <br /> Smatch reports:<br /> drivers/usb/phy/phy-tahvo.c: tahvo_usb_probe()<br /> warn: missing unwind goto?<br /> <br /> After geting irq, if ret

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/i915/dpt: Treat the DPT BO as a framebuffer<br /> <br /> Currently i915_gem_object_is_framebuffer() doesn&amp;#39;t treat the<br /> BO containing the framebuffer&amp;#39;s DPT as a framebuffer itself.<br /> This means eg. that the shrinker can evict the DPT BO while<br /> leaving the actual FB BO bound, when the DPT is allocated<br /> from regular shmem.<br /> <br /> That causes an immediate oops during hibernate as we<br /> try to rewrite the PTEs inside the already evicted<br /> DPT obj.<br /> <br /> TODO: presumably this might also be the reason for the<br /> DPT related display faults under heavy memory pressure,<br /> but I&amp;#39;m still not sure how that would happen as the object<br /> should be pinned by intel_dpt_pin() while in active use by<br /> the display engine...<br /> <br /> (cherry picked from commit 779cb5ba64ec7df80675a956c9022929514f517a)

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cifs: prevent use-after-free by freeing the cfile later<br /> <br /> In smb2_compound_op we have a possible use-after-free<br /> which can cause hard to debug problems later on.<br /> <br /> This was revealed during stress testing with KASAN enabled<br /> kernel. Fixing it by moving the cfile free call to<br /> a few lines below, after the usage.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> staging: greybus: audio_helper: remove unused and wrong debugfs usage<br /> <br /> In the greybus audio_helper code, the debugfs file for the dapm has the<br /> potential to be removed and memory will be leaked. There is also the<br /> very real potential for this code to remove ALL debugfs entries from the<br /> system, and it seems like this is what will really happen if this code<br /> ever runs. This all is very wrong as the greybus audio driver did not<br /> create this debugfs file, the sound core did and controls the lifespan<br /> of it.<br /> <br /> So remove all of the debugfs logic from the audio_helper code as there&amp;#39;s<br /> no way it could be correct. If this really is needed, it can come back<br /> with a fixup for the incorrect usage of the debugfs_lookup() call which<br /> is what caused this to be noticed at all.