mbox series

[v4,0/3] Replace the use of simple_strtol/ul functions with kstrto

Message ID 20241028191700.GA918263@lichtman.org (mailing list archive)
Headers show
Series Replace the use of simple_strtol/ul functions with kstrto | expand

Message

Nir Lichtman Oct. 28, 2024, 7:17 p.m. UTC
The simple_str* family of functions perform no error checking in
scenarios where the input value overflows the intended output variable.
This results in these function successfully returning even when the
output does not match the input string.

Or as it was mentioned [1], "...simple_strtol(), simple_strtoll(),
simple_strtoul(), and simple_strtoull() functions explicitly ignore
overflows, which may lead to unexpected results in callers."
Hence, the use of those functions is discouraged.

This patch series replaces uses of the simple_strto* series of function
with the safer  kstrto* alternatives.

  
[1] https://www.kernel.org/doc/html/latest/process/deprecated.html#simple-strtol-simple-strtoll-simple-strtoul-simple-strtoull

Yuran Pereira (2):
  kdb: Replace the use of simple_strto with safer kstrto in kdb_main
  trace: kdb: Replace simple_strtoul with kstrtoul in kdb_ftdump
Nir Lichtman (1):
  kdb: Remove fallback interpretation of arbitrary numbers as hex

This patch is originally based upon
https://lore.kernel.org/all/GV1PR10MB65635561FB160078C3744B5FE8B4A@GV1PR10MB6563.EURPRD10.PROD.OUTLOOK.COM/

Since the original thread was left with a review and the comments have not been addressed,
decided to continue the minor work left to move this patch forward.

v2:
- Styling fixes
- Fix an invalid conversion to unsigned int instead of signed as it was supposed to be
- Fix one of the conversions to return an error in case of failure, instead of silently falling back to a default value
- Add Douglas's suggestion for removing the hex interpretation fallback
v3: 
- Split to 3 parts instead of 2 (in which the 3rd part now contains the hex interpretation fix)
- Fix the patch series to properly reference the cover
- Fix credit tags
v4:
- Fix regression between v2 to v3 in which I accidentaly
reverted an improper unsigned/signed conversion
- Fix nit of spacing in if condition parens split into multiple lines


 kernel/debug/kdb/kdb_main.c | 69 +++++++++--------------------------
 kernel/trace/trace_kdb.c    | 15 +++-----
 2 files changed, 23 insertions(+), 61 deletions(-)
--
2.39.2

Comments

Daniel Thompson Nov. 8, 2024, 8:38 a.m. UTC | #1
On Mon, 28 Oct 2024 19:17:00 +0000, Nir Lichtman wrote:
> The simple_str* family of functions perform no error checking in
> scenarios where the input value overflows the intended output variable.
> This results in these function successfully returning even when the
> output does not match the input string.
> 
> Or as it was mentioned [1], "...simple_strtol(), simple_strtoll(),
> simple_strtoul(), and simple_strtoull() functions explicitly ignore
> overflows, which may lead to unexpected results in callers."
> Hence, the use of those functions is discouraged.
> 
> [...]

Applied, thanks!

[1/3] kdb: Replace the use of simple_strto with safer kstrto in kdb_main
      commit: fe0c87871fc0b97f6d374b670c81f7c4087eebc5
[2/3] trace: kdb: Replace simple_strtoul with kstrtoul in kdb_ftdump
      commit: c56642c737fc0bd9bcc3a22a2bf8ed6f5900a660
[3/3] kdb: Remove fallback interpretation of arbitrary numbers as hex
      commit: 5f4ca702e36893a276fccb0aa55ab36e19dfbb50

Best regards,
Nir Lichtman Nov. 8, 2024, 11:06 a.m. UTC | #2
On Fri, Nov 08, 2024 at 08:38:35AM +0000, Daniel Thompson wrote:
> 
> On Mon, 28 Oct 2024 19:17:00 +0000, Nir Lichtman wrote:
> > The simple_str* family of functions perform no error checking in
> > scenarios where the input value overflows the intended output variable.
> > This results in these function successfully returning even when the
> > output does not match the input string.
> > 
> > Or as it was mentioned [1], "...simple_strtol(), simple_strtoll(),
> > simple_strtoul(), and simple_strtoull() functions explicitly ignore
> > overflows, which may lead to unexpected results in callers."
> > Hence, the use of those functions is discouraged.
> > 
> > [...]
> 
> Applied, thanks!

Thanks!

Nir