linux-kernel - Re: [Bug 206175] Fedora >= 5.4 kernels instantly freeze on boot without producing any display output

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <eadd21f1-c618-9523-fa14-e862dfa256ac@arm.com>
Date:   Wed, 11 Mar 2020 16:15:31 +0000
From:   Robin Murphy <robin.murphy@....com>
To:     "Artem S. Tashkinov" <aros@....com>, Christoph Hellwig <hch@....de>
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        iommu@...ts.linux-foundation.org,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        linux-kernel@...r.kernel.org
Subject: Re: [Bug 206175] Fedora >= 5.4 kernels instantly freeze on boot
 without producing any display output

On 11/03/2020 4:02 pm, Artem S. Tashkinov wrote:
> On 3/11/20 3:47 PM, Christoph Hellwig wrote:
>> And actually one more idea after looking at what slab interactions
>> could exist.  platform_device_register_full frees the dma_mask
>> unconditionally, even if it didn't allocated it, which might lead
>> to weird memory corruption if we hit the failure path.  So let's try
>> something like this, replacing the earlier patch in that file.
>>
>> diff --git a/drivers/base/platform.c b/drivers/base/platform.c
>> index b230beb6ccb4..04080a8d94e2 100644
>> --- a/drivers/base/platform.c
>> +++ b/drivers/base/platform.c
>> @@ -632,19 +632,6 @@ struct platform_device 
>> *platform_device_register_full(
>>       pdev->dev.of_node_reused = pdevinfo->of_node_reused;
>>
>>       if (pdevinfo->dma_mask) {
>> -        /*
>> -         * This memory isn't freed when the device is put,
>> -         * I don't have a nice idea for that though.  Conceptually
>> -         * dma_mask in struct device should not be a pointer.
>> -         * See http://thread.gmane.org/gmane.linux.kernel.pci/9081
>> -         */
>> -        pdev->dev.dma_mask =
>> -            kmalloc(sizeof(*pdev->dev.dma_mask), GFP_KERNEL);
>> -        if (!pdev->dev.dma_mask)
>> -            goto err;
>> -
>> -        kmemleak_ignore(pdev->dev.dma_mask);
>> -
>>           *pdev->dev.dma_mask = pdevinfo->dma_mask;
>>           pdev->dev.coherent_dma_mask = pdevinfo->dma_mask;
>>       }
>> @@ -670,7 +657,6 @@ struct platform_device 
>> *platform_device_register_full(
>>       if (ret) {
>>   err:
>>           ACPI_COMPANION_SET(&pdev->dev, NULL);
>> -        kfree(pdev->dev.dma_mask);
>>           platform_device_put(pdev);
>>           return ERR_PTR(ret);
>>       }
>>
> 
> With this patch the system works (I haven't created an initrd, so it
> doesn't completely boot and panics on not being able to mount root fs
> but that's expected).

Yup, a few lines earlier in the log you can see the wdat_wdt driver 
failing in platform_device_add(), which since it called into 
platform_device_register_full() with pdevinfo.dma_mask = 0, will have 
unwound into that kfree() of pdev.dma_mask corrupting the heap.

Robin.