在 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@xxxxxxxxxx>
*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>
