linux-kernel - Re: [PATCH] filp->f_pos not correctly updated in proc_task

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <m17i2okogv.fsf@fess.ebiederm.org>
Date:	Tue, 17 Mar 2009 11:12:48 -0700
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Zhang Le <r0bertz@...too.org>
Cc:	linux-kernel@...r.kernel.org, torvalds@...l.org, alan@...hat.com,
	Alexey Dobriyan <adobriyan@...il.com>,
	Al Viro <viro@...IV.linux.org.uk>
Subject: Re: [PATCH] filp->f_pos not correctly updated in proc_task_readdir

Zhang Le <r0bertz@...too.org> writes:

> filp->f_pos only get updated at the end of the function. Thus d_off of those
> dirents who are in the middle will be 0, and this will cause a problem in
> glibc's readdir implementation, specifically endless loop. Because when overflow
> occurs, f_pos will be set to next dirent to read, however it will be 0, unless
> the next one is the last one. So it will start over again and again.
>
> There is a sample program in man 2 gendents. This is the output of the program
> running on a multithread program's task dir before this patch is applied:
>
> $ ./a.out /proc/3807/task
> --------------- nread=128 ---------------
> i-node#  file type  d_reclen  d_off   d_name
>   506442  directory    16          1  .
>   506441  directory    16          0  ..
>   506443  directory    16          0  3807
>   506444  directory    16          0  3809
>   506445  directory    16          0  3812
>   506446  directory    16          0  3861
>   506447  directory    16          0  3862
>   506448  directory    16          8  3863
>
> This is the output after this patch is applied
>
> $ ./a.out /proc/3807/task
> --------------- nread=128 ---------------
> i-node#  file type  d_reclen  d_off   d_name
>   506442  directory    16          1  .
>   506441  directory    16          2  ..
>   506443  directory    16          3  3807
>   506444  directory    16          4  3809
>   506445  directory    16          5  3812
>   506446  directory    16          6  3861
>   506447  directory    16          7  3862
>   506448  directory    16          8  3863

I'm trying to understand what the problem that glibc
runs into.  Is this the glibc seekdir madness?

Under which conditions have you seen this problem?

The reason I ask is if this is triggered by seekdir and people really
care then the current proc_task_readdir for the /proc/<pid>/task/
directories is not quite sufficient.  As threads come and go the d_off
associated with a specific thread will change.

Which means we probably should be returning:

$ ./a.out /proc/3807/task
--------------- nread=128 ---------------
i-node#  file type  d_reclen  d_off   d_name
  506442  directory    16          1  .
  506441  directory    16          2  ..
  506443  directory    16          3809  3807
  506444  directory    16          3811  3809
  506445  directory    16          3814  3812
  506446  directory    16          3863  3861
  506447  directory    16          3864  3862
  506448  directory    16          3865  3863

Which is slightly better unfortunately it doesn't give us the
guarantee that the d_off will be continually increasing.

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