[PATCH -next 0/2] fix nfsv4 bugs of opening with O_ACCMODE flag

[PATCH -next 0/2] fix nfsv4 bugs of opening with O_ACCMODE flag

[ChenXiaoSong]

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

[PATCH -next 1/2] Revert "NFSv4: Handle the special Linux file open access mode"

[ChenXiaoSong]

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 <tao.lyu@epfl.ch>
Signed-off-by: ChenXiaoSong <chenxiaosong2@huawei.com>
---
 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

[PATCH -next 2/2] NFSv4: fix open failure with O_ACCMODE flag

[ChenXiaoSong]

open() with O_ACCMODE|O_DIRECT flags secondly will fail.

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)

Server nfsd4_decode_share_access() will fail with error nfserr_bad_xdr when
client use incorrect share access mode of 0.

Fix this by using NFS4_SHARE_ACCESS_BOTH share access mode in client,
just like firstly opening.

Fixes: ce4ef7c0a8a05 ("NFS: Split out NFS v4 file operations")
Signed-off-by: ChenXiaoSong <chenxiaosong2@huawei.com>
---
 fs/nfs/dir.c      | 10 ----------
 fs/nfs/internal.h | 10 ++++++++++
 fs/nfs/nfs4file.c |  6 ++++--
 3 files changed, 14 insertions(+), 12 deletions(-)

diff --git a/fs/nfs/dir.c b/fs/nfs/dir.c
index 75cb1cbe4cde..911bdb35eb08 100644
--- a/fs/nfs/dir.c
+++ b/fs/nfs/dir.c
@@ -1853,16 +1853,6 @@ const struct dentry_operations nfs4_dentry_operations = {
 };
 EXPORT_SYMBOL_GPL(nfs4_dentry_operations);
 
-static fmode_t flags_to_mode(int flags)
-{
-	fmode_t res = (__force fmode_t)flags & FMODE_EXEC;
-	if ((flags & O_ACCMODE) != O_WRONLY)
-		res |= FMODE_READ;
-	if ((flags & O_ACCMODE) != O_RDONLY)
-		res |= FMODE_WRITE;
-	return res;
-}
-
 static struct nfs_open_context *create_nfs_open_context(struct dentry *dentry, int open_flags, struct file *filp)
 {
 	return alloc_nfs_open_context(dentry, flags_to_mode(open_flags), filp);
diff --git a/fs/nfs/internal.h b/fs/nfs/internal.h
index 2de7c56a1fbe..58e618a5d88e 100644
--- a/fs/nfs/internal.h
+++ b/fs/nfs/internal.h
@@ -42,6 +42,16 @@ static inline bool nfs_lookup_is_soft_revalidate(const struct dentry *dentry)
 	return true;
 }
 
+static inline fmode_t flags_to_mode(int flags)
+{
+	fmode_t res = (__force fmode_t)flags & FMODE_EXEC;
+	if ((flags & O_ACCMODE) != O_WRONLY)
+		res |= FMODE_READ;
+	if ((flags & O_ACCMODE) != O_RDONLY)
+		res |= FMODE_WRITE;
+	return res;
+}
+
 /*
  * Note: RFC 1813 doesn't limit the number of auth flavors that
  * a server can return, so make something up.
diff --git a/fs/nfs/nfs4file.c b/fs/nfs/nfs4file.c
index c178db86a6e8..e34af48fb4f4 100644
--- a/fs/nfs/nfs4file.c
+++ b/fs/nfs/nfs4file.c
@@ -32,6 +32,7 @@ nfs4_file_open(struct inode *inode, struct file *filp)
 	struct dentry *parent = NULL;
 	struct inode *dir;
 	unsigned openflags = filp->f_flags;
+	fmode_t f_mode;
 	struct iattr attr;
 	int err;
 
@@ -50,8 +51,9 @@ nfs4_file_open(struct inode *inode, struct file *filp)
 	if (err)
 		return err;
 
+	f_mode = filp->f_mode;
 	if ((openflags & O_ACCMODE) == 3)
-		openflags--;
+		f_mode |= flags_to_mode(openflags);
 
 	/* We can't create new files here */
 	openflags &= ~(O_CREAT|O_EXCL);
