Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5e: fix memory leak in mlx5e_ptp_open<br /> <br /> When kvzalloc_node or kvzalloc failed in mlx5e_ptp_open, the memory<br /> pointed by "c" or "cparams" is not freed, which can lead to a memory<br /> leak. Fix by freeing the array in the error path.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> keys: Fix linking a duplicate key to a keyring&amp;#39;s assoc_array<br /> <br /> When making a DNS query inside the kernel using dns_query(), the request<br /> code can in rare cases end up creating a duplicate index key in the<br /> assoc_array of the destination keyring. It is eventually found by<br /> a BUG_ON() check in the assoc_array implementation and results in<br /> a crash.<br /> <br /> Example report:<br /> [2158499.700025] kernel BUG at ../lib/assoc_array.c:652!<br /> [2158499.700039] invalid opcode: 0000 [#1] SMP PTI<br /> [2158499.700065] CPU: 3 PID: 31985 Comm: kworker/3:1 Kdump: loaded Not tainted 5.3.18-150300.59.90-default #1 SLE15-SP3<br /> [2158499.700096] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020<br /> [2158499.700351] Workqueue: cifsiod cifs_resolve_server [cifs]<br /> [2158499.700380] RIP: 0010:assoc_array_insert+0x85f/0xa40<br /> [2158499.700401] Code: ff 74 2b 48 8b 3b 49 8b 45 18 4c 89 e6 48 83 e7 fe e8 95 ec 74 00 3b 45 88 7d db 85 c0 79 d4 0f 0b 0f 0b 0f 0b e8 41 f2 be ff 0b 0f 0b 81 7d 88 ff ff ff 7f 4c 89 eb 4c 8b ad 58 ff ff ff 0f<br /> [2158499.700448] RSP: 0018:ffffc0bd6187faf0 EFLAGS: 00010282<br /> [2158499.700470] RAX: ffff9f1ea7da2fe8 RBX: ffff9f1ea7da2fc1 RCX: 0000000000000005<br /> [2158499.700492] RDX: 0000000000000000 RSI: 0000000000000005 RDI: 0000000000000000<br /> [2158499.700515] RBP: ffffc0bd6187fbb0 R08: ffff9f185faf1100 R09: 0000000000000000<br /> [2158499.700538] R10: ffff9f1ea7da2cc0 R11: 000000005ed8cec8 R12: ffffc0bd6187fc28<br /> [2158499.700561] R13: ffff9f15feb8d000 R14: ffff9f1ea7da2fc0 R15: ffff9f168dc0d740<br /> [2158499.700585] FS: 0000000000000000(0000) GS:ffff9f185fac0000(0000) knlGS:0000000000000000<br /> [2158499.700610] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [2158499.700630] CR2: 00007fdd94fca238 CR3: 0000000809d8c006 CR4: 00000000003706e0<br /> [2158499.700702] Call Trace:<br /> [2158499.700741] ? key_alloc+0x447/0x4b0<br /> [2158499.700768] ? __key_link_begin+0x43/0xa0<br /> [2158499.700790] __key_link_begin+0x43/0xa0<br /> [2158499.700814] request_key_and_link+0x2c7/0x730<br /> [2158499.700847] ? dns_resolver_read+0x20/0x20 [dns_resolver]<br /> [2158499.700873] ? key_default_cmp+0x20/0x20<br /> [2158499.700898] request_key_tag+0x43/0xa0<br /> [2158499.700926] dns_query+0x114/0x2ca [dns_resolver]<br /> [2158499.701127] dns_resolve_server_name_to_ip+0x194/0x310 [cifs]<br /> [2158499.701164] ? scnprintf+0x49/0x90<br /> [2158499.701190] ? __switch_to_asm+0x40/0x70<br /> [2158499.701211] ? __switch_to_asm+0x34/0x70<br /> [2158499.701405] reconn_set_ipaddr_from_hostname+0x81/0x2a0 [cifs]<br /> [2158499.701603] cifs_resolve_server+0x4b/0xd0 [cifs]<br /> [2158499.701632] process_one_work+0x1f8/0x3e0<br /> [2158499.701658] worker_thread+0x2d/0x3f0<br /> [2158499.701682] ? process_one_work+0x3e0/0x3e0<br /> [2158499.701703] kthread+0x10d/0x130<br /> [2158499.701723] ? kthread_park+0xb0/0xb0<br /> [2158499.701746] ret_from_fork+0x1f/0x40<br /> <br /> The situation occurs as follows:<br /> * Some kernel facility invokes dns_query() to resolve a hostname, for<br /> example, "abcdef". The function registers its global DNS resolver<br /> cache as current-&gt;cred.thread_keyring and passes the query to<br /> request_key_net() -&gt; request_key_tag() -&gt; request_key_and_link().<br /> * Function request_key_and_link() creates a keyring_search_context<br /> object. Its match_data.cmp method gets set via a call to<br /> type-&gt;match_preparse() (resolves to dns_resolver_match_preparse()) to<br /> dns_resolver_cmp().<br /> * Function request_key_and_link() continues and invokes<br /> search_process_keyrings_rcu() which returns that a given key was not<br /> found. The control is then passed to request_key_and_link() -&gt;<br /> construct_alloc_key().<br /> * Concurrently to that, a second task similarly makes a DNS query for<br /> "abcdef." and its result gets inserted into the DNS resolver cache.<br /> * Back on the first task, function construct_alloc_key() first runs<br /> __key_link_begin() to determine an assoc_array_edit operation to<br /> insert a new key. Index keys in the array are compared exactly as-is,<br /> using keyring_compare_object(). The operation <br /> ---truncated---

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tracing: Fix memory leak of iter-&gt;temp when reading trace_pipe<br /> <br /> kmemleak reports:<br /> unreferenced object 0xffff88814d14e200 (size 256):<br /> comm "cat", pid 336, jiffies 4294871818 (age 779.490s)<br /> hex dump (first 32 bytes):<br /> 04 00 01 03 00 00 00 00 08 00 00 00 00 00 00 00 ................<br /> 0c d8 c8 9b ff ff ff ff 04 5a ca 9b ff ff ff ff .........Z......<br /> backtrace:<br /> [] __kmalloc+0x4f/0x140<br /> [] trace_find_next_entry+0xbb/0x1d0<br /> [] trace_print_lat_context+0xaf/0x4e0<br /> [] print_trace_line+0x3e0/0x950<br /> [] tracing_read_pipe+0x2d9/0x5a0<br /> [] vfs_read+0x143/0x520<br /> [] ksys_read+0xbd/0x160<br /> [] do_syscall_64+0x3f/0x90<br /> [] entry_SYSCALL_64_after_hwframe+0x6e/0xd8<br /> <br /> when reading file &amp;#39;trace_pipe&amp;#39;, &amp;#39;iter-&gt;temp&amp;#39; is allocated or relocated<br /> in trace_find_next_entry() but not freed before &amp;#39;trace_pipe&amp;#39; is closed.<br /> <br /> To fix it, free &amp;#39;iter-&gt;temp&amp;#39; in tracing_release_pipe().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: ath10k: add peer map clean up for peer delete in ath10k_sta_state()<br /> <br /> When peer delete failed in a disconnect operation, use-after-free<br /> detected by KFENCE in below log. It is because for each vdev_id and<br /> address, it has only one struct ath10k_peer, it is allocated in<br /> ath10k_peer_map_event(). When connected to an AP, it has more than<br /> one HTT_T2H_MSG_TYPE_PEER_MAP reported from firmware, then the<br /> array peer_map of struct ath10k will be set muti-elements to the<br /> same ath10k_peer in ath10k_peer_map_event(). When peer delete failed<br /> in ath10k_sta_state(), the ath10k_peer will be free for the 1st peer<br /> id in array peer_map of struct ath10k, and then use-after-free happened<br /> for the 2nd peer id because they map to the same ath10k_peer.<br /> <br /> And clean up all peers in array peer_map for the ath10k_peer, then<br /> user-after-free disappeared<br /> <br /> peer map event log:<br /> [ 306.911021] wlan0: authenticate with b0:2a:43:e6:75:0e<br /> [ 306.957187] ath10k_pci 0000:01:00.0: mac vdev 0 peer create b0:2a:43:e6:75:0e (new sta) sta 1 / 32 peer 1 / 33<br /> [ 306.957395] ath10k_pci 0000:01:00.0: htt peer map vdev 0 peer b0:2a:43:e6:75:0e id 246<br /> [ 306.957404] ath10k_pci 0000:01:00.0: htt peer map vdev 0 peer b0:2a:43:e6:75:0e id 198<br /> [ 306.986924] ath10k_pci 0000:01:00.0: htt peer map vdev 0 peer b0:2a:43:e6:75:0e id 166<br /> <br /> peer unmap event log:<br /> [ 435.715691] wlan0: deauthenticating from b0:2a:43:e6:75:0e by local choice (Reason: 3=DEAUTH_LEAVING)<br /> [ 435.716802] ath10k_pci 0000:01:00.0: mac vdev 0 peer delete b0:2a:43:e6:75:0e sta ffff990e0e9c2b50 (sta gone)<br /> [ 435.717177] ath10k_pci 0000:01:00.0: htt peer unmap vdev 0 peer b0:2a:43:e6:75:0e id 246<br /> [ 435.717186] ath10k_pci 0000:01:00.0: htt peer unmap vdev 0 peer b0:2a:43:e6:75:0e id 198<br /> [ 435.717193] ath10k_pci 0000:01:00.0: htt peer unmap vdev 0 peer b0:2a:43:e6:75:0e id 166<br /> <br /> use-after-free log:<br /> [21705.888627] wlan0: deauthenticating from d0:76:8f:82:be:75 by local choice (Reason: 3=DEAUTH_LEAVING)<br /> [21713.799910] ath10k_pci 0000:01:00.0: failed to delete peer d0:76:8f:82:be:75 for vdev 0: -110<br /> [21713.799925] ath10k_pci 0000:01:00.0: found sta peer d0:76:8f:82:be:75 (ptr 0000000000000000 id 102) entry on vdev 0 after it was supposedly removed<br /> [21713.799968] ==================================================================<br /> [21713.799991] BUG: KFENCE: use-after-free read in ath10k_sta_state+0x265/0xb8a [ath10k_core]<br /> [21713.799991]<br /> [21713.799997] Use-after-free read at 0x00000000abe1c75e (in kfence-#69):<br /> [21713.800010] ath10k_sta_state+0x265/0xb8a [ath10k_core]<br /> [21713.800041] drv_sta_state+0x115/0x677 [mac80211]<br /> [21713.800059] __sta_info_destroy_part2+0xb1/0x133 [mac80211]<br /> [21713.800076] __sta_info_flush+0x11d/0x162 [mac80211]<br /> [21713.800093] ieee80211_set_disassoc+0x12d/0x2f4 [mac80211]<br /> [21713.800110] ieee80211_mgd_deauth+0x26c/0x29b [mac80211]<br /> [21713.800137] cfg80211_mlme_deauth+0x13f/0x1bb [cfg80211]<br /> [21713.800153] nl80211_deauthenticate+0xf8/0x121 [cfg80211]<br /> [21713.800161] genl_rcv_msg+0x38e/0x3be<br /> [21713.800166] netlink_rcv_skb+0x89/0xf7<br /> [21713.800171] genl_rcv+0x28/0x36<br /> [21713.800176] netlink_unicast+0x179/0x24b<br /> [21713.800181] netlink_sendmsg+0x3a0/0x40e<br /> [21713.800187] sock_sendmsg+0x72/0x76<br /> [21713.800192] ____sys_sendmsg+0x16d/0x1e3<br /> [21713.800196] ___sys_sendmsg+0x95/0xd1<br /> [21713.800200] __sys_sendmsg+0x85/0xbf<br /> [21713.800205] do_syscall_64+0x43/0x55<br /> [21713.800210] entry_SYSCALL_64_after_hwframe+0x44/0xa9<br /> [21713.800213]<br /> [21713.800219] kfence-#69: 0x000000009149b0d5-0x000000004c0697fb, size=1064, cache=kmalloc-2k<br /> [21713.800219]<br /> [21713.800224] allocated by task 13 on cpu 0 at 21705.501373s:<br /> [21713.800241] ath10k_peer_map_event+0x7e/0x154 [ath10k_core]<br /> [21713.800254] ath10k_htt_t2h_msg_handler+0x586/0x1039 [ath10k_core]<br /> [21713.800265] ath10k_htt_htc_t2h_msg_handler+0x12/0x28 [ath10k_core]<br /> [21713.800277] ath10k_htc_rx_completion_handler+0x14c/0x1b5 [ath10k_core]<br /> [21713.800283] ath10k_pci_process_rx_cb+0x195/0x1d<br /> ---truncated---

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: ath9k: Fix use-after-free in ath9k_hif_usb_disconnect()<br /> <br /> This patch fixes a use-after-free in ath9k that occurs in<br /> ath9k_hif_usb_disconnect() when ath9k_destroy_wmi() is trying to access<br /> &amp;#39;drv_priv&amp;#39; that has already been freed by ieee80211_free_hw(), called by<br /> ath9k_htc_hw_deinit(). The patch moves ath9k_destroy_wmi() before<br /> ieee80211_free_hw(). Note that urbs from the driver should be killed<br /> before freeing &amp;#39;wmi&amp;#39; with ath9k_destroy_wmi() as their callbacks will<br /> access &amp;#39;wmi&amp;#39;.<br /> <br /> Found by a modified version of syzkaller.<br /> <br /> ==================================================================<br /> BUG: KASAN: use-after-free in ath9k_destroy_wmi+0x38/0x40<br /> Read of size 8 at addr ffff8881069132a0 by task kworker/0:1/7<br /> <br /> CPU: 0 PID: 7 Comm: kworker/0:1 Tainted: G O 5.14.0+ #131<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014<br /> Workqueue: usb_hub_wq hub_event<br /> Call Trace:<br /> dump_stack_lvl+0x8e/0xd1<br /> print_address_description.constprop.0.cold+0x93/0x334<br /> ? ath9k_destroy_wmi+0x38/0x40<br /> ? ath9k_destroy_wmi+0x38/0x40<br /> kasan_report.cold+0x83/0xdf<br /> ? ath9k_destroy_wmi+0x38/0x40<br /> ath9k_destroy_wmi+0x38/0x40<br /> ath9k_hif_usb_disconnect+0x329/0x3f0<br /> ? ath9k_hif_usb_suspend+0x120/0x120<br /> ? usb_disable_interface+0xfc/0x180<br /> usb_unbind_interface+0x19b/0x7e0<br /> ? usb_autoresume_device+0x50/0x50<br /> device_release_driver_internal+0x44d/0x520<br /> bus_remove_device+0x2e5/0x5a0<br /> device_del+0x5b2/0xe30<br /> ? __device_link_del+0x370/0x370<br /> ? usb_remove_ep_devs+0x43/0x80<br /> ? remove_intf_ep_devs+0x112/0x1a0<br /> usb_disable_device+0x1e3/0x5a0<br /> usb_disconnect+0x267/0x870<br /> hub_event+0x168d/0x3950<br /> ? rcu_read_lock_sched_held+0xa1/0xd0<br /> ? hub_port_debounce+0x2e0/0x2e0<br /> ? check_irq_usage+0x860/0xf20<br /> ? drain_workqueue+0x281/0x360<br /> ? lock_release+0x640/0x640<br /> ? rcu_read_lock_sched_held+0xa1/0xd0<br /> ? rcu_read_lock_bh_held+0xb0/0xb0<br /> ? lockdep_hardirqs_on_prepare+0x273/0x3e0<br /> process_one_work+0x92b/0x1460<br /> ? pwq_dec_nr_in_flight+0x330/0x330<br /> ? rwlock_bug.part.0+0x90/0x90<br /> worker_thread+0x95/0xe00<br /> ? __kthread_parkme+0x115/0x1e0<br /> ? process_one_work+0x1460/0x1460<br /> kthread+0x3a1/0x480<br /> ? set_kthread_struct+0x120/0x120<br /> ret_from_fork+0x1f/0x30<br /> <br /> The buggy address belongs to the page:<br /> page:ffffea00041a44c0 refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x106913<br /> flags: 0x200000000000000(node=0|zone=2)<br /> raw: 0200000000000000 0000000000000000 dead000000000122 0000000000000000<br /> raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000<br /> page dumped because: kasan: bad access detected<br /> page_owner tracks the page as freed<br /> page last allocated via order 3, migratetype Unmovable, gfp_mask 0x40dc0(GFP_KERNEL|__GFP_COMP|__GFP_ZERO), pid 7, ts 38347963444, free_ts 41399957635<br /> prep_new_page+0x1aa/0x240<br /> get_page_from_freelist+0x159a/0x27c0<br /> __alloc_pages+0x2da/0x6a0<br /> alloc_pages+0xec/0x1e0<br /> kmalloc_order+0x39/0xf0<br /> kmalloc_order_trace+0x19/0x120<br /> __kmalloc+0x308/0x390<br /> wiphy_new_nm+0x6f5/0x1dd0<br /> ieee80211_alloc_hw_nm+0x36d/0x2230<br /> ath9k_htc_probe_device+0x9d/0x1e10<br /> ath9k_htc_hw_init+0x34/0x50<br /> ath9k_hif_usb_firmware_cb+0x25f/0x4e0<br /> request_firmware_work_func+0x131/0x240<br /> process_one_work+0x92b/0x1460<br /> worker_thread+0x95/0xe00<br /> kthread+0x3a1/0x480<br /> page last free stack trace:<br /> free_pcp_prepare+0x3d3/0x7f0<br /> free_unref_page+0x1e/0x3d0<br /> device_release+0xa4/0x240<br /> kobject_put+0x186/0x4c0<br /> put_device+0x20/0x30<br /> ath9k_htc_disconnect_device+0x1cf/0x2c0<br /> ath9k_htc_hw_deinit+0x26/0x30<br /> ath9k_hif_usb_disconnect+0x2d9/0x3f0<br /> usb_unbind_interface+0x19b/0x7e0<br /> device_release_driver_internal+0x44d/0x520<br /> bus_remove_device+0x2e5/0x5a0<br /> device_del+0x5b2/0xe30<br /> usb_disable_device+0x1e3/0x5a0<br /> usb_disconnect+0x267/0x870<br /> hub_event+0x168d/0x3950<br /> process_one_work+0x92b/0x1460<br /> <br /> Memory state around the buggy address:<br /> ffff888106913180: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff<br /> ffff888106913200: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff<br /> &gt;ffff888<br /> ---truncated---

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: uvcvideo: Fix memory leak in uvc_gpio_parse<br /> <br /> Previously the unit buffer was allocated before checking the IRQ for<br /> privacy GPIO. In case of error, the unit buffer was leaked.<br /> <br /> Allocate the unit buffer after the IRQ to avoid it.<br /> <br /> Addresses-Coverity-ID: 1474639 ("Resource leak")

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm: Prevent drm_copy_field() to attempt copying a NULL pointer<br /> <br /> There are some struct drm_driver fields that are required by drivers since<br /> drm_copy_field() attempts to copy them to user-space via DRM_IOCTL_VERSION.<br /> <br /> But it can be possible that a driver has a bug and did not set some of the<br /> fields, which leads to drm_copy_field() attempting to copy a NULL pointer:<br /> <br /> [ +10.395966] Unable to handle kernel access to user memory outside uaccess routines at virtual address 0000000000000000<br /> [ +0.010955] Mem abort info:<br /> [ +0.002835] ESR = 0x0000000096000004<br /> [ +0.003872] EC = 0x25: DABT (current EL), IL = 32 bits<br /> [ +0.005395] SET = 0, FnV = 0<br /> [ +0.003113] EA = 0, S1PTW = 0<br /> [ +0.003182] FSC = 0x04: level 0 translation fault<br /> [ +0.004964] Data abort info:<br /> [ +0.002919] ISV = 0, ISS = 0x00000004<br /> [ +0.003886] CM = 0, WnR = 0<br /> [ +0.003040] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000115dad000<br /> [ +0.006536] [0000000000000000] pgd=0000000000000000, p4d=0000000000000000<br /> [ +0.006925] Internal error: Oops: 96000004 [#1] SMP<br /> ...<br /> [ +0.011113] pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> [ +0.007061] pc : __pi_strlen+0x14/0x150<br /> [ +0.003895] lr : drm_copy_field+0x30/0x1a4<br /> [ +0.004156] sp : ffff8000094b3a50<br /> [ +0.003355] x29: ffff8000094b3a50 x28: ffff8000094b3b70 x27: 0000000000000040<br /> [ +0.007242] x26: ffff443743c2ba00 x25: 0000000000000000 x24: 0000000000000040<br /> [ +0.007243] x23: ffff443743c2ba00 x22: ffff8000094b3b70 x21: 0000000000000000<br /> [ +0.007241] x20: 0000000000000000 x19: ffff8000094b3b90 x18: 0000000000000000<br /> [ +0.007241] x17: 0000000000000000 x16: 0000000000000000 x15: 0000aaab14b9af40<br /> [ +0.007241] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000<br /> [ +0.007239] x11: 0000000000000000 x10: 0000000000000000 x9 : ffffa524ad67d4d8<br /> [ +0.007242] x8 : 0101010101010101 x7 : 7f7f7f7f7f7f7f7f x6 : 6c6e6263606e7141<br /> [ +0.007239] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000<br /> [ +0.007241] x2 : 0000000000000000 x1 : ffff8000094b3b90 x0 : 0000000000000000<br /> [ +0.007240] Call trace:<br /> [ +0.002475] __pi_strlen+0x14/0x150<br /> [ +0.003537] drm_version+0x84/0xac<br /> [ +0.003448] drm_ioctl_kernel+0xa8/0x16c<br /> [ +0.003975] drm_ioctl+0x270/0x580<br /> [ +0.003448] __arm64_sys_ioctl+0xb8/0xfc<br /> [ +0.003978] invoke_syscall+0x78/0x100<br /> [ +0.003799] el0_svc_common.constprop.0+0x4c/0xf4<br /> [ +0.004767] do_el0_svc+0x38/0x4c<br /> [ +0.003357] el0_svc+0x34/0x100<br /> [ +0.003185] el0t_64_sync_handler+0x11c/0x150<br /> [ +0.004418] el0t_64_sync+0x190/0x194<br /> [ +0.003716] Code: 92402c04 b200c3e8 f13fc09f 5400088c (a9400c02)<br /> [ +0.006180] ---[ end trace 0000000000000000 ]---

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/rxe: Fix NULL-ptr-deref in rxe_qp_do_cleanup() when socket create failed<br /> <br /> There is a null-ptr-deref when mount.cifs over rdma:<br /> <br /> BUG: KASAN: null-ptr-deref in rxe_qp_do_cleanup+0x2f3/0x360 [rdma_rxe]<br /> Read of size 8 at addr 0000000000000018 by task mount.cifs/3046<br /> <br /> CPU: 2 PID: 3046 Comm: mount.cifs Not tainted 6.1.0-rc5+ #62<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-1.fc3<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x34/0x44<br /> kasan_report+0xad/0x130<br /> rxe_qp_do_cleanup+0x2f3/0x360 [rdma_rxe]<br /> execute_in_process_context+0x25/0x90<br /> __rxe_cleanup+0x101/0x1d0 [rdma_rxe]<br /> rxe_create_qp+0x16a/0x180 [rdma_rxe]<br /> create_qp.part.0+0x27d/0x340<br /> ib_create_qp_kernel+0x73/0x160<br /> rdma_create_qp+0x100/0x230<br /> _smbd_get_connection+0x752/0x20f0<br /> smbd_get_connection+0x21/0x40<br /> cifs_get_tcp_session+0x8ef/0xda0<br /> mount_get_conns+0x60/0x750<br /> cifs_mount+0x103/0xd00<br /> cifs_smb3_do_mount+0x1dd/0xcb0<br /> smb3_get_tree+0x1d5/0x300<br /> vfs_get_tree+0x41/0xf0<br /> path_mount+0x9b3/0xdd0<br /> __x64_sys_mount+0x190/0x1d0<br /> do_syscall_64+0x35/0x80<br /> entry_SYSCALL_64_after_hwframe+0x46/0xb0<br /> <br /> The root cause of the issue is the socket create failed in<br /> rxe_qp_init_req().<br /> <br /> So move the reset rxe_qp_do_cleanup() after the NULL ptr check.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mmc: toshsd: fix return value check of mmc_add_host()<br /> <br /> mmc_add_host() may return error, if we ignore its return value, the memory<br /> that allocated in mmc_alloc_host() will be leaked and it will lead a kernel<br /> crash because of deleting not added device in the remove path.<br /> <br /> So fix this by checking the return value and goto error path which will call<br /> mmc_free_host(), besides, free_irq() also needs be called.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> regulator: core: fix unbalanced of node refcount in regulator_dev_lookup()<br /> <br /> I got the the following report:<br /> <br /> OF: ERROR: memory leak, expected refcount 1 instead of 2,<br /> of_node_get()/of_node_put() unbalanced - destroy cset entry:<br /> attach overlay node /i2c/pmic@62/regulators/exten<br /> <br /> In of_get_regulator(), the node is returned from of_parse_phandle()<br /> with refcount incremented, after using it, of_node_put() need be called.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> remoteproc: qcom: q6v5: Fix potential null-ptr-deref in q6v5_wcss_init_mmio()<br /> <br /> q6v5_wcss_init_mmio() will call platform_get_resource_byname() that may<br /> fail and return NULL. devm_ioremap() will use res-&gt;start as input, which<br /> may causes null-ptr-deref. Check the ret value of<br /> platform_get_resource_byname() to avoid the null-ptr-deref.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Prevent decl_tag from being referenced in func_proto arg<br /> <br /> Syzkaller managed to hit another decl_tag issue:<br /> <br /> btf_func_proto_check kernel/bpf/btf.c:4506 [inline]<br /> btf_check_all_types kernel/bpf/btf.c:4734 [inline]<br /> btf_parse_type_sec+0x1175/0x1980 kernel/bpf/btf.c:4763<br /> btf_parse kernel/bpf/btf.c:5042 [inline]<br /> btf_new_fd+0x65a/0xb00 kernel/bpf/btf.c:6709<br /> bpf_btf_load+0x6f/0x90 kernel/bpf/syscall.c:4342<br /> __sys_bpf+0x50a/0x6c0 kernel/bpf/syscall.c:5034<br /> __do_sys_bpf kernel/bpf/syscall.c:5093 [inline]<br /> __se_sys_bpf kernel/bpf/syscall.c:5091 [inline]<br /> __x64_sys_bpf+0x7c/0x90 kernel/bpf/syscall.c:5091<br /> do_syscall_64+0x54/0x70 arch/x86/entry/common.c:48<br /> <br /> This seems similar to commit ea68376c8bed ("bpf: prevent decl_tag from being<br /> referenced in func_proto") but for the argument.