Le 12/12/2022 à 04:52, Nicholas Piggin a écrit : > On Sun Dec 11, 2022 at 11:19 PM AEST, wrote: >> https://bugzilla.kernel.org/show_bug.cgi?id=214913 >> >> --- Comment #7 from Zorro Lang (zl...@redhat.com) --- >> (In reply to Michael Ellerman from comment #5) >>> Sorry I don't have any idea which commit could have fixed this. >>> >>> The process that crashed was "fsstress", do you know if it uses io_uring? >> >> Yes, fsstress has io_uring read/write operations. And from the kernel .config >> file(as attachment), the CONFIG_IO_URING=y > > The task being dumped seems like it's lost its task->thread.regs. The > NULL pointer is here: > > int tm_cgpr_active(struct task_struct *target, const struct user_regset > *regset) > { > if (!cpu_has_feature(CPU_FTR_TM)) > return -ENODEV; > > if (!MSR_TM_ACTIVE(target->thread.regs->msr)) > return 0; > > return regset->n; > } > > On that regs->msr deref. r9 contains the regs pointer. > > The kernel attempt to read user page - exploit attempt? message is > I think a red herring it's coming up because of the NULL deref I > think (I thought we fixed that). >
No we didn't fix that, my patch was rejected see https://patchwork.ozlabs.org/project/linuxppc-dev/patch/8b865b93d25c15c8e6d41e71c368bfc28da4489d.1606816701.git.christophe.le...@csgroup.eu/ The reason for the rejection was: The first page can be mapped if mmap_min_addr is 0. Blocking all faults to the first page would potentially break any program that does that. Also if there is something mapped at 0 it's a good chance it is an exploit attempt :) Christophe