diff options
author | Artem Bityutskiy <artem.bityutskiy@linux.intel.com> | 2013-06-28 14:15:14 +0300 |
---|---|---|
committer | Ben Hutchings <ben@decadent.org.uk> | 2013-07-27 05:34:23 +0100 |
commit | e869332d2e5bb766cc6ac636a5594d2208e11baf (patch) | |
tree | ff0e66ca7c7a61de05782f60a8936e884a4c84d4 /net | |
parent | 8e31a5dc1d911603053b45b63d6f862b1315ed27 (diff) | |
download | lwn-e869332d2e5bb766cc6ac636a5594d2208e11baf.tar.gz lwn-e869332d2e5bb766cc6ac636a5594d2208e11baf.zip |
UBIFS: prepare to fix a horrid bug
commit 33f1a63ae84dfd9ad298cf275b8f1887043ced36 upstream.
Al Viro pointed me to the fact that '->readdir()' and '->llseek()' have no
mutual exclusion, which means the 'ubifs_dir_llseek()' can be run while we are
in the middle of 'ubifs_readdir()'.
First of all, this means that 'file->private_data' can be freed while
'ubifs_readdir()' uses it. But this particular patch does not fix the problem.
This patch is only a preparation, and the fix will follow next.
In this patch we make 'ubifs_readdir()' stop using 'file->f_pos' directly,
because 'file->f_pos' can be changed by '->llseek()' at any point. This may
lead 'ubifs_readdir()' to returning inconsistent data: directory entry names
may correspond to incorrect file positions.
So here we introduce a local variable 'pos', read 'file->f_pose' once at very
the beginning, and then stick to 'pos'. The result of this is that when
'ubifs_dir_llseek()' changes 'file->f_pos' while we are in the middle of
'ubifs_readdir()', the latter "wins".
Reported-by: Al Viro <viro@zeniv.linux.org.uk>
Tested-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Diffstat (limited to 'net')
0 files changed, 0 insertions, 0 deletions