[PATCH AUTOSEL 6.17-5.4] bpf: Don't use %pK through printk

[Sasha Levin <sashal@kernel.org>]

From: Thomas Weißschuh <thomas.weissschuh@linutronix.de>

[ Upstream commit 2caa6b88e0ba0231fb4ff0ba8e73cedd5fb81fc8 ]

In the past %pK was preferable to %p as it would not leak raw pointer
values into the kernel log.
Since commit ad67b74d2469 ("printk: hash addresses printed with %p")
the regular %p has been improved to avoid this issue.
Furthermore, restricted pointers ("%pK") were never meant to be used
through printk(). They can still unintentionally leak raw pointers or
acquire sleeping locks in atomic contexts.

Switch to the regular pointer formatting which is safer and
easier to reason about.

Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Link: https://lore.kernel.org/bpf/20250811-restricted-pointers-bpf-v1-1-a1d7cc3cb9e7@linutronix.de
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

## BACKPORT ANALYSIS

**Backport Status: YES**

### Rationale

This commit should be backported to stable kernel trees based on the
following comprehensive analysis:

### 1. **Part of Kernel-Wide Safety Cleanup**

This is one of 70+ commits in a tree-wide effort to remove incorrect %pK
usage through printk(). The commit addresses a real correctness issue
where %pK format specifier is being misused in a context where it was
never intended.

### 2. **Technical Issue Being Fixed**

The %pK format specifier has specific problems when used through
printk():

**From lib/vsprintf.c:870-878**, the restricted_pointer() function
shows:
```c
/*
 - kptr_restrict==1 cannot be used in IRQ context
 - because its test for CAP_SYSLOG would be meaningless.
 */
if (in_hardirq() || in_serving_softirq() || in_nmi()) {
    if (spec.field_width == -1)
        spec.field_width = 2 * sizeof(ptr);
    return error_string(buf, end, "pK-error", spec);
}
```

This means:
- If `bpf_jit_dump()` is called from interrupt context with
  `kptr_restrict=1`, it outputs "pK-error" instead of the pointer
- The CAP_SYSLOG check in %pK can potentially acquire sleeping locks in
  atomic contexts
- %pK was only designed for seq_file operations (procfs/sysfs), not for
  printk() as documented in Documentation/core-api/printk-formats.rst:94

### 3. **Strong Stable Backporting Precedent**

Similar commits from the same cleanup series have been explicitly
backported to stable:

- **timer_list commit** (a52067c24ccf): Backported to at least 5 stable
  trees (da36c3ad7c177, e563401934e41, 3695ade72a9bc, 41dd0c31ad4a2,
  3fb9ee05ec15f)
- **LoongArch commit** (2362e8124ed21): Tagged with `Cc:
  stable@vger.kernel.org` and backported (248449ba8977c)

Both commits have identical rationale and commit messages, indicating
this class of fix is considered appropriate for stable.

### 4. **Low Risk, High Safety**

The change is minimal and safe:
- **Single line change**: `%pK` → `%p` in include/linux/filter.h:1299
- **No functional logic changes**: Only affects debug output formatting
- **No API changes**: The bpf_jit_dump() function signature remains
  unchanged
- **Improves safety**: Prevents "pK-error" output and potential
  sleeping-in-atomic issues
- **Since 2017**: The %p formatter already hashes addresses (commit
  ad67b74d2469), so no new information leakage

### 5. **Affects Critical Subsystem**

The BPF JIT subsystem is critical for:
- Performance (eBPF program execution)
- Security (sandboxing, filtering)
- Debugging (when developers need JIT dumps)

Having correct debug output is important for troubleshooting BPF JIT
issues.

### 6. **Historical Context**

- **2015** (b13138ef72178a): %pK added to bpf_jit_dump when it was the
  recommended practice
- **2017** (ad67b74d2469): %p improved to hash addresses by default,
  making %pK obsolete for printk()
- **2025**: Tree-wide cleanup to remove obsolete %pK usage from printk()
  calls

### 7. **Matches Stable Kernel Criteria**

From stable kernel rules, this commit:
- ✅ Fixes incorrect API usage (misuse of %pK)
- ✅ Is obviously correct (single format specifier change)
- ✅ Has minimal risk of regression
- ✅ Doesn't introduce new features
- ✅ Part of a series with established backporting precedent

### Code Analysis

The changed code at include/linux/filter.h:1299:
```c
-pr_err("flen=%u proglen=%u pass=%u image=%pK from=%s pid=%d\n", flen,
+pr_err("flen=%u proglen=%u pass=%u image=%p from=%s pid=%d\n", flen,
```

This function is called from arch-specific BPF JIT compilers during JIT
compilation, potentially in contexts where %pK would be problematic.

### Conclusion

This commit should be backported to stable trees because it:
1. Fixes incorrect use of a kernel API (%pK through printk)
2. Prevents potential "pK-error" output in debug messages
3. Aligns with kernel-wide cleanup effort that has stable backporting
   precedent
4. Carries minimal risk while improving code correctness
5. Follows the same pattern as other commits already accepted into
   stable

 include/linux/filter.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/filter.h b/include/linux/filter.h
index 1e7fd3ee759e0..52fecb7a1fe36 100644
--- a/include/linux/filter.h
+++ b/include/linux/filter.h
@@ -1296,7 +1296,7 @@ void bpf_jit_prog_release_other(struct bpf_prog *fp, struct bpf_prog *fp_other);
 static inline void bpf_jit_dump(unsigned int flen, unsigned int proglen,
 				u32 pass, void *image)
 {
-	pr_err("flen=%u proglen=%u pass=%u image=%pK from=%s pid=%d\n", flen,
+	pr_err("flen=%u proglen=%u pass=%u image=%p from=%s pid=%d\n", flen,
 	       proglen, pass, image, current->comm, task_pid_nr(current));
 
 	if (image)
-- 
2.51.0