CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2022-48791 – scsi: pm8001: Fix use-after-free for aborted TMF sas_task
https://notcve.org/view.php?id=CVE-2022-48791
In the Linux kernel, the following vulnerability has been resolved: scsi: pm8001: Fix use-after-free for aborted TMF sas_task Currently a use-after-free may occur if a TMF sas_task is aborted before we handle the IO completion in mpi_ssp_completion(). The abort occurs due to timeout. When the timeout occurs, the SAS_TASK_STATE_ABORTED flag is set and the sas_task is freed in pm8001_exec_internal_tmf_task(). However, if the I/O completion occurs later, the I/O completion still thinks that the sas_task is available. Fix this by clearing the ccb->task if the TMF times out - the I/O completion handler does nothing if this pointer is cleared. • https://git.kernel.org/stable/c/d872e7b5fe38f325f5206b6872746fa02c2b4819 https://git.kernel.org/stable/c/3c334cdfd94945b8edb94022a0371a8665b17366 https://git.kernel.org/stable/c/510b21442c3a2e3ecc071ba3e666b320e7acdd61 https://git.kernel.org/stable/c/61f162aa4381845acbdc7f2be4dfb694d027c018 •
CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2022-48790 – nvme: fix a possible use-after-free in controller reset during load
https://notcve.org/view.php?id=CVE-2022-48790
In the Linux kernel, the following vulnerability has been resolved: nvme: fix a possible use-after-free in controller reset during load Unlike .queue_rq, in .submit_async_event drivers may not check the ctrl readiness for AER submission. This may lead to a use-after-free condition that was observed with nvme-tcp. The race condition may happen in the following scenario: 1. driver executes its reset_ctrl_work 2. -> nvme_stop_ctrl - flushes ctrl async_event_work 3. ctrl sends AEN which is received by the host, which in turn schedules AEN handling 4. teardown admin queue (which releases the queue socket) 5. AEN processed, submits another AER, calling the driver to submit 6. driver attempts to send the cmd ==> use-after-free In order to fix that, add ctrl state check to validate the ctrl is actually able to accept the AER submission. This addresses the above race in controller resets because the driver during teardown should: 1. change ctrl state to RESETTING 2. flush async_event_work (as well as other async work elements) So after 1,2, any other AER command will find the ctrl state to be RESETTING and bail out without submitting the AER. • https://git.kernel.org/stable/c/a25e460fbb0340488d119fb2e28fe3f829b7417e https://git.kernel.org/stable/c/70356b756a58704e5c8818cb09da5854af87e765 https://git.kernel.org/stable/c/0ead57ceb21bbf15963b4874c2ac67143455382f https://git.kernel.org/stable/c/e043fb5a0336ee74614e26f0d9f36f1f5bb6d606 https://git.kernel.org/stable/c/9e956a2596ae276124ef0d96829c013dd0faf861 https://git.kernel.org/stable/c/0fa0f99fc84e41057cbdd2efbfe91c6b2f47dd9d •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2022-48789 – nvme-tcp: fix possible use-after-free in transport error_recovery work
https://notcve.org/view.php?id=CVE-2022-48789
In the Linux kernel, the following vulnerability has been resolved: nvme-tcp: fix possible use-after-free in transport error_recovery work While nvme_tcp_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/61a26ffd5ad3ece456d74c4c79f7b5e3f440a141 https://git.kernel.org/stable/c/e192184cf8bce8dd55d619f5611a2eaba996fa05 https://git.kernel.org/stable/c/5e42fca37ccc76f39f73732661bd47254cad5982 https://git.kernel.org/stable/c/bb0d8fb35c4ff00a503c2c4dca4cce8d102a21c4 https://git.kernel.org/stable/c/ff9fc7ebf5c06de1ef72a69f9b1ab40af8b07f9e •
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 •