@@ -59,7 +61,7 @@ nfs4_file_open(struct inode *inode, struct file *filp)
 	parent = dget_parent(dentry);
 	dir = d_inode(parent);
 
-	ctx = alloc_nfs_open_context(file_dentry(filp), filp->f_mode, filp);
+	ctx = alloc_nfs_open_context(file_dentry(filp), f_mode, filp);
 	err = PTR_ERR(ctx);
 	if (IS_ERR(ctx))
 		goto out;
-- 
2.31.1

Re: [PATCH -next 2/2] NFSv4: fix open failure with O_ACCMODE flag

[Trond Myklebust]

On Tue, 2022-03-29 at 19:32 +0800, ChenXiaoSong wrote:
> open() with O_ACCMODE|O_DIRECT flags secondly will fail.
> 
> 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)
> 
> Server nfsd4_decode_share_access() will fail with error
> nfserr_bad_xdr when
> client use incorrect share access mode of 0.
> 
> Fix this by using NFS4_SHARE_ACCESS_BOTH share access mode in client,
> just like firstly opening.
> 
> Fixes: ce4ef7c0a8a05 ("NFS: Split out NFS v4 file operations")
> Signed-off-by: ChenXiaoSong <chenxiaosong2@huawei.com>
> ---
>  fs/nfs/dir.c      | 10 ----------
>  fs/nfs/internal.h | 10 ++++++++++
>  fs/nfs/nfs4file.c |  6 ++++--
>  3 files changed, 14 insertions(+), 12 deletions(-)
> 
> diff --git a/fs/nfs/dir.c b/fs/nfs/dir.c
> index 75cb1cbe4cde..911bdb35eb08 100644
> --- a/fs/nfs/dir.c
> +++ b/fs/nfs/dir.c
> @@ -1853,16 +1853,6 @@ const struct dentry_operations
> nfs4_dentry_operations = {
>  };
>  EXPORT_SYMBOL_GPL(nfs4_dentry_operations);
>  
> -static fmode_t flags_to_mode(int flags)
> -{
> -       fmode_t res = (__force fmode_t)flags & FMODE_EXEC;
> -       if ((flags & O_ACCMODE) != O_WRONLY)
> -               res |= FMODE_READ;
> -       if ((flags & O_ACCMODE) != O_RDONLY)
> -               res |= FMODE_WRITE;
> -       return res;
> -}
> -
>  static struct nfs_open_context *create_nfs_open_context(struct
> dentry *dentry, int open_flags, struct file *filp)
>  {
>         return alloc_nfs_open_context(dentry,
> flags_to_mode(open_flags), filp);
> diff --git a/fs/nfs/internal.h b/fs/nfs/internal.h
> index 2de7c56a1fbe..58e618a5d88e 100644
> --- a/fs/nfs/internal.h
> +++ b/fs/nfs/internal.h
> @@ -42,6 +42,16 @@ static inline bool
> nfs_lookup_is_soft_revalidate(const struct dentry *dentry)
>         return true;
>  }
>  
> +static inline fmode_t flags_to_mode(int flags)
> +{
> +       fmode_t res = (__force fmode_t)flags & FMODE_EXEC;
> +       if ((flags & O_ACCMODE) != O_WRONLY)
> +               res |= FMODE_READ;
> +       if ((flags & O_ACCMODE) != O_RDONLY)
> +               res |= FMODE_WRITE;
> +       return res;
> +}
> +
>  /*
>   * Note: RFC 1813 doesn't limit the number of auth flavors that
>   * a server can return, so make something up.
> diff --git a/fs/nfs/nfs4file.c b/fs/nfs/nfs4file.c
> index c178db86a6e8..e34af48fb4f4 100644
> --- a/fs/nfs/nfs4file.c
> +++ b/fs/nfs/nfs4file.c
> @@ -32,6 +32,7 @@ nfs4_file_open(struct inode *inode, struct file
> *filp)
>         struct dentry *parent = NULL;
>         struct inode *dir;
>         unsigned openflags = filp->f_flags;
> +       fmode_t f_mode;
>         struct iattr attr;
>         int err;
>  
> @@ -50,8 +51,9 @@ nfs4_file_open(struct inode *inode, struct file
> *filp)
>         if (err)
>                 return err;
>  
> +       f_mode = filp->f_mode;
>         if ((openflags & O_ACCMODE) == 3)
> -               openflags--;
> +               f_mode |= flags_to_mode(openflags);
>  

No. This will not fit the definition of open(2) in the manpage.

       Linux reserves the special, nonstandard access mode 3  (binary  11)  in
       flags  to mean: check for read and write permission on the file and re‐
       turn a file descriptor that can't be used for reading or writing.  This
       nonstandard  access mode is used by some Linux drivers to return a file
       descriptor that is to be used only for device-specific ioctl(2)  opera‐
       tions.

Your patch will now cause FMODE_READ and FMODE_WRITE to be set on the
file, allowing the file descriptor to be usable for I/O.

>         /* We can't create new files here */
>         openflags &= ~(O_CREAT|O_EXCL);
> @@ -59,7 +61,7 @@ nfs4_file_open(struct inode *inode, struct file
> *filp)
>         parent = dget_parent(dentry);
>         dir = d_inode(parent);
>  
> -       ctx = alloc_nfs_open_context(file_dentry(filp), filp->f_mode,
> filp);
> +       ctx = alloc_nfs_open_context(file_dentry(filp), f_mode,
> filp);
>         err = PTR_ERR(ctx);
>         if (IS_ERR(ctx))
>                 goto out;

-- 
Trond Myklebust
Linux NFS client maintainer, Hammerspace
trond.myklebust@hammerspace.com

Re: [PATCH -next 2/2] NFSv4: fix open failure with O_ACCMODE flag

[chenxiaosong (A)]

在 2022/3/29 21:05, Trond Myklebust 写道:
> No. This will not fit the definition of open(2) in the manpage.
> 
>         Linux reserves the special, nonstandard access mode 3  (binary  11)  in
>         flags  to mean: check for read and write permission on the file and re‐
>         turn a file descriptor that can't be used for reading or writing.  This
>         nonstandard  access mode is used by some Linux drivers to return a file
>         descriptor that is to be used only for device-specific ioctl(2)  opera‐
>         tions.
 > Your patch will now cause FMODE_READ and FMODE_WRITE to be set on the
 > file, allowing the file descriptor to be usable for I/O.

Reproducer:
```
   1. mount -t nfs -o vers=4.2 $server_ip:/ /mnt/
   2. fd = open("/mnt/file", O_ACCMODE|O_DIRECT|O_CREAT) = 3
   3. close(fd)
   4. fd = open("/mnt/file", O_ACCMODE|O_DIRECT) = -1
```

When firstly open with O_ACCMODE|O_DIRECT flags:
```c
   path_openat
     open_last_lookups
       lookup_open
         atomic_open
           nfs_atomic_open
             create_nfs_open_context
               f_mode = flags_to_mode
               alloc_nfs_open_context(..., f_mode, ...)
                 ctx->mode = f_mode // FMODE_READ|FMODE_WRITE
```

When secondly open with O_ACCMODE|O_DIRECT flags:
```c
   path_openat
     do_open
       vfs_open
         do_dentry_open
           nfs4_file_open
             f_mode = filp->f_mode | flags_to_mode(openflags)
             alloc_nfs_open_context(..., f_mode, ...)
               ctx->mode = f_mode // FMODE_READ|FMODE_WRITE
```

Before merging this patch, when firstly open, we does not set FMODE_READ 
and FMODE_WRITE to file mode of client, FMODE_READ and FMODE_WRITE just 
be set to context mode.

After merging this patch, when secondly open, I just do the same thing, 
file mode of client will not have FMODE_READ and FMODE_WRITE bits, file 
descriptor can't be used for reading or writing.

Re: [PATCH -next 2/2] NFSv4: fix open failure with O_ACCMODE flag

[Trond Myklebust]

On Tue, 2022-03-29 at 21:44 +0800, chenxiaosong (A) wrote:
> 在 2022/3/29 21:05, Trond Myklebust 写道:
> > No. This will not fit the definition of open(2) in the manpage.
> > 
> >         Linux reserves the special, nonstandard access mode 3 
> > (binary  11)  in
> >         flags  to mean: check for read and write permission on the
> > file and re‐
> >         turn a file descriptor that can't be used for reading or
> > writing.  This
> >         nonstandard  access mode is used by some Linux drivers to
> > return a file
> >         descriptor that is to be used only for device-specific
> > ioctl(2)  opera‐
> >         tions.
>  > Your patch will now cause FMODE_READ and FMODE_WRITE to be set on
> the
>  > file, allowing the file descriptor to be usable for I/O.
> 
> Reproducer:
> ```
>    1. mount -t nfs -o vers=4.2 $server_ip:/ /mnt/
>    2. fd = open("/mnt/file", O_ACCMODE|O_DIRECT|O_CREAT) = 3
>    3. close(fd)
>    4. fd = open("/mnt/file", O_ACCMODE|O_DIRECT) = -1
> ```
> 
> When firstly open with O_ACCMODE|O_DIRECT flags:
> ```c
>    path_openat
>      open_last_lookups
>        lookup_open
>          atomic_open
>            nfs_atomic_open
>              create_nfs_open_context
>                f_mode = flags_to_mode
>                alloc_nfs_open_context(..., f_mode, ...)
>                  ctx->mode = f_mode // FMODE_READ|FMODE_WRITE
> ```
> 
> When secondly open with O_ACCMODE|O_DIRECT flags:
> ```c
>    path_openat
>      do_open
>        vfs_open
>          do_dentry_open
>            nfs4_file_open
>              f_mode = filp->f_mode | flags_to_mode(openflags)
>              alloc_nfs_open_context(..., f_mode, ...)
>                ctx->mode = f_mode // FMODE_READ|FMODE_WRITE
> ```
> 
> Before merging this patch, when firstly open, we does not set
> FMODE_READ 
> and FMODE_WRITE to file mode of client, FMODE_READ and FMODE_WRITE
> just 
> be set to context mode.
> 
> After merging this patch, when secondly open, I just do the same
> thing, 
> file mode of client will not have FMODE_READ and FMODE_WRITE bits,
> file 
> descriptor can't be used for reading or writing.

I see. OK, I'll probably not apply this for the merge window (since I'm
pretty much queued up to send the pull request at this point), but it
might go in as a bug fix in rc1.

-- 
Trond Myklebust
Linux NFS client maintainer, Hammerspace
trond.myklebust@hammerspace.com

Re: [PATCH -next 0/2] fix nfsv4 bugs of opening with O_ACCMODE flag

[chenxiaosong (A)]

在 2022/3/29 19:32, ChenXiaoSong 写道:
> 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(-)
> 

I wonder if these bugs related to 
[CVE-2022-24448](https://nvd.nist.gov/vuln/detail/CVE-2022-24448) ?

[Question about 
CVE-2022-24448](https://lore.kernel.org/all/1bb42908-8f58-bf56-c2da-42739ee48d16@huawei.com/T/)

Is there POC of patch ac795161c936 ("NFSv4: Handle case where the lookup 
of a directory fails") ?

CVE-2022-24448 Description:
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.

Re: [PATCH -next 0/2] fix nfsv4 bugs of opening with O_ACCMODE flag

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

Re: [PATCH -next 0/2] fix nfsv4 bugs of opening with O_ACCMODE flag

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

Re: [PATCH -next 0/2] fix nfsv4 bugs of opening with O_ACCMODE flag

[chenxiaosong (A)]

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

Re: [PATCH -next 0/2] fix nfsv4 bugs of opening with O_ACCMODE flag

[chenxiaosong (A)]

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

Re: [PATCH -next 0/2] fix nfsv4 bugs of opening with O_ACCMODE flag

[chenxiaosong (A)]

在 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/20220329113208.2466000-1-chenxiaosong2@huawei.com/

Re: [PATCH -next 0/2] fix nfsv4 bugs of opening with O_ACCMODE flag

[Lyu Tao]

From: chenxiaosong (A) <chenxiaosong2@huawei.com>
Sent: Thursday, April 14, 2022 4:41 AM
To: Lyu Tao; Trond Myklebust; anna@kernel.org; bjschuma@netapp.com
Cc: linux-nfs@vger.kernel.org; linux-kernel@vger.kernel.org; liuyongqiang13@huawei.com; yi.zhang@huawei.com; zhangxiaoxu5@huawei.com
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/20220329113208.2466000-1-chenxiaosong2@huawei.com/
 
OK! Thanks for letting me know.

Re: [PATCH -next 0/2] fix nfsv4 bugs of opening with O_ACCMODE flag

[chenxiaosong (A)]

"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

Re: [PATCH -next 0/2] fix nfsv4 bugs of opening with O_ACCMODE flag

[Lyu Tao]

> From: chenxiaosong (A) <chenxiaosong2@huawei.com>
> Sent: Thursday, May 5, 2022 4:48 AM
> To: Lyu Tao
> Cc: linux-nfs@vger.kernel.org; linux-kernel@vger.kernel.org; bjschuma@netapp.com; anna@kernel.org; Trond Myklebust; liuyongqiang13@huawei.com; yi.zhang@huawei.com; zhangxiaoxu5@huawei.com
> 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

Re: [PATCH -next 0/2] fix nfsv4 bugs of opening with O_ACCMODE flag

[chenxiaosong (A)]

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) <chenxiaosong2@huawei.com>
>> Sent: Thursday, May 5, 2022 4:48 AM
>> To: Lyu Tao
>> Cc: linux-nfs@vger.kernel.org; linux-kernel@vger.kernel.org; bjschuma@netapp.com; anna@kernel.org; Trond Myklebust; liuyongqiang13@huawei.com; yi.zhang@huawei.com; zhangxiaoxu5@huawei.com
>> 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.
> 

Re: [PATCH -next 0/2] fix nfsv4 bugs of opening with O_ACCMODE flag

[Lyu Tao]

Hi Xiaosong,

I sent the first email on 05.05.2022 to CVE-Request@mitre.org 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) <chenxiaosong2@huawei.com>
>Sent: Tuesday, May 31, 2022 8:40 AM
>To: Lyu Tao
>Cc: linux-nfs@vger.kernel.org; linux-kernel@vger.kernel.org; bjschuma@netapp.com; anna@kernel.org; Trond Myklebust; liuyongqiang13@huawei.com; yi.zhang@huawei.com; zhangxiaoxu5@huawei.com
>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) <chenxiaosong2@huawei.com>
>>> Sent: Thursday, May 5, 2022 4:48 AM
>>> To: Lyu Tao
>>> Cc: linux-nfs@vger.kernel.org; linux-kernel@vger.kernel.org; bjschuma@netapp.com; anna@kernel.org; Trond Myklebust; liuyongqiang13@huawei.com; yi.zhang@huawei.com; zhangxiaoxu5@huawei.com
>>> 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.
>> 






    

Re: [PATCH -next 0/2] fix nfsv4 bugs of opening with O_ACCMODE flag

[chenxiaosong (A)]

I do not know other ways to update the description, you can try to send 
email to CVE-Request@mitre.org again.

在 2022/5/31 16:16, Lyu Tao 写道:
> Hi Xiaosong,
> 
> I sent the first email on 05.05.2022 to CVE-Request@mitre.org 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) <chenxiaosong2@huawei.com>
>> Sent: Tuesday, May 31, 2022 8:40 AM
>> To: Lyu Tao
>> Cc: linux-nfs@vger.kernel.org; linux-kernel@vger.kernel.org; bjschuma@netapp.com; anna@kernel.org; Trond Myklebust; liuyongqiang13@huawei.com; yi.zhang@huawei.com; zhangxiaoxu5@huawei.com
>> 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) <chenxiaosong2@huawei.com>
>>>> Sent: Thursday, May 5, 2022 4:48 AM
>>>> To: Lyu Tao
>>>> Cc: linux-nfs@vger.kernel.org; linux-kernel@vger.kernel.org; bjschuma@netapp.com; anna@kernel.org; Trond Myklebust; liuyongqiang13@huawei.com; yi.zhang@huawei.com; zhangxiaoxu5@huawei.com
>>>> 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.
>>>
> 
> 
> 
> 
> 
> 
>      .
>