* [PATCH -next 0/2] fix nfsv4 bugs of opening with O_ACCMODE flag
@ 2022-03-29 11:32 ChenXiaoSong
2022-03-29 11:32 ` [PATCH -next 1/2] Revert "NFSv4: Handle the special Linux file open access mode" ChenXiaoSong
` (2 more replies)
0 siblings, 3 replies; 18+ messages in thread
From: ChenXiaoSong @ 2022-03-29 11:32 UTC (permalink / raw)
To: trond.myklebust, anna, bjschuma
Cc: linux-nfs, linux-kernel, chenxiaosong2, liuyongqiang13, yi.zhang,
zhangxiaoxu5, tao.lyu
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
^ permalink raw reply [flat|nested] 18+ messages in thread
* [PATCH -next 1/2] Revert "NFSv4: Handle the special Linux file open access mode"
2022-03-29 11:32 [PATCH -next 0/2] fix nfsv4 bugs of opening with O_ACCMODE flag ChenXiaoSong
@ 2022-03-29 11:32 ` ChenXiaoSong
2022-03-29 11:32 ` [PATCH -next 2/2] NFSv4: fix open failure with O_ACCMODE flag ChenXiaoSong
2022-03-29 14:32 ` [PATCH -next 0/2] fix nfsv4 bugs of opening " chenxiaosong (A)
2 siblings, 0 replies; 18+ messages in thread
From: ChenXiaoSong @ 2022-03-29 11:32 UTC (permalink / raw)
To: trond.myklebust, anna, bjschuma
Cc: linux-nfs, linux-kernel, chenxiaosong2, liuyongqiang13, yi.zhang,
zhangxiaoxu5, tao.lyu
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
^ permalink raw reply related [flat|nested] 18+ messages in thread
* [PATCH -next 2/2] NFSv4: fix open failure with O_ACCMODE flag
2022-03-29 11:32 [PATCH -next 0/2] fix nfsv4 bugs of opening with O_ACCMODE flag ChenXiaoSong
2022-03-29 11:32 ` [PATCH -next 1/2] Revert "NFSv4: Handle the special Linux file open access mode" ChenXiaoSong
@ 2022-03-29 11:32 ` ChenXiaoSong
2022-03-29 13:05 ` Trond Myklebust
2022-03-29 14:32 ` [PATCH -next 0/2] fix nfsv4 bugs of opening " chenxiaosong (A)
2 siblings, 1 reply; 18+ messages in thread
From: ChenXiaoSong @ 2022-03-29 11:32 UTC (permalink / raw)
To: trond.myklebust, anna, bjschuma
Cc: linux-nfs, linux-kernel, chenxiaosong2, liuyongqiang13, yi.zhang,
zhangxiaoxu5, tao.lyu
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
^ permalink raw reply related [flat|nested] 18+ messages in thread
* Re: [PATCH -next 2/2] NFSv4: fix open failure with O_ACCMODE flag
2022-03-29 11:32 ` [PATCH -next 2/2] NFSv4: fix open failure with O_ACCMODE flag ChenXiaoSong
@ 2022-03-29 13:05 ` Trond Myklebust
2022-03-29 13:44 ` chenxiaosong (A)
0 siblings, 1 reply; 18+ messages in thread
From: Trond Myklebust @ 2022-03-29 13:05 UTC (permalink / raw)
To: anna, chenxiaosong2, bjschuma
Cc: tao.lyu, linux-nfs, liuyongqiang13, linux-kernel, yi.zhang, zhangxiaoxu5
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
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH -next 2/2] NFSv4: fix open failure with O_ACCMODE flag
2022-03-29 13:05 ` Trond Myklebust
@ 2022-03-29 13:44 ` chenxiaosong (A)
2022-03-29 13:56 ` Trond Myklebust
0 siblings, 1 reply; 18+ messages in thread
From: chenxiaosong (A) @ 2022-03-29 13:44 UTC (permalink / raw)
To: Trond Myklebust, anna, bjschuma
Cc: tao.lyu, linux-nfs, liuyongqiang13, linux-kernel, yi.zhang, zhangxiaoxu5
在 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.
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH -next 2/2] NFSv4: fix open failure with O_ACCMODE flag
2022-03-29 13:44 ` chenxiaosong (A)
@ 2022-03-29 13:56 ` Trond Myklebust
0 siblings, 0 replies; 18+ messages in thread
From: Trond Myklebust @ 2022-03-29 13:56 UTC (permalink / raw)
To: anna, chenxiaosong2, bjschuma
Cc: linux-nfs, liuyongqiang13, linux-kernel, tao.lyu, zhangxiaoxu5, yi.zhang
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
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH -next 0/2] fix nfsv4 bugs of opening with O_ACCMODE flag
2022-03-29 11:32 [PATCH -next 0/2] fix nfsv4 bugs of opening with O_ACCMODE flag ChenXiaoSong
2022-03-29 11:32 ` [PATCH -next 1/2] Revert "NFSv4: Handle the special Linux file open access mode" ChenXiaoSong
2022-03-29 11:32 ` [PATCH -next 2/2] NFSv4: fix open failure with O_ACCMODE flag ChenXiaoSong
@ 2022-03-29 14:32 ` chenxiaosong (A)
[not found] ` <e0c2d7ec62b447cabddbc8a9274be955@epfl.ch>
2 siblings, 1 reply; 18+ messages in thread
From: chenxiaosong (A) @ 2022-03-29 14:32 UTC (permalink / raw)
To: trond.myklebust, anna, bjschuma
Cc: linux-nfs, linux-kernel, liuyongqiang13, yi.zhang, zhangxiaoxu5,
tao.lyu, ChenXiaoSong
在 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.
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH -next 0/2] fix nfsv4 bugs of opening with O_ACCMODE flag
[not found] ` <e0c2d7ec62b447cabddbc8a9274be955@epfl.ch>
@ 2022-04-13 13:42 ` chenxiaosong (A)
2022-04-13 14:05 ` chenxiaosong (A)
0 siblings, 1 reply; 18+ messages in thread
From: chenxiaosong (A) @ 2022-04-13 13:42 UTC (permalink / raw)
To: Lyu Tao, Trond Myklebust, anna, bjschuma
Cc: linux-nfs, linux-kernel, liuyongqiang13, yi.zhang, zhangxiaoxu5
在 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.
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH -next 0/2] fix nfsv4 bugs of opening with O_ACCMODE flag
2022-04-13 13:42 ` chenxiaosong (A)
@ 2022-04-13 14:05 ` chenxiaosong (A)
2022-04-13 14:34 ` chenxiaosong (A)
[not found] ` <3ee78045f18b4932b1651de776ee73c4@epfl.ch>
0 siblings, 2 replies; 18+ messages in thread
From: chenxiaosong (A) @ 2022-04-13 14:05 UTC (permalink / raw)
To: Lyu Tao, Trond Myklebust, anna, bjschuma
Cc: linux-nfs, linux-kernel, liuyongqiang13, yi.zhang, zhangxiaoxu5
在 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).
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH -next 0/2] fix nfsv4 bugs of opening with O_ACCMODE flag
2022-04-13 14:05 ` chenxiaosong (A)
@ 2022-04-13 14:34 ` chenxiaosong (A)
[not found] ` <3ee78045f18b4932b1651de776ee73c4@epfl.ch>
1 sibling, 0 replies; 18+ messages in thread
From: chenxiaosong (A) @ 2022-04-13 14:34 UTC (permalink / raw)
To: Lyu Tao, Trond Myklebust, anna, bjschuma
Cc: linux-nfs, linux-kernel, liuyongqiang13, yi.zhang, zhangxiaoxu5
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).
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH -next 0/2] fix nfsv4 bugs of opening with O_ACCMODE flag
[not found] ` <3ee78045f18b4932b1651de776ee73c4@epfl.ch>
@ 2022-04-13 14:42 ` chenxiaosong (A)
[not found] ` <55415e44b4b04bbfa66c42d5f2788384@epfl.ch>
0 siblings, 1 reply; 18+ messages in thread
From: chenxiaosong (A) @ 2022-04-13 14:42 UTC (permalink / raw)
To: Lyu Tao, Trond Myklebust, anna, bjschuma
Cc: linux-nfs, linux-kernel, liuyongqiang13, yi.zhang, zhangxiaoxu5
在 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.
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH -next 0/2] fix nfsv4 bugs of opening with O_ACCMODE flag
[not found] ` <55415e44b4b04bbfa66c42d5f2788384@epfl.ch>
@ 2022-04-14 2:41 ` chenxiaosong (A)
2022-04-14 7:33 ` Lyu Tao
0 siblings, 1 reply; 18+ messages in thread
From: chenxiaosong (A) @ 2022-04-14 2:41 UTC (permalink / raw)
To: Lyu Tao, Trond Myklebust, anna, bjschuma
Cc: linux-nfs, linux-kernel, liuyongqiang13, yi.zhang, zhangxiaoxu5
在 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/
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH -next 0/2] fix nfsv4 bugs of opening with O_ACCMODE flag
2022-04-14 2:41 ` chenxiaosong (A)
@ 2022-04-14 7:33 ` Lyu Tao
2022-05-05 2:48 ` chenxiaosong (A)
0 siblings, 1 reply; 18+ messages in thread
From: Lyu Tao @ 2022-04-14 7:33 UTC (permalink / raw)
To: chenxiaosong (A), Trond Myklebust, anna, bjschuma
Cc: linux-nfs, linux-kernel, liuyongqiang13, yi.zhang, zhangxiaoxu5
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.
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH -next 0/2] fix nfsv4 bugs of opening with O_ACCMODE flag
2022-04-14 7:33 ` Lyu Tao
@ 2022-05-05 2:48 ` chenxiaosong (A)
2022-05-06 7:40 ` Lyu Tao
0 siblings, 1 reply; 18+ messages in thread
From: chenxiaosong (A) @ 2022-05-05 2:48 UTC (permalink / raw)
To: Lyu Tao
Cc: linux-nfs, linux-kernel, bjschuma, anna, Trond Myklebust,
liuyongqiang13, yi.zhang, zhangxiaoxu5
"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
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH -next 0/2] fix nfsv4 bugs of opening with O_ACCMODE flag
2022-05-05 2:48 ` chenxiaosong (A)
@ 2022-05-06 7:40 ` Lyu Tao
2022-05-31 6:40 ` chenxiaosong (A)
0 siblings, 1 reply; 18+ messages in thread
From: Lyu Tao @ 2022-05-06 7:40 UTC (permalink / raw)
To: chenxiaosong (A)
Cc: linux-nfs, linux-kernel, bjschuma, anna, Trond Myklebust,
liuyongqiang13, yi.zhang, zhangxiaoxu5
> 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
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH -next 0/2] fix nfsv4 bugs of opening with O_ACCMODE flag
2022-05-06 7:40 ` Lyu Tao
@ 2022-05-31 6:40 ` chenxiaosong (A)
2022-05-31 8:16 ` Lyu Tao
0 siblings, 1 reply; 18+ messages in thread
From: chenxiaosong (A) @ 2022-05-31 6:40 UTC (permalink / raw)
To: Lyu Tao
Cc: linux-nfs, linux-kernel, bjschuma, anna, Trond Myklebust,
liuyongqiang13, yi.zhang, zhangxiaoxu5
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.
>
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH -next 0/2] fix nfsv4 bugs of opening with O_ACCMODE flag
2022-05-31 6:40 ` chenxiaosong (A)
@ 2022-05-31 8:16 ` Lyu Tao
2022-05-31 8:47 ` chenxiaosong (A)
0 siblings, 1 reply; 18+ messages in thread
From: Lyu Tao @ 2022-05-31 8:16 UTC (permalink / raw)
To: chenxiaosong (A)
Cc: linux-nfs, linux-kernel, bjschuma, anna, Trond Myklebust,
liuyongqiang13, yi.zhang, zhangxiaoxu5
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.
>>
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH -next 0/2] fix nfsv4 bugs of opening with O_ACCMODE flag
2022-05-31 8:16 ` Lyu Tao
@ 2022-05-31 8:47 ` chenxiaosong (A)
0 siblings, 0 replies; 18+ messages in thread
From: chenxiaosong (A) @ 2022-05-31 8:47 UTC (permalink / raw)
To: Lyu Tao
Cc: linux-nfs, linux-kernel, bjschuma, anna, Trond Myklebust,
liuyongqiang13, yi.zhang, zhangxiaoxu5
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.
>>>
>
>
>
>
>
>
> .
>
^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2022-05-31 8:47 UTC | newest]
Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-03-29 11:32 [PATCH -next 0/2] fix nfsv4 bugs of opening with O_ACCMODE flag ChenXiaoSong
2022-03-29 11:32 ` [PATCH -next 1/2] Revert "NFSv4: Handle the special Linux file open access mode" ChenXiaoSong
2022-03-29 11:32 ` [PATCH -next 2/2] NFSv4: fix open failure with O_ACCMODE flag ChenXiaoSong
2022-03-29 13:05 ` Trond Myklebust
2022-03-29 13:44 ` chenxiaosong (A)
2022-03-29 13:56 ` Trond Myklebust
2022-03-29 14:32 ` [PATCH -next 0/2] fix nfsv4 bugs of opening " chenxiaosong (A)
[not found] ` <e0c2d7ec62b447cabddbc8a9274be955@epfl.ch>
2022-04-13 13:42 ` chenxiaosong (A)
2022-04-13 14:05 ` chenxiaosong (A)
2022-04-13 14:34 ` chenxiaosong (A)
[not found] ` <3ee78045f18b4932b1651de776ee73c4@epfl.ch>
2022-04-13 14:42 ` chenxiaosong (A)
[not found] ` <55415e44b4b04bbfa66c42d5f2788384@epfl.ch>
2022-04-14 2:41 ` chenxiaosong (A)
2022-04-14 7:33 ` Lyu Tao
2022-05-05 2:48 ` chenxiaosong (A)
2022-05-06 7:40 ` Lyu Tao
2022-05-31 6:40 ` chenxiaosong (A)
2022-05-31 8:16 ` Lyu Tao
2022-05-31 8:47 ` chenxiaosong (A)
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.