This series fixes following bugs:
When lseek() a file secondly opened with O_ACCMODE|O_DIRECT flags,
nfs4_valid_open_stateid() will dereference NULL nfs4_state.
open() with O_ACCMODE|O_DIRECT flags secondly will fail.
ChenXiaoSong (2):
Revert "NFSv4: Handle the special Linux file open access mode"
NFSv4: fix open failure with O_ACCMODE flag
fs/nfs/dir.c | 10 ----------
fs/nfs/inode.c | 1 -
fs/nfs/internal.h | 10 ++++++++++
fs/nfs/nfs4file.c | 6 ++++--
4 files changed, 14 insertions(+), 13 deletions(-)
--
2.31.1
This reverts commit 44942b4e457beda00981f616402a1a791e8c616e.
After secondly opening a file with O_ACCMODE|O_DIRECT flags,
nfs4_valid_open_stateid() will dereference NULL nfs4_state when lseek().
Reproducer:
1. mount -t nfs -o vers=4.2 $server_ip:/ /mnt/
2. fd = open("/mnt/file", O_ACCMODE|O_DIRECT|O_CREAT)
3. close(fd)
4. fd = open("/mnt/file", O_ACCMODE|O_DIRECT)
5. lseek(fd)
Reported-by: Lyu Tao <[email protected]>
Signed-off-by: ChenXiaoSong <[email protected]>
---
fs/nfs/inode.c | 1 -
fs/nfs/nfs4file.c | 2 +-
2 files changed, 1 insertion(+), 2 deletions(-)
diff --git a/fs/nfs/inode.c b/fs/nfs/inode.c
index 3351c2de3e08..bb91b228f1e5 100644
--- a/fs/nfs/inode.c
+++ b/fs/nfs/inode.c
@@ -1180,7 +1180,6 @@ int nfs_open(struct inode *inode, struct file *filp)
nfs_fscache_open_file(inode, filp);
return 0;
}
-EXPORT_SYMBOL_GPL(nfs_open);
/*
* This function is called whenever some part of NFS notices that
diff --git a/fs/nfs/nfs4file.c b/fs/nfs/nfs4file.c
index e79ae4cbc395..c178db86a6e8 100644
--- a/fs/nfs/nfs4file.c
+++ b/fs/nfs/nfs4file.c
@@ -51,7 +51,7 @@ nfs4_file_open(struct inode *inode, struct file *filp)
return err;
if ((openflags & O_ACCMODE) == 3)
- return nfs_open(inode, filp);
+ openflags--;
/* We can't create new files here */
openflags &= ~(O_CREAT|O_EXCL);
--
2.31.1
在 2022/4/13 21:42, chenxiaosong (A) 写道:
>
> 在 2022/4/13 20:07, Lyu Tao 写道:
>>
>> Hi Xiaosong,
>>
>>
>> Thanks for keeping focusing on this bug.
>>
>>
>> I applied this CVE for the NULL dereference bug at
>> nfs4_valid_open_stateid() and added the following description to this
>> CVE due to the NFS maintainers replied that to me.
>>
>> "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.
>>
>>
>> Actually I'm still confused with the root cause of this bug. In the
>> original PoC, there is no O_DIRECTORY flag but commit ac795161c936
>> mentioned.
>>
>> Moreover, in your latest commit ab0fc21bc710, it said "After secondly
>> opening a file with O_ACCMODE|O_DIRECT flags,
>> nfs4_valid_open_stateid() will dereference NULL nfs4_state when
>> lseek()." However, the original PoC opens the file only with
>> O_RDWR|O_CREAT for the first time.
>>
>>
>> Original PoC:
>>
>> fd = openat("./file1", o_RDWR|O_CREAT, 000);
>>
>> open("./file1",
>> O_ACCMODE|O_CREAT|O_DIRECT|O_LARGEFILE|O_NOFOLLOW|O_NOATIME|O_CLOEXEC|FASYNC|0xb3000008,
>> 001);
>>
>> lseek(fd, 9, SEEK_HOLE);
>>
>>
>> I'll update this CVE's description after I figure out these.
>>
>>
>> Best Regards,
>>
>> Tao
>>
>
> Hi Tao:
>
> Yes, O_ACCEMODE is _not_ necessary when fistly open() file.
>
> When open() the file secondly, O_ACCEMODE is necessary if we want to
> reproduce the bug.
>
> Waiting for your modification of the CVE's description.
>
> Best Regards.
> .
My reproducer:
1. mount -t nfs -o vers=4.2 $server_ip:/ /mnt/
2. fd = open("/mnt/file", O_ACCMODE|O_DIRECT|O_CREAT)
3. close(fd)
4. fd = open("/mnt/file", O_ACCMODE|O_DIRECT)
5. lseek(fd)
When firstly open() file, O_ACCMODE|O_DIRECT is _not_ necessary, we just
use O_CREAT to create new file.
When secondly open() file, only O_ACCMODE|O_DIRECT is necessary,
O_CREAT|O_LARGEFILE|O_NOFOLLOW|O_NOATIME|O_CLOEXEC|FASYNC|0xb3000008 in
your original PoC is not necessary (however, they are harmless).
I will give some detailed code process.
firstly open():
```c
open
do_sys_open
do_sys_openat2
do_filp_open
path_openat
open_last_lookups
lookup_open
atomic_open
nfs_atomic_open
create_nfs_open_context
flags_to_mode() = FMODE_READ|FMODE_WRITE
alloc_nfs_open_context
ctx->mode = f_mode // FMODE_READ|FMODE_WRITE
// NFS_PROTO(dir)->open_context
nfs4_atomic_open
nfs4_do_open
_nfs4_do_open
fmode = _nfs4_ctx_to_openmode(ctx) = 3
ret = ctx->mode & (FMODE_READ|FMODE_WRITE) //
ctx->mode = 3
nfs4_opendata_alloc
nfs4_map_atomic_open_share
return NFS4_SHARE_ACCESS_BOTH
```
secondly open():
```c
open
do_sys_open
do_sys_openat2
do_filp_open
path_openat
open_last_lookups
lookup_open
return dentry // if (dentry->d_inode) {
do_open
vfs_open
do_dentry_open
// f->f_op->open
nfs4_file_open
if ((openflags & O_ACCMODE) == 3)
nfs_open // without sunrpc request
alloc_nfs_open_context
ctx->state = NULL; // this is point
```
lseek() after secondly open():
```c
lseek
ksys_lseek
vfs_llseek
// file->f_op->llseek
nfs4_file_llseek
nfs42_proc_llseek
_nfs42_proc_llseek(lock)
nfs4_set_rw_stateid(ctx=lock->open_context)
nfs4_select_rw_stateid(state=ctx->state)
nfs4_valid_open_stateid(state)
state->flags // dereference NULL state
```
在 2022/4/13 22:05, chenxiaosong (A) 写道:
> 在 2022/4/13 21:42, chenxiaosong (A) 写道:
>>
>> 在 2022/4/13 20:07, Lyu Tao 写道:
>>>
>>> Hi Xiaosong,
>>>
>>>
>>> Thanks for keeping focusing on this bug.
>>>
>>>
>>> I applied this CVE for the NULL dereference bug at
>>> nfs4_valid_open_stateid() and added the following description to this
>>> CVE due to the NFS maintainers replied that to me.
>>>
>>> "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.
>>>
>>>
>>> Actually I'm still confused with the root cause of this bug. In the
>>> original PoC, there is no O_DIRECTORY flag but commit ac795161c936
>>> mentioned.
>>>
>>> Moreover, in your latest commit ab0fc21bc710, it said "After secondly
>>> opening a file with O_ACCMODE|O_DIRECT flags,
>>> nfs4_valid_open_stateid() will dereference NULL nfs4_state when
>>> lseek()." However, the original PoC opens the file only with
>>> O_RDWR|O_CREAT for the first time.
>>>
>>>
>>> Original PoC:
>>>
>>> fd = openat("./file1", o_RDWR|O_CREAT, 000);
>>>
>>> open("./file1",
>>> O_ACCMODE|O_CREAT|O_DIRECT|O_LARGEFILE|O_NOFOLLOW|O_NOATIME|O_CLOEXEC|FASYNC|0xb3000008,
>>> 001);
>>>
>>> lseek(fd, 9, SEEK_HOLE);
>>>
>>>
>>> I'll update this CVE's description after I figure out these.
>>>
>>>
>>> Best Regards,
>>>
>>> Tao
>>>
>>
>> Hi Tao:
>>
>> Yes, O_ACCEMODE is _not_ necessary when fistly open() file.
>>
>> When open() the file secondly, O_ACCEMODE is necessary if we want to
>> reproduce the bug.
>>
>> Waiting for your modification of the CVE's description.
>>
>> Best Regards.
>> .
>
> My reproducer:
> 1. mount -t nfs -o vers=4.2 $server_ip:/ /mnt/
> 2. fd = open("/mnt/file", O_ACCMODE|O_DIRECT|O_CREAT)
> 3. close(fd)
> 4. fd = open("/mnt/file", O_ACCMODE|O_DIRECT)
> 5. lseek(fd)
>
> When firstly open() file, O_ACCMODE|O_DIRECT is _not_ necessary, we just
> use O_CREAT to create new file.
>
> When secondly open() file, only O_ACCMODE|O_DIRECT is necessary,
> O_CREAT|O_LARGEFILE|O_NOFOLLOW|O_NOATIME|O_CLOEXEC|FASYNC|0xb3000008 in
> your original PoC is not necessary (however, they are harmless).
在 2022/4/13 22:16, Lyu Tao 写道:
> Got it. Thanks!
>
>
> By the way, is this bug related to commit ac795161c936? Or have you
> tested NFS using your PoC on the version only with commit ab0fc21bc710
> (without commit ac795161c936).
>
>
> Best,
>
> Tao
>
I am also confused ac795161c936 ("NFSv4: Handle case where the lookup of
a directory fails"), this bug reported by you is not related it, I don't
know why Trond create this patch.
在 2022/4/13 20:07, Lyu Tao 写道:
>
> Hi Xiaosong,
>
>
> Thanks for keeping focusing on this bug.
>
>
> I applied this CVE for the NULL dereference bug at
> nfs4_valid_open_stateid() and added the following description to this
> CVE due to the NFS maintainers replied that to me.
>
> "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.
>
>
> Actually I'm still confused with the root cause of this bug. In the
> original PoC, there is no O_DIRECTORY flag but commit ac795161c936
> mentioned.
>
> Moreover, in your latest commit ab0fc21bc710, it said "After secondly
> opening a file with O_ACCMODE|O_DIRECT flags, nfs4_valid_open_stateid()
> will dereference NULL nfs4_state when lseek()." However, the original
> PoC opens the file only with O_RDWR|O_CREAT for the first time.
>
>
> Original PoC:
>
> fd = openat("./file1", o_RDWR|O_CREAT, 000);
>
> open("./file1",
> O_ACCMODE|O_CREAT|O_DIRECT|O_LARGEFILE|O_NOFOLLOW|O_NOATIME|O_CLOEXEC|FASYNC|0xb3000008,
> 001);
>
> lseek(fd, 9, SEEK_HOLE);
>
>
> I'll update this CVE's description after I figure out these.
>
>
> Best Regards,
>
> Tao
>
Hi Tao:
Yes, O_ACCEMODE is _not_ necessary when fistly open() file.
When open() the file secondly, O_ACCEMODE is necessary if we want to
reproduce the bug.
Waiting for your modification of the CVE's description.
Best Regards.
From: chenxiaosong (A) <[email protected]>
Sent: Thursday, April 14, 2022 4:41 AM
To: Lyu Tao; Trond Myklebust; [email protected]; [email protected]
Cc: [email protected]; [email protected]; [email protected]; [email protected]; [email protected]
Subject: Re: [PATCH -next 0/2] fix nfsv4 bugs of opening with O_ACCMODE flag
>在 2022/4/13 23:32, Lyu Tao 写道:
>> Got it. Thank you for detailed explanation!
>>
>>
>> Best,
>>
>> Tao
>>
>
>By the way, it seems that the kernel mailing list will reject rich text
>format, your emails can not be seen in NFS mailing list.
>
>https://patchwork.kernel.org/project/linux-nfs/cover/[email protected]/
OK! Thanks for letting me know.
在 2022/4/13 23:32, Lyu Tao 写道:
> Got it. Thank you for detailed explanation!
>
>
> Best,
>
> Tao
>
By the way, it seems that the kernel mailing list will reject rich text
format, your emails can not be seen in NFS mailing list.
https://patchwork.kernel.org/project/linux-nfs/cover/[email protected]/
> From: chenxiaosong (A) <[email protected]>
> Sent: Thursday, May 5, 2022 4:48 AM
> To: Lyu Tao
> Cc: [email protected]; [email protected]; [email protected]; [email protected]; Trond Myklebust; [email protected]; [email protected]; [email protected]
> Subject: Re: [PATCH -next 0/2] fix nfsv4 bugs of opening with O_ACCMODE flag
?
> "NVD Last Modified" date of CVE-2022-24448 is updated as 04/29/2022, but the content of the cve is old.
> https://nvd.nist.gov/vuln/detail/CVE-2022-24448
Hi,
Thanks for reaching out.
I've requested to update the CVE description and they replied me that it would be updated yesterday. Maybe the system need some time to reflesh. Let's wait a few more days.
Best,
Tao
Hi Xiaosong,
I sent the first email on 05.05.2022 to [email protected] to require them update the description with the following information. They replied that they will update the information within that day. However, they didn't updated the description and then I sent the second email and they didn't reply me.
Do you know any other ways to update the description.
"I need to update the CVE description as below:
After secondly opening a file with O_ACCMODE|O_DIRECT flags, nfs4_valid_open_stateid() will dereference NULL nfs4_state when lseek().
And its references should be updated as this:
https://github.com/torvalds/linux/commit/ab0fc21bc7105b54bafd85bd8b82742f9e68898a "
Best,
Tao
>From: chenxiaosong (A) <[email protected]>
>Sent: Tuesday, May 31, 2022 8:40 AM
>To: Lyu Tao
>Cc: [email protected]; [email protected]; [email protected]; [email protected]; Trond Myklebust; [email protected]; [email protected]; [email protected]
>Subject: Re: [PATCH -next 0/2] fix nfsv4 bugs of opening with O_ACCMODE flag
>
>Hi Tao:
>
>"NVD Last Modified" date of
>[CVE-2022-24448](https://nvd.nist.gov/vuln/detail/CVE-2022-24448) is
>already updated to 05/12/2022, but the description of the cve is still
>wrong, and the hyperlink of [unrelated patch: NFSv4: Handle case where
>the lookup of a directory
>fails](https://github.com/torvalds/linux/commit/ac795161c93699d600db16c1a8cc23a65a1eceaf)
>is still shown in the web.
>
>There is two fix patches of the cve, the web just show one of my patches.
>
>one patch is already shown in the web: [Revert "NFSv4: Handle the
>special Linux file open access
>mode"](https://github.com/torvalds/linux/commit/ab0fc21bc7105b54bafd85bd8b82742f9e68898a)
>
>second patch is not shown in the web: [NFSv4: fix open failure with
>O_ACCMODE
>flag](https://github.com/torvalds/linux/commit/b243874f6f9568b2daf1a00e9222cacdc15e159c)
>
>$B:_(B 2022/5/6 15:40, Lyu Tao $B<LF;(B:
>>> From: chenxiaosong (A) <[email protected]>
>>> Sent: Thursday, May 5, 2022 4:48 AM
>>> To: Lyu Tao
>>> Cc: [email protected]; [email protected]; [email protected]; [email protected]; Trond Myklebust; [email protected]; [email protected]; [email protected]
>>> Subject: Re: [PATCH -next 0/2] fix nfsv4 bugs of opening with O_ACCMODE flag
>>
>>> "NVD Last Modified" date of CVE-2022-24448 is updated as 04/29/2022, but the content of the cve is old.
>>> https://nvd.nist.gov/vuln/detail/CVE-2022-24448
>>
>> Hi,
>>
>> Thanks for reaching out.
>>
>> I've requested to update the CVE description and they replied me that it would be updated yesterday. Maybe the system need some time to reflesh. Let's wait a few more days.
>>
>> Best,
>> Tao.
>>
I do not know other ways to update the description, you can try to send
email to [email protected] again.
在 2022/5/31 16:16, Lyu Tao 写道:
> Hi Xiaosong,
>
> I sent the first email on 05.05.2022 to [email protected] to require them update the description with the following information. They replied that they will update the information within that day. However, they didn't updated the description and then I sent the second email and they didn't reply me.
>
> Do you know any other ways to update the description.
>
>
> "I need to update the CVE description as below:
> After secondly opening a file with O_ACCMODE|O_DIRECT flags, nfs4_valid_open_stateid() will dereference NULL nfs4_state when lseek().
> And its references should be updated as this:
> https://github.com/torvalds/linux/commit/ab0fc21bc7105b54bafd85bd8b82742f9e68898a "
>
> Best,
> Tao
>
>> From: chenxiaosong (A) <[email protected]>
>> Sent: Tuesday, May 31, 2022 8:40 AM
>> To: Lyu Tao
>> Cc: [email protected]; [email protected]; [email protected]; [email protected]; Trond Myklebust; [email protected]; [email protected]; [email protected]
>> Subject: Re: [PATCH -next 0/2] fix nfsv4 bugs of opening with O_ACCMODE flag
>>
>> Hi Tao:
>>
>> "NVD Last Modified" date of
>> [CVE-2022-24448](https://nvd.nist.gov/vuln/detail/CVE-2022-24448) is
>> already updated to 05/12/2022, but the description of the cve is still
>> wrong, and the hyperlink of [unrelated patch: NFSv4: Handle case where
>> the lookup of a directory
>> fails](https://github.com/torvalds/linux/commit/ac795161c93699d600db16c1a8cc23a65a1eceaf)
>> is still shown in the web.
>>
>> There is two fix patches of the cve, the web just show one of my patches.
>>
>> one patch is already shown in the web: [Revert "NFSv4: Handle the
>> special Linux file open access
>> mode"](https://github.com/torvalds/linux/commit/ab0fc21bc7105b54bafd85bd8b82742f9e68898a)
>>
>> second patch is not shown in the web: [NFSv4: fix open failure with
>> O_ACCMODE
>> flag](https://github.com/torvalds/linux/commit/b243874f6f9568b2daf1a00e9222cacdc15e159c)
>>
>> 在 2022/5/6 15:40, Lyu Tao 写道:
>>>> From: chenxiaosong (A) <[email protected]>
>>>> Sent: Thursday, May 5, 2022 4:48 AM
>>>> To: Lyu Tao
>>>> Cc: [email protected]; [email protected]; [email protected]; [email protected]; Trond Myklebust; [email protected]; [email protected]; [email protected]
>>>> Subject: Re: [PATCH -next 0/2] fix nfsv4 bugs of opening with O_ACCMODE flag
>>>
>>>> "NVD Last Modified" date of CVE-2022-24448 is updated as 04/29/2022, but the content of the cve is old.
>>>> https://nvd.nist.gov/vuln/detail/CVE-2022-24448
>>>
>>> Hi,
>>>
>>> Thanks for reaching out.
>>>
>>> I've requested to update the CVE description and they replied me that it would be updated yesterday. Maybe the system need some time to reflesh. Let's wait a few more days.
>>>
>>> Best,
>>> Tao.
>>>
>
>
>
>
>
>
> .
>
Hi Tao:
"NVD Last Modified" date of
[CVE-2022-24448](https://nvd.nist.gov/vuln/detail/CVE-2022-24448) is
already updated to 05/12/2022, but the description of the cve is still
wrong, and the hyperlink of [unrelated patch: NFSv4: Handle case where
the lookup of a directory
fails](https://github.com/torvalds/linux/commit/ac795161c93699d600db16c1a8cc23a65a1eceaf)
is still shown in the web.
There is two fix patches of the cve, the web just show one of my patches.
one patch is already shown in the web: [Revert "NFSv4: Handle the
special Linux file open access
mode"](https://github.com/torvalds/linux/commit/ab0fc21bc7105b54bafd85bd8b82742f9e68898a)
second patch is not shown in the web: [NFSv4: fix open failure with
O_ACCMODE
flag](https://github.com/torvalds/linux/commit/b243874f6f9568b2daf1a00e9222cacdc15e159c)
在 2022/5/6 15:40, Lyu Tao 写道:
>> From: chenxiaosong (A) <[email protected]>
>> Sent: Thursday, May 5, 2022 4:48 AM
>> To: Lyu Tao
>> Cc: [email protected]; [email protected]; [email protected]; [email protected]; Trond Myklebust; [email protected]; [email protected]; [email protected]
>> Subject: Re: [PATCH -next 0/2] fix nfsv4 bugs of opening with O_ACCMODE flag
>
>> "NVD Last Modified" date of CVE-2022-24448 is updated as 04/29/2022, but the content of the cve is old.
>> https://nvd.nist.gov/vuln/detail/CVE-2022-24448
>
> Hi,
>
> Thanks for reaching out.
>
> I've requested to update the CVE description and they replied me that it would be updated yesterday. Maybe the system need some time to reflesh. Let's wait a few more days.
>
> Best,
> Tao.
>