2023-09-29 15:29:43

by Wolfram Sang

[permalink] [raw]
Subject: [PATCH v3] i2c: fix memleak in i2c_new_client_device()

Yang Yingliang reported a memleak:
===

I got memory leak as follows when doing fault injection test:

unreferenced object 0xffff888014aec078 (size 8):
comm "xrun", pid 356, jiffies 4294910619 (age 16.332s)
hex dump (first 8 bytes):
31 2d 30 30 31 63 00 00 1-001c..
backtrace:
[<00000000eb56c0a9>] __kmalloc_track_caller+0x1a6/0x300
[<000000000b220ea3>] kvasprintf+0xad/0x140
[<00000000b83203e5>] kvasprintf_const+0x62/0x190
[<000000002a5eab37>] kobject_set_name_vargs+0x56/0x140
[<00000000300ac279>] dev_set_name+0xb0/0xe0
[<00000000b66ebd6f>] i2c_new_client_device+0x7e4/0x9a0

If device_register() returns error in i2c_new_client_device(),
the name allocated by i2c_dev_set_name() need be freed. As
comment of device_register() says, it should use put_device()
to give up the reference in the error path.

===
I think this solution is less intrusive and more robust than he
originally proposed solutions, though.

Reported-by: Yang Yingliang <[email protected]>
Closes: http://patchwork.ozlabs.org/project/linux-i2c/patch/[email protected]/
Signed-off-by: Wolfram Sang <[email protected]>
---

Build tested only.

@Yang Yingliang: I'd be happy if you could test it/comment on it.

drivers/i2c/i2c-core-base.c | 13 +++++++++----
1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/drivers/i2c/i2c-core-base.c b/drivers/i2c/i2c-core-base.c
index cc4a20465456..0d6172d6b808 100644
--- a/drivers/i2c/i2c-core-base.c
+++ b/drivers/i2c/i2c-core-base.c
@@ -931,8 +931,9 @@ int i2c_dev_irq_from_resources(const struct resource *resources,
struct i2c_client *
i2c_new_client_device(struct i2c_adapter *adap, struct i2c_board_info const *info)
{
- struct i2c_client *client;
- int status;
+ struct i2c_client *client;
+ bool need_put = false;
+ int status;

client = kzalloc(sizeof *client, GFP_KERNEL);
if (!client)
@@ -970,7 +971,6 @@ i2c_new_client_device(struct i2c_adapter *adap, struct i2c_board_info const *inf
client->dev.fwnode = info->fwnode;

device_enable_async_suspend(&client->dev);
- i2c_dev_set_name(adap, client, info);

if (info->swnode) {
status = device_add_software_node(&client->dev, info->swnode);
@@ -982,6 +982,7 @@ i2c_new_client_device(struct i2c_adapter *adap, struct i2c_board_info const *inf
}
}

+ i2c_dev_set_name(adap, client, info);
status = device_register(&client->dev);
if (status)
goto out_remove_swnode;
@@ -993,6 +994,7 @@ i2c_new_client_device(struct i2c_adapter *adap, struct i2c_board_info const *inf

out_remove_swnode:
device_remove_software_node(&client->dev);
+ need_put = true;
out_err_put_of_node:
of_node_put(info->of_node);
out_err:
@@ -1000,7 +1002,10 @@ i2c_new_client_device(struct i2c_adapter *adap, struct i2c_board_info const *inf
"Failed to register i2c client %s at 0x%02x (%d)\n",
client->name, client->addr, status);
out_err_silent:
- kfree(client);
+ if (need_put)
+ put_device(&client->dev);
+ else
+ kfree(client);
return ERR_PTR(status);
}
EXPORT_SYMBOL_GPL(i2c_new_client_device);
--
2.30.2


2023-10-23 15:26:35

by Wolfram Sang

[permalink] [raw]
Subject: Re: [PATCH v3] i2c: fix memleak in i2c_new_client_device()

On Fri, Sep 29, 2023 at 11:19:52AM +0200, Wolfram Sang wrote:
> Yang Yingliang reported a memleak:
> ===
>
> I got memory leak as follows when doing fault injection test:
>
> unreferenced object 0xffff888014aec078 (size 8):
> comm "xrun", pid 356, jiffies 4294910619 (age 16.332s)
> hex dump (first 8 bytes):
> 31 2d 30 30 31 63 00 00 1-001c..
> backtrace:
> [<00000000eb56c0a9>] __kmalloc_track_caller+0x1a6/0x300
> [<000000000b220ea3>] kvasprintf+0xad/0x140
> [<00000000b83203e5>] kvasprintf_const+0x62/0x190
> [<000000002a5eab37>] kobject_set_name_vargs+0x56/0x140
> [<00000000300ac279>] dev_set_name+0xb0/0xe0
> [<00000000b66ebd6f>] i2c_new_client_device+0x7e4/0x9a0
>
> If device_register() returns error in i2c_new_client_device(),
> the name allocated by i2c_dev_set_name() need be freed. As
> comment of device_register() says, it should use put_device()
> to give up the reference in the error path.
>
> ===
> I think this solution is less intrusive and more robust than he
> originally proposed solutions, though.
>
> Reported-by: Yang Yingliang <[email protected]>
> Closes: http://patchwork.ozlabs.org/project/linux-i2c/patch/[email protected]/
> Signed-off-by: Wolfram Sang <[email protected]>

Applied to for-next, thanks!


Attachments:
(No filename) (1.36 kB)
signature.asc (849.00 B)
Download all attachments