From: Christophe Leroy <christophe.leroy@csgroup.eu>
To: "Thomas Weißschuh" <thomas.weissschuh@linutronix.de>,
"Mahesh J Salgaonkar" <mahesh@linux.ibm.com>,
"Oliver O'Halloran" <oohall@gmail.com>,
"Madhavan Srinivasan" <maddy@linux.ibm.com>,
"Michael Ellerman" <mpe@ellerman.id.au>,
"Nicholas Piggin" <npiggin@gmail.com>,
"Naveen N Rao" <naveen@kernel.org>
Cc: linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] powerpc: Don't use %pK through printk
Date: Mon, 24 Feb 2025 13:15:00 +0100 [thread overview]
Message-ID: <ffd5dd44-babc-480a-b1bc-61bd7ff1e920@csgroup.eu> (raw)
In-Reply-To: <20250217-restricted-pointers-powerpc-v1-1-32c6bff63c9a@linutronix.de>
Le 17/02/2025 à 08:39, Thomas Weißschuh a écrit :
> Restricted pointers ("%pK") are not meant to be used through printk().
> It can unintentionally expose security sensitive, raw pointer values.
>
> Use regular pointer formatting instead.
>
> Link: https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Flkml%2F20250113171731-dc10e3c1-da64-4af0-b767-7c7070468023%40linutronix.de%2F&data=05%7C02%7Cchristophe.leroy%40csgroup.eu%7C75a852a0fef54fa43a3608dd4f263f45%7C8b87af7d86474dc78df45f69a2011bb5%7C0%7C0%7C638753747883689862%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=aUgq6pXb1ySaQ6e%2FdyM09jfc4MNLE71Njw0%2FnCg%2F6VU%3D&reserved=0
> Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
Reviewed-by: Christophe Leroy <christophe.leroy@csgroup.eu>
> ---
> arch/powerpc/kernel/eeh_driver.c | 2 +-
> arch/powerpc/perf/hv-24x7.c | 8 ++++----
> 2 files changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/arch/powerpc/kernel/eeh_driver.c b/arch/powerpc/kernel/eeh_driver.c
> index 7efe04c68f0fe3fb1c3c13d97d58e79e47cf103b..10ce6b3bd3b7c54f91544ae7f7fd3f32a51ee09a 100644
> --- a/arch/powerpc/kernel/eeh_driver.c
> +++ b/arch/powerpc/kernel/eeh_driver.c
> @@ -907,7 +907,7 @@ void eeh_handle_normal_event(struct eeh_pe *pe)
> /* FIXME: Use the same format as dump_stack() */
> pr_err("EEH: Call Trace:\n");
> for (i = 0; i < pe->trace_entries; i++)
> - pr_err("EEH: [%pK] %pS\n", ptrs[i], ptrs[i]);
> + pr_err("EEH: [%p] %pS\n", ptrs[i], ptrs[i]);
>
> pe->trace_entries = 0;
> }
> diff --git a/arch/powerpc/perf/hv-24x7.c b/arch/powerpc/perf/hv-24x7.c
> index d400fa391c2765cf201ee4dc754007e655cc74ca..f6d734431b1dcdfec3b9205c3b48577b4fc26b53 100644
> --- a/arch/powerpc/perf/hv-24x7.c
> +++ b/arch/powerpc/perf/hv-24x7.c
> @@ -713,12 +713,12 @@ static ssize_t catalog_event_len_validate(struct hv_24x7_event_data *event,
> ev_len = be16_to_cpu(event->length);
>
> if (ev_len % 16)
> - pr_info("event %zu has length %zu not divisible by 16: event=%pK\n",
> + pr_info("event %zu has length %zu not divisible by 16: event=%p\n",
> event_idx, ev_len, event);
>
> ev_end = (__u8 *)event + ev_len;
> if (ev_end > end) {
> - pr_warn("event %zu has .length=%zu, ends after buffer end: ev_end=%pK > end=%pK, offset=%zu\n",
> + pr_warn("event %zu has .length=%zu, ends after buffer end: ev_end=%p > end=%p, offset=%zu\n",
> event_idx, ev_len, ev_end, end,
> offset);
> return -1;
> @@ -726,14 +726,14 @@ static ssize_t catalog_event_len_validate(struct hv_24x7_event_data *event,
>
> calc_ev_end = event_end(event, end);
> if (!calc_ev_end) {
> - pr_warn("event %zu has a calculated length which exceeds buffer length %zu: event=%pK end=%pK, offset=%zu\n",
> + pr_warn("event %zu has a calculated length which exceeds buffer length %zu: event=%p end=%p, offset=%zu\n",
> event_idx, event_data_bytes, event, end,
> offset);
> return -1;
> }
>
> if (calc_ev_end > ev_end) {
> - pr_warn("event %zu exceeds its own length: event=%pK, end=%pK, offset=%zu, calc_ev_end=%pK\n",
> + pr_warn("event %zu exceeds its own length: event=%p, end=%p, offset=%zu, calc_ev_end=%p\n",
> event_idx, event, ev_end, offset, calc_ev_end);
> return -1;
> }
>
> ---
> base-commit: 0ad2507d5d93f39619fc42372c347d6006b64319
> change-id: 20250217-restricted-pointers-powerpc-f11876496464
>
> Best regards,
next prev parent reply other threads:[~2025-02-24 12:50 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-17 7:39 Thomas Weißschuh
2025-02-24 12:15 ` Christophe Leroy [this message]
2025-02-24 18:54 ` Maciej W. Rozycki
2025-02-25 5:58 ` Christophe Leroy
2025-02-25 17:29 ` Maciej W. Rozycki
2025-02-25 8:19 ` Thomas Weißschuh
2025-02-25 17:32 ` Maciej W. Rozycki
2025-02-26 10:15 ` Thomas Weißschuh
2025-02-28 20:15 ` Maciej W. Rozycki
2025-03-03 11:08 ` Thomas Weißschuh
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ffd5dd44-babc-480a-b1bc-61bd7ff1e920@csgroup.eu \
--to=christophe.leroy@csgroup.eu \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=maddy@linux.ibm.com \
--cc=mahesh@linux.ibm.com \
--cc=mpe@ellerman.id.au \
--cc=naveen@kernel.org \
--cc=npiggin@gmail.com \
--cc=oohall@gmail.com \
--cc=thomas.weissschuh@linutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®