Re: [PATCH RESEND v13 2/2] rust: fmt: route {:p} through HashedPtr to prevent address leaks

Alice Ryhl <[email protected]> Wed, 5 Aug 2026 08:15:06 +0000
Newsgroups org.kernel.vger.rust-for-linux
Message-ID <[email protected]>
On Mon, Jul 06, 2026 at 01:18:44PM +0800, Ke Sun wrote:
> Define a custom `kernel::fmt::Pointer` trait and `HashedPtr` wrapper
> so that `{:p}` formatting uses the kernel's `%p` hashed format instead
> of printing raw pointer values, preventing kernel address space leaks.
> 
> Signed-off-by: Ke Sun <[email protected]>

Overall looks good to me, but one thing:

> +impl<T: ?Sized> Pointer for HashedPtr<T> {
> +    fn fmt(&self, f: &mut Formatter<'_>) -> Result {
> +        use crate::str::CStrExt as _;
> +
> +        let mut buf = [0u8; 32];
> +
> +        // SAFETY: `buf` is a valid, writable buffer of 32 bytes, sufficient for all architectures
> +        // (max 19 bytes for 64-bit). The format string `c"0x%p"` is null-terminated and `%p`
> +        // matches the pointer argument.
> +        let len = unsafe {
> +            crate::bindings::scnprintf(
> +                buf.as_mut_ptr().cast(),
> +                buf.len(),
> +                // Rust's `{:p}` includes a "0x" prefix, the kernel's `%p` does not.
> +                c"0x%p".as_char_ptr(),
> +                self.0.cast::<core::ffi::c_void>(),
> +            )
> +        };

When given a null pointer, this will print 0x(null), which seems a bit
weird. It may also print 0x(ptrval) or 0x(____ptrval____) during early
boot.

It seems like it'd be nice to special-case these to provide better
output in those cases.

Alice