Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ARM: OMAP2+: omap4-common: Fix refcount leak bug<br /> <br /> In omap4_sram_init(), of_find_compatible_node() will return a node<br /> pointer with refcount incremented. We should use of_node_put() when<br /> it is not used anymore.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dmaengine: qcom-adm: fix wrong sizeof config in slave_config<br /> <br /> Fix broken slave_config function that uncorrectly compare the<br /> peripheral_size with the size of the config pointer instead of the size<br /> of the config struct. This cause the crci value to be ignored and cause<br /> a kernel panic on any slave that use adm driver.<br /> <br /> To fix this, compare to the size of the struct and NOT the size of the<br /> pointer.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dmaengine: ti: k3-udma: Reset UDMA_CHAN_RT byte counters to prevent overflow<br /> <br /> UDMA_CHAN_RT_*BCNT_REG stores the real-time channel bytecount statistics.<br /> These registers are 32-bit hardware counters and the driver uses these<br /> counters to monitor the operational progress status for a channel, when<br /> transferring more than 4GB of data it was observed that these counters<br /> overflow and completion calculation of a operation gets affected and the<br /> transfer hangs indefinitely.<br /> <br /> This commit adds changes to decrease the byte count for every complete<br /> transaction so that these registers never overflow and the proper byte<br /> count statistics is maintained for ongoing transaction by the RT counters.<br /> <br /> Earlier uc-&gt;bcnt used to maintain a count of the completed bytes at driver<br /> side, since the RT counters maintain the statistics of current transaction<br /> now, the maintenance of uc-&gt;bcnt is not necessary.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: si470x: Fix use-after-free in si470x_int_in_callback()<br /> <br /> syzbot reported use-after-free in si470x_int_in_callback() [1]. This<br /> indicates that urb-&gt;context, which contains struct si470x_device<br /> object, is freed when si470x_int_in_callback() is called.<br /> <br /> The cause of this issue is that si470x_int_in_callback() is called for<br /> freed urb.<br /> <br /> si470x_usb_driver_probe() calls si470x_start_usb(), which then calls<br /> usb_submit_urb() and si470x_start(). If si470x_start_usb() fails,<br /> si470x_usb_driver_probe() doesn&amp;#39;t kill urb, but it just frees struct<br /> si470x_device object, as depicted below:<br /> <br /> si470x_usb_driver_probe()<br /> ...<br /> si470x_start_usb()<br /> ...<br /> usb_submit_urb()<br /> retval = si470x_start()<br /> return retval<br /> if (retval

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/rxe: Fix mr-&gt;map double free<br /> <br /> rxe_mr_cleanup() which tries to free mr-&gt;map again will be called when<br /> rxe_mr_init_user() fails:<br /> <br /> CPU: 0 PID: 4917 Comm: rdma_flush_serv Kdump: loaded Not tainted 6.1.0-rc1-roce-flush+ #25<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x45/0x5d<br /> panic+0x19e/0x349<br /> end_report.part.0+0x54/0x7c<br /> kasan_report.cold+0xa/0xf<br /> rxe_mr_cleanup+0x9d/0xf0 [rdma_rxe]<br /> __rxe_cleanup+0x10a/0x1e0 [rdma_rxe]<br /> rxe_reg_user_mr+0xb7/0xd0 [rdma_rxe]<br /> ib_uverbs_reg_mr+0x26a/0x480 [ib_uverbs]<br /> ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x1a2/0x250 [ib_uverbs]<br /> ib_uverbs_cmd_verbs+0x1397/0x15a0 [ib_uverbs]<br /> <br /> This issue was firstly exposed since commit b18c7da63fcb ("RDMA/rxe: Fix<br /> memory leak in error path code") and then we fixed it in commit<br /> 8ff5f5d9d8cf ("RDMA/rxe: Prevent double freeing rxe_map_set()") but this<br /> fix was reverted together at last by commit 1e75550648da (Revert<br /> "RDMA/rxe: Create duplicate mapping tables for FMRs")<br /> <br /> Simply let rxe_mr_cleanup() always handle freeing the mr-&gt;map once it is<br /> successfully allocated.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: host: xhci: Fix potential memory leak in xhci_alloc_stream_info()<br /> <br /> xhci_alloc_stream_info() allocates stream context array for stream_info<br /> -&gt;stream_ctx_array with xhci_alloc_stream_ctx(). When some error occurs,<br /> stream_info-&gt;stream_ctx_array is not released, which will lead to a<br /> memory leak.<br /> <br /> We can fix it by releasing the stream_info-&gt;stream_ctx_array with<br /> xhci_free_stream_ctx() on the error path to avoid the potential memory<br /> leak.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> r6040: Fix kmemleak in probe and remove<br /> <br /> There is a memory leaks reported by kmemleak:<br /> <br /> unreferenced object 0xffff888116111000 (size 2048):<br /> comm "modprobe", pid 817, jiffies 4294759745 (age 76.502s)<br /> hex dump (first 32 bytes):<br /> 00 c4 0a 04 81 88 ff ff 08 10 11 16 81 88 ff ff ................<br /> 08 10 11 16 81 88 ff ff 00 00 00 00 00 00 00 00 ................<br /> backtrace:<br /> [] kmalloc_trace+0x22/0x60<br /> [] phy_device_create+0x4e/0x90<br /> [] get_phy_device+0xd2/0x220<br /> [] mdiobus_scan+0xa4/0x2e0<br /> [] __mdiobus_register+0x482/0x8b0<br /> [] r6040_init_one+0x714/0xd2c [r6040]<br /> ...<br /> <br /> The problem occurs in probe process as follows:<br /> r6040_init_one:<br /> mdiobus_register<br /> mdiobus_scan

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> blk-mq: fix null pointer dereference in blk_mq_clear_rq_mapping()<br /> <br /> Our syzkaller report a null pointer dereference, root cause is<br /> following:<br /> <br /> __blk_mq_alloc_map_and_rqs<br /> set-&gt;tags[hctx_idx] = blk_mq_alloc_map_and_rqs<br /> blk_mq_alloc_map_and_rqs<br /> blk_mq_alloc_rqs<br /> // failed due to oom<br /> alloc_pages_node<br /> // set-&gt;tags[hctx_idx] is still NULL<br /> blk_mq_free_rqs<br /> drv_tags = set-&gt;tags[hctx_idx];<br /> // null pointer dereference is triggered<br /> blk_mq_clear_rq_mapping(drv_tags, ...)<br /> <br /> This is because commit 63064be150e4 ("blk-mq:<br /> Add blk_mq_alloc_map_and_rqs()") merged the two steps:<br /> <br /> 1) set-&gt;tags[hctx_idx] = blk_mq_alloc_rq_map()<br /> 2) blk_mq_alloc_rqs(..., set-&gt;tags[hctx_idx])<br /> <br /> into one step:<br /> <br /> set-&gt;tags[hctx_idx] = blk_mq_alloc_map_and_rqs()<br /> <br /> Since tags is not initialized yet in this case, fix the problem by<br /> checking if tags is NULL pointer in blk_mq_clear_rq_mapping().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tipc: fix an information leak in tipc_topsrv_kern_subscr<br /> <br /> Use a 8-byte write to initialize sub.usr_handle in<br /> tipc_topsrv_kern_subscr(), otherwise four bytes remain uninitialized<br /> when issuing setsockopt(..., SOL_TIPC, ...).<br /> This resulted in an infoleak reported by KMSAN when the packet was<br /> received:<br /> <br /> =====================================================<br /> BUG: KMSAN: kernel-infoleak in copyout+0xbc/0x100 lib/iov_iter.c:169<br /> instrument_copy_to_user ./include/linux/instrumented.h:121<br /> copyout+0xbc/0x100 lib/iov_iter.c:169<br /> _copy_to_iter+0x5c0/0x20a0 lib/iov_iter.c:527<br /> copy_to_iter ./include/linux/uio.h:176<br /> simple_copy_to_iter+0x64/0xa0 net/core/datagram.c:513<br /> __skb_datagram_iter+0x123/0xdc0 net/core/datagram.c:419<br /> skb_copy_datagram_iter+0x58/0x200 net/core/datagram.c:527<br /> skb_copy_datagram_msg ./include/linux/skbuff.h:3903<br /> packet_recvmsg+0x521/0x1e70 net/packet/af_packet.c:3469<br /> ____sys_recvmsg+0x2c4/0x810 net/socket.c:?<br /> ___sys_recvmsg+0x217/0x840 net/socket.c:2743<br /> __sys_recvmsg net/socket.c:2773<br /> __do_sys_recvmsg net/socket.c:2783<br /> __se_sys_recvmsg net/socket.c:2780<br /> __x64_sys_recvmsg+0x364/0x540 net/socket.c:2780<br /> do_syscall_x64 arch/x86/entry/common.c:50<br /> do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd arch/x86/entry/entry_64.S:120<br /> <br /> ...<br /> <br /> Uninit was stored to memory at:<br /> tipc_sub_subscribe+0x42d/0xb50 net/tipc/subscr.c:156<br /> tipc_conn_rcv_sub+0x246/0x620 net/tipc/topsrv.c:375<br /> tipc_topsrv_kern_subscr+0x2e8/0x400 net/tipc/topsrv.c:579<br /> tipc_group_create+0x4e7/0x7d0 net/tipc/group.c:190<br /> tipc_sk_join+0x2a8/0x770 net/tipc/socket.c:3084<br /> tipc_setsockopt+0xae5/0xe40 net/tipc/socket.c:3201<br /> __sys_setsockopt+0x87f/0xdc0 net/socket.c:2252<br /> __do_sys_setsockopt net/socket.c:2263<br /> __se_sys_setsockopt net/socket.c:2260<br /> __x64_sys_setsockopt+0xe0/0x160 net/socket.c:2260<br /> do_syscall_x64 arch/x86/entry/common.c:50<br /> do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd arch/x86/entry/entry_64.S:120<br /> <br /> Local variable sub created at:<br /> tipc_topsrv_kern_subscr+0x57/0x400 net/tipc/topsrv.c:562<br /> tipc_group_create+0x4e7/0x7d0 net/tipc/group.c:190<br /> <br /> Bytes 84-87 of 88 are uninitialized<br /> Memory access of size 88 starts at ffff88801ed57cd0<br /> Data copied to user address 0000000020000400<br /> ...<br /> =====================================================

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: mpt3sas: Fix possible resource leaks in mpt3sas_transport_port_add()<br /> <br /> In mpt3sas_transport_port_add(), if sas_rphy_add() returns error,<br /> sas_rphy_free() needs be called to free the resource allocated in<br /> sas_end_device_alloc(). Otherwise a kernel crash will happen:<br /> <br /> Unable to handle kernel NULL pointer dereference at virtual address 0000000000000108<br /> CPU: 45 PID: 37020 Comm: bash Kdump: loaded Tainted: G W 6.1.0-rc1+ #189<br /> pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> pc : device_del+0x54/0x3d0<br /> lr : device_del+0x37c/0x3d0<br /> Call trace:<br /> device_del+0x54/0x3d0<br /> attribute_container_class_device_del+0x28/0x38<br /> transport_remove_classdev+0x6c/0x80<br /> attribute_container_device_trigger+0x108/0x110<br /> transport_remove_device+0x28/0x38<br /> sas_rphy_remove+0x50/0x78 [scsi_transport_sas]<br /> sas_port_delete+0x30/0x148 [scsi_transport_sas]<br /> do_sas_phy_delete+0x78/0x80 [scsi_transport_sas]<br /> device_for_each_child+0x68/0xb0<br /> sas_remove_children+0x30/0x50 [scsi_transport_sas]<br /> sas_rphy_remove+0x38/0x78 [scsi_transport_sas]<br /> sas_port_delete+0x30/0x148 [scsi_transport_sas]<br /> do_sas_phy_delete+0x78/0x80 [scsi_transport_sas]<br /> device_for_each_child+0x68/0xb0<br /> sas_remove_children+0x30/0x50 [scsi_transport_sas]<br /> sas_remove_host+0x20/0x38 [scsi_transport_sas]<br /> scsih_remove+0xd8/0x420 [mpt3sas]<br /> <br /> Because transport_add_device() is not called when sas_rphy_add() fails, the<br /> device is not added. When sas_rphy_remove() is subsequently called to<br /> remove the device in the remove() path, a NULL pointer dereference happens.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mac80211: mlme: fix null-ptr deref on failed assoc<br /> <br /> If association to an AP without a link 0 fails, then we crash in<br /> tracing because it assumes that either ap_mld_addr or link 0 BSS<br /> is valid, since we clear sdata-&gt;vif.valid_links and then don&amp;#39;t<br /> add the ap_mld_addr to the struct.<br /> <br /> Since we clear also sdata-&gt;vif.cfg.ap_addr, keep a local copy of<br /> it and assign it earlier, before clearing valid_links, to fix<br /> this.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dm thin: Use last transaction&amp;#39;s pmd-&gt;root when commit failed<br /> <br /> Recently we found a softlock up problem in dm thin pool btree lookup<br /> code due to corrupted metadata:<br /> <br /> Kernel panic - not syncing: softlockup: hung tasks<br /> CPU: 7 PID: 2669225 Comm: kworker/u16:3<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)<br /> Workqueue: dm-thin do_worker [dm_thin_pool]<br /> Call Trace:<br /> <br /> dump_stack+0x9c/0xd3<br /> panic+0x35d/0x6b9<br /> watchdog_timer_fn.cold+0x16/0x25<br /> __run_hrtimer+0xa2/0x2d0<br /> <br /> RIP: 0010:__relink_lru+0x102/0x220 [dm_bufio]<br /> __bufio_new+0x11f/0x4f0 [dm_bufio]<br /> new_read+0xa3/0x1e0 [dm_bufio]<br /> dm_bm_read_lock+0x33/0xd0 [dm_persistent_data]<br /> ro_step+0x63/0x100 [dm_persistent_data]<br /> btree_lookup_raw.constprop.0+0x44/0x220 [dm_persistent_data]<br /> dm_btree_lookup+0x16f/0x210 [dm_persistent_data]<br /> dm_thin_find_block+0x12c/0x210 [dm_thin_pool]<br /> __process_bio_read_only+0xc5/0x400 [dm_thin_pool]<br /> process_thin_deferred_bios+0x1a4/0x4a0 [dm_thin_pool]<br /> process_one_work+0x3c5/0x730<br /> <br /> Following process may generate a broken btree mixed with fresh and<br /> stale btree nodes, which could get dm thin trapped in an infinite loop<br /> while looking up data block:<br /> Transaction 1: pmd-&gt;root = A, A-&gt;B-&gt;C // One path in btree<br /> pmd-&gt;root = X, X-&gt;Y-&gt;Z // Copy-up<br /> Transaction 2: X,Z is updated on disk, Y write failed.<br /> // Commit failed, dm thin becomes read-only.<br /> process_bio_read_only<br /> dm_thin_find_block<br /> __find_block<br /> dm_btree_lookup(pmd-&gt;root)<br /> The pmd-&gt;root points to a broken btree, Y may contain stale node<br /> pointing to any block, for example X, which gets dm thin trapped into<br /> a dead loop while looking up Z.<br /> <br /> Fix this by setting pmd-&gt;root in __open_metadata(), so that dm thin<br /> will use the last transaction&amp;#39;s pmd-&gt;root if commit failed.<br /> <br /> Fetch a reproducer in [Link].<br /> <br /> Linke: https://bugzilla.kernel.org/show_bug.cgi?id=216790