linux-kernel - Re: [PATCH v3] zram: don't free statically defined names

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]

Message-ID: <8294e492-5811-44de-8ee2-5f460a065f54@wanadoo.fr>
Date: Tue, 24 Sep 2024 07:21:35 +0200
From: Christophe JAILLET <christophe.jaillet@...adoo.fr>
To: Andrey Skvortsov <andrej.skvortzov@...il.com>,
 Venkat Rao Bagalkote <venkat88@...ux.vnet.ibm.com>,
 Minchan Kim <minchan@...nel.org>,
 Sergey Senozhatsky <senozhatsky@...omium.org>, Jens Axboe <axboe@...nel.dk>,
 Andrew Morton <akpm@...ux-foundation.org>, linux-kernel@...r.kernel.org,
 linux-block@...r.kernel.org, stable@...r.kernel.org
Subject: Re: [PATCH v3] zram: don't free statically defined names

Le 24/09/2024 à 00:41, Andrey Skvortsov a écrit :
> On 24-09-23 19:40, Christophe JAILLET wrote:
>> Le 23/09/2024 à 18:48, Andrey Skvortsov a écrit :
>>> When CONFIG_ZRAM_MULTI_COMP isn't set ZRAM_SECONDARY_COMP can hold
>>> default_compressor, because it's the same offset as ZRAM_PRIMARY_COMP,
>>> so we need to make sure that we don't attempt to kfree() the
>>> statically defined compressor name.
>>>
>>> This is detected by KASAN.
>>>
>>> ==================================================================
>>>     Call trace:
>>>      kfree+0x60/0x3a0
>>>      zram_destroy_comps+0x98/0x198 [zram]
>>>      zram_reset_device+0x22c/0x4a8 [zram]
>>>      reset_store+0x1bc/0x2d8 [zram]
>>>      dev_attr_store+0x44/0x80
>>>      sysfs_kf_write+0xfc/0x188
>>>      kernfs_fop_write_iter+0x28c/0x428
>>>      vfs_write+0x4dc/0x9b8
>>>      ksys_write+0x100/0x1f8
>>>      __arm64_sys_write+0x74/0xb8
>>>      invoke_syscall+0xd8/0x260
>>>      el0_svc_common.constprop.0+0xb4/0x240
>>>      do_el0_svc+0x48/0x68
>>>      el0_svc+0x40/0xc8
>>>      el0t_64_sync_handler+0x120/0x130
>>>      el0t_64_sync+0x190/0x198
>>> ==================================================================
>>>
>>> Signed-off-by: Andrey Skvortsov <andrej.skvortzov@...il.com>
>>> Fixes: 684826f8271a ("zram: free secondary algorithms names")
>>> Cc: <stable@...r.kernel.org>
>>> ---
>>>
>>> Changes in v2:
>>>    - removed comment from source code about freeing statically defined compression
>>>    - removed part of KASAN report from commit description
>>>    - added information about CONFIG_ZRAM_MULTI_COMP into commit description
>>>
>>> Changes in v3:
>>>    - modified commit description based on Sergey's comment
>>>    - changed start for-loop to ZRAM_PRIMARY_COMP
>>>
>>>
>>>    drivers/block/zram/zram_drv.c | 6 ++++--
>>>    1 file changed, 4 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
>>> index c3d245617083d..ad9c9bc3ccfc5 100644
>>> --- a/drivers/block/zram/zram_drv.c
>>> +++ b/drivers/block/zram/zram_drv.c
>>> @@ -2115,8 +2115,10 @@ static void zram_destroy_comps(struct zram *zram)
>>>    		zram->num_active_comps--;
>>>    	}
>>> -	for (prio = ZRAM_SECONDARY_COMP; prio < ZRAM_MAX_COMPS; prio++) {
>>> -		kfree(zram->comp_algs[prio]);
>>> +	for (prio = ZRAM_PRIMARY_COMP; prio < ZRAM_MAX_COMPS; prio++) {
>>> +		/* Do not free statically defined compression algorithms */
>>> +		if (zram->comp_algs[prio] != default_compressor)
>>> +			kfree(zram->comp_algs[prio]);
>>
>> Hi,
>>
>> maybe kfree_const() to be more future proof and less verbose?
> 
> kfree_const() will not work if zram is built as a module. It works
> only for .rodata for kernel image. [1]
> 
> 1. https://elixir.bootlin.com/linux/v6.11/source/include/asm-generic/sections.h#L177
> 

If so, then it is likely that it is not correctly used elsewhere.

https://elixir.bootlin.com/linux/v6.11/source/drivers/dax/kmem.c#L289
https://elixir.bootlin.com/linux/v6.11/source/drivers/firmware/arm_scmi/bus.c#L341
https://elixir.bootlin.com/linux/v6.11/source/drivers/input/touchscreen/chipone_icn8505.c#L379
https://elixir.bootlin.com/linux/v6.11/source/drivers/remoteproc/qcom_common.c#L262
...

all seem to be build-able as modules.

I'll try to give it a look in the coming days.

CJ