CVSS: 5.5EPSS: 0%CPEs: 3EXPL: 0CVE-2022-48793 – KVM: x86: nSVM: fix potential NULL derefernce on nested migration
https://notcve.org/view.php?id=CVE-2022-48793
In the Linux kernel, the following vulnerability has been resolved: KVM: x86: nSVM: fix potential NULL derefernce on nested migration Turns out that due to review feedback and/or rebases I accidentally moved the call to nested_svm_load_cr3 to be too early, before the NPT is enabled, which is very wrong to do. KVM can't even access guest memory at that point as nested NPT is needed for that, and of course it won't initialize the walk_mmu, which is main issue the patch was addressing. Fix this for real. A vulnerability was found in the nested.c file in the Linux kernel's KVM driver, where a potential NULL dereference can occur. This happens when the call to load the nested state is executed before Nested Page Tables (NPT) are enabled, preventing access to guest memory, lead to system instability and a denial of service during nested migration processes. • https://git.kernel.org/stable/c/232f75d3b4b5456de6f0b671aa86345d62de1473 https://git.kernel.org/stable/c/74b426bea4f7e3b081add2b88d4fba16d3af7ab6 https://git.kernel.org/stable/c/352193edda48e08e8824a7ece09aec830a603cfe https://git.kernel.org/stable/c/e1779c2714c3023e4629825762bcbc43a3b943df https://access.redhat.com/security/cve/CVE-2022-48793 https://bugzilla.redhat.com/show_bug.cgi?id=2298129 • CWE-476: NULL Pointer Dereference •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2022-48792 – scsi: pm8001: Fix use-after-free for aborted SSP/STP sas_task
https://notcve.org/view.php?id=CVE-2022-48792
In the Linux kernel, the following vulnerability has been resolved: scsi: pm8001: Fix use-after-free for aborted SSP/STP sas_task Currently a use-after-free may occur if a sas_task is aborted by the upper layer before we handle the I/O completion in mpi_ssp_completion() or mpi_sata_completion(). In this case, the following are the two steps in handling those I/O completions: - Call complete() to inform the upper layer handler of completion of the I/O. - Release driver resources associated with the sas_task in pm8001_ccb_task_free() call. When complete() is called, the upper layer may free the sas_task. As such, we should not touch the associated sas_task afterwards, but we do so in the pm8001_ccb_task_free() call. Fix by swapping the complete() and pm8001_ccb_task_free() calls ordering. • https://git.kernel.org/stable/c/fe9ac3eaa2e387a5742b380b73a5a6bc237bf184 https://git.kernel.org/stable/c/d9d93f32534a0a80a1c26bdb0746d90a7b19c2c2 https://git.kernel.org/stable/c/f61f9fccb2cb4bb275674a79d638704db6bc2171 https://git.kernel.org/stable/c/df7abcaa1246e2537ab4016077b5443bb3c09378 •
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 •