Re: [PATCH v2 3/3] lockdown: Use snprintf in lockdown_read

[Nikolay Borisov <nik.borisov@suse.com>]

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@suse.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
>>