CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2022-48795 – parisc: Fix data TLB miss in sba_unmap_sg
https://notcve.org/view.php?id=CVE-2022-48795
In the Linux kernel, the following vulnerability has been resolved: parisc: Fix data TLB miss in sba_unmap_sg Rolf Eike Beer reported the following bug: [1274934.746891] Bad Address (null pointer deref?): Code=15 (Data TLB miss fault) at addr 0000004140000018 [1274934.746891] CPU: 3 PID: 5549 Comm: cmake Not tainted 5.15.4-gentoo-parisc64 #4 [1274934.746891] Hardware name: 9000/785/C8000 [1274934.746891] [1274934.746891] YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI [1274934.746891] PSW: 00001000000001001111111000001110 Not tainted [1274934.746891] r00-03 000000ff0804fe0e 0000000040bc9bc0 00000000406760e4 0000004140000000 [1274934.746891] r04-07 0000000040b693c0 0000004140000000 000000004a2b08b0 0000000000000001 [1274934.746891] r08-11 0000000041f98810 0000000000000000 000000004a0a7000 0000000000000001 [1274934.746891] r12-15 0000000040bddbc0 0000000040c0cbc0 0000000040bddbc0 0000000040bddbc0 [1274934.746891] r16-19 0000000040bde3c0 0000000040bddbc0 0000000040bde3c0 0000000000000007 [1274934.746891] r20-23 0000000000000006 000000004a368950 0000000000000000 0000000000000001 [1274934.746891] r24-27 0000000000001fff 000000000800000e 000000004a1710f0 0000000040b693c0 [1274934.746891] r28-31 0000000000000001 0000000041f988b0 0000000041f98840 000000004a171118 [1274934.746891] sr00-03 00000000066e5800 0000000000000000 0000000000000000 00000000066e5800 [1274934.746891] sr04-07 0000000000000000 0000000000000000 0000000000000000 0000000000000000 [1274934.746891] [1274934.746891] IASQ: 0000000000000000 0000000000000000 IAOQ: 00000000406760e8 00000000406760ec [1274934.746891] IIR: 48780030 ISR: 0000000000000000 IOR: 0000004140000018 [1274934.746891] CPU: 3 CR30: 00000040e3a9c000 CR31: ffffffffffffffff [1274934.746891] ORIG_R28: 0000000040acdd58 [1274934.746891] IAOQ[0]: sba_unmap_sg+0xb0/0x118 [1274934.746891] IAOQ[1]: sba_unmap_sg+0xb4/0x118 [1274934.746891] RP(r2): sba_unmap_sg+0xac/0x118 [1274934.746891] Backtrace: [1274934.746891] [<00000000402740cc>] dma_unmap_sg_attrs+0x6c/0x70 [1274934.746891] [<000000004074d6bc>] scsi_dma_unmap+0x54/0x60 [1274934.746891] [<00000000407a3488>] mptscsih_io_done+0x150/0xd70 [1274934.746891] [<0000000040798600>] mpt_interrupt+0x168/0xa68 [1274934.746891] [<0000000040255a48>] __handle_irq_event_percpu+0xc8/0x278 [1274934.746891] [<0000000040255c34>] handle_irq_event_percpu+0x3c/0xd8 [1274934.746891] [<000000004025ecb4>] handle_percpu_irq+0xb4/0xf0 [1274934.746891] [<00000000402548e0>] generic_handle_irq+0x50/0x70 [1274934.746891] [<000000004019a254>] call_on_stack+0x18/0x24 [1274934.746891] [1274934.746891] Kernel panic - not syncing: Bad Address (null pointer deref?) The bug is caused by overrunning the sglist and incorrectly testing sg_dma_len(sglist) before nents. Normally this doesn't cause a crash, but in this case sglist crossed a page boundary. This occurs in the following code: while (sg_dma_len(sglist) && nents--) { The fix is simply to test nents first and move the decrement of nents into the loop. • https://git.kernel.org/stable/c/f23f0444ead4d941165aa82ce2fcbb997dc00e97 https://git.kernel.org/stable/c/de75676ee99bf9f25b1124ff301b3f7b8ba597d4 https://git.kernel.org/stable/c/867e50231c7605547d9334904d70a181f39f2d9e https://git.kernel.org/stable/c/efccc9b0c7e28d0eb7918a236e59f60dc23db4c3 https://git.kernel.org/stable/c/f8f519d7df66c334b5e08f896ac70ee3b53add3b https://git.kernel.org/stable/c/8c8e949ae81e7f5ab58f9f9f8e9b573b93173dd2 https://git.kernel.org/stable/c/e40ae3133ed87d6d526f3c8fc6a5f9a2d72dcdbf https://git.kernel.org/stable/c/b7d6f44a0fa716a82969725516dc0b16b •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2022-48794 – net: ieee802154: at86rf230: Stop leaking skb's
https://notcve.org/view.php?id=CVE-2022-48794
In the Linux kernel, the following vulnerability has been resolved: net: ieee802154: at86rf230: Stop leaking skb's Upon error the ieee802154_xmit_complete() helper is not called. Only ieee802154_wake_queue() is called manually. In the Tx case we then leak the skb structure. Free the skb structure upon error before returning when appropriate. As the 'is_tx = 0' cannot be moved in the complete handler because of a possible race between the delay in switching to STATE_RX_AACK_ON and a new interrupt, we introduce an intermediate 'was_tx' boolean just for this purpose. There is no Fixes tag applying here, many changes have been made on this area and the issue kind of always existed. • https://git.kernel.org/stable/c/d2a1eaf51b7d4412319adb6acef114ba472d1692 https://git.kernel.org/stable/c/af649e5c95f56df64363bc46f6746b87819f9c0d https://git.kernel.org/stable/c/6312f6a53fd3ea38125dcaca5e3c9aa7d8a60cf7 https://git.kernel.org/stable/c/455ef08d6e5473526fa6763f75a93f7198206966 https://git.kernel.org/stable/c/0fd484644c68897c490a3307bfcc8bf767df5a43 https://git.kernel.org/stable/c/23b2a25382400168427ea278f3d8bf4ecfd333bf https://git.kernel.org/stable/c/1c72f04d52b7200bb83426a9bed378668271ea4a https://git.kernel.org/stable/c/e5ce576d45bf72fd0e3dc37eff897bfcc •
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 •