Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: ISO: fix iso_conn related locking and validity issues<br /> <br /> sk-&gt;sk_state indicates whether iso_pi(sk)-&gt;conn is valid. Operations<br /> that check/update sk_state and access conn should hold lock_sock,<br /> otherwise they can race.<br /> <br /> The order of taking locks is hci_dev_lock &gt; lock_sock &gt; iso_conn_lock,<br /> which is how it is in connect/disconnect_cfm -&gt; iso_conn_del -&gt;<br /> iso_chan_del.<br /> <br /> Fix locking in iso_connect_cis/bis and sendmsg/recvmsg to take lock_sock<br /> around updating sk_state and conn.<br /> <br /> iso_conn_del must not occur during iso_connect_cis/bis, as it frees the<br /> iso_conn. Hold hdev-&gt;lock longer to prevent that.<br /> <br /> This should not reintroduce the issue fixed in commit 241f51931c35<br /> ("Bluetooth: ISO: Avoid circular locking dependency"), since the we<br /> acquire locks in order. We retain the fix in iso_sock_connect to release<br /> lock_sock before iso_connect_* acquires hdev-&gt;lock.<br /> <br /> Similarly for commit 6a5ad251b7cd ("Bluetooth: ISO: Fix possible<br /> circular locking dependency"). We retain the fix in iso_conn_ready to<br /> not acquire iso_conn_lock before lock_sock.<br /> <br /> iso_conn_add shall return iso_conn with valid hcon. Make it so also when<br /> reusing an old CIS connection waiting for disconnect timeout (see<br /> __iso_sock_close where conn-&gt;hcon is set to NULL).<br /> <br /> Trace with iso_conn_del after iso_chan_add in iso_connect_cis:<br /> ===============================================================<br /> iso_sock_create:771: sock 00000000be9b69b7<br /> iso_sock_init:693: sk 000000004dff667e<br /> iso_sock_bind:827: sk 000000004dff667e 70:1a:b8:98:ff:a2 type 1<br /> iso_sock_setsockopt:1289: sk 000000004dff667e<br /> iso_sock_setsockopt:1289: sk 000000004dff667e<br /> iso_sock_setsockopt:1289: sk 000000004dff667e<br /> iso_sock_connect:875: sk 000000004dff667e<br /> iso_connect_cis:353: 70:1a:b8:98:ff:a2 -&gt; 28:3d:c2:4a:7e:da<br /> hci_get_route:1199: 70:1a:b8:98:ff:a2 -&gt; 28:3d:c2:4a:7e:da<br /> hci_conn_add:1005: hci0 dst 28:3d:c2:4a:7e:da<br /> iso_conn_add:140: hcon 000000007b65d182 conn 00000000daf8625e<br /> __iso_chan_add:214: conn 00000000daf8625e<br /> iso_connect_cfm:1700: hcon 000000007b65d182 bdaddr 28:3d:c2:4a:7e:da status 12<br /> iso_conn_del:187: hcon 000000007b65d182 conn 00000000daf8625e, err 16<br /> iso_sock_clear_timer:117: sock 000000004dff667e state 3<br /> <br /> iso_chan_del:153: sk 000000004dff667e, conn 00000000daf8625e, err 16<br /> hci_conn_del:1151: hci0 hcon 000000007b65d182 handle 65535<br /> hci_conn_unlink:1102: hci0: hcon 000000007b65d182<br /> hci_chan_list_flush:2780: hcon 000000007b65d182<br /> iso_sock_getsockopt:1376: sk 000000004dff667e<br /> iso_sock_getname:1070: sock 00000000be9b69b7, sk 000000004dff667e<br /> iso_sock_getname:1070: sock 00000000be9b69b7, sk 000000004dff667e<br /> iso_sock_getsockopt:1376: sk 000000004dff667e<br /> iso_sock_getname:1070: sock 00000000be9b69b7, sk 000000004dff667e<br /> iso_sock_getname:1070: sock 00000000be9b69b7, sk 000000004dff667e<br /> iso_sock_shutdown:1434: sock 00000000be9b69b7, sk 000000004dff667e, how 1<br /> __iso_sock_close:632: sk 000000004dff667e state 5 socket 00000000be9b69b7<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000000<br /> PGD 8000000006467067 P4D 8000000006467067 PUD 3f5f067 PMD 0<br /> Oops: 0000 [#1] PREEMPT SMP PTI<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-1.fc38 04/01/2014<br /> RIP: 0010:__iso_sock_close (net/bluetooth/iso.c:664) bluetooth<br /> ===============================================================<br /> <br /> Trace with iso_conn_del before iso_chan_add in iso_connect_cis:<br /> ===============================================================<br /> iso_connect_cis:356: 70:1a:b8:98:ff:a2 -&gt; 28:3d:c2:4a:7e:da<br /> ...<br /> iso_conn_add:140: hcon 0000000093bc551f conn 00000000768ae504<br /> hci_dev_put:1487: hci0 orig refcnt 21<br /> hci_event_packet:7607: hci0: e<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> zsmalloc: move LRU update from zs_map_object() to zs_malloc()<br /> <br /> Under memory pressure, we sometimes observe the following crash:<br /> <br /> [ 5694.832838] ------------[ cut here ]------------<br /> [ 5694.842093] list_del corruption, ffff888014b6a448-&gt;next is LIST_POISON1 (dead000000000100)<br /> [ 5694.858677] WARNING: CPU: 33 PID: 418824 at lib/list_debug.c:47 __list_del_entry_valid+0x42/0x80<br /> [ 5694.961820] CPU: 33 PID: 418824 Comm: fuse_counters.s Kdump: loaded Tainted: G S 5.19.0-0_fbk3_rc3_hoangnhatpzsdynshrv41_10870_g85a9558a25de #1<br /> [ 5694.990194] Hardware name: Wiwynn Twin Lakes MP/Twin Lakes Passive MP, BIOS YMM16 05/24/2021<br /> [ 5695.007072] RIP: 0010:__list_del_entry_valid+0x42/0x80<br /> [ 5695.017351] Code: 08 48 83 c2 22 48 39 d0 74 24 48 8b 10 48 39 f2 75 2c 48 8b 51 08 b0 01 48 39 f2 75 34 c3 48 c7 c7 55 d7 78 82 e8 4e 45 3b 00 0b eb 31 48 c7 c7 27 a8 70 82 e8 3e 45 3b 00 0f 0b eb 21 48 c7<br /> [ 5695.054919] RSP: 0018:ffffc90027aef4f0 EFLAGS: 00010246<br /> [ 5695.065366] RAX: 41fe484987275300 RBX: ffff888008988180 RCX: 0000000000000000<br /> [ 5695.079636] RDX: ffff88886006c280 RSI: ffff888860060480 RDI: ffff888860060480<br /> [ 5695.093904] RBP: 0000000000000002 R08: 0000000000000000 R09: ffffc90027aef370<br /> [ 5695.108175] R10: 0000000000000000 R11: ffffffff82fdf1c0 R12: 0000000010000002<br /> [ 5695.122447] R13: ffff888014b6a448 R14: ffff888014b6a420 R15: 00000000138dc240<br /> [ 5695.136717] FS: 00007f23a7d3f740(0000) GS:ffff888860040000(0000) knlGS:0000000000000000<br /> [ 5695.152899] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 5695.164388] CR2: 0000560ceaab6ac0 CR3: 000000001c06c001 CR4: 00000000007706e0<br /> [ 5695.178659] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> [ 5695.192927] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> [ 5695.207197] PKRU: 55555554<br /> [ 5695.212602] Call Trace:<br /> [ 5695.217486] <br /> [ 5695.221674] zs_map_object+0x91/0x270<br /> [ 5695.229000] zswap_frontswap_store+0x33d/0x870<br /> [ 5695.237885] ? do_raw_spin_lock+0x5d/0xa0<br /> [ 5695.245899] __frontswap_store+0x51/0xb0<br /> [ 5695.253742] swap_writepage+0x3c/0x60<br /> [ 5695.261063] shrink_page_list+0x738/0x1230<br /> [ 5695.269255] shrink_lruvec+0x5ec/0xcd0<br /> [ 5695.276749] ? shrink_slab+0x187/0x5f0<br /> [ 5695.284240] ? mem_cgroup_iter+0x6e/0x120<br /> [ 5695.292255] shrink_node+0x293/0x7b0<br /> [ 5695.299402] do_try_to_free_pages+0xea/0x550<br /> [ 5695.307940] try_to_free_pages+0x19a/0x490<br /> [ 5695.316126] __folio_alloc+0x19ff/0x3e40<br /> [ 5695.323971] ? __filemap_get_folio+0x8a/0x4e0<br /> [ 5695.332681] ? walk_component+0x2a8/0xb50<br /> [ 5695.340697] ? generic_permission+0xda/0x2a0<br /> [ 5695.349231] ? __filemap_get_folio+0x8a/0x4e0<br /> [ 5695.357940] ? walk_component+0x2a8/0xb50<br /> [ 5695.365955] vma_alloc_folio+0x10e/0x570<br /> [ 5695.373796] ? walk_component+0x52/0xb50<br /> [ 5695.381634] wp_page_copy+0x38c/0xc10<br /> [ 5695.388953] ? filename_lookup+0x378/0xbc0<br /> [ 5695.397140] handle_mm_fault+0x87f/0x1800<br /> [ 5695.405157] do_user_addr_fault+0x1bd/0x570<br /> [ 5695.413520] exc_page_fault+0x5d/0x110<br /> [ 5695.421017] asm_exc_page_fault+0x22/0x30<br /> <br /> After some investigation, I have found the following issue: unlike other<br /> zswap backends, zsmalloc performs the LRU list update at the object<br /> mapping time, rather than when the slot for the object is allocated.<br /> This deviation was discussed and agreed upon during the review process<br /> of the zsmalloc writeback patch series:<br /> <br /> https://lore.kernel.org/lkml/Y3flcAXNxxrvy3ZH@cmpxchg.org/<br /> <br /> Unfortunately, this introduces a subtle bug that occurs when there is a<br /> concurrent store and reclaim, which interleave as follows:<br /> <br /> zswap_frontswap_store() shrink_worker()<br /> zs_malloc() zs_zpool_shrink()<br /> spin_lock(&amp;pool-&gt;lock) zs_reclaim_page()<br /> zspage = find_get_zspage()<br /> spin_unlock(&amp;pool-&gt;lock)<br /> spin_lock(&amp;pool-&gt;lock)<br /> zspage = list_first_entry(&amp;pool-&gt;lru)<br /> <br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> igc: Fix Kernel Panic during ndo_tx_timeout callback<br /> <br /> The Xeon validation group has been carrying out some loaded tests<br /> with various HW configurations, and they have seen some transmit<br /> queue time out happening during the test. This will cause the<br /> reset adapter function to be called by igc_tx_timeout().<br /> Similar race conditions may arise when the interface is being brought<br /> down and up in igc_reinit_locked(), an interrupt being generated, and<br /> igc_clean_tx_irq() being called to complete the TX.<br /> <br /> When the igc_tx_timeout() function is invoked, this patch will turn<br /> off all TX ring HW queues during igc_down() process. TX ring HW queues<br /> will be activated again during the igc_configure_tx_ring() process<br /> when performing the igc_up() procedure later.<br /> <br /> This patch also moved existing igc_disable_tx_ring_hw() to avoid using<br /> forward declaration.<br /> <br /> Kernel trace:<br /> [ 7678.747813] ------------[ cut here ]------------<br /> [ 7678.757914] NETDEV WATCHDOG: enp1s0 (igc): transmit queue 2 timed out<br /> [ 7678.770117] WARNING: CPU: 0 PID: 13 at net/sched/sch_generic.c:525 dev_watchdog+0x1ae/0x1f0<br /> [ 7678.784459] Modules linked in: xt_conntrack nft_chain_nat xt_MASQUERADE xt_addrtype nft_compat<br /> nf_tables nfnetlink br_netfilter bridge stp llc overlay dm_mod emrcha(PO) emriio(PO) rktpm(PO)<br /> cegbuf_mod(PO) patch_update(PO) se(PO) sgx_tgts(PO) mktme(PO) keylocker(PO) svtdx(PO) svfs_pci_hotplug(PO)<br /> vtd_mod(PO) davemem(PO) svmabort(PO) svindexio(PO) usbx2(PO) ehci_sched(PO) svheartbeat(PO) ioapic(PO)<br /> sv8259(PO) svintr(PO) lt(PO) pcierootport(PO) enginefw_mod(PO) ata(PO) smbus(PO) spiflash_cdf(PO) arden(PO)<br /> dsa_iax(PO) oobmsm_punit(PO) cpm(PO) svkdb(PO) ebg_pch(PO) pch(PO) sviotargets(PO) svbdf(PO) svmem(PO)<br /> svbios(PO) dram(PO) svtsc(PO) targets(PO) superio(PO) svkernel(PO) cswitch(PO) mcf(PO) pentiumIII_mod(PO)<br /> fs_svfs(PO) mdevdefdb(PO) svfs_os_services(O) ixgbe mdio mdio_devres libphy emeraldrapids_svdefs(PO)<br /> regsupport(O) libnvdimm nls_cp437 snd_hda_codec_realtek snd_hda_codec_generic ledtrig_audio snd_hda_intel<br /> snd_intel_dspcfg snd_hda_codec snd_hwdep x86_pkg_temp_thermal snd_hda_core snd_pcm snd_timer isst_if_mbox_pci<br /> [ 7678.784496] input_leds isst_if_mmio sg snd isst_if_common soundcore wmi button sad9(O) drm fuse backlight<br /> configfs efivarfs ip_tables x_tables vmd sdhci led_class rtl8150 r8152 hid_generic pegasus mmc_block usbhid<br /> mmc_core hid megaraid_sas ixgb igb i2c_algo_bit ice i40e hpsa scsi_transport_sas e1000e e1000 e100 ax88179_178a<br /> usbnet xhci_pci sd_mod xhci_hcd t10_pi crc32c_intel crc64_rocksoft igc crc64 crc_t10dif usbcore<br /> crct10dif_generic ptp crct10dif_common usb_common pps_core<br /> [ 7679.200403] RIP: 0010:dev_watchdog+0x1ae/0x1f0<br /> [ 7679.210201] Code: 28 e9 53 ff ff ff 4c 89 e7 c6 05 06 42 b9 00 01 e8 17 d1 fb ff 44 89 e9 4c<br /> 89 e6 48 c7 c7 40 ad fb 81 48 89 c2 e8 52 62 82 ff 0b e9 72 ff ff ff 65 8b 05 80 7d 7c 7e<br /> 89 c0 48 0f a3 05 0a c1<br /> [ 7679.245438] RSP: 0018:ffa00000001f7d90 EFLAGS: 00010282<br /> [ 7679.256021] RAX: 0000000000000000 RBX: ff11000109938440 RCX: 0000000000000000<br /> [ 7679.268710] RDX: ff11000361e26cd8 RSI: ff11000361e1b880 RDI: ff11000361e1b880<br /> [ 7679.281314] RBP: ffa00000001f7da8 R08: ff1100035f8fffe8 R09: 0000000000027ffb<br /> [ 7679.293840] R10: 0000000000001f0a R11: ff1100035f840000 R12: ff11000109938000<br /> [ 7679.306276] R13: 0000000000000002 R14: dead000000000122 R15: ffa00000001f7e18<br /> [ 7679.318648] FS: 0000000000000000(0000) GS:ff11000361e00000(0000) knlGS:0000000000000000<br /> [ 7679.332064] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 7679.342757] CR2: 00007ffff7fca168 CR3: 000000013b08a006 CR4: 0000000000471ef8<br /> [ 7679.354984] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> [ 7679.367207] DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400<br /> [ 7679.379370] PKRU: 55555554<br /> [ 7679.386446] Call Trace:<br /> [ 7679.393152] <br /> [ 7679.399363] ? __pfx_dev_watchdog+0x10/0x10<br /> [ 7679.407870] call_timer_fn+0x31/0x110<br /> [ 7679.415698] e<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> m68k: mm: Move initrd phys_to_virt handling after paging_init()<br /> <br /> When booting with an initial ramdisk on platforms where physical memory<br /> does not start at address zero (e.g. on Amiga):<br /> <br /> initrd: 0ef0602c - 0f800000<br /> Zone ranges:<br /> DMA [mem 0x0000000008000000-0x000000f7ffffffff]<br /> Normal empty<br /> Movable zone start for each node<br /> Early memory node ranges<br /> node 0: [mem 0x0000000008000000-0x000000000f7fffff]<br /> Initmem setup node 0 [mem 0x0000000008000000-0x000000000f7fffff]<br /> Unable to handle kernel access at virtual address (ptrval)<br /> Oops: 00000000<br /> Modules linked in:<br /> PC: [] memcmp+0x28/0x56<br /> <br /> As phys_to_virt() relies on m68k_memoffset and module_fixup(), it must<br /> not be called before paging_init(). Hence postpone the phys_to_virt<br /> handling for the initial ramdisk until after calling paging_init().<br /> <br /> While at it, reduce #ifdef clutter by using IS_ENABLED() instead.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/mlx4: Prevent shift wrapping in set_user_sq_size()<br /> <br /> The ucmd-&gt;log_sq_bb_count variable is controlled by the user so this<br /> shift can wrap. Fix it by using check_shl_overflow() in the same way<br /> that it was done in commit 515f60004ed9 ("RDMA/hns: Prevent undefined<br /> behavior in hns_roce_set_user_sq_size()").

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.

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

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().

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

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

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")

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 ]---