Received: by 2002:a05:6a10:17d3:0:0:0:0 with SMTP id hz19csp2404929pxb; Tue, 13 Apr 2021 00:41:09 -0700 (PDT) X-Google-Smtp-Source: ABdhPJw777fRCHEoPZY/JoL+G5z3mbZX3EaaT+cA015zKghXtD+fv6NdckjebenmNubs7jf5xZYi X-Received: by 2002:aa7:cd83:: with SMTP id x3mr33112939edv.373.1618299669484; Tue, 13 Apr 2021 00:41:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1618299669; cv=none; d=google.com; s=arc-20160816; b=yTXJ5N9UB2gQ0Dt7PJzLgxjt8Fm3+Rgm3TERy8u+DH27Xs+BI5w8hafDEuecv3pwwm r6e3bw962VdFV4jVoHgjZwo+vzE/k9A/dvMh22JCQv5MK7o1sVYV0FC/1M9+Et5scA4d IgDIdirb5mbLjry31N1sksH+vGWDlS8nq+0LcYbUEZkPdkqvEJ4ZQ/j2gw3czFwxyHw4 WQFkUQsbA4E35oF3zq8jNjNMUJJHvc7CMhEMQEzD3T0pab9f00cShbRccpm3v+pIa062 1MpRbAPbjJBQQ/NVAgMOafFRUnD/wpCwWYnN72NXbDJifvoq7hD5qeNB+3f9vRglt57h raRQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to :mime-version:user-agent:date:message-id:from:cc:references:to :subject; bh=gfo6mNURwGy9E524MUnfUwpOCPH4rzr1t9wnZ4rb+3Y=; b=OXs0f1zfBBM6nj/AbSdfoSG0ispTleiYEv+89mdfRKHtRkj2bpxv+2nELx38uosaIu rjWALKWQNAlh+iL7POckgIqi4BYWO665CXOUiiFJ8tdid5h8226DwUut2TktH6t1g8j6 speoT/oA9GATm/qS2OC7qmpwvu/YrDxMb85xXE9/hHLh9ADBVulvkzCcDJ7hMA2rmr4g QEeNaQLFZSrb2tK/Sldyv7Qyfm8jLLT+fy+oNxOVKx80+H0X9nkJeznn6TgpdW/8cuy8 ymLoN3GpqA4Rbly2kVcd5dJVNYYV+CmN1WEs0PCrLZhXx96z9a31zFEGyPO0x325haTz AVmw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id ds10si10065365ejc.709.2021.04.13.00.40.46; Tue, 13 Apr 2021 00:41:09 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240394AbhDMBQL (ORCPT + 99 others); Mon, 12 Apr 2021 21:16:11 -0400 Received: from mail.loongson.cn ([114.242.206.163]:38862 "EHLO loongson.cn" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S240327AbhDMBQK (ORCPT ); Mon, 12 Apr 2021 21:16:10 -0400 Received: from [10.130.0.55] (unknown [113.200.148.30]) by mail.loongson.cn (Coremail) with SMTP id AQAAf9Dxr+_E8HRg7lwHAA--.84S3; Tue, 13 Apr 2021 09:15:48 +0800 (CST) Subject: Re: [PATCH] MIPS: Fix strnlen_user access check To: Thomas Bogendoerfer , Tiezhu Yang References: <1618139092-4018-1-git-send-email-hejinyang@loongson.cn> <20210412142730.GA23146@alpha.franken.de> Cc: linux-mips@vger.kernel.org, linux-kernel@vger.kernel.org From: Jinyang He Message-ID: <2fd31420-1f96-9165-23ea-fdccac1b522a@loongson.cn> Date: Tue, 13 Apr 2021 09:15:48 +0800 User-Agent: Mozilla/5.0 (X11; Linux mips64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <20210412142730.GA23146@alpha.franken.de> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-CM-TRANSID: AQAAf9Dxr+_E8HRg7lwHAA--.84S3 X-Coremail-Antispam: 1UD129KBjvJXoWxAw4rWFW8Zw1kJrWrtryxXwb_yoW5Wr1rpa 95AF1kKFsYgry3Aa42y3yxXF15Gws8Kr4Yg34qkr1UZr4qvr13trWS9r1F9348JrsrAas2 gFW8Zrs8Wr1Yv3DanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUvC14x267AKxVWUJVW8JwAFc2x0x2IEx4CE42xK8VAvwI8IcIk0 rVWrJVCq3wAFIxvE14AKwVWUJVWUGwA2ocxC64kIII0Yj41l84x0c7CEw4AK67xGY2AK02 1l84ACjcxK6xIIjxv20xvE14v26ryj6F1UM28EF7xvwVC0I7IYx2IY6xkF7I0E14v26r4U JVWxJr1l84ACjcxK6I8E87Iv67AKxVW8Jr0_Cr1UM28EF7xvwVC2z280aVCY1x0267AKxV W8Jr0_Cr1UM2AIxVAIcxkEcVAq07x20xvEncxIr21l5I8CrVACY4xI64kE6c02F40Ex7xf McIj6xIIjxv20xvE14v26r1j6r18McIj6I8E87Iv67AKxVWUJVW8JwAm72CE4IkC6x0Yz7 v_Jr0_Gr1lF7xvr2IY64vIr41lF7I21c0EjII2zVCS5cI20VAGYxC7Mxk0xIA0c2IEe2xF o4CEbIxvr21lc2xSY4AK67AK6w4l42xK82IYc2Ij64vIr41l4I8I3I0E4IkC6x0Yz7v_Jr 0_Gr1lx2IqxVAqx4xG67AKxVWUJVWUGwC20s026x8GjcxK67AKxVWUGVWUWwC2zVAF1VAY 17CE14v26r126r1DMIIYrxkI7VAKI48JMIIF0xvE2Ix0cI8IcVAFwI0_Jr0_JF4lIxAIcV C0I7IYx2IY6xkF7I0E14v26r1j6r4UMIIF0xvE42xK8VAvwI8IcIk0rVWrZr1j6s0DMIIF 0xvEx4A2jsIE14v26r1j6r4UMIIF0xvEx4A2jsIEc7CjxVAFwI0_Jr0_GrUvcSsGvfC2Kf nxnUUI43ZEXa7VUbYFAPUUUUU== X-CM-SenderInfo: pkhmx0p1dqwqxorr0wxvrqhubq/ Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 04/12/2021 10:27 PM, Thomas Bogendoerfer wrote: > On Mon, Apr 12, 2021 at 11:02:19AM +0800, Tiezhu Yang wrote: >> On 04/11/2021 07:04 PM, Jinyang He wrote: >>> Commit 04324f44cb69 ("MIPS: Remove get_fs/set_fs") brought a problem for >>> strnlen_user(). Jump out when checking access_ok() with condition that >>> (s + strlen(s)) < __UA_LIMIT <= (s + n). The old __strnlen_user_asm() >>> just checked (ua_limit & s) without checking (ua_limit & (s + n)). >>> Therefore, find strlen form s to __UA_LIMIT - 1 in that condition. >>> >>> Signed-off-by: Jinyang He >>> --- >>> arch/mips/include/asm/uaccess.h | 11 +++++++++-- >>> 1 file changed, 9 insertions(+), 2 deletions(-) >>> >>> diff --git a/arch/mips/include/asm/uaccess.h b/arch/mips/include/asm/uaccess.h >>> index 91bc7fb..85ba0c8 100644 >>> --- a/arch/mips/include/asm/uaccess.h >>> +++ b/arch/mips/include/asm/uaccess.h >>> @@ -630,8 +630,15 @@ static inline long strnlen_user(const char __user *s, long n) >>> { >>> long res; >>> - if (!access_ok(s, n)) >>> - return -0; >>> + if (unlikely(n <= 0)) >>> + return 0; >>> + >>> + if (!access_ok(s, n)) { >>> + if (!access_ok(s, 0)) >>> + return 0; >>> + >>> + n = __UA_LIMIT - (unsigned long)s - 1; >>> + } >>> might_fault(); >>> __asm__ __volatile__( >> The following simple changes are OK to fix this issue? >> >> diff --git a/arch/mips/include/asm/uaccess.h b/arch/mips/include/asm/uaccess.h >> index 91bc7fb..eafc99b 100644 >> --- a/arch/mips/include/asm/uaccess.h >> +++ b/arch/mips/include/asm/uaccess.h >> @@ -630,8 +630,8 @@ static inline long strnlen_user(const char __user *s, long n) >> { >> long res; >> - if (!access_ok(s, n)) >> - return -0; >> + if (!access_ok(s, 1)) >> + return 0; >> might_fault(); >> __asm__ __volatile__( > that's the fix I'd like to apply. Could someone send it as a formal > patch ? Thanks. > > Thomas. > Hi, Thomas, Thank you for bringing me more thinking. I always think it is better to use access_ok(s, 0) on MIPS. I have been curious about the difference between access_ok(s, 0) and access_ok(s, 1) until I saw __access_ok() on RISCV at arch/riscv/include/asm/uaccess.h The __access_ok() is noted with `Ensure that the range [addr, addr+size) is within the process's address space`. Does the range checked by __access_ok() on MIPS is [addr, addr+size]. So if we want to use access_ok(s, 1), should we modify __access_ok()? Or my misunderstanding? More importantly, the implementation of strnlen_user in lib/strnlen_user.c is noted `we hit the address space limit, and we still had more characters the caller would have wanted. That's 0.` Does it make sense? It is not achieved on MIPS when hit __ua_limit, if only access_ok(s, 1) is used. Thanks, Jinyang