From: "zhangxiaoxu (A)" <zhangxiaoxu5@huawei.com>
To: Lyu Tao <tao.lyu@epfl.ch>,
Trond Myklebust <trond.myklebust@hammerspace.com>
Cc: ChenXiaoSong <chenxiaosong2@huawei.com>,
yanaijie <yanaijie@huawei.com>,
"zhangyi (F)" <yi.zhang@huawei.com>,
Linux NFS Mailing List <linux-nfs@vger.kernel.org>,
Kashyap Sanidhya <sanidhya.kashyap@epfl.ch>,
"mathias.payer@nebelwelt.net" <mathias.payer@nebelwelt.net>
Subject: Re: Question about CVE-2022-24448
Date: Wed, 9 Feb 2022 19:28:03 +0800 [thread overview]
Message-ID: <6aba4c65-36df-62ab-e6c2-500489b61d6d@huawei.com> (raw)
In-Reply-To: <4e965ca75c4c4b70ac3322c39873d418@epfl.ch>
在 2022/2/8 20:31, Lyu Tao 写道:
>
> Hi Xiaoxu,
>
> I only know about the question 2 and 4.
>
> 2. When the kernel executes nfs4_valid_open_stateid, the state is zero. Then it enters into the inline function nfs4_valid_open_stateid, and executes a dereference operation.
>
> /int nfs4_select_rw_stateid(struct nfs4_state *state,
> fmode_t fmode, const struct nfs_lock_context *l_ctx,
> nfs4_stateid *dst, const struct cred **cred)
> {
> ...
> if (!nfs4_valid_open_stateid(state))
> return -EIO;
> ...
> }
>
> static inline bool nfs4_valid_open_stateid(const struct nfs4_state *state)
> {
> return test_bit(NFS_STATE_RECOVERY_FAILED, &state->flags) == 0;
> }/
how it happend? do you have the panic stacks?
when 'nfs_atomic_open' returned, the 'do_open' always checked the dentry type,
if not directory, it will return -ENOTDIR.
path_openat
alloc_empty_file
__alloc_file
atomic_long_set(&f->f_count, 1);
open_last_lookups
lookup_open
file->f_mode &= ~FMODE_CREATED;
atomic_open
nfs_atomic_open
goto no_open; # open_flags & O_DIRECTORY
nfs_lookup
do_open
if ((nd->flags & LOOKUP_DIRECTORY) && !d_can_lookup(nd->path.dentry))
return -ENOTDIR;
# will return error here, how call the 'nfs4_select_rw_stateid' with ctx->state = NULL?
fput
>
> 4. The PoC is attached.
i create file1 on nfs mount point and run the poc, no nullptr derference occured.
Also, there no O_DIRECTORY flag set when call 'open/openat' syscall.
[root@fedora mnt]# ll
total 24
---------- 1 root root 0 Feb 9 06:11 file1
-rwxr-xr-x 1 root root 24440 Feb 9 06:05 poc
[root@fedora mnt]# strace -e trace=open,openat ./poc
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/lib64/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "./file1", O_RDWR|O_CREAT, 000) = 3
open("./file1", O_ACCMODE|O_CREAT|O_DIRECT|O_LARGEFILE|O_NOFOLLOW|O_NOATIME|O_CLOEXEC|FASYNC|0xb3000008, 001) = 4
+++ exited with 0 +++
>
> Best,
> Tao
>
> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> *From:* zhangxiaoxu (A) <zhangxiaoxu5@huawei.com>
> *Sent:* Tuesday, February 8, 2022 12:48:58 PM
> *To:* Lyu Tao; Trond Myklebust
> *Cc:* ChenXiaoSong; yanaijie; zhangyi (F); Linux NFS Mailing List
> *Subject:* Question about CVE-2022-24448
> Hi Trond and Tao,
>
> I have some question about CVE-2022-24448[1].
>
> It's description as:
> An issue was discovered in fs/nfs/dir.c in the Linux kernel before 5.16.5.
> If an application sets the O_DIRECTORY flag, and tries to open a regular
> file, nfs_atomic_open() performs a regular lookup. If a regular file is
> found, ENOTDIR should occur, but the server instead returns uninitialized
> data in the file descriptor.
>
> It's fixed by ac795161c936 ("NFSv4: Handle case where the lookup of a directory fails")
>
> When try to open a regular file with O_DIRECTORY flag,
> it always return -ENOTDIR to userspace rather than a
> valid file descriptor because the 'do_open' check the
> dentry type.
>
> My questions are:
> 1. which uninitialized data in the file description are returned from 'nfs_atomic_open'?
> 2. where use the uninitialized data?
> 3. which uninitialized data are returned from server?
> 4. is there a PoC reproducer or how to trigger it?
>
>
> [1] https://nvd.nist.gov/vuln/detail/CVE-2022-24448 <https://nvd.nist.gov/vuln/detail/CVE-2022-24448>
prev parent reply other threads:[~2022-02-09 12:07 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-08 11:48 Question about CVE-2022-24448 zhangxiaoxu (A)
[not found] ` <4e965ca75c4c4b70ac3322c39873d418@epfl.ch>
2022-02-09 11:28 ` zhangxiaoxu (A) [this message]
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=6aba4c65-36df-62ab-e6c2-500489b61d6d@huawei.com \
--to=zhangxiaoxu5@huawei.com \
--cc=chenxiaosong2@huawei.com \
--cc=linux-nfs@vger.kernel.org \
--cc=mathias.payer@nebelwelt.net \
--cc=sanidhya.kashyap@epfl.ch \
--cc=tao.lyu@epfl.ch \
--cc=trond.myklebust@hammerspace.com \
--cc=yanaijie@huawei.com \
--cc=yi.zhang@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox