2019-10-19 14:24:14

by Stephen Kitt

[permalink] [raw]
Subject: [PATCH v3] clk/ti/adpll: allocate room for terminating null

The buffer allocated in ti_adpll_clk_get_name doesn't account for the
terminating null. This patch switches to devm_kasprintf to avoid
overflowing.

Signed-off-by: Stephen Kitt <[email protected]>
---
Changes since v2:
- Move "adpll" into the format string and drop base_name entirely.

Changes since v1:
- Use devm_kasprintf instead of manually allocating the target
buffer.
---
drivers/clk/ti/adpll.c | 11 ++---------
1 file changed, 2 insertions(+), 9 deletions(-)

diff --git a/drivers/clk/ti/adpll.c b/drivers/clk/ti/adpll.c
index fdfb90058504..bb2f2836dab2 100644
--- a/drivers/clk/ti/adpll.c
+++ b/drivers/clk/ti/adpll.c
@@ -194,15 +194,8 @@ static const char *ti_adpll_clk_get_name(struct ti_adpll_data *d,
if (err)
return NULL;
} else {
- const char *base_name = "adpll";
- char *buf;
-
- buf = devm_kzalloc(d->dev, 8 + 1 + strlen(base_name) + 1 +
- strlen(postfix), GFP_KERNEL);
- if (!buf)
- return NULL;
- sprintf(buf, "%08lx.%s.%s", d->pa, base_name, postfix);
- name = buf;
+ name = devm_kasprintf(d->dev, GFP_KERNEL, "%08lx.adpll.%s",
+ d->pa, postfix);
}

return name;
--
2.20.1


2019-10-21 14:31:54

by Tony Lindgren

[permalink] [raw]
Subject: Re: [PATCH v3] clk/ti/adpll: allocate room for terminating null

* Stephen Kitt <[email protected]> [191019 14:07]:
> The buffer allocated in ti_adpll_clk_get_name doesn't account for the
> terminating null. This patch switches to devm_kasprintf to avoid
> overflowing.
>
> Signed-off-by: Stephen Kitt <[email protected]>
> ---
> Changes since v2:
> - Move "adpll" into the format string and drop base_name entirely.
>
> Changes since v1:
> - Use devm_kasprintf instead of manually allocating the target
> buffer.

Acked-by: Tony Lindgren <[email protected]>

> ---
> drivers/clk/ti/adpll.c | 11 ++---------
> 1 file changed, 2 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/clk/ti/adpll.c b/drivers/clk/ti/adpll.c
> index fdfb90058504..bb2f2836dab2 100644
> --- a/drivers/clk/ti/adpll.c
> +++ b/drivers/clk/ti/adpll.c
> @@ -194,15 +194,8 @@ static const char *ti_adpll_clk_get_name(struct ti_adpll_data *d,
> if (err)
> return NULL;
> } else {
> - const char *base_name = "adpll";
> - char *buf;
> -
> - buf = devm_kzalloc(d->dev, 8 + 1 + strlen(base_name) + 1 +
> - strlen(postfix), GFP_KERNEL);
> - if (!buf)
> - return NULL;
> - sprintf(buf, "%08lx.%s.%s", d->pa, base_name, postfix);
> - name = buf;
> + name = devm_kasprintf(d->dev, GFP_KERNEL, "%08lx.adpll.%s",
> + d->pa, postfix);
> }
>
> return name;
> --
> 2.20.1
>

2019-11-08 17:02:38

by Stephen Boyd

[permalink] [raw]
Subject: Re: [PATCH v3] clk/ti/adpll: allocate room for terminating null

Quoting Stephen Kitt (2019-10-19 07:06:34)
> The buffer allocated in ti_adpll_clk_get_name doesn't account for the
> terminating null. This patch switches to devm_kasprintf to avoid
> overflowing.
>
> Signed-off-by: Stephen Kitt <[email protected]>
> ---

Please don't send as replies to existing threads. It screws up my
tooling and makes it more manual to apply the patch. I guess I'll have
to go fix my scripts to ignore certain emails.

2019-11-08 17:05:32

by Stephen Boyd

[permalink] [raw]
Subject: Re: [PATCH v3] clk/ti/adpll: allocate room for terminating null

Quoting Stephen Kitt (2019-10-19 07:06:34)
> The buffer allocated in ti_adpll_clk_get_name doesn't account for the
> terminating null. This patch switches to devm_kasprintf to avoid
> overflowing.
>
> Signed-off-by: Stephen Kitt <[email protected]>
> ---

Applied to clk-next

2019-11-08 20:19:48

by Stephen Kitt

[permalink] [raw]
Subject: Re: [PATCH v3] clk/ti/adpll: allocate room for terminating null

On Fri, 08 Nov 2019 09:00:25 -0800, Stephen Boyd <[email protected]> wrote:
> Quoting Stephen Kitt (2019-10-19 07:06:34)
> > The buffer allocated in ti_adpll_clk_get_name doesn't account for the
> > terminating null. This patch switches to devm_kasprintf to avoid
> > overflowing.
> >
> > Signed-off-by: Stephen Kitt <[email protected]>
> > ---
>
> Please don't send as replies to existing threads. It screws up my
> tooling and makes it more manual to apply the patch. I guess I'll have
> to go fix my scripts to ignore certain emails.

My bad, sorry about that, I misread the In-Reply-To section of
submitting-patches :-(.

Regards,

Stephen


Attachments:
(No filename) (849.00 B)
OpenPGP digital signature