| Message ID | 20240229122250.24786-1-duoming@zju.edu.cn (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [v2] clk: zynq: Prevent null pointer dereference caused by kmalloc failure | expand |
On 2/29/24 13:22, 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 adds 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 v2: > - Use stack variable to replace kmalloc(). > > drivers/clk/zynq/clkc.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/drivers/clk/zynq/clkc.c b/drivers/clk/zynq/clkc.c > index 7bdeaff2bfd..e4c4c9adf79 100644 > --- a/drivers/clk/zynq/clkc.c > +++ b/drivers/clk/zynq/clkc.c > @@ -427,7 +427,7 @@ static void __init zynq_clk_setup(struct device_node *np) > SLCR_GEM1_CLK_CTRL, 0, 0, &gem1clk_lock); > > tmp = strlen("mio_clk_00x"); > - clk_name = kmalloc(tmp, GFP_KERNEL); > + char clk_name[tmp]; I know that Stephen asked for it but variable with variable length in the middle of code doesn't look good or useful. I would allocate rather bigger array on stack with size bigger than max length which will use it. Thanks, Michal
On Thu, 29 Feb 2024 13:45:54 +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 adds 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 v2: > > - Use stack variable to replace kmalloc(). > > > > drivers/clk/zynq/clkc.c | 3 +-- > > 1 file changed, 1 insertion(+), 2 deletions(-) > > > > diff --git a/drivers/clk/zynq/clkc.c b/drivers/clk/zynq/clkc.c > > index 7bdeaff2bfd..e4c4c9adf79 100644 > > --- a/drivers/clk/zynq/clkc.c > > +++ b/drivers/clk/zynq/clkc.c > > @@ -427,7 +427,7 @@ static void __init zynq_clk_setup(struct device_node *np) > > SLCR_GEM1_CLK_CTRL, 0, 0, &gem1clk_lock); > > > > tmp = strlen("mio_clk_00x"); > > - clk_name = kmalloc(tmp, GFP_KERNEL); > > + char clk_name[tmp]; > > I know that Stephen asked for it but variable with variable length in the middle > of code doesn't look good or useful. > I would allocate rather bigger array on stack with size bigger than max length > which will use it. The length of "mio_clk_00x" is 11 bytes, and the kernel will alloc 16 bytes to it. I use a local variable whose size is 16 bytes to replace it. The detail is shown below: diff --git a/drivers/clk/zynq/clkc.c b/drivers/clk/zynq/clkc.c index 7bdeaff2bfd..81d530e3357 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]; @@ -427,7 +427,6 @@ static void __init zynq_clk_setup(struct device_node *np) 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; @@ -439,7 +438,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); Do you think the above is better? Best regards, Duoming Zhou
Quoting Michal Simek (2024-02-29 04:45:54) > On 2/29/24 13:22, Duoming Zhou wrote: > > diff --git a/drivers/clk/zynq/clkc.c b/drivers/clk/zynq/clkc.c > > index 7bdeaff2bfd..e4c4c9adf79 100644 > > --- a/drivers/clk/zynq/clkc.c > > +++ b/drivers/clk/zynq/clkc.c > > @@ -427,7 +427,7 @@ static void __init zynq_clk_setup(struct device_node *np) > > SLCR_GEM1_CLK_CTRL, 0, 0, &gem1clk_lock); > > > > tmp = strlen("mio_clk_00x"); > > - clk_name = kmalloc(tmp, GFP_KERNEL); > > + char clk_name[tmp]; > > I know that Stephen asked for it but variable with variable length in the middle > of code doesn't look good or useful. I didn't ask for it to be in the middle of the function :)
Quoting duoming@zju.edu.cn (2024-02-29 06:16:28) > On Thu, 29 Feb 2024 13:45:54 +0100 Michal Simek wrote: > > The length of "mio_clk_00x" is 11 bytes, and the kernel will alloc 16 bytes to it. > I use a local variable whose size is 16 bytes to replace it. The detail is shown > below: > > diff --git a/drivers/clk/zynq/clkc.c b/drivers/clk/zynq/clkc.c > index 7bdeaff2bfd..81d530e3357 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]; > @@ -427,7 +427,6 @@ static void __init zynq_clk_setup(struct device_node *np) > SLCR_GEM1_CLK_CTRL, 0, 0, &gem1clk_lock); > > tmp = strlen("mio_clk_00x"); Is tmp used now? > - clk_name = kmalloc(tmp, GFP_KERNEL); > for (i = 0; i < NUM_MIO_PINS; i++) { > int idx; > > @@ -439,7 +438,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); > > Do you think the above is better? > It's getting there.
On 3/1/24 02:21, Stephen Boyd wrote: > Quoting Michal Simek (2024-02-29 04:45:54) >> On 2/29/24 13:22, Duoming Zhou wrote: >>> diff --git a/drivers/clk/zynq/clkc.c b/drivers/clk/zynq/clkc.c >>> index 7bdeaff2bfd..e4c4c9adf79 100644 >>> --- a/drivers/clk/zynq/clkc.c >>> +++ b/drivers/clk/zynq/clkc.c >>> @@ -427,7 +427,7 @@ static void __init zynq_clk_setup(struct device_node *np) >>> SLCR_GEM1_CLK_CTRL, 0, 0, &gem1clk_lock); >>> >>> tmp = strlen("mio_clk_00x"); >>> - clk_name = kmalloc(tmp, GFP_KERNEL); >>> + char clk_name[tmp]; >> >> I know that Stephen asked for it but variable with variable length in the middle >> of code doesn't look good or useful. > > I didn't ask for it to be in the middle of the function :) I didn't say it. :-) I know it was about putting it on the stack instead. M
diff --git a/drivers/clk/zynq/clkc.c b/drivers/clk/zynq/clkc.c index 7bdeaff2bfd..e4c4c9adf79 100644 --- a/drivers/clk/zynq/clkc.c +++ b/drivers/clk/zynq/clkc.c @@ -427,7 +427,7 @@ static void __init zynq_clk_setup(struct device_node *np) SLCR_GEM1_CLK_CTRL, 0, 0, &gem1clk_lock); tmp = strlen("mio_clk_00x"); - clk_name = kmalloc(tmp, GFP_KERNEL); + char clk_name[tmp]; for (i = 0; i < NUM_MIO_PINS; i++) { int idx; @@ -439,7 +439,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);
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 adds 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 v2: - Use stack variable to replace kmalloc(). drivers/clk/zynq/clkc.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)