Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <0b6546f7-8a04-9d6e-50c3-483c8a1a6591@huawei.com>
Date:   Wed, 13 Apr 2022 21:42:39 +0800
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
 Thunderbird/91.2.1
Subject: Re: [PATCH -next 0/2] fix nfsv4 bugs of opening with O_ACCMODE flag
To:     Lyu Tao <tao.lyu@epfl.ch>,
        Trond Myklebust <trond.myklebust@hammerspace.com>,
        "anna@kernel.org" <anna@kernel.org>,
        "bjschuma@netapp.com" <bjschuma@netapp.com>
CC:     "linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "liuyongqiang13@huawei.com" <liuyongqiang13@huawei.com>,
        "yi.zhang@huawei.com" <yi.zhang@huawei.com>,
        "zhangxiaoxu5@huawei.com" <zhangxiaoxu5@huawei.com>
References: <20220329113208.2466000-1-chenxiaosong2@huawei.com>
 <68b65889-3b2c-fb72-a0a8-d0afc15a03e0@huawei.com>
 <e0c2d7ec62b447cabddbc8a9274be955@epfl.ch>
From:   "chenxiaosong (A)" <chenxiaosong2@huawei.com>
In-Reply-To: <e0c2d7ec62b447cabddbc8a9274be955@epfl.ch>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 8bit
Precedence: bulk


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