[PATCH] w1: Use kfree_sensitive() instead of memset(0) and kfree()

Thorsten Blum posted 1 patch 1 month, 4 weeks ago
drivers/w1/w1.c | 5 +----
1 file changed, 1 insertion(+), 4 deletions(-)
[PATCH] w1: Use kfree_sensitive() instead of memset(0) and kfree()
Posted by Thorsten Blum 1 month, 4 weeks ago
Use kfree_sensitive() to simplify w1_unref_slave() and remove the
following Coccinelle/coccicheck warning reported by
kfree_sensitive.cocci:

  WARNING opportunity for kfree_sensitive/kvfree_sensitive

Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
---
Please note: this change assumes that #ifdef DEBUG is no longer needed
and we should always zero out the memory.
---
 drivers/w1/w1.c | 5 +----
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/w1/w1.c b/drivers/w1/w1.c
index d82e86d3ddf6..127694180eb8 100644
--- a/drivers/w1/w1.c
+++ b/drivers/w1/w1.c
@@ -795,10 +795,7 @@ int w1_unref_slave(struct w1_slave *sl)
 
 		w1_family_notify(BUS_NOTIFY_DEL_DEVICE, sl);
 		device_unregister(&sl->dev);
-		#ifdef DEBUG
-		memset(sl, 0, sizeof(*sl));
-		#endif
-		kfree(sl);
+		kfree_sensitive(sl);
 	}
 	atomic_dec(&dev->refcnt);
 	mutex_unlock(&dev->list_mutex);
-- 
2.46.2
Re: [PATCH] w1: Use kfree_sensitive() instead of memset(0) and kfree()
Posted by Krzysztof Kozlowski 1 month, 4 weeks ago
On 30/09/2024 13:44, Thorsten Blum wrote:
> Use kfree_sensitive() to simplify w1_unref_slave() and remove the
> following Coccinelle/coccicheck warning reported by
> kfree_sensitive.cocci:
> 
>   WARNING opportunity for kfree_sensitive/kvfree_sensitive

So are you fixing coccinelle just to hide the warning or actually fixing
issue? Why this structure should be zeroed?

> 
> Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
> ---
> Please note: this change assumes that #ifdef DEBUG is no longer needed
> and we should always zero out the memory.

But why are you assuming that? Your patch is not equivalent and I do not
see any explanation in commit msg why is that.

Best regards,
Krzysztof
Re: [PATCH] w1: Use kfree_sensitive() instead of memset(0) and kfree()
Posted by Thorsten Blum 1 month, 4 weeks ago
On 30. Sep 2024, at 13:50, Krzysztof Kozlowski <krzk@kernel.org> wrote:
> On 30/09/2024 13:44, Thorsten Blum wrote:
>> Use kfree_sensitive() to simplify w1_unref_slave() and remove the
>> following Coccinelle/coccicheck warning reported by
>> kfree_sensitive.cocci:
>> 
>> WARNING opportunity for kfree_sensitive/kvfree_sensitive
> 
> So are you fixing coccinelle just to hide the warning or actually fixing
> issue? Why this structure should be zeroed?

No issue, just a refactoring (+zeroing out) to silence the warning. The
structure probably doesn't need to be zeroed out, but why is it done
for DEBUG builds?

>> Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
>> ---
>> Please note: this change assumes that #ifdef DEBUG is no longer needed
>> and we should always zero out the memory.
> 
> But why are you assuming that? Your patch is not equivalent and I do not
> see any explanation in commit msg why is that.
Re: [PATCH] w1: Use kfree_sensitive() instead of memset(0) and kfree()
Posted by Thorsten Blum 1 month, 4 weeks ago
On 30. Sep 2024, at 14:15, Thorsten Blum <thorsten.blum@linux.dev> wrote:
> On 30. Sep 2024, at 13:50, Krzysztof Kozlowski <krzk@kernel.org> wrote:
>> On 30/09/2024 13:44, Thorsten Blum wrote:
>>> Use kfree_sensitive() to simplify w1_unref_slave() and remove the
>>> following Coccinelle/coccicheck warning reported by
>>> kfree_sensitive.cocci:
>>> 
>>> WARNING opportunity for kfree_sensitive/kvfree_sensitive
>> 
>> So are you fixing coccinelle just to hide the warning or actually fixing
>> issue? Why this structure should be zeroed?
> 
> No issue, just a refactoring (+zeroing out) to silence the warning. The
> structure probably doesn't need to be zeroed out, but why is it done
> for DEBUG builds?
> 
>>> Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
>>> ---
>>> Please note: this change assumes that #ifdef DEBUG is no longer needed
>>> and we should always zero out the memory.
>> 
>> But why are you assuming that? Your patch is not equivalent and I do not
>> see any explanation in commit msg why is that.

Sorry, just ignore this patch for now. I misread the code and mixed
things up.

Thanks,
Thorsten