[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ec7add92-2865-48dd-9f87-078860d8e57b@suse.com>
Date: Tue, 5 Aug 2025 10:56:38 +0300
From: Nikolay Borisov <nik.borisov@...e.com>
To: "Serge E. Hallyn" <serge@...lyn.com>
Cc: linux-security-module@...r.kernel.org, linux-kernel@...r.kernel.org,
paul@...l-moore.com, jmorris@...ei.org, dan.j.williams@...el.com
Subject: Re: [PATCH v2 3/3] lockdown: Use snprintf in lockdown_read
On 7/28/25 15:39, Serge E. Hallyn wrote:
> On Mon, Jul 28, 2025 at 02:15:17PM +0300, Nikolay Borisov wrote:
>> Since individual features are now locked down separately ensure that if
>> the printing code is change to list them a buffer overrun won't be
>> introduced. As per Serge's recommendation switch from using sprintf to
>> using snprintf and return EINVAL in case longer than 80 char string hasi
>> to be printed.
>>
>> Signed-off-by: Nikolay Borisov <nik.borisov@...e.com>
>
> Thanks, 2 comments below
>
>> ---
>> security/lockdown/lockdown.c | 12 ++++++++++--
>> 1 file changed, 10 insertions(+), 2 deletions(-)
>>
>> diff --git a/security/lockdown/lockdown.c b/security/lockdown/lockdown.c
>> index 412184121279..ed1dde41d7d3 100644
>> --- a/security/lockdown/lockdown.c
>> +++ b/security/lockdown/lockdown.c
>> @@ -112,11 +112,19 @@ static ssize_t lockdown_read(struct file *filp, char __user *buf, size_t count,
>>
>> if (lockdown_reasons[level]) {
>> const char *label = lockdown_reasons[level];
>> + int ret = 0;
>> + int write_len = 80-offset;
>
> 80 should really be a #define (and used to declare the length of temp as
> well).
ack
>
>> +
>>
>> if (test_bit(level, kernel_locked_down))
>> - offset += sprintf(temp+offset, "[%s] ", label);
>> + ret = snprintf(temp+offset, write_len, "[%s] ", label);
>> else
>> - offset += sprintf(temp+offset, "%s ", label);
>> + ret = snprintf(temp+offset, write_len, "%s ", label);
>> +
>> + if (ret < 0 || ret >= write_len)
>> + return -ENOMEM;
>
> is ENOMEM right here, or should it be something like EINVAL or E2BIG?
Indeed, I was wondering the same when writing the code initially. I
guess either einval/e2big are both well fitted in this case. If I had to
choose I'd likely go with E2BIG since it's less prevalent than einval
and if someone changes the implementation and starts getting E2BIG it
should be easier to spot where it's coming from. That'd be my only
consideration between the 2.
However, given that this series seems to be unconvincing for the
maintainer I'll defer those changes until it's decided that it's
eventually getting merged :)
>
>> +
>> + offset += ret;
>> }
>> }
>>
>> --
>> 2.34.1
>>
Powered by blists - more mailing lists