[Bug 214913] [xfstests generic/051] BUG: Kernel NULL pointer dereference on read at 0x00000108 NIP [c0000000000372e4] tm_cgpr_active+0x14/0x40
Christophe Leroy
christophe.leroy at csgroup.eu
Mon Dec 12 18:30:52 AEDT 2022
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 (zlang at 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.leroy@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
More information about the Linuxppc-dev
mailing list