[PATCH] s390/cmm: Account for NUL when calculating 'len' in cmm_timeout_handler

Thorsten Blum posted 1 patch 1 month, 3 weeks ago
arch/s390/mm/cmm.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
[PATCH] s390/cmm: Account for NUL when calculating 'len' in cmm_timeout_handler
Posted by Thorsten Blum 1 month, 3 weeks ago
When the input length 'lenp' equals sizeof(buf), the current code copies
all 64 bytes, but then immediately overwrites the last byte with a NUL
terminator. Limit the number of bytes to copy to 'sizeof(buf) - 1' to
reserve space for the NUL terminator.

Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
---
 arch/s390/mm/cmm.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/s390/mm/cmm.c b/arch/s390/mm/cmm.c
index eb7ef63fab1e..06512bc178a5 100644
--- a/arch/s390/mm/cmm.c
+++ b/arch/s390/mm/cmm.c
@@ -311,9 +311,9 @@ static int cmm_timeout_handler(const struct ctl_table *ctl, int write,
 	}
 
 	if (write) {
-		len = min(*lenp, sizeof(buf));
+		len = min(*lenp, sizeof(buf) - 1);
 		memcpy(buf, buffer, len);
-		buf[len - 1] = '\0';
+		buf[len] = '\0';
 		cmm_skip_blanks(buf, &p);
 		nr = simple_strtoul(p, &p, 0);
 		cmm_skip_blanks(p, &p);
-- 
Thorsten Blum <thorsten.blum@linux.dev>
GPG: 1D60 735E 8AEF 3BE4 73B6  9D84 7336 78FD 8DFE EAD4
Re: [PATCH] s390/cmm: Account for NUL when calculating 'len' in cmm_timeout_handler
Posted by Alexander Gordeev 1 month, 3 weeks ago
On Mon, Dec 15, 2025 at 01:22:14PM +0100, Thorsten Blum wrote:

Hi Thorsten,

> When the input length 'lenp' equals sizeof(buf), the current code copies
> all 64 bytes, but then immediately overwrites the last byte with a NUL
> terminator. Limit the number of bytes to copy to 'sizeof(buf) - 1' to
> reserve space for the NUL terminator.

I see you point, but can not see much of the benefit. Besides,
to me buf[len] = '\0' rings like a past-end-of-the-buffer access
(although it is not, it feels like that on a cursory look).

> Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
> ---
>  arch/s390/mm/cmm.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/s390/mm/cmm.c b/arch/s390/mm/cmm.c
> index eb7ef63fab1e..06512bc178a5 100644
> --- a/arch/s390/mm/cmm.c
> +++ b/arch/s390/mm/cmm.c
> @@ -311,9 +311,9 @@ static int cmm_timeout_handler(const struct ctl_table *ctl, int write,
>  	}
>  
>  	if (write) {
> -		len = min(*lenp, sizeof(buf));
> +		len = min(*lenp, sizeof(buf) - 1);
>  		memcpy(buf, buffer, len);
> -		buf[len - 1] = '\0';
> +		buf[len] = '\0';
>  		cmm_skip_blanks(buf, &p);
>  		nr = simple_strtoul(p, &p, 0);
>  		cmm_skip_blanks(p, &p);
> -- 
> Thorsten Blum <thorsten.blum@linux.dev>

Thanks!
Re: [PATCH] s390/cmm: Account for NUL when calculating 'len' in cmm_timeout_handler
Posted by Heiko Carstens 1 month, 2 weeks ago
On Thu, Dec 18, 2025 at 08:57:24AM +0100, Alexander Gordeev wrote:
> On Mon, Dec 15, 2025 at 01:22:14PM +0100, Thorsten Blum wrote:
> > When the input length 'lenp' equals sizeof(buf), the current code copies
> > all 64 bytes, but then immediately overwrites the last byte with a NUL
> > terminator. Limit the number of bytes to copy to 'sizeof(buf) - 1' to
> > reserve space for the NUL terminator.
> 
> I see you point, but can not see much of the benefit. Besides,
> to me buf[len] = '\0' rings like a past-end-of-the-buffer access
> (although it is not, it feels like that on a cursory look).
> 
> > Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
> > ---
> >  arch/s390/mm/cmm.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/arch/s390/mm/cmm.c b/arch/s390/mm/cmm.c
> > index eb7ef63fab1e..06512bc178a5 100644
> > --- a/arch/s390/mm/cmm.c
> > +++ b/arch/s390/mm/cmm.c
> > @@ -311,9 +311,9 @@ static int cmm_timeout_handler(const struct ctl_table *ctl, int write,
> >  	}
> >  
> >  	if (write) {
> > -		len = min(*lenp, sizeof(buf));
> > +		len = min(*lenp, sizeof(buf) - 1);
> >  		memcpy(buf, buffer, len);
> > -		buf[len - 1] = '\0';
> > +		buf[len] = '\0';

Well, I don't see any point at all: the compiler is able to tell the
same and may or may not generate code accordingly to what this patch
tries to improve. This patch is pointless.