linux-kernel - Re: Question: consult patch

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] [day] [month] [year] [list]

Message-ID: <90e4f8ef-36af-02b6-3204-f68896af0ae9@huaweicloud.com>
Date:   Fri, 12 Aug 2022 17:39:42 +0800
From:   "zhangwensheng (E)" <zhangwensheng@...weicloud.com>
To:     Lee Jones <lee.jones@...aro.org>
Cc:     Christoph Hellwig <hch@...radead.org>,
        linux-kernel@...r.kernel.org, linux-block@...r.kernel.org,
        Lee Jones <lee@...nel.org>, yi.zhang@...wei.com
Subject: Re: Question: consult patch

thanks for your reply!

在 2022/8/12 15:38, zhangwensheng (E) 写道:
> Hi Lee
>
> I'm sorry I didn't fully understand you. did you mean the CVE
> was caused by a commit which was applied to an internal kernel
> version?  What commitment can be displayed? and I know that
> mainline do not have the problem because of some code refactoring,
> But are there any problems with some other stable branches?
>
> thank you very much!
> Wensheng
>
> 在 2022/8/12 15:26, Lee Jones 写道:
>> On Fri, 12 Aug 2022, zhangwensheng (E) wrote:
>>
>>> Hi
>>>
>>> In CVE list last week, there is a new cve reported in asop 4.14 like 
>>> below:
>>> Reference link: 
>>> https://lore.kernel.org/all/CAODzB9rgMexvLjE=WuTm+SN8SfUggaZgWG-aBcy6cotppju6mw@mail.gmail.com/T/
>>>
>>> ---
>>> CVE-2022-20158: mm: backing-dev: Take a reference to the bdi in use to
>>> prevent UAF
>>>
>>> CVSS v3 score is not assigned.
>>>
>>> AOSP kernel 4.14 contains following 2 patches.
>>> - 69e8f03c5ced3e4e6fb4181f4dac185104e3420b ("mm: backing-dev: Take a
>>> reference to the bdi in use to prevent UAF")
>>> - 80d91b86a199798ee2321a0ab0f09e6e12764678 ("fs: explicitly unregister
>>> per-superblock BDIs")
>>>
>>> The first commit 69e8f03("mm: backing-dev: Take a reference to the bdi
>>> in use to prevent UAF") is not merged in the mainline and stable
>>> kernels.
>>> Commit 80d91b8 was merged in 5.16-rc1(commit hash is
>>> 0b3ea0926afb8dde70cfab00316ae0a70b93a7cc) which requires commit
>>> c6fd3ac ("mm: export bdi_unregister") that exports symbol of
>>> bdi_unregister().
>>>
>>> Fixed status
>>> mainline: [0b3ea0926afb8dde70cfab00316ae0a70b93a7cc]
>>> ---
>>>
>>> As mentioned above, patch 69e8f03c5ced ("mm: backing-dev: Take a
>>> reference to the bdi in use to prevent UAF") in asop 4.14 can fix
>>> a null dereference problem, form my analysis, may like below:
>>>
>>> blk_cleanup_queue
>>>      blk_put_queue
>>>          kobject_put(&q->kobj)
>>>                  blk_release_queue
>>>                      blk_exit_queue
>>>                          bdi_put
>>>                              release_bdi  // bdi -> null
>>> del_gendisk
>>>      bdi_unregister(disk->queue->backing_dev_info) // null -> reference
>>>
>>>  From my analysis, In asop 4.14 kernel, in loop_remove function, 
>>> there is
>>> such a timing that executing "blk_cleanup_queue" first and then
>>> "del_gendisk".
>>> but because of the refcnt of queue will add by hte line
>>> "WARN_ON_ONCE(!blk_get_queue(disk->queue));" in "device_add_disk", 
>>> which may
>>> not result in "bdi_put" releasing bdi  in "blk_cleanup_queue".
>>>
>>> I'm not sure where the problem is, so I want to ask Lee Jones who 
>>> sent this
>>> patch
>>> for clarification.
>>>
>>> Thanks!
>>>
>>> Wensheng
>>>
>>> 在 2022/8/12 13:44, Christoph Hellwig 写道:
>>>> On Fri, Aug 12, 2022 at 11:34:59AM +0800, zhangwensheng (E) wrote:
>>>>> Hi Lee ：
>>>>>       I saw your patch because of CVE-2022-20158, the patch like 
>>>>> below:
>>>>>
>>>>> ---
>>>>>       mm: backing-dev: Take a reference to the bdi in use to 
>>>>> prevent UAF
>>>> I can't see that patch anywhere, and I've not seen an bug report 
>>>> for it.
>>>>
>>>>>       Because of a distinct lack of locking and/or reference taking,
>>>>>       blk_cleanup_queue() puts the final taken reference to the 
>>>>> bdi, which
>>>> .. and blk_cleanup_queue also is gone upstream.
>>>>
>>>> What am I missing?
>> The issue reported in the aforementioned CVE was caused by a commit
>> which was applied to an internal, device specific repository. One
>> that has never existed in Mainline.  I failed to reproduce the KASAN
>> report in any upstream or stable tree without the offending patch
>> applied.  The issue was fixed in all affected internal trees.
>>
>
> .