linux-kernel - Re: [PATCH AUTOSEL 6.18] tracing: Avoid possible signed 64-bit truncation

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] [day] [month] [year] [list]

Message-ID: <20260128195920.0fd14c6a@gandalf.local.home>
Date: Wed, 28 Jan 2026 19:59:20 -0500
From: Steven Rostedt <rostedt@...dmis.org>
To: Sasha Levin <sashal@...nel.org>
Cc: patches@...ts.linux.dev, stable@...r.kernel.org, Ian Rogers
 <irogers@...gle.com>, Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
 "Masami Hiramatsu (Google)" <mhiramat@...nel.org>,
 linux-kernel@...r.kernel.org, linux-trace-kernel@...r.kernel.org
Subject: Re: [PATCH AUTOSEL 6.18] tracing: Avoid possible signed 64-bit
 truncation

On Wed, 28 Jan 2026 17:33:16 -0500
Sasha Levin <sashal@...nel.org> wrote:

> LLM Generated explanations, may be completely bogus:
> 
> The original buggy code was introduced in v6.15 and later. It's only
> present in 6.15+ kernels.

Interesting self discussion from the LLM.

> 
> ### 8. SUMMARY OF ANALYSIS
> 
> **The Bug:**
> - The `cmp_mod_entry()` function uses subtraction of two `unsigned long`
>   values and returns the result as `int`
> - On 64-bit systems, if addresses differ by more than 2^31 (~2GB), the
>   truncation from 64-bit to 32-bit can flip the sign
> - This would cause `bsearch()` to make wrong decisions about search
>   direction
> - Result: potentially incorrect module address lookups in trace data
> 
> **The Fix:**
> - Replaces arithmetic subtraction with simple comparisons
> - Returns -1, 0, or 1 directly based on comparisons
> - No overflow or truncation possible with the new code
> - Logic is more readable and provably correct
> 
> **Stable Criteria Evaluation:**
> 1. ✅ **Obviously correct and tested**: Simple logic, reviewed by
>    maintainers
> 2. ✅ **Fixes a real bug**: Yes, a potential comparator correctness bug
> 3. ⚠️ **Important issue**: Moderate - unlikely to trigger (requires >2GB
>    address separation) but could cause incorrect trace output

I purposely didn't add Cc: stable because there's basically no chance of
two modules being more than 2GB apart.

> 4. ✅ **Small and contained**: Only changes one function body (~6 lines)
> 5. ✅ **No new features**: Pure bug fix
> 6. ✅ **Applies cleanly**: Should apply to 6.15+ kernels where this code
>    exists
> 
> **Risk Assessment:**
> - Very low risk - the change is small and the new logic is simpler
> - The original code has a provable bug (integer overflow on truncation)
> - The new code has no such issues
> 
> **Concerns:**
> - The code only exists in 6.15+ kernels (introduced March 2025)
> - The bug is "unlikely" per the author (requires addresses >2GB apart)
> - No known real-world reports of this actually causing issues
> 
> ### DECISION
> 
> This is a valid bug fix that:
> - Fixes a real (though unlikely to trigger) bug in the comparator
>   function
> - Is very small and self-contained
> - Has been reviewed and acked by the tracing maintainers
> - Has near-zero regression risk
> - Applies to 6.15+ kernels only
> 
> The fix is surgical, obviously correct, and addresses a potential
> correctness issue. While the bug is unlikely to trigger in practice
> (addresses must be >2GB apart), it could cause silent data corruption in
> trace output when it does trigger. The fix is trivial and risk-free.
> 
> **YES**

But I see the bot considered the same thing, but because of the risk factor
it decided to take it.

I have no issue with backporting it (I did label it a "fix"). I was
actually wondering if the bot would notice likeliness of it not happening.
It did, but decided to take it for "correctness" reasons vs risk factor.

Nice,

-- Steve