linux-kernel - AW: [PATCH 1/4] clk: mvebu: Fix a memory leak in an error handling path

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 23 Apr 2021 11:42:30 +0000
From:   Walter Harms <wharms@....de>
To:     Christophe JAILLET <christophe.jaillet@...adoo.fr>,
        "mturquette@...libre.com" <mturquette@...libre.com>,
        "sboyd@...nel.org" <sboyd@...nel.org>,
        "gregory.clement@...tlin.com" <gregory.clement@...tlin.com>,
        "thomas.petazzoni@...e-electrons.com" 
        <thomas.petazzoni@...e-electrons.com>
CC:     "linux-clk@...r.kernel.org" <linux-clk@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "kernel-janitors@...r.kernel.org" <kernel-janitors@...r.kernel.org>
Subject: AW: [PATCH 1/4] clk: mvebu: Fix a memory leak in an error handling
 path

nitpicking:
 clk_name could be replaced with cpuclk[cpu].clk_name

and the commit msg is from the other patch (free  cpuclk[cpu].clk_name)

jm2c,

re,
 wh
________________________________________
Von: Christophe JAILLET <christophe.jaillet@...adoo.fr>
Gesendet: Freitag, 23. April 2021 08:25:01
An: mturquette@...libre.com; sboyd@...nel.org; gregory.clement@...tlin.com; thomas.petazzoni@...e-electrons.com
Cc: linux-clk@...r.kernel.org; linux-kernel@...r.kernel.org; kernel-janitors@...r.kernel.org; Christophe JAILLET
Betreff: [PATCH 1/4] clk: mvebu: Fix a memory leak in an error handling path

WARNUNG: Diese E-Mail kam von außerhalb der Organisation. Klicken Sie nicht auf Links oder öffnen Sie keine Anhänge, es sei denn, Sie kennen den/die Absender*in und wissen, dass der Inhalt sicher ist.


If an error occurs in the for_each loop, clk_name must be freed.

In order to do so, sightly rearrange the code:
   - move the allocation to simplify error handling
   - use kasprintf instead of kzalloc/sprintf to simplify code and avoid a
     magic number

Fixes: ab8ba01b3fe5 ("clk: mvebu: add armada-370-xp CPU specific clocks")
Signed-off-by: Christophe JAILLET <christophe.jaillet@...adoo.fr>
---
The { } around the 1 line block after kasprintf is intentional and makes
sense with 2/2
---
 drivers/clk/mvebu/clk-cpu.c | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/clk/mvebu/clk-cpu.c b/drivers/clk/mvebu/clk-cpu.c
index c2af3395cf13..a11d7273fcc7 100644
--- a/drivers/clk/mvebu/clk-cpu.c
+++ b/drivers/clk/mvebu/clk-cpu.c
@@ -195,17 +195,17 @@ static void __init of_cpu_clk_setup(struct device_node *node)
        for_each_of_cpu_node(dn) {
                struct clk_init_data init;
                struct clk *clk;
-               char *clk_name = kzalloc(5, GFP_KERNEL);
+               char *clk_name;
                int cpu, err;

-               if (WARN_ON(!clk_name))
-                       goto bail_out;
-
                err = of_property_read_u32(dn, "reg", &cpu);
                if (WARN_ON(err))
                        goto bail_out;

-               sprintf(clk_name, "cpu%d", cpu);
+               clk_name = kasprintf(GFP_KERNEL, "cpu%d", cpu);
+               if (WARN_ON(!clk_name)) {
+                       goto bail_out;
+               }

                cpuclk[cpu].parent_name = of_clk_get_parent_name(node, 0);
                cpuclk[cpu].clk_name = clk_name;
--
2.27.0