[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <98feb3ff-835a-e4cf-40a9-284d21e16993@redhat.com>
Date: Tue, 17 Mar 2020 14:36:50 -0400
From: Waiman Long <longman@...hat.com>
To: Jarkko Sakkinen <jarkko.sakkinen@...ux.intel.com>
Cc: David Howells <dhowells@...hat.com>,
James Morris <jmorris@...ei.org>,
"Serge E. Hallyn" <serge@...lyn.com>,
Mimi Zohar <zohar@...ux.ibm.com>, keyrings@...r.kernel.org,
linux-kernel@...r.kernel.org,
linux-security-module@...r.kernel.org,
linux-integrity@...r.kernel.org,
Sumit Garg <sumit.garg@...aro.org>,
Jerry Snitselaar <jsnitsel@...hat.com>,
Roberto Sassu <roberto.sassu@...wei.com>,
Eric Biggers <ebiggers@...gle.com>,
Chris von Recklinghausen <crecklin@...hat.com>
Subject: Re: [PATCH v3 2/3] KEYS: Avoid false positive ENOMEM error on key
read
On 3/15/20 5:32 PM, Jarkko Sakkinen wrote:
> On Fri, Mar 13, 2020 at 11:21:01AM -0400, Waiman Long wrote:
>> - * Read methods will just return the required length
>> - * without any copying if the provided length isn't big
>> - * enough.
>> + * We don't want an erronous -ENOMEM error due to an
>> + * arbitrary large user-supplied buflen. So if buflen
>> + * exceeds a threshold (1024 bytes in this case), we call
>> + * the read method twice. The first time to get the buffer
>> + * length and the second time to read out the key data.
>> + *
>> + * N.B. All the read methods will return the required
>> + * buffer length with a NULL input buffer or when
>> + * the input buffer length isn't large enough.
>> */
>> + if (buflen <= 0x400) {
> 1. The overwhelmingly long comment. Will be destined to rotten.
> 2. Magic number.
> 3. The cap must be updated both in comment and code, and not only
> that, but the numbers use a different base (dec and hex).
>
> /Jarkko
>
Thank for the comment. I will make the necessary change.
Cheers,
Longman
Powered by blists - more mailing lists