On Tue, Jun 05, 2018 at 04:40:41PM -0700, Daniel Rosenberg wrote: > The format specifier %p can leak kernel addresses > while not valuing the kptr_restrict system settings. > Use %pK instead of %p, which also evaluates whether > kptr_restrict is set. > > Signed-off-by: Divya Ponnusamy <pdivya@xxxxxxxxxxxxxx> > Signed-off-by: Daniel Rosenberg <drosen@xxxxxxxxxx> > Cc: stable <stable@xxxxxxxxxxxxxxx> > --- > drivers/dma-buf/sync_debug.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/dma-buf/sync_debug.c b/drivers/dma-buf/sync_debug.c > index c4c8ecb24aa9..d8d340542a79 100644 > --- a/drivers/dma-buf/sync_debug.c > +++ b/drivers/dma-buf/sync_debug.c > @@ -133,7 +133,7 @@ static void sync_print_sync_file(struct seq_file *s, > char buf[128]; > int i; > > - seq_printf(s, "[%p] %s: %s\n", sync_file, > + seq_printf(s, "[%pK] %s: %s\n", sync_file, This is a root-only file, right? So it's not that bad of a problem. Also, by default, all %p pointers are now hashed so what really is leaking here? And finally, why even print out a pointer at all? Why not just stick with the name and not worry about the pointer? thanks, greg k-h _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel