linux-kernel - re: [PATCH bpf-next v3 1/2] bpf: add bpf

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

Message-ID: <CAPKFLCRwu8ZYGoBOvjFs_YaV3nqy=uRC1wfKmMXd2Q96MpGQdA@mail.gmail.com>
Date: Wed, 3 Sep 2025 21:35:35 +1000
From: Sebastian Ramadan <slay.sebbeh@...il.com>
To: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: re: [PATCH bpf-next v3 1/2] bpf: add bpf_strcasecmp kfunc

Hi,

While reviewing the recent patch ([PATCH bpf-next v3 1/2] bpf: add
bpf_strcasecmp kfunc), I noticed a small but important standards
compliance issue regarding the use of tolower() with char variables:

char c1, c2;
// ...
if (ignore_case) {
    c1 = tolower(c1);
    c2 = tolower(c2);
}

According to the ISO C standard, functions and macros in <ctype.h>
(such as tolower()) are only defined for arguments that are either:
1/ Representable as an unsigned char, or
2/ Equal to the special value EOF.

Passing a plain char that contains a negative value (other than EOF)
results in undefined behavior. This can easily go unnoticed in
environments where char defaults to unsigned (such as GCC on x86), but
will break or behave unpredictably on platforms where char is signed.

To ensure portable and defined behavior, it's typically recommended to
cast to unsigned char before passing to tolower():

c1 = tolower((unsigned char)c1);
c2 = tolower((unsigned char)c2);

This ensures compliance with the standard and avoids silent issues
across different toolchains and architectures.

While this may not cause immediate problems in the GNU-C ecosystem,
implicitly relying on compiler-specific behavior can gradually reduce
the kernel's portability. Keeping these cases in check helps maintain
the kernel's long-standing goal of wide platform support.

Thanks for your time, and for the ongoing work toward clean and
portable kernel code.

Regards, Sebastian Ramadan