From: "Nicholas Piggin" <npiggin@gmail.com>
To: "Benjamin Gray" <bgray@linux.ibm.com>,
"Erhard F." <erhard_f@mailbox.org>,
<linuxppc-dev@lists.ozlabs.org>
Subject: Re: Bug: Write fault blocked by KUAP! (kernel 6.2-rc6, Talos II)
Date: Fri, 03 Feb 2023 12:45:40 +1000 [thread overview]
Message-ID: <CQ8L0O2CYDIX.8HICM7H2PCMN@bobo> (raw)
In-Reply-To: <5f0714428e4c696e3d5c00f3bafb4d2970cb6e2b.camel@linux.ibm.com>
On Fri Feb 3, 2023 at 12:02 PM AEST, Benjamin Gray wrote:
> On Fri, 2023-02-03 at 00:46 +0100, Erhard F. wrote:
> > Happened during boot:
> >
> > [...]
> > Creating 6 MTD partitions on "flash@0":
> > 0x000000000000-0x000004000000 : "PNOR"
> > 0x000001b21000-0x000003921000 : "BOOTKERNEL"
> > 0x000003a44000-0x000003a68000 : "CAPP"
> > 0x000003a88000-0x000003a89000 : "VERSION"
> > 0x000003a89000-0x000003ac9000 : "IMA_CATALOG"
> > 0x000003e10000-0x000004000000 : "BOOTKERNFW"
> > BTRFS info: devid 1 device path /dev/root changed to /dev/nvme0n1p3
> > scanned by systemd-udevd (387)
> > Kernel attempted to write user page (aa55c280000) - exploit attempt?
> > (uid: 0)
> > ------------[ cut here ]------------
> > Bug: Write fault blocked by KUAP!
KUAP is a red herring of course, the KUAP test just checks if the
faulting address is below TASK_SIZE.
[snip]
> > --- interrupt: 300 at __patch_instruction+0x50/0x70
> > NIP: c000000000064670 LR: c000000000064c2c CTR: c000000000048ee0
> > REGS: c000000023b57630 TRAP: 0300 Tainted: G T
> > (6.2.0-rc6-P9)
> > MSR: 900000000280b032 <SF,HV,VEC,VSX,EE,FP,ME,IR,DR,RI> CR:
> > 24222244 XER: 00000000
> > CFAR: c00000000006462c DAR: 00000aa55c280000 DSISR: 42000000 IRQMASK:
^^^^ ^^
First byte of page, store, no PTE.
> > 1
> > GPR00: 0000000000000000 c000000023b578d0 c000000000e7cc00
> > c00800000ce33ffc
> > GPR04: 041ae13000000000 00000aa55c27fffc 0000000000000000
^^^^
Last word of previous page.
Probably from create_stub function descriptor patching, which is not
actually patching in an instruction so it probably gets unlucky and
gets some data that matches prefix opcode and so it tries to store
8 bytes.
So not your bug, your temp mm code just exposed it. Data shouldn't
be patched using patch_instruction. We should have a patch_data_u32
or similar that doesn't use instructions.
Thanks,
Nick
next prev parent reply other threads:[~2023-02-03 2:46 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-02 23:46 Bug: Write fault blocked by KUAP! (kernel 6.2-rc6, Talos II) Erhard F.
2023-02-03 2:02 ` Benjamin Gray
2023-02-03 2:45 ` Nicholas Piggin [this message]
2023-02-09 7:21 ` Christophe Leroy
2023-02-16 15:20 ` Erhard F.
2023-02-03 10:46 ` Erhard F.
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=CQ8L0O2CYDIX.8HICM7H2PCMN@bobo \
--to=npiggin@gmail.com \
--cc=bgray@linux.ibm.com \
--cc=erhard_f@mailbox.org \
--cc=linuxppc-dev@lists.ozlabs.org \
/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;
as well as URLs for NNTP newsgroup(s).