mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "zhangwensheng (E)" <zhangwensheng@huaweicloud.com>
To: Lee Jones <lee.jones@linaro.org>
Cc: Christoph Hellwig <hch@infradead.org>,
	linux-kernel@vger.kernel.org, linux-block@vger.kernel.org,
	Lee Jones <lee@kernel.org>
Subject: Re: Question: consult patch
Date: Fri, 12 Aug 2022 15:38:55 +0800	[thread overview]
Message-ID: <f179ff36-e511-1bad-078f-71b8b19d404e@huaweicloud.com> (raw)
In-Reply-To: <YvYAmmaJgvydex4p@google.com>

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.
>


  reply	other threads:[~2022-08-12  7:39 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-12  3:34 zhangwensheng (E)
2022-08-12  5:44 ` Christoph Hellwig
2022-08-12  6:27   ` zhangwensheng (E)
2022-08-12  7:26     ` Lee Jones
2022-08-12  7:38       ` zhangwensheng (E) [this message]
2022-08-12  9:31         ` Lee Jones
2022-08-12  9:39         ` zhangwensheng (E)

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=f179ff36-e511-1bad-078f-71b8b19d404e@huaweicloud.com \
    --to=zhangwensheng@huaweicloud.com \
    --cc=hch@infradead.org \
    --cc=lee.jones@linaro.org \
    --cc=lee@kernel.org \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®