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;
From:   "zhangxiaoxu (A)" <zhangxiaoxu5@huawei.com>
To:     <tao.lyu@epfl.ch>,
        Trond Myklebust <trond.myklebust@hammerspace.com>
CC:     ChenXiaoSong <chenxiaosong2@huawei.com>,
        yanaijie <yanaijie@huawei.com>,
        "zhangyi (F)" <yi.zhang@huawei.com>,
        Linux NFS Mailing List <linux-nfs@vger.kernel.org>
Subject: Question about CVE-2022-24448
Message-ID: <1bb42908-8f58-bf56-c2da-42739ee48d16@huawei.com>
Date:   Tue, 8 Feb 2022 19:48:58 +0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
 Thunderbird/78.7.1
MIME-Version: 1.0
Content-Type: text/plain; charset="gbk"; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk

Hi Trond and Tao,

I have some question about CVE-2022-24448[1].

It's description as:
   An issue was discovered in fs/nfs/dir.c in the Linux kernel before 5.16.5.
   If an application sets the O_DIRECTORY flag, and tries to open a regular
   file, nfs_atomic_open() performs a regular lookup. If a regular file is
   found, ENOTDIR should occur, but the server instead returns uninitialized
   data in the file descriptor.

It's fixed by ac795161c936 ("NFSv4: Handle case where the lookup of a directory fails")

When try to open a regular file with O_DIRECTORY flag,
it always return -ENOTDIR to userspace rather than a
valid file descriptor because the 'do_open' check the
dentry type.

My questions are:
1. which uninitialized data in the file description are returned from 'nfs_atomic_open'?
2. where use the uninitialized data?
3. which uninitialized data are returned from server?
4. is there a PoC reproducer or how to trigger it?


[1] https://nvd.nist.gov/vuln/detail/CVE-2022-24448