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-a1d7cc3cb9... 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)