Re: [PATCH bpf v3] bpf: Fix NULL pointer dereference in bpf_sk_storage_clone and diag paths

[sashiko-bot@kernel.org]

Sashiko AI review found 1 potential issue(s):
- [High] diag_get() leaks uninitialized kernel memory to user space when dumping BPF map values containing special fields (e.g., bpf_spin_lock, bpf_timer).
--

Note: The format of this review has been altered to provide a free-form
summary without quoting the original patch code directly due to recitation
restrictions.

commit 32307cca407ebdd5cf1feae057cd9956ec19daa4
Author: Weiming Shi <bestswngs@gmail.com>
Subject: bpf: Fix NULL pointer dereference in bpf_sk_storage_clone and diag paths

This patch addresses a race condition where a concurrent RCU reader in
bpf_sk_storage_clone() could observe a selem with a NULL smap, leading to a
NULL pointer dereference. It adds NULL checks in clone and diag paths and
updates diag_get() to take the validated smap directly.

While reviewing the changes to the diag_get() function, I noticed a
potential pre-existing issue regarding how map values are copied to the
netlink attribute.

Does this function leak uninitialized kernel memory to user space when
dumping BPF map values that contain special fields like bpf_spin_lock or
bpf_timer?

The function allocates space for the value using nla_reserve_64bit(), which
reserves space in the skb but does not initialize it. It then copies the
map value into this space using copy_map_value_locked() or copy_map_value().
However, those copy functions intentionally skip copying special fields,
leaving holes in the destination buffer.

In the standard bpf_map_lookup_elem() syscall path,
check_and_init_map_value() is called to explicitly zero out these holes
after copying. Since diag_get() does not appear to initialize these holes
before sending the netlink message, could uninitialized skb memory be
exposed to user space?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260422065411.1007737-2-bestswngs@gmail.com?part=1