Patch "s390/qeth: fix NULL deref in qeth_clear_working_pool_list()" has been added to the 5.10-stable tree

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



This is a note to let you know that I've just added the patch titled

    s390/qeth: fix NULL deref in qeth_clear_working_pool_list()

to the 5.10-stable tree which can be found at:
    http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
     s390-qeth-fix-null-deref-in-qeth_clear_working_pool_.patch
and it can be found in the queue-5.10 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@xxxxxxxxxxxxxxx> know about it.



commit 44afeea40901165b55c38292448b6fa19e1a84a9
Author: Julian Wiedmann <jwi@xxxxxxxxxxxxx>
Date:   Tue Sep 21 16:52:15 2021 +0200

    s390/qeth: fix NULL deref in qeth_clear_working_pool_list()
    
    [ Upstream commit 248f064af222a1f97ee02c84a98013dfbccad386 ]
    
    When qeth_set_online() calls qeth_clear_working_pool_list() to roll
    back after an error exit from qeth_hardsetup_card(), we are at risk of
    accessing card->qdio.in_q before it was allocated by
    qeth_alloc_qdio_queues() via qeth_mpc_initialize().
    
    qeth_clear_working_pool_list() then dereferences NULL, and by writing to
    queue->bufs[i].pool_entry scribbles all over the CPU's lowcore.
    Resulting in a crash when those lowcore areas are used next (eg. on
    the next machine-check interrupt).
    
    Such a scenario would typically happen when the device is first set
    online and its queues aren't allocated yet. An early IO error or certain
    misconfigs (eg. mismatched transport mode, bad portno) then cause us to
    error out from qeth_hardsetup_card() with card->qdio.in_q still being
    NULL.
    
    Fix it by checking the pointer for NULL before accessing it.
    
    Note that we also have (rare) paths inside qeth_mpc_initialize() where
    a configuration change can cause us to free the existing queues,
    expecting that subsequent code will allocate them again. If we then
    error out before that re-allocation happens, the same bug occurs.
    
    Fixes: eff73e16ee11 ("s390/qeth: tolerate pre-filled RX buffer")
    Reported-by: Stefan Raspl <raspl@xxxxxxxxxxxxx>
    Root-caused-by: Heiko Carstens <hca@xxxxxxxxxxxxx>
    Signed-off-by: Julian Wiedmann <jwi@xxxxxxxxxxxxx>
    Reviewed-by: Alexandra Winter <wintera@xxxxxxxxxxxxx>
    Signed-off-by: Jakub Kicinski <kuba@xxxxxxxxxx>
    Signed-off-by: Sasha Levin <sashal@xxxxxxxxxx>

diff --git a/drivers/s390/net/qeth_core_main.c b/drivers/s390/net/qeth_core_main.c
index 4d51c4ace8ea..7b0155b0e99e 100644
--- a/drivers/s390/net/qeth_core_main.c
+++ b/drivers/s390/net/qeth_core_main.c
@@ -210,6 +210,9 @@ static void qeth_clear_working_pool_list(struct qeth_card *card)
 				 &card->qdio.in_buf_pool.entry_list, list)
 		list_del(&pool_entry->list);
 
+	if (!queue)
+		return;
+
 	for (i = 0; i < ARRAY_SIZE(queue->bufs); i++)
 		queue->bufs[i].pool_entry = NULL;
 }



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux