Patch "bpf: Fix bpf_strtol and bpf_strtoul helpers for 32bit" has been added to the 5.15-stable tree

[Sasha Levin <sashal@xxxxxxxxxx>]

This is a note to let you know that I've just added the patch titled

    bpf: Fix bpf_strtol and bpf_strtoul helpers for 32bit

to the 5.15-stable tree which can be found at:
    http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
     bpf-fix-bpf_strtol-and-bpf_strtoul-helpers-for-32bit.patch
and it can be found in the queue-5.15 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@xxxxxxxxxxxxxxx> know about it.



commit c1896fdd09fb46a33b801a170ef3367eabd54c8b
Author: Daniel Borkmann <daniel@xxxxxxxxxxxxx>
Date:   Fri Sep 13 21:17:46 2024 +0200

    bpf: Fix bpf_strtol and bpf_strtoul helpers for 32bit
    
    [ Upstream commit cfe69c50b05510b24e26ccb427c7cc70beafd6c1 ]
    
    The bpf_strtol() and bpf_strtoul() helpers are currently broken on 32bit:
    
    The argument type ARG_PTR_TO_LONG is BPF-side "long", not kernel-side "long"
    and therefore always considered fixed 64bit no matter if 64 or 32bit underlying
    architecture.
    
    This contract breaks in case of the two mentioned helpers since their BPF_CALL
    definition for the helpers was added with {unsigned,}long *res. Meaning, the
    transition from BPF-side "long" (BPF program) to kernel-side "long" (BPF helper)
    breaks here.
    
    Both helpers call __bpf_strtoll() with "long long" correctly, but later assigning
    the result into 32-bit "*(long *)" on 32bit architectures. From a BPF program
    point of view, this means upper bits will be seen as uninitialised.
    
    Therefore, fix both BPF_CALL signatures to {s,u}64 types to fix this situation.
    
    Now, changing also uapi/bpf.h helper documentation which generates bpf_helper_defs.h
    for BPF programs is tricky: Changing signatures there to __{s,u}64 would trigger
    compiler warnings (incompatible pointer types passing 'long *' to parameter of type
    '__s64 *' (aka 'long long *')) for existing BPF programs.
    
    Leaving the signatures as-is would be fine as from BPF program point of view it is
    still BPF-side "long" and thus equivalent to __{s,u}64 on 64 or 32bit underlying
    architectures.
    
    Note that bpf_strtol() and bpf_strtoul() are the only helpers with this issue.
    
    Fixes: d7a4cb9b6705 ("bpf: Introduce bpf_strtol and bpf_strtoul helpers")
    Reported-by: Alexei Starovoitov <ast@xxxxxxxxxx>
    Signed-off-by: Daniel Borkmann <daniel@xxxxxxxxxxxxx>
    Acked-by: Andrii Nakryiko <andrii@xxxxxxxxxx>
    Link: https://lore.kernel.org/bpf/481fcec8-c12c-9abb-8ecb-76c71c009959@xxxxxxxxxxxxx
    Link: https://lore.kernel.org/r/20240913191754.13290-1-daniel@xxxxxxxxxxxxx
    Signed-off-by: Alexei Starovoitov <ast@xxxxxxxxxx>
    Signed-off-by: Sasha Levin <sashal@xxxxxxxxxx>

diff --git a/kernel/bpf/helpers.c b/kernel/bpf/helpers.c
index 273f2f0deb239..13f870e47ab6d 100644
--- a/kernel/bpf/helpers.c
+++ b/kernel/bpf/helpers.c
@@ -512,7 +512,7 @@ static int __bpf_strtoll(const char *buf, size_t buf_len, u64 flags,
 }
 
 BPF_CALL_4(bpf_strtol, const char *, buf, size_t, buf_len, u64, flags,
-	   long *, res)
+	   s64 *, res)
 {
 	long long _res;
 	int err;
@@ -537,7 +537,7 @@ const struct bpf_func_proto bpf_strtol_proto = {
 };
 
 BPF_CALL_4(bpf_strtoul, const char *, buf, size_t, buf_len, u64, flags,
-	   unsigned long *, res)
+	   u64 *, res)
 {
 	unsigned long long _res;
 	bool is_negative;