Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Wed, 28 Dec 2022 09:25:45 +0800 (CST)
Message-ID: <202212280925459299284@zte.com.cn>
In-Reply-To: <ca6e40fff619aa16cb178382f5404d047ed08f3c.camel@HansenPartnership.com>
References: 202212231040562072342@zte.com.cn,0fb8a86a-ca92-8d5f-99da-6815b2d5ec3e@gmx.de,eaad272203baa65ad65ac2206e5197595c88508e.camel@HansenPartnership.com,279ea596-6a20-0bb8-39c3-67b45d7425a6@gmx.de,ca6e40fff619aa16cb178382f5404d047ed08f3c.camel@HansenPartnership.com
Mime-Version: 1.0
From:   <yang.yang29@zte.com.cn>
To:     <James.Bottomley@HansenPartnership.com>
Cc:     <deller@gmx.de>, <linux-parisc@vger.kernel.org>,
        <linux-kernel@vger.kernel.org>, <xu.panda@zte.com.cn>
Subject: =?UTF-8?B?UmU6IFtQQVRDSCBsaW51eC1uZXh0XSBwYXJpc2M6IHVzZSBzdHJzY3B5KCkgdG8gaW5zdGVhZCBvZiBzdHJuY3B5KCk=?=
Content-Type: text/plain;
        charset="UTF-8"
Precedence: bulk

> the array buf[] is actually buf[count], so if count < 64 then
> sizeof(buf) < sizeof(in) and you're copying whatever is after buf on
> the stack or wherever it comes from. The amount you copy into in[]
> truly has to be the smaller of count and sizeof(in).  These are file
> operations, so you shouldn't rely on buf[] being null terminated
> (kernfs ensures it is, but it's a dangerous thing to rely on in the
> face of someone trying to exploit a stack smashing attack).

Should we send patchv3 which is back to v1, or we directly use
patchv1 to continue the reviewing?

Thanks!