[v3] clk: zynq: Prevent null pointer dereference caused by kmalloc failure

[PATCH v3] clk: zynq: Prevent null pointer dereference caused by kmalloc failure

Posted by Duoming Zhou 1 year, 11 months ago

The kmalloc() in zynq_clk_setup() will return null if the
physical memory has run out. As a result, if we use snprintf()
to write data to the null address, the null pointer dereference
bug will happen.

This patch uses a stack variable to replace the kmalloc().

Fixes: 0ee52b157b8e ("clk: zynq: Add clock controller driver")
Signed-off-by: Duoming Zhou <duoming@zju.edu.cn>
---
Changes in v3:
  - Put stack variable in the head of the function and remove variable tmp.

 drivers/clk/zynq/clkc.c | 7 ++-----
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/drivers/clk/zynq/clkc.c b/drivers/clk/zynq/clkc.c
index 7bdeaff2bfd..45479653c3b 100644
--- a/drivers/clk/zynq/clkc.c
+++ b/drivers/clk/zynq/clkc.c
@@ -215,7 +215,7 @@ static void __init zynq_clk_setup(struct device_node *np)
 	int i;
 	u32 tmp;
 	int ret;
-	char *clk_name;
+	char clk_name[16];
 	unsigned int fclk_enable = 0;
 	const char *clk_output_name[clk_max];
 	const char *cpu_parents[4];
@@ -426,12 +426,10 @@ static void __init zynq_clk_setup(struct device_node *np)
 			"gem1_emio_mux", CLK_SET_RATE_PARENT,
 			SLCR_GEM1_CLK_CTRL, 0, 0, &gem1clk_lock);
 
-	tmp = strlen("mio_clk_00x");
-	clk_name = kmalloc(tmp, GFP_KERNEL);
 	for (i = 0; i < NUM_MIO_PINS; i++) {
 		int idx;
 
-		snprintf(clk_name, tmp, "mio_clk_%2.2d", i);
+		snprintf(clk_name, 16, "mio_clk_%2.2d", i);
 		idx = of_property_match_string(np, "clock-names", clk_name);
 		if (idx >= 0)
 			can_mio_mux_parents[i] = of_clk_get_parent_name(np,
@@ -439,7 +437,6 @@ static void __init zynq_clk_setup(struct device_node *np)
 		else
 			can_mio_mux_parents[i] = dummy_nm;
 	}
-	kfree(clk_name);
 	clk_register_mux(NULL, "can_mux", periph_parents, 4,
 			CLK_SET_RATE_NO_REPARENT, SLCR_CAN_CLK_CTRL, 4, 2, 0,
 			&canclk_lock);
-- 
2.17.1

Re: [PATCH v3] clk: zynq: Prevent null pointer dereference caused by kmalloc failure

Posted by Michal Simek 1 year, 11 months ago


On 3/1/24 08:03, Duoming Zhou wrote:
> The kmalloc() in zynq_clk_setup() will return null if the
> physical memory has run out. As a result, if we use snprintf()
> to write data to the null address, the null pointer dereference
> bug will happen.
> 
> This patch uses a stack variable to replace the kmalloc().
> 
> Fixes: 0ee52b157b8e ("clk: zynq: Add clock controller driver")
> Signed-off-by: Duoming Zhou <duoming@zju.edu.cn>
> ---
> Changes in v3:
>    - Put stack variable in the head of the function and remove variable tmp.
> 
>   drivers/clk/zynq/clkc.c | 7 ++-----
>   1 file changed, 2 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/clk/zynq/clkc.c b/drivers/clk/zynq/clkc.c
> index 7bdeaff2bfd..45479653c3b 100644
> --- a/drivers/clk/zynq/clkc.c
> +++ b/drivers/clk/zynq/clkc.c
> @@ -215,7 +215,7 @@ static void __init zynq_clk_setup(struct device_node *np)
>   	int i;
>   	u32 tmp;
>   	int ret;
> -	char *clk_name;
> +	char clk_name[16];
>   	unsigned int fclk_enable = 0;
>   	const char *clk_output_name[clk_max];
>   	const char *cpu_parents[4];
> @@ -426,12 +426,10 @@ static void __init zynq_clk_setup(struct device_node *np)
>   			"gem1_emio_mux", CLK_SET_RATE_PARENT,
>   			SLCR_GEM1_CLK_CTRL, 0, 0, &gem1clk_lock);
>   
> -	tmp = strlen("mio_clk_00x");
> -	clk_name = kmalloc(tmp, GFP_KERNEL);
>   	for (i = 0; i < NUM_MIO_PINS; i++) {
>   		int idx;
>   
> -		snprintf(clk_name, tmp, "mio_clk_%2.2d", i);
> +		snprintf(clk_name, 16, "mio_clk_%2.2d", i);

I would prefer to use macro/define if that values has to match and have connection.

Thanks,
Michal

Re: [PATCH v3] clk: zynq: Prevent null pointer dereference caused by kmalloc failure

Posted by duoming@zju.edu.cn 1 year, 11 months ago

On Fri, 1 Mar 2024 08:05:17 +0100 Michal Simek wrote:
> > The kmalloc() in zynq_clk_setup() will return null if the
> > physical memory has run out. As a result, if we use snprintf()
> > to write data to the null address, the null pointer dereference
> > bug will happen.
> > 
> > This patch uses a stack variable to replace the kmalloc().
> > 
> > Fixes: 0ee52b157b8e ("clk: zynq: Add clock controller driver")
> > Signed-off-by: Duoming Zhou <duoming@zju.edu.cn>
> > ---
> > Changes in v3:
> >    - Put stack variable in the head of the function and remove variable tmp.
> > 
> >   drivers/clk/zynq/clkc.c | 7 ++-----
> >   1 file changed, 2 insertions(+), 5 deletions(-)
> > 
> > diff --git a/drivers/clk/zynq/clkc.c b/drivers/clk/zynq/clkc.c
> > index 7bdeaff2bfd..45479653c3b 100644
> > --- a/drivers/clk/zynq/clkc.c
> > +++ b/drivers/clk/zynq/clkc.c
> > @@ -215,7 +215,7 @@ static void __init zynq_clk_setup(struct device_node *np)
> >   	int i;
> >   	u32 tmp;
> >   	int ret;
> > -	char *clk_name;
> > +	char clk_name[16];
> >   	unsigned int fclk_enable = 0;
> >   	const char *clk_output_name[clk_max];
> >   	const char *cpu_parents[4];
> > @@ -426,12 +426,10 @@ static void __init zynq_clk_setup(struct device_node *np)
> >   			"gem1_emio_mux", CLK_SET_RATE_PARENT,
> >   			SLCR_GEM1_CLK_CTRL, 0, 0, &gem1clk_lock);
> >   
> > -	tmp = strlen("mio_clk_00x");
> > -	clk_name = kmalloc(tmp, GFP_KERNEL);
> >   	for (i = 0; i < NUM_MIO_PINS; i++) {
> >   		int idx;
> >   
> > -		snprintf(clk_name, tmp, "mio_clk_%2.2d", i);
> > +		snprintf(clk_name, 16, "mio_clk_%2.2d", i);
> 
> I would prefer to use macro/define if that values has to match and have connection.

The origin code "clk_name = kmalloc(tmp, GFP_KERNEL)" allocates 16 bytes, so I set
the size of stack variable clk_name to 16 bytes. 

Do you think if we use "#define CLK_NAME_LEN 16" is better?

Best regards,
Duoming Zhou

Re: [PATCH v3] clk: zynq: Prevent null pointer dereference caused by kmalloc failure

Posted by Michal Simek 1 year, 11 months ago


On 3/1/24 08:24, duoming@zju.edu.cn wrote:
> On Fri, 1 Mar 2024 08:05:17 +0100 Michal Simek wrote:
>>> The kmalloc() in zynq_clk_setup() will return null if the
>>> physical memory has run out. As a result, if we use snprintf()
>>> to write data to the null address, the null pointer dereference
>>> bug will happen.
>>>
>>> This patch uses a stack variable to replace the kmalloc().
>>>
>>> Fixes: 0ee52b157b8e ("clk: zynq: Add clock controller driver")
>>> Signed-off-by: Duoming Zhou <duoming@zju.edu.cn>
>>> ---
>>> Changes in v3:
>>>     - Put stack variable in the head of the function and remove variable tmp.
>>>
>>>    drivers/clk/zynq/clkc.c | 7 ++-----
>>>    1 file changed, 2 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/drivers/clk/zynq/clkc.c b/drivers/clk/zynq/clkc.c
>>> index 7bdeaff2bfd..45479653c3b 100644
>>> --- a/drivers/clk/zynq/clkc.c
>>> +++ b/drivers/clk/zynq/clkc.c
>>> @@ -215,7 +215,7 @@ static void __init zynq_clk_setup(struct device_node *np)
>>>    	int i;
>>>    	u32 tmp;
>>>    	int ret;
>>> -	char *clk_name;
>>> +	char clk_name[16];
>>>    	unsigned int fclk_enable = 0;
>>>    	const char *clk_output_name[clk_max];
>>>    	const char *cpu_parents[4];
>>> @@ -426,12 +426,10 @@ static void __init zynq_clk_setup(struct device_node *np)
>>>    			"gem1_emio_mux", CLK_SET_RATE_PARENT,
>>>    			SLCR_GEM1_CLK_CTRL, 0, 0, &gem1clk_lock);
>>>    
>>> -	tmp = strlen("mio_clk_00x");
>>> -	clk_name = kmalloc(tmp, GFP_KERNEL);
>>>    	for (i = 0; i < NUM_MIO_PINS; i++) {
>>>    		int idx;
>>>    
>>> -		snprintf(clk_name, tmp, "mio_clk_%2.2d", i);
>>> +		snprintf(clk_name, 16, "mio_clk_%2.2d", i);
>>
>> I would prefer to use macro/define if that values has to match and have connection.
> 
> The origin code "clk_name = kmalloc(tmp, GFP_KERNEL)" allocates 16 bytes, so I set
> the size of stack variable clk_name to 16 bytes.
> 
> Do you think if we use "#define CLK_NAME_LEN 16" is better?

name is fine for me. What macro gives you is that you know that number 16 from 
array size is the same number 16 which you are checking.
It is clear from your patch but some time from now someone can change just one 
part of code without looking at connection.

M

Re: [PATCH v3] clk: zynq: Prevent null pointer dereference caused by kmalloc failure

Posted by duoming@zju.edu.cn 1 year, 11 months ago

On Fri, 1 Mar 2024 08:30:05 +0100 Michal Simek wrote:
> >>> The kmalloc() in zynq_clk_setup() will return null if the
> >>> physical memory has run out. As a result, if we use snprintf()
> >>> to write data to the null address, the null pointer dereference
> >>> bug will happen.
> >>>
> >>> This patch uses a stack variable to replace the kmalloc().
> >>>
> >>> Fixes: 0ee52b157b8e ("clk: zynq: Add clock controller driver")
> >>> Signed-off-by: Duoming Zhou <duoming@zju.edu.cn>
> >>> ---
> >>> Changes in v3:
> >>>     - Put stack variable in the head of the function and remove variable tmp.
> >>>
> >>>    drivers/clk/zynq/clkc.c | 7 ++-----
> >>>    1 file changed, 2 insertions(+), 5 deletions(-)
> >>>
> >>> diff --git a/drivers/clk/zynq/clkc.c b/drivers/clk/zynq/clkc.c
> >>> index 7bdeaff2bfd..45479653c3b 100644
> >>> --- a/drivers/clk/zynq/clkc.c
> >>> +++ b/drivers/clk/zynq/clkc.c
> >>> @@ -215,7 +215,7 @@ static void __init zynq_clk_setup(struct device_node *np)
> >>>    	int i;
> >>>    	u32 tmp;
> >>>    	int ret;
> >>> -	char *clk_name;
> >>> +	char clk_name[16];
> >>>    	unsigned int fclk_enable = 0;
> >>>    	const char *clk_output_name[clk_max];
> >>>    	const char *cpu_parents[4];
> >>> @@ -426,12 +426,10 @@ static void __init zynq_clk_setup(struct device_node *np)
> >>>    			"gem1_emio_mux", CLK_SET_RATE_PARENT,
> >>>    			SLCR_GEM1_CLK_CTRL, 0, 0, &gem1clk_lock);
> >>>    
> >>> -	tmp = strlen("mio_clk_00x");
> >>> -	clk_name = kmalloc(tmp, GFP_KERNEL);
> >>>    	for (i = 0; i < NUM_MIO_PINS; i++) {
> >>>    		int idx;
> >>>    
> >>> -		snprintf(clk_name, tmp, "mio_clk_%2.2d", i);
> >>> +		snprintf(clk_name, 16, "mio_clk_%2.2d", i);
> >>
> >> I would prefer to use macro/define if that values has to match and have connection.
> > 
> > The origin code "clk_name = kmalloc(tmp, GFP_KERNEL)" allocates 16 bytes, so I set
> > the size of stack variable clk_name to 16 bytes.
> > 
> > Do you think if we use "#define CLK_NAME_LEN 16" is better?
> 
> name is fine for me. What macro gives you is that you know that number 16 from 
> array size is the same number 16 which you are checking.
> It is clear from your patch but some time from now someone can change just one 
> part of code without looking at connection.

Thank you for your suggestions! I will use "CLK_NAME_LEN" to replace the 16.

Best regards,
Duoming Zhou