All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Laight <david.laight.linux@gmail.com>
To: Krzysztof Kozlowski <krzk@kernel.org>
Cc: Thorsten Blum <thorsten.blum@linux.dev>,
	Huisong Li <lihuisong@huawei.com>,
	Akira Shimahara <akira215corp@gmail.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	stable@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v4] w1: therm: Fix off-by-one buffer overflow in alarms_store
Date: Tue, 16 Dec 2025 09:28:09 +0000	[thread overview]
Message-ID: <20251216092809.2e9b153d@pumpkin> (raw)
In-Reply-To: <243ec26f-1fe1-4b3c-ab24-a6ebab163cde@kernel.org>

On Tue, 16 Dec 2025 08:11:13 +0100
Krzysztof Kozlowski <krzk@kernel.org> wrote:

> On 11/11/2025 21:44, Thorsten Blum wrote:
> > The sysfs buffer passed to alarms_store() is allocated with 'size + 1'
> > bytes and a NUL terminator is appended. However, the 'size' argument
> > does not account for this extra byte. The original code then allocated
> > 'size' bytes and used strcpy() to copy 'buf', which always writes one
> > byte past the allocated buffer since strcpy() copies until the NUL
> > terminator at index 'size'.
> > 
> > Fix this by parsing the 'buf' parameter directly using simple_strtoll()
> > without allocating any intermediate memory or string copying. This
> > removes the overflow while simplifying the code.
> > 
> > Cc: stable@vger.kernel.org
> > Fixes: e2c94d6f5720 ("w1_therm: adding alarm sysfs entry")
> > Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
> > ---
> > Compile-tested only.
> > 
> > Changes in v4:
> > - Use simple_strtoll because kstrtoint also parses long long internally
> > - Return -ERANGE in addition to -EINVAL to match kstrtoint's behavior
> > - Remove any changes unrelated to fixing the buffer overflow (Krzysztof)
> >   while maintaining the same behavior and return values as before
> > - Link to v3: https://lore.kernel.org/lkml/20251030155614.447905-1-thorsten.blum@linux.dev/
> > 
> > Changes in v3:
> > - Add integer range check for 'temp' to match kstrtoint() behavior
> > - Explicitly cast 'temp' to int when calling int_to_short()
> > - Link to v2: https://lore.kernel.org/lkml/20251029130045.70127-2-thorsten.blum@linux.dev/
> > 
> > Changes in v2:
> > - Fix buffer overflow instead of truncating the copy using strscpy()
> > - Parse buffer directly using simple_strtol() as suggested by David
> > - Update patch subject and description
> > - Link to v1: https://lore.kernel.org/lkml/20251017170047.114224-2-thorsten.blum@linux.dev/
> > ---
> >  drivers/w1/slaves/w1_therm.c | 64 ++++++++++++------------------------
> >  1 file changed, 21 insertions(+), 43 deletions(-)
> > 
> > diff --git a/drivers/w1/slaves/w1_therm.c b/drivers/w1/slaves/w1_therm.c
> > index 9ccedb3264fb..5707fa34e804 100644
> > --- a/drivers/w1/slaves/w1_therm.c
> > +++ b/drivers/w1/slaves/w1_therm.c
> > @@ -1836,55 +1836,36 @@ static ssize_t alarms_store(struct device *device,
> >  	struct w1_slave *sl = dev_to_w1_slave(device);
> >  	struct therm_info info;
> >  	u8 new_config_register[3];	/* array of data to be written */
> > -	int temp, ret;
> > -	char *token = NULL;
> > +	long long temp;
> > +	int ret = 0;
> >  	s8 tl, th;	/* 1 byte per value + temp ring order */
> > -	char *p_args, *orig;
> > -
> > -	p_args = orig = kmalloc(size, GFP_KERNEL);
> > -	/* Safe string copys as buf is const */
> > -	if (!p_args) {
> > -		dev_warn(device,
> > -			"%s: error unable to allocate memory %d\n",
> > -			__func__, -ENOMEM);
> > -		return size;
> > -	}
> > -	strcpy(p_args, buf);
> > -
> > -	/* Split string using space char */
> > -	token = strsep(&p_args, " ");
> > -
> > -	if (!token)	{
> > -		dev_info(device,
> > -			"%s: error parsing args %d\n", __func__, -EINVAL);
> > -		goto free_m;
> > -	}
> > -
> > -	/* Convert 1st entry to int */
> > -	ret = kstrtoint (token, 10, &temp);
> > +	const char *p = buf;
> > +	char *endp;
> > +
> > +	temp = simple_strtoll(p, &endp, 10);  
> 
> Why using this, instead of explicitly encouraged kstrtoll()?

Because the code needs to look at the terminating character.
The kstrtoxxx() family only support buffers that contain a single value.
While they return an indication of 'overflow' they are useless for
more general parameter parsing.

The simple_strtoxxx() could detect overflow and then set 'endp'
to the digit that make the value too big - which should give an
error provided the callers checks the separator.

I don't know the full history of these functions...

	David


> 
> > +	if (p == endp || *endp != ' ')
> > +		ret = -EINVAL;
> > +	else if (temp < INT_MIN || temp > INT_MAX)
> > +		ret = -ERANGE;
> >  	if (ret) {
> >  		dev_info(device,
> >  			"%s: error parsing args %d\n", __func__, ret);
> > -		goto free_m;
> > +		goto err;  
> 
> So this is just return size.
> 
> 
> Best regards,
> Krzysztof


  reply	other threads:[~2025-12-16 11:19 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-11-11 20:44 [PATCH v4] w1: therm: Fix off-by-one buffer overflow in alarms_store Thorsten Blum
2025-11-24 11:05 ` Thorsten Blum
2025-12-16  7:11 ` Krzysztof Kozlowski
2025-12-16  9:28   ` David Laight [this message]
2025-12-16 13:16     ` Krzysztof Kozlowski
2025-12-16 12:30   ` Thorsten Blum
2025-12-16 13:17     ` Krzysztof Kozlowski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20251216092809.2e9b153d@pumpkin \
    --to=david.laight.linux@gmail.com \
    --cc=akira215corp@gmail.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=krzk@kernel.org \
    --cc=lihuisong@huawei.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=stable@vger.kernel.org \
    --cc=thorsten.blum@linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.