CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2022-48788 – nvme-rdma: fix possible use-after-free in transport error_recovery work
https://notcve.org/view.php?id=CVE-2022-48788
In the Linux kernel, the following vulnerability has been resolved: nvme-rdma: fix possible use-after-free in transport error_recovery work While nvme_rdma_submit_async_event_work is checking the ctrl and queue state before preparing the AER command and scheduling io_work, in order to fully prevent a race where this check is not reliable the error recovery work must flush async_event_work before continuing to destroy the admin queue after setting the ctrl state to RESETTING such that there is no race .submit_async_event and the error recovery handler itself changing the ctrl state. • https://git.kernel.org/stable/c/5593f72d1922403c11749532e3a0aa4cf61414e9 https://git.kernel.org/stable/c/d411b2a5da68b8a130c23097014434ac140a2ace https://git.kernel.org/stable/c/324f5bdc52ecb6a6dadb31a62823ef8c709d1439 https://git.kernel.org/stable/c/646952b2210f19e584d2bf9eb5d092abdca2fcc1 https://git.kernel.org/stable/c/ea86027ac467a055849c4945906f799e7f65ab99 https://git.kernel.org/stable/c/b6bb1722f34bbdbabed27acdceaf585d300c5fd2 •
CVSS: 4.4EPSS: 0%CPEs: 8EXPL: 0CVE-2022-48786 – vsock: remove vsock from connected table when connect is interrupted by a signal
https://notcve.org/view.php?id=CVE-2022-48786
In the Linux kernel, the following vulnerability has been resolved: vsock: remove vsock from connected table when connect is interrupted by a signal vsock_connect() expects that the socket could already be in the TCP_ESTABLISHED state when the connecting task wakes up with a signal pending. If this happens the socket will be in the connected table, and it is not removed when the socket state is reset. In this situation it's common for the process to retry connect(), and if the connection is successful the socket will be added to the connected table a second time, corrupting the list. Prevent this by calling vsock_remove_connected() if a signal is received while waiting for a connection. This is harmless if the socket is not in the connected table, and if it is in the table then removing it will prevent list corruption from a double add. Note for backporting: this patch requires d5afa82c977e ("vsock: correct removal of socket from the list"), which is in all current stable trees except 4.9.y. • https://git.kernel.org/stable/c/d021c344051af91f42c5ba9fdedc176740cbd238 https://git.kernel.org/stable/c/0bb88f3f7e8d506f3efe46d694964117e20efbfc https://git.kernel.org/stable/c/e3b3939fd137aab6d00d54bee0ee9244b286a608 https://git.kernel.org/stable/c/2910bcb9f67551a45397735e47b6d456eb8cd549 https://git.kernel.org/stable/c/5f326fe2aef411a6575628f92bd861463ea91df7 https://git.kernel.org/stable/c/87cd1bbd6677411e17369cd4b7389ab1e1fdba44 https://git.kernel.org/stable/c/787468ee7a435777521d33399d012fd591ae2f94 https://git.kernel.org/stable/c/addd62a8cb6fa90aa322365c62487da61 • CWE-371: State Issues •
CVSS: 3.3EPSS: 0%CPEs: 3EXPL: 0CVE-2021-47624 – net/sunrpc: fix reference count leaks in rpc_sysfs_xprt_state_change
https://notcve.org/view.php?id=CVE-2021-47624
In the Linux kernel, the following vulnerability has been resolved: net/sunrpc: fix reference count leaks in rpc_sysfs_xprt_state_change The refcount leak issues take place in an error handling path. When the 3rd argument buf doesn't match with "offline", "online" or "remove", the function simply returns -EINVAL and forgets to decrease the reference count of a rpc_xprt object and a rpc_xprt_switch object increased by rpc_sysfs_xprt_kobj_get_xprt() and rpc_sysfs_xprt_kobj_get_xprt_switch(), causing reference count leaks of both unused objects. Fix this issue by jumping to the error handling path labelled with out_put when buf matches none of "offline", "online" or "remove". A memory leak flaw was found in the Linux kernel’s SunRpc filesystem (sysfs). This flaw allows a local user to crash the system. • https://git.kernel.org/stable/c/4b22aa42bd4d2d630ef1854c139275c3532937cb https://git.kernel.org/stable/c/5f6024c05a2c0fdd180b29395aaf686d25af3a0f https://git.kernel.org/stable/c/776d794f28c95051bc70405a7b1fa40115658a18 https://access.redhat.com/security/cve/CVE-2021-47624 https://bugzilla.redhat.com/show_bug.cgi?id=2298108 • CWE-402: Transmission of Private Resources into a New Sphere ('Resource Leak') •
CVSS: 4.4EPSS: 0%CPEs: 4EXPL: 0CVE-2021-47623 – powerpc/fixmap: Fix VM debug warning on unmap
https://notcve.org/view.php?id=CVE-2021-47623
In the Linux kernel, the following vulnerability has been resolved: powerpc/fixmap: Fix VM debug warning on unmap Unmapping a fixmap entry is done by calling __set_fixmap() with FIXMAP_PAGE_CLEAR as flags. Today, powerpc __set_fixmap() calls map_kernel_page(). map_kernel_page() is not happy when called a second time for the same page. WARNING: CPU: 0 PID: 1 at arch/powerpc/mm/pgtable.c:194 set_pte_at+0xc/0x1e8 CPU: 0 PID: 1 Comm: swapper Not tainted 5.16.0-rc3-s3k-dev-01993-g350ff07feb7d-dirty #682 NIP: c0017cd4 LR: c00187f0 CTR: 00000010 REGS: e1011d50 TRAP: 0700 Not tainted (5.16.0-rc3-s3k-dev-01993-g350ff07feb7d-dirty) MSR: 00029032 <EE,ME,IR,DR,RI> CR: 42000208 XER: 00000000 GPR00: c0165fec e1011e10 c14c0000 c0ee2550 ff800000 c0f3d000 00000000 c001686c GPR08: 00001000 b00045a9 00000001 c0f58460 c0f50000 00000000 c0007e10 00000000 GPR16: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 GPR24: 00000000 00000000 c0ee2550 00000000 c0f57000 00000ff8 00000000 ff800000 NIP [c0017cd4] set_pte_at+0xc/0x1e8 LR [c00187f0] map_kernel_page+0x9c/0x100 Call Trace: [e1011e10] [c0736c68] vsnprintf+0x358/0x6c8 (unreliable) [e1011e30] [c0165fec] __set_fixmap+0x30/0x44 [e1011e40] [c0c13bdc] early_iounmap+0x11c/0x170 [e1011e70] [c0c06cb0] ioremap_legacy_serial_console+0x88/0xc0 [e1011e90] [c0c03634] do_one_initcall+0x80/0x178 [e1011ef0] [c0c0385c] kernel_init_freeable+0xb4/0x250 [e1011f20] [c0007e34] kernel_init+0x24/0x140 [e1011f30] [c0016268] ret_from_kernel_thread+0x5c/0x64 Instruction dump: 7fe3fb78 48019689 80010014 7c630034 83e1000c 5463d97e 7c0803a6 38210010 4e800020 81250000 712a0001 41820008 <0fe00000> 9421ffe0 93e1001c 48000030 Implement unmap_kernel_page() which clears an existing pte. • https://git.kernel.org/stable/c/67baac10dd5ad1e9f50e8f2659984b3b0728d54e https://git.kernel.org/stable/c/43ae0ccc4d2722b833fb59b905af129428e06d03 https://git.kernel.org/stable/c/033fd42c18d9b2121595b6f1e8419a115f9ac5b7 https://git.kernel.org/stable/c/aec982603aa8cc0a21143681feb5f60ecc69d718 https://access.redhat.com/security/cve/CVE-2021-47623 https://bugzilla.redhat.com/show_bug.cgi?id=2298107 • CWE-99: Improper Control of Resource Identifiers ('Resource Injection') •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2021-47622 – scsi: ufs: Fix a deadlock in the error handler
https://notcve.org/view.php?id=CVE-2021-47622
In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: Fix a deadlock in the error handler The following deadlock has been observed on a test setup: - All tags allocated - The SCSI error handler calls ufshcd_eh_host_reset_handler() - ufshcd_eh_host_reset_handler() queues work that calls ufshcd_err_handler() - ufshcd_err_handler() locks up as follows: Workqueue: ufs_eh_wq_0 ufshcd_err_handler.cfi_jt Call trace: __switch_to+0x298/0x5d8 __schedule+0x6cc/0xa94 schedule+0x12c/0x298 blk_mq_get_tag+0x210/0x480 __blk_mq_alloc_request+0x1c8/0x284 blk_get_request+0x74/0x134 ufshcd_exec_dev_cmd+0x68/0x640 ufshcd_verify_dev_init+0x68/0x35c ufshcd_probe_hba+0x12c/0x1cb8 ufshcd_host_reset_and_restore+0x88/0x254 ufshcd_reset_and_restore+0xd0/0x354 ufshcd_err_handler+0x408/0xc58 process_one_work+0x24c/0x66c worker_thread+0x3e8/0xa4c kthread+0x150/0x1b4 ret_from_fork+0x10/0x30 Fix this lockup by making ufshcd_exec_dev_cmd() allocate a reserved request. • https://git.kernel.org/stable/c/493c9e850677df8b4eda150c2364b1c1a72ed724 https://git.kernel.org/stable/c/d69d98d8edf90e25e4e09930dd36dd6d09dd6768 https://git.kernel.org/stable/c/945c3cca05d78351bba29fa65d93834cb7934c7b •