On 7/28/25 15:39, Serge E. Hallyn wrote:
On Mon, Jul 28, 2025 at 02:15:17PM +0300, Nikolay Borisov wrote:
quoted
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 <redacted>
Thanks, 2 comments below
quoted
---
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
quoted
+
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 :)
quoted
+
+ offset += ret;
}
}
--
2.34.1