Re: [PATCH] Fix seq_read dead loop and trigger memory allocation failure.

[Fengwei Yin]

On Thu, Apr 24, 2014 at 5:58 AM, Al Viro <viro@xxxxxxxxxxxxxxxxxx> wrote:
> On Mon, Apr 21, 2014 at 10:12:42PM +0800, Fengwei Yin wrote:
>> When dump /proc/xxx/maps, if d_path return error in seq_path, the
>> buffer will be exhaust and trigger dead loop in seq_read. Till
>> kmalloc fails with -ENOMEM.
>
> *WHAT* d_path error?  -ENAMETOOLONG, aka. "you've got too little space"?
>
I could check it and get you back. But I suppose it's not this one
because it still  fails even I have buffer with 4M size.

>> @@ -295,8 +295,16 @@ show_map_vma(struct seq_file *m, struct vm_area_struct *vma, int is_pid)
>>        * special [heap] marker for the heap:
>>        */
>>       if (file) {
>> +             size_t sz;
>>               seq_pad(m, ' ');
>> -             seq_path(m, &file->f_path, "\n");
>> +             /* Save current count. Once seq_path return negtive value,
>> +              * we need to restore saved count. Otherwise, seq_path will
>> +              * exhaust the buffer and make seq_read dead loop till
>> +              * m->buff allocation failure.
>> +              */
>> +             sz = m->count;
>> +             if (seq_path(m, &file->f_path, "\n") < 0)
>> +                     m->count = sz;
>
> NAK.  No way in hell.  Any code playing with m->count that way is broken.
> Post the reproducer for that infinite loop; then we'll be able to see
> what triggers an impossible error from d_path().  _That_ is where the bug
> is, assuming it exists at all.

Thanks a lot for checking this.
When I play the Android x86_64 emulator (with 64bit kernel) and cat
the /proc/xxxx/maps (xxxx is a 32bit process id), seq_read return
-ENOMEM.

I tried to reproduce the same issue on a native environment. But
couldn't reproduce it.

I will collect more info and post here.

Regards
Yin, Fengwei
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/