From: Greg KH <gregkh@linuxfoundation.org>
To: Yu Kuai <yukuai1@huaweicloud.com>
Cc: yangerkun@huawei.com, chuck.lever@oracle.com, brauner@kernel.org,
sashal@kernel.org, Coly Li <colyli@suse.de>,
"yukuai (C)" <yukuai3@huawei.com>,
linux-kernel@vger.kernel.org, cve@kernel.org
Subject: Re: CVE-2024-46701: libfs: fix infinite directory reads for offset dir
Date: Tue, 24 Sep 2024 11:03:36 +0200 [thread overview]
Message-ID: <2024092400-appointee-sensation-ddb1@gregkh> (raw)
In-Reply-To: <b378c634-102f-e115-e925-0a20dc450ff7@huaweicloud.com>
On Tue, Sep 24, 2024 at 03:35:33PM +0800, Yu Kuai wrote:
> Hi, all!
>
> This is a request to close this CVE.
>
> First of all, I think this really is not a kernel BUG, the deadloop
> only exist in user side and user must rename between each readdir
> syscall:
>
> while (readdr() > 0)
> rename()
Sounds like a real thing that users can do, so why does this not fit the
definition of "vulnerability" as documented by cve.org?
> On the other hand, v6.6 is affected by this CVE, and this fix can't
> be backported to v6.6 because the patchset [1] must be backported first
> to expand offset from 32-bit to 64-bit.(This kind of refactor will
> break kabi, hence it's not acceptable in our downstream kernels)
That's your business decision, and does not affect if we do, or do not,
assign a CVE at all. Go work with your management if you wish to change
this as it does not pertain to the community in any way.
thanks,
greg k-h
next parent reply other threads:[~2024-09-24 9:03 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <b378c634-102f-e115-e925-0a20dc450ff7@huaweicloud.com>
2024-09-24 9:03 ` Greg KH [this message]
2024-09-24 9:44 ` CVE-2024-46701: libfs: fix infinite directory reads for offset dir Yu Kuai
2024-09-24 12:13 ` Greg KH
2024-09-13 6:28 Greg Kroah-Hartman
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=2024092400-appointee-sensation-ddb1@gregkh \
--to=gregkh@linuxfoundation.org \
--cc=brauner@kernel.org \
--cc=chuck.lever@oracle.com \
--cc=colyli@suse.de \
--cc=cve@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=sashal@kernel.org \
--cc=yangerkun@huawei.com \
--cc=yukuai1@huaweicloud.com \
--cc=yukuai3@huawei.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.