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: 6.1EPSS: 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". • 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') •