lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<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

Powered by Openwall GNU/*/Linux Powered by OpenVZ