linux-kernel - Re: [PATCH] ftrace: Avoid potential division by zero in function_stat

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20250205095021.15771b88@gandalf.local.home>
Date: Wed, 5 Feb 2025 09:50:21 -0500
From: Steven Rostedt <rostedt@...dmis.org>
To: Nikolay Kuratov <kniv@...dex-team.ru>
Cc: linux-kernel@...r.kernel.org, linux-trace-kernel@...r.kernel.org, Wen
 Yang <wenyang@...ux.alibaba.com>, Mark Rutland <mark.rutland@....com>,
 Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
Subject: Re: [PATCH] ftrace: Avoid potential division by zero in
 function_stat_show()

On Wed,  5 Feb 2025 14:21:54 +0300
Nikolay Kuratov <kniv@...dex-team.ru> wrote:

> Oops, this still does not fix an overflow because of
> 
> > rec->time_square_sum += calltime * calltime;  
> 
> We can't eliminate overflows easily without both using u64 and converting
> ns to us prior to any squaring. I will send an appropriate patch later
> if needed. Maybe we're a way too paranoid about overflows and really want
> only not to divide by zero?

Well, the divide by zero will cause a kernel crash (very bad!) whereas the
overflow just causes corrupted data (sorta bad).

But yeah, I've noticed a lot of bogus data in the stddev and pretty much
ignore it. Perhaps it would have been better not to add it to begin with :-p

The divide by zero scenario definitely needs to be fixed, and I may take my
last patch to fix it as it also stops some of the overflows.

But we can add another patch to stop the other overflows with some runtime
checks too.

-- Steve