From: Audra Mitchell <aubaker@redhat.com>
To: linuxppc-dev@lists.ozlabs.org
Cc: linux-kernel@vger.kernel.org, linux-hardening@vger.kernel.org,
aubaker@redhat.com, nathanl@linux.ibm.com, keescook@chromium.org,
christophe.leroy@csgroup.eu, npiggin@gmail.com,
mpe@ellerman.id.au
Subject: [PATCH] Update creation of flash_block_cache to accout for potential panic
Date: Mon, 28 Aug 2023 16:54:53 -0400 [thread overview]
Message-ID: <20230828205453.307962-1-aubaker@redhat.com> (raw)
With PPC builds enabling CONFIG_HARDENED_USERCOPY, interacting with the RunTime
Abstraction Services (RTAS) firmware by writing to
/proc/powerpc/rtas/firmware_flash will end up triggering the mm/usercopy.c:101
assertion:
[ 38.647148] rw /proc/powerpc/rtas/firmware_flash
[ 38.650254] usercopy: Kernel memory overwrite attempt detected to SLUB object 'rtas_flash_cache' (offset 0, size 34)!
[ 38.650264] ------------[ cut here ]------------
[ 38.650264] kernel BUG at mm/usercopy.c:101!
[ 38.650267] Oops: Exception in kernel mode, sig: 5 [#1]
[ 38.650283] LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA pSeries
[ 38.650287] Modules linked in: binfmt_misc loop rfkill bonding tls sunrpc pseries_rng drm fuse drm_panel_orientation_quirks xfs libcrc32c sd_mod t10_pi sg ibmveth ibmvscsi scsi_transport_srp vmx_crypto
[ 38.650306] CPU: 0 PID: 12898 Comm: echo Kdump: loaded Not tainted 5.14.0-299.el9.ppc64le #1
[ 38.650311] NIP: c00000000056d870 LR: c00000000056d86c CTR: c000000000886090
[ 38.650314] REGS: c0000000ba6e78c0 TRAP: 0700 Not tainted (5.14.0-299.el9.ppc64le)
[ 38.650318] MSR: 8000000000029033 <SF,EE,ME,IR,DR,RI,LE> CR: 28002203 XER: 20040000
[ 38.650326] CFAR: c0000000001f76fc IRQMASK: 0
[ 38.650326] GPR00: c00000000056d86c c0000000ba6e7b60 c000000002b15a00 0000000000000069
[ 38.650326] GPR04: c000000fff447f90 c000000fff4ccd00 000000000000000f 0000000000000027
[ 38.650326] GPR08: 0000000000000000 c000000fff44adc0 0000000ffd2f0000 0000000000002000
[ 38.650326] GPR12: 6174722720746365 c000000002ea0000 0000000000000000 0000000000000000
[ 38.650326] GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
[ 38.650326] GPR20: 0000000000000000 0000000000000000 0000000000000002 0000000000000001
[ 38.650326] GPR24: 0000000000000000 000000012eef55a0 c0000000025f39e0 c0000000b988d000
[ 38.650326] GPR28: c0000000b988d022 0000000000000022 0000000000000000 c00000000134d6e8
[ 38.650366] NIP [c00000000056d870] usercopy_abort+0xb0/0xc0
[ 38.650373] LR [c00000000056d86c] usercopy_abort+0xac/0xc0
[ 38.650377] Call Trace:
[ 38.650379] [c0000000ba6e7b60] [c00000000056d86c] usercopy_abort+0xac/0xc0 (unreliable)
[ 38.650384] [c0000000ba6e7be0] [c0000000005178f0] __check_heap_object+0xf0/0x120
[ 38.650389] [c0000000ba6e7c00] [c00000000056d5e0] check_heap_object+0x1f0/0x220
[ 38.650394] [c0000000ba6e7c40] [c00000000056d6a0] __check_object_size+0x90/0x1b0
[ 38.650399] [c0000000ba6e7c80] [c0000000000462fc] rtas_flash_write+0x11c/0x2b0
[ 38.650404] [c0000000ba6e7ce0] [c00000000064d2ec] proc_reg_write+0xfc/0x160
[ 38.650409] [c0000000ba6e7d10] [c000000000579e64] vfs_write+0xe4/0x390
[ 38.650413] [c0000000ba6e7d60] [c00000000057a414] ksys_write+0x84/0x140
[ 38.650417] [c0000000ba6e7db0] [c00000000002f314] system_call_exception+0x164/0x310
[ 38.650421] [c0000000ba6e7e10] [c00000000000bfe8] system_call_vectored_common+0xe8/0x278
[ 38.650426] --- interrupt: 3000 at 0x7fff87f3aa34
[ 38.650430] NIP: 00007fff87f3aa34 LR: 0000000000000000 CTR: 0000000000000000
[ 38.650433] REGS: c0000000ba6e7e80 TRAP: 3000 Not tainted (5.14.0-299.el9.ppc64le)
[ 38.650436] MSR: 800000000280f033 <SF,VEC,VSX,EE,PR,FP,ME,IR,DR,RI,LE> CR: 42002408 XER: 00000000
[ 38.650446] IRQMASK: 0
This used to be caught with a warning in __check_heap_object to allow impacted
drivers time to update to kmem_cache_create_usercopy, but commit 53944f171a89d
("mm: remove HARDENED_USERCOPY_FALLBACK") removed that check. To resolve this
issue, update the creation of the flash_block_cache to use
kmem_cache_create_usercopy with a default size of RTAS_BLK_SIZE.
Signed-off-by: Audra Mitchell <aubaker@redhat.com>
---
arch/powerpc/kernel/rtas_flash.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kernel/rtas_flash.c b/arch/powerpc/kernel/rtas_flash.c
index a99179d83538..0a156a600f31 100644
--- a/arch/powerpc/kernel/rtas_flash.c
+++ b/arch/powerpc/kernel/rtas_flash.c
@@ -710,9 +710,9 @@ static int __init rtas_flash_init(void)
if (!rtas_validate_flash_data.buf)
return -ENOMEM;
- flash_block_cache = kmem_cache_create("rtas_flash_cache",
+ flash_block_cache = kmem_cache_create_usercopy("rtas_flash_cache",
RTAS_BLK_SIZE, RTAS_BLK_SIZE, 0,
- NULL);
+ 0, RTAS_BLK_SIZE, NULL);
if (!flash_block_cache) {
printk(KERN_ERR "%s: failed to create block cache\n",
__func__);
--
2.40.1
WARNING: multiple messages have this Message-ID (diff)
From: Audra Mitchell <aubaker@redhat.com>
To: linuxppc-dev@lists.ozlabs.org
Cc: aubaker@redhat.com, nathanl@linux.ibm.com, keescook@chromium.org,
npiggin@gmail.com, linux-kernel@vger.kernel.org,
linux-hardening@vger.kernel.org
Subject: [PATCH] Update creation of flash_block_cache to accout for potential panic
Date: Mon, 28 Aug 2023 16:54:53 -0400 [thread overview]
Message-ID: <20230828205453.307962-1-aubaker@redhat.com> (raw)
With PPC builds enabling CONFIG_HARDENED_USERCOPY, interacting with the RunTime
Abstraction Services (RTAS) firmware by writing to
/proc/powerpc/rtas/firmware_flash will end up triggering the mm/usercopy.c:101
assertion:
[ 38.647148] rw /proc/powerpc/rtas/firmware_flash
[ 38.650254] usercopy: Kernel memory overwrite attempt detected to SLUB object 'rtas_flash_cache' (offset 0, size 34)!
[ 38.650264] ------------[ cut here ]------------
[ 38.650264] kernel BUG at mm/usercopy.c:101!
[ 38.650267] Oops: Exception in kernel mode, sig: 5 [#1]
[ 38.650283] LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA pSeries
[ 38.650287] Modules linked in: binfmt_misc loop rfkill bonding tls sunrpc pseries_rng drm fuse drm_panel_orientation_quirks xfs libcrc32c sd_mod t10_pi sg ibmveth ibmvscsi scsi_transport_srp vmx_crypto
[ 38.650306] CPU: 0 PID: 12898 Comm: echo Kdump: loaded Not tainted 5.14.0-299.el9.ppc64le #1
[ 38.650311] NIP: c00000000056d870 LR: c00000000056d86c CTR: c000000000886090
[ 38.650314] REGS: c0000000ba6e78c0 TRAP: 0700 Not tainted (5.14.0-299.el9.ppc64le)
[ 38.650318] MSR: 8000000000029033 <SF,EE,ME,IR,DR,RI,LE> CR: 28002203 XER: 20040000
[ 38.650326] CFAR: c0000000001f76fc IRQMASK: 0
[ 38.650326] GPR00: c00000000056d86c c0000000ba6e7b60 c000000002b15a00 0000000000000069
[ 38.650326] GPR04: c000000fff447f90 c000000fff4ccd00 000000000000000f 0000000000000027
[ 38.650326] GPR08: 0000000000000000 c000000fff44adc0 0000000ffd2f0000 0000000000002000
[ 38.650326] GPR12: 6174722720746365 c000000002ea0000 0000000000000000 0000000000000000
[ 38.650326] GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
[ 38.650326] GPR20: 0000000000000000 0000000000000000 0000000000000002 0000000000000001
[ 38.650326] GPR24: 0000000000000000 000000012eef55a0 c0000000025f39e0 c0000000b988d000
[ 38.650326] GPR28: c0000000b988d022 0000000000000022 0000000000000000 c00000000134d6e8
[ 38.650366] NIP [c00000000056d870] usercopy_abort+0xb0/0xc0
[ 38.650373] LR [c00000000056d86c] usercopy_abort+0xac/0xc0
[ 38.650377] Call Trace:
[ 38.650379] [c0000000ba6e7b60] [c00000000056d86c] usercopy_abort+0xac/0xc0 (unreliable)
[ 38.650384] [c0000000ba6e7be0] [c0000000005178f0] __check_heap_object+0xf0/0x120
[ 38.650389] [c0000000ba6e7c00] [c00000000056d5e0] check_heap_object+0x1f0/0x220
[ 38.650394] [c0000000ba6e7c40] [c00000000056d6a0] __check_object_size+0x90/0x1b0
[ 38.650399] [c0000000ba6e7c80] [c0000000000462fc] rtas_flash_write+0x11c/0x2b0
[ 38.650404] [c0000000ba6e7ce0] [c00000000064d2ec] proc_reg_write+0xfc/0x160
[ 38.650409] [c0000000ba6e7d10] [c000000000579e64] vfs_write+0xe4/0x390
[ 38.650413] [c0000000ba6e7d60] [c00000000057a414] ksys_write+0x84/0x140
[ 38.650417] [c0000000ba6e7db0] [c00000000002f314] system_call_exception+0x164/0x310
[ 38.650421] [c0000000ba6e7e10] [c00000000000bfe8] system_call_vectored_common+0xe8/0x278
[ 38.650426] --- interrupt: 3000 at 0x7fff87f3aa34
[ 38.650430] NIP: 00007fff87f3aa34 LR: 0000000000000000 CTR: 0000000000000000
[ 38.650433] REGS: c0000000ba6e7e80 TRAP: 3000 Not tainted (5.14.0-299.el9.ppc64le)
[ 38.650436] MSR: 800000000280f033 <SF,VEC,VSX,EE,PR,FP,ME,IR,DR,RI,LE> CR: 42002408 XER: 00000000
[ 38.650446] IRQMASK: 0
This used to be caught with a warning in __check_heap_object to allow impacted
drivers time to update to kmem_cache_create_usercopy, but commit 53944f171a89d
("mm: remove HARDENED_USERCOPY_FALLBACK") removed that check. To resolve this
issue, update the creation of the flash_block_cache to use
kmem_cache_create_usercopy with a default size of RTAS_BLK_SIZE.
Signed-off-by: Audra Mitchell <aubaker@redhat.com>
---
arch/powerpc/kernel/rtas_flash.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kernel/rtas_flash.c b/arch/powerpc/kernel/rtas_flash.c
index a99179d83538..0a156a600f31 100644
--- a/arch/powerpc/kernel/rtas_flash.c
+++ b/arch/powerpc/kernel/rtas_flash.c
@@ -710,9 +710,9 @@ static int __init rtas_flash_init(void)
if (!rtas_validate_flash_data.buf)
return -ENOMEM;
- flash_block_cache = kmem_cache_create("rtas_flash_cache",
+ flash_block_cache = kmem_cache_create_usercopy("rtas_flash_cache",
RTAS_BLK_SIZE, RTAS_BLK_SIZE, 0,
- NULL);
+ 0, RTAS_BLK_SIZE, NULL);
if (!flash_block_cache) {
printk(KERN_ERR "%s: failed to create block cache\n",
__func__);
--
2.40.1
next reply other threads:[~2023-08-28 20:56 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-28 20:54 Audra Mitchell [this message]
2023-08-28 20:54 ` [PATCH] Update creation of flash_block_cache to accout for potential panic Audra Mitchell
2023-08-28 21:02 ` Nathan Lynch
2023-08-28 21:02 ` Nathan Lynch
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=20230828205453.307962-1-aubaker@redhat.com \
--to=aubaker@redhat.com \
--cc=christophe.leroy@csgroup.eu \
--cc=keescook@chromium.org \
--cc=linux-hardening@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mpe@ellerman.id.au \
--cc=nathanl@linux.ibm.com \
--cc=npiggin@gmail.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.