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: <0f3f3858-5fae-1305-3e33-ca0a2f939119@oracle.com>
Date:   Mon, 12 Dec 2022 11:45:49 -0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0)
 Gecko/20100101 Thunderbird/102.5.1
Subject: Re: [PATCH 1/1] NFSD: fix use-after-free in __nfs42_ssc_open()
Content-Language: en-US
To:     Chuck Lever III <chuck.lever@oracle.com>
Cc:     Jeff Layton <jlayton@kernel.org>,
        Greg KH <gregkh@linuxfoundation.org>,
        Olga Kornievskaia <kolga@netapp.com>,
        "hdthky0@gmail.com" <hdthky0@gmail.com>,
        Linux NFS Mailing List <linux-nfs@vger.kernel.org>,
        "security@kernel.org" <security@kernel.org>
References: <1670786549-27041-1-git-send-email-dai.ngo@oracle.com>
 <7f68cb23445820b4a1c12b74dce0954f537ae5e2.camel@kernel.org>
 <56b0cb4f-dfe9-6892-7fef-1a2965cf1d99@oracle.com>
 <0ab8efccae708faa092a56c6935c33564814bfed.camel@kernel.org>
 <Y5czwRabTFiwah2b@kroah.com>
 <a47cc610af621e95ba359388e93d988f1ef5b17f.camel@kernel.org>
 <Y5dha1Hcgolctt0K@kroah.com>
 <7365935036c192bfc64cda41cb9ccb297e3eb86f.camel@kernel.org>
 <6D5F96AA-A8A7-4E19-A566-959F19A3CB0A@oracle.com>
 <6200943464679d51de50a05ab2ca1cc0c91d8685.camel@kernel.org>
 <a895cb89-f8f3-a2e1-1958-cf9379ecdcd5@oracle.com>
 <4CAE538E-9F0B-4B44-956E-C6498A37A83A@oracle.com>
From:   dai.ngo@oracle.com
In-Reply-To: <4CAE538E-9F0B-4B44-956E-C6498A37A83A@oracle.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?SXphTWVwZ1RwZEp4a3JWZVhEOTBXMk44MTJaV3BCb2VGOGNSeEVqTHJIdUFP?=
 =?utf-8?B?OVMzVDJDZVJIdjBOYUVJRFRqQXZYN1Z2Ynk0Y1JrOTlGSkZwOWZ4SjU2MUlq?=
 =?utf-8?B?ZFZpaUVjSTlBcHNHWmNyRFJoTzI3Rkh1KzRvMUgxMDh5VGx0eWo4VEdFZ1Vv?=
 =?utf-8?B?THVEUm1UOHpuUit4d1RmQ3NzSVhKQ3QwWEowRmZrZlRkVWZpYklxb2hYZUVB?=
 =?utf-8?B?bkRwUmI1UmdWbFp3RTRVZktDaGdSbHNmVWtoWlFtc2tJVlhYMWplU2kvSWZX?=
 =?utf-8?B?ZUp5SUF5SmY0cW15Y2tMcXdWd2dxcXJJRVQ2YU0vblpzVjNjZmpSUS9hMDJZ?=
 =?utf-8?B?Z0xRaTBWQ2RoTDRDZTlaMFo4VTYyYnBPWTAvMU5mbUl0bG5jbVk0VGl3Y0Mr?=
 =?utf-8?B?TStVSVpmNVV1N3BBWlRITlAzWjNyaytkRUYyUytXakxnVXpxc2VWUmF3WW9j?=
 =?utf-8?B?RDd6THZ6ZkhQUFpFeXVjUHZ1U0NQSHRHVzhDL2NYRTREYTRjTzFpVGxtTFVI?=
 =?utf-8?B?Qkh1ZkJBT1NPcUo3WmIzWEQ0VS9RRHVBYUx1bXBpUmFRMXg5bExEQW1HLzEy?=
 =?utf-8?B?TkEyZkFza3RaR09qOUlWRVVsdVZwdDdSTXRicnAxZmREaFVtUWpWcUN4YW9Q?=
 =?utf-8?B?QkpEaDkrK0wySlQyeXJzSTVtclZvM3FRTk5rdjg0RlhhM1hkNWN5UlNReVEv?=
 =?utf-8?B?aHBoQ1IvYVFBejlHNGFaSnhvZUVIV3pydU5uOUZQbkJoRWJVVHFnY0VhVFNi?=
 =?utf-8?B?RmErZkE4eHhlTnZwSFBtUUpUQ1dJWDFXajNiVlR3aWFEWVJmZ1huN2ZsT0NZ?=
 =?utf-8?B?TmJPN0swQ29zMkx5dXJ4dDgzeXZqKzd5M2hBQXRRekM5R2FmU2ZlSFBrbzll?=
 =?utf-8?B?c2JzMFRlUmtRbUg5R3J3V0ZGcG9DUmlETjkwK1FYbVdYVG5xelNwNHlyQXFZ?=
 =?utf-8?B?ZjJsWTU1MGt5cmFtNmI5dmNsNmZ4aDh5bnVmMnpqSDFJdEdYS3hkVzZMbk42?=
 =?utf-8?B?WCtRcjNLZXJlL0IwajNrOTRNM202NjZ0SDc0c2pRK1NHQnhQWmEwV09EbVFL?=
 =?utf-8?B?VTh2YVgwMUQzamFMR2hhemJUYlNweW5rbC9NaTNFVFM3WE8ydWJ4aXRYNE94?=
 =?utf-8?B?MmJjUHN1Ri95c1Vua1dESGlEOHRweDlIeVl6WHNMRkJFZENZTWVyc0hiUmdk?=
 =?utf-8?B?Q1phV0VVK0NVdnd3dDA4aDhiY2pjVXJrcHZKVEdXdmdBaDg4SDlYRkk1UmE2?=
 =?utf-8?B?dFdlcnc0UWllV3pnUXBSc2JlRmswYUxVZFBXcXE2eHpZa0J3VkVINWxneHJQ?=
 =?utf-8?B?WldJUEhJS2YrTnZ0azNDRjhJWjlvb1ZFUjZLOHUzRmgvSHdVWTRvS0QxaU1V?=
 =?utf-8?B?dGs1RktJcFdXMjMvL05ZZWZUcm1PMXpvNFNSTEZmYU0yamNnYjZucTJNM1M3?=
 =?utf-8?B?amRVWDQzblhPamQ1RWswNmtTN29pbnBrcmtmd21GU1crZmtRUzgyWVZFTnpq?=
 =?utf-8?B?ejlPZUF0Nmc3VVJTU0tnR3ltRXNzWWl6MVF5aHZFeGpuallFdkNDaDEzYWFk?=
 =?utf-8?B?K3R6ak43MzNJRWJ3ZHNYM2pwbDFodFJPanVNcWFHdjBabmRmUHlFS2lSVzFm?=
 =?utf-8?B?Y3BBM25jNDlZd1hiQzg1WVM0R2hzUWtFc2ovRzZrVU5tZlljd3puSEhKL3lT?=
 =?utf-8?B?dmpTbTYvdkpwT0I2Z1ZzRDVKOFNJemJ5NDFiOHVJUmZmbmtZWG1uaUFMOWlN?=
 =?utf-8?B?dExpaGdTR2daSTZFZzBTK0EzelllUkhCTWVtUzVGM0hJRmNLNy92SDlsaDRC?=
 =?utf-8?B?MXZqSTJFMmtpRW90WXlpejBBZ2UzUk16VEh3aDU3VW9wQk5LOUZXTFFKNkNj?=
 =?utf-8?B?U09HTXluVzBHenhVNlFGeUhnQzdOSjFUNTVibElTRlRwdStTYjF3SzkydzNV?=
 =?utf-8?B?QXNTRlNURWFNR3hnSTJDMnlIY0E2bUY5a3AveTlhZGRVY0EzOFNXVmN6UVlt?=
 =?utf-8?B?TDlMaThYZmtkbjBhN3NiRnl6d0xhMldoeUlTWjAxWVJFNnp6QS8vRXZRMlNG?=
 =?utf-8?B?ZUcwcUhYenJ1YW9rbWR5S0M0dklLT2ZvS3dKSms1YXZxREE5WmtEMHZJZWtB?=
 =?utf-8?Q?xDK/kWbu8HfG1/3HOrkX1E1xv?=
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-Network-Message-Id: a755b31a-09ba-4c66-3193-08dadc797a83
X-MS-Exchange-CrossTenant-AuthSource: BY5PR10MB4257.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Dec 2022 19:45:54.5148
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: 8CzkLlo2MfSfoJoyRCkyk5ln+fjNraN43StbC6j/Lrz+UZLlztYw5aG0+DF6ZP5dFiwwp1ZeCDuVmroq0JSE4w==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR10MB5567
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.205,Aquarius:18.0.923,Hydra:6.0.545,FMLib:17.11.122.1
 definitions=2022-12-12_02,2022-12-12_02,2022-06-22_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 phishscore=0 bulkscore=0
 malwarescore=0 mlxlogscore=999 mlxscore=0 adultscore=0 suspectscore=0
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2210170000
 definitions=main-2212120177
X-Proofpoint-GUID: 6GwwoNKncL8Q-wTPfvP2fZETwn5tDslG
X-Proofpoint-ORIG-GUID: 6GwwoNKncL8Q-wTPfvP2fZETwn5tDslG
X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,
        DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_DNSWL_LOW,
        RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE autolearn=ham
        autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-nfs.vger.kernel.org>
X-Mailing-List: linux-nfs@vger.kernel.org


On 12/12/22 11:28 AM, Chuck Lever III wrote:
>
>> On Dec 12, 2022, at 2:16 PM, Dai Ngo <dai.ngo@oracle.com> wrote:
>>
>>
>> On 12/12/22 10:38 AM, Jeff Layton wrote:
>>> On Mon, 2022-12-12 at 18:16 +0000, Chuck Lever III wrote:
>>>>> On Dec 12, 2022, at 12:44 PM, Jeff Layton <jlayton@kernel.org> wrote:
>>>>>
>>>>> On Mon, 2022-12-12 at 18:14 +0100, Greg KH wrote:
>>>>>> On Mon, Dec 12, 2022 at 09:31:19AM -0500, Jeff Layton wrote:
>>>>>>> On Mon, 2022-12-12 at 14:59 +0100, Greg KH wrote:
>>>>>>>> On Mon, Dec 12, 2022 at 08:40:31AM -0500, Jeff Layton wrote:
>>>>>>>>> On Mon, 2022-12-12 at 05:34 -0800, dai.ngo@oracle.com wrote:
>>>>>>>>>> On 12/12/22 4:22 AM, Jeff Layton wrote:
>>>>>>>>>>> On Sun, 2022-12-11 at 11:22 -0800, Dai Ngo wrote:
>>>>>>>>>>>> Problem caused by source's vfsmount being unmounted but remains
>>>>>>>>>>>> on the delayed unmount list. This happens when nfs42_ssc_open()
>>>>>>>>>>>> return errors.
>>>>>>>>>>>> Fixed by removing nfsd4_interssc_connect(), leave the vfsmount
>>>>>>>>>>>> for the laundromat to unmount when idle time expires.
>>>>>>>>>>>>
>>>>>>>>>>>> Reported-by: Xingyuan Mo <hdthky0@gmail.com>
>>>>>>>>>>>> Signed-off-by: Dai Ngo <dai.ngo@oracle.com>
>>>>>>>>>>>> ---
>>>>>>>>>>>>   fs/nfsd/nfs4proc.c | 23 +++++++----------------
>>>>>>>>>>>>   1 file changed, 7 insertions(+), 16 deletions(-)
>>>>>>>>>>>>
>>>>>>>>>>>> diff --git a/fs/nfsd/nfs4proc.c b/fs/nfsd/nfs4proc.c
>>>>>>>>>>>> index 8beb2bc4c328..756e42cf0d01 100644
>>>>>>>>>>>> --- a/fs/nfsd/nfs4proc.c
>>>>>>>>>>>> +++ b/fs/nfsd/nfs4proc.c
>>>>>>>>>>>> @@ -1463,13 +1463,6 @@ nfsd4_interssc_connect(struct nl4_server *nss, struct svc_rqst *rqstp,
>>>>>>>>>>>>   	return status;
>>>>>>>>>>>>   }
>>>>>>>>>>>>
>>>>>>>>>>>> -static void
>>>>>>>>>>>> -nfsd4_interssc_disconnect(struct vfsmount *ss_mnt)
>>>>>>>>>>>> -{
>>>>>>>>>>>> -	nfs_do_sb_deactive(ss_mnt->mnt_sb);
>>>>>>>>>>>> -	mntput(ss_mnt);
>>>>>>>>>>>> -}
>>>>>>>>>>>> -
>>>>>>>>>>>>   /*
>>>>>>>>>>>>    * Verify COPY destination stateid.
>>>>>>>>>>>>    *
>>>>>>>>>>>> @@ -1572,11 +1565,6 @@ nfsd4_cleanup_inter_ssc(struct vfsmount *ss_mnt, struct file *filp,
>>>>>>>>>>>>   {
>>>>>>>>>>>>   }
>>>>>>>>>>>>
>>>>>>>>>>>> -static void
>>>>>>>>>>>> -nfsd4_interssc_disconnect(struct vfsmount *ss_mnt)
>>>>>>>>>>>> -{
>>>>>>>>>>>> -}
>>>>>>>>>>>> -
>>>>>>>>>>>>   static struct file *nfs42_ssc_open(struct vfsmount *ss_mnt,
>>>>>>>>>>>>   				   struct nfs_fh *src_fh,
>>>>>>>>>>>>   				   nfs4_stateid *stateid)
>>>>>>>>>>>> @@ -1762,7 +1750,8 @@ static int nfsd4_do_async_copy(void *data)
>>>>>>>>>>>>   		struct file *filp;
>>>>>>>>>>>>
>>>>>>>>>>>>   		filp = nfs42_ssc_open(copy->ss_mnt, &copy->c_fh,
>>>>>>>>>>>> -				      &copy->stateid);
>>>>>>>>>>>> +					&copy->stateid);
>>>>>>>>>>>> +
>>>>>>>>>>>>   		if (IS_ERR(filp)) {
>>>>>>>>>>>>   			switch (PTR_ERR(filp)) {
>>>>>>>>>>>>   			case -EBADF:
>>>>>>>>>>>> @@ -1771,7 +1760,7 @@ static int nfsd4_do_async_copy(void *data)
>>>>>>>>>>>>   			default:
>>>>>>>>>>>>   				nfserr = nfserr_offload_denied;
>>>>>>>>>>>>   			}
>>>>>>>>>>>> -			nfsd4_interssc_disconnect(copy->ss_mnt);
>>>>>>>>>>>> +			/* ss_mnt will be unmounted by the laundromat */
>>>>>>>>>>>>   			goto do_callback;
>>>>>>>>>>>>   		}
>>>>>>>>>>>>   		nfserr = nfsd4_do_copy(copy, filp, copy->nf_dst->nf_file,
>>>>>>>>>>>> @@ -1852,8 +1841,10 @@ nfsd4_copy(struct svc_rqst *rqstp, struct nfsd4_compound_state *cstate,
>>>>>>>>>>>>   	if (async_copy)
>>>>>>>>>>>>   		cleanup_async_copy(async_copy);
>>>>>>>>>>>>   	status = nfserrno(-ENOMEM);
>>>>>>>>>>>> -	if (nfsd4_ssc_is_inter(copy))
>>>>>>>>>>>> -		nfsd4_interssc_disconnect(copy->ss_mnt);
>>>>>>>>>>>> +	/*
>>>>>>>>>>>> +	 * source's vfsmount of inter-copy will be unmounted
>>>>>>>>>>>> +	 * by the laundromat
>>>>>>>>>>>> +	 */
>>>>>>>>>>>>   	goto out;
>>>>>>>>>>>>   }
>>>>>>>>>>>>
>>>>>>>>>>> This looks reasonable at first glance, but I have some concerns with the
>>>>>>>>>>> refcounting around ss_mnt elsewhere in this code. nfsd4_ssc_setup_dul
>>>>>>>>>>> looks for an existing connection and bumps the ni->nsui_refcnt if it
>>>>>>>>>>> finds one.
>>>>>>>>>>>
>>>>>>>>>>> But then later, nfsd4_cleanup_inter_ssc has a couple of cases where it
>>>>>>>>>>> just does a bare mntput:
>>>>>>>>>>>
>>>>>>>>>>>          if (!nn) {
>>>>>>>>>>>                  mntput(ss_mnt);
>>>>>>>>>>>                  return;
>>>>>>>>>>>          }
>>>>>>>>>>> ...
>>>>>>>>>>>          if (!found) {
>>>>>>>>>>>                  mntput(ss_mnt);
>>>>>>>>>>>                  return;
>>>>>>>>>>>          }
>>>>>>>>>>>
>>>>>>>>>>> The first one looks bogus. Can net_generic return NULL? If so how, and
>>>>>>>>>>> why is it not a problem elsewhere in the kernel?
>>>>>>>>>> it looks like net_generic can not fail, no where else check for NULL
>>>>>>>>>> so I will remove this check.
>>>>>>>>>>
>>>>>>>>>>> For the second case, if the ni is no longer on the list, where did the
>>>>>>>>>>> extra ss_mnt reference come from? Maybe that should be a WARN_ON or
>>>>>>>>>>> BUG_ON?
>>>>>>>>>> if ni is not found on the list then it's a bug somewhere so I will add
>>>>>>>>>> a BUG_ON on this.
>>>>>>>>>>
>>>>>>>>> Probably better to just WARN_ON and let any references leak in that
>>>>>>>>> case. A BUG_ON implies a panic in some environments, and it's best to
>>>>>>>>> avoid that unless there really is no choice.
>>>>>>>> WARN_ON also causes machines to boot that have panic_on_warn enabled.
>>>>>>>> Why not just handle the error and keep going?  Why panic at all?
>>>>>>>>
>>>>>>> Who the hell sets panic_on_warn (outside of testing environments)?
>>>>>> All cloud providers and anyone else that wants to "kill the system that
>>>>>> had a problem and have it reboot fast" in order to keep things working
>>>>>> overall.
>>>>>>
>>>>> If that's the case, then this situation would probably be one where a
>>>>> cloud provider would want to crash it and come back. NFS grace periods
>>>>> can suck though.
>>>>>
>>>>>>> I'm
>>>>>>> suggesting a WARN_ON because not finding an entry at this point
>>>>>>> represents a bug that we'd want reported.
>>>>>> Your call, but we are generally discouraging adding new WARN_ON() for
>>>>>> anything that userspace could ever trigger.  And if userspace can't
>>>>>> trigger it, then it's a normal type of error that you need to handle
>>>>>> anyway, right?
>>>>>>
>>>>>> Anyway, your call, just letting you know.
>>>>>>
>>>>> Understood.
>>>>>
>>>>>>> The caller should hold a reference to the object that holds a vfsmount
>>>>>>> reference. It relies on that vfsmount to do a copy. If it's gone at this
>>>>>>> point where we're releasing that reference, then we're looking at a
>>>>>>> refcounting bug of some sort.
>>>>>> refcounting in the nfsd code, or outside of that?
>>>>>>
>>>>> It'd be in the nfsd code, but might affect the vfsmount refcount. Inter-
>>>>> server copy is quite the tenuous house of cards. ;)
>>>>>
>>>>>>> I would expect anyone who sets panic_on_warn to _desire_ a panic in this
>>>>>>> situation. After all, they asked for it. Presumably they want it to do
>>>>>>> some coredump analysis or something?
>>>>>>>
>>>>>>> It is debatable whether the stack trace at this point would be helpful
>>>>>>> though, so you might consider a pr_warn or something less log-spammy.
>>>>>> If you can recover from it, then yeah, pr_warn() is usually best.
>>>>>>
>>>>> It does look like Dai went with pr_warn on his v2 patch.
>>>>>
>>>>> We'd "recover" by leaking a vfsmount reference. The immediate crash
>>>>> would be avoided, but it might make for interesting "fun" later when you
>>>>> went to try and unmount the thing.
>>>> This is a red flag for me. If the leak prevents the system from
>>>> shutting down reliably, then we need to do something more than
>>>> a pr_warn(), I would think.
>>>>
>>> Sorry, I should correct myself.
>>>
>>> We wouldn't (necessarily) leak a vfsmount reference. If the entry was no
>>> longer on the list, then presumably it has already been cleaned up and
>>> the vfsmount reference put.
>> I think the issue here is not vfsmount reference count. The issue is that
>> we could not find a nfsd4_ssc_umount_item on the list that matches the
>> vfsmount ss_mnt. So the question is what should we do in this case?
>>
>> Prior to this patch, when we hit this scenario we just go ahead and
>> unmount the ss_mnt there since it won't be unmounted by the laundromat
>> (it's not on the delayed unmount list).
>>
>> With this patch, we don't even unmount the ss_mnt, we just do a pr_warn.
>>
>> I'd prefer to go back to the previous code to do the unmount and also
>> do a pr_warn.
>>
>>> It's still a bug though since we _should_ still have a reference to the
>>> nfsd4_ssc_umount_item at this point. So this is really just a potential
>>> use-after-free.
>> The ss_mnt still might have a reference on the nfsd4_ssc_umount_item
>> but we just can't find it on the list. Even though the possibility for
>> this to happen is from slim to none, we still have to check for it.
>>
>>> FWIW, the object handling here is somewhat weird as the copy operation
>>> holds a reference to the nfsd4_ssc_umount_item but passes around a
>>> pointer to the vfsmount
>>>
>>> I have to wonder if it'd be cleaner to have nfsd4_setup_inter_ssc pass
>>> back a pointer to the nfsd4_ssc_umount_item, so you could pass that to
>>> nfsd4_cleanup_inter_ssc and skip searching for it again at cleanup time.
>> Yes, I think returning a pointer to the nfsd4_ssc_umount_item approach
>> would be better.  We won't have to deal with the situation where we can't
>> find an item on the list (even though it almost never happen).
>>
>> Can we do this enhancement after fixing this use-after-free problem, in
>> a separate patch series?
> Is there a reason not fix it correctly now?
>
> I'd rather not merge a fix that leaves the possibility of a leak.

I think we should do it separately because the reported problem of
use-after-free is not related to the problem of not finding the ni
item on the list.

AFAIK, the problem of not finding ni item on the list was never
reported or happened during my testing.

The fix for the use-after-free deals with the handling of errors
returned from nfs42_ssc_open and other places in the code. This
fix remains the same no matter how the vfsmount is passed around.

-Dai