[